| 00:00.03 | ``Erik | there's a program called "nirt", it's a console interface to individually fire rays at geometry with text output... maybe that'll be helpful playing with to understand what's in the C structures? |
| 00:00.21 | abhi2011 | ah thats for nirt is for |
| 00:00.32 | abhi2011 | right i ll do that |
| 00:00.49 | ``Erik | "natelies interactive ray tracer" |
| 00:01.10 | ``Erik | starseeker did a lot of work overhauling the documentation for it |
| 00:01.15 | abhi2011 | yes I remember reading that somewhere among the heap of docs :P |
| 00:01.26 | abhi2011 | cool |
| 00:09.32 | ``Erik | okie, I'm heading out, if you have questions, throw 'em out... if no one else answers them, I'll be back on tomorrow morning and try to respond to them all :) |
| 00:16.23 | *** join/#brlcad merzo (~merzo@118-62-132-95.pool.ukrtel.net) |
| 00:21.44 | abhi2011 | right thanks Erik |
| 00:22.24 | abhi2011 | here is the program for getting the BB for geometry in a .g file using only librt : http://bin.cakephp.org/view/570066725 |
| 00:33.23 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) |
| 01:15.46 | CIA-62 | BRL-CAD: 03kunigami * r45779 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c view.c worker.c): added the random, unbuffered mode. it have a strange behaviour: the frame buffer is only painting pixels with x=0, even though I'm passing random values of x ranging from 0 to 511 |
| 01:56.47 | kunigami | In the lines of my commit's comment, I've made some tests with different values of w and h when calling RT. |
| 01:57.05 | kunigami | 512x512: http://dl.dropbox.com/u/1399996/GSoC/RT512x512.png |
| 01:57.22 | kunigami | 128x128: http://dl.dropbox.com/u/1399996/GSoC/RT128x128.png |
| 01:57.37 | kunigami | 300x300: http://dl.dropbox.com/u/1399996/GSoC/RT300x300.png |
| 01:57.49 | kunigami | 64x64: http://dl.dropbox.com/u/1399996/GSoC/RT64x64.png |
| 01:58.58 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca) |
| 01:59.21 | kunigami | One note: the last rendering (64x64) was done in unbuffered mode(because the width is less than 96) |
| 02:01.42 | kunigami | Is this a bug or one is not supposed to use w,h less than 512 in fb mode? |
| 02:04.21 | kunigami | also, when I force rt to use unbuffered mode, it renders a black scene. (512x512) |
| 02:14.31 | CIA-62 | BRL-CAD: 03kunigami * r45780 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed (again) the loop in sh_osl since we are doing multi-samples before calling this shader |
| 06:28.14 | brlcad | kunigami: you're looking at several bugs there |
| 06:28.36 | brlcad | at least two of them related to x11 changes in the past 10 years |
| 06:29.04 | brlcad | first, I don't believe the black one is actually black, it's just not updating |
| 06:29.20 | brlcad | you might see an image if you minimize/restore .. something to cause a redraw |
| 06:30.03 | brlcad | the 128 version is supposed to be "zoomed" where pixels are auto-scaled 4x4 |
| 06:30.33 | brlcad | that used to work, but something has changed, causing it to only draw some subset of duplicated lines |
| 06:31.26 | brlcad | kunigami: one tool you might find useful since you're working in framebuffer land is 'fbserv' .. you can run a persistent framebuffer and send render results to it |
| 06:31.43 | brlcad | fbserv -S1024 0 /dev/ogl & |
| 06:31.50 | brlcad | rt -F0 file.g object |
| 06:33.00 | brlcad | especially for debugging, it helps sort out whether problems are on the sender/drawing side or on the receiving/framebuffer side |
| 06:33.24 | brlcad | abhi2011: nice work! |
| 06:33.43 | brlcad | keep that code around, you'll need it for your project |
| 08:01.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 13:30.36 | brlcad | yawns |
| 13:35.42 | abhi2011 | brlcad: is there any example which shows how to actually move geometry in mged |
| 13:37.15 | brlcad | undoubtedly |
| 13:37.31 | brlcad | the general idea is that you apply a transformation matrix |
| 13:37.31 | abhi2011 | :) |
| 13:37.36 | abhi2011 | yes right |
| 13:37.48 | abhi2011 | so some of the functions fromvmath.h |
| 13:41.26 | brlcad | those are general math macros |
| 13:41.38 | brlcad | maybe helpful, but they don't know about geometry |
| 13:49.01 | brlcad | there is a function table that responds to all entity types and performs operations on them |
| 13:49.18 | brlcad | applying a transformation matrix is the ft_xform() callback |
| 13:49.46 | brlcad | rt_matrix_transform() wraps that into a relatively simple API call |
| 13:50.10 | brlcad | see src/librt/transform.c |
| 13:52.50 | abhi2011 | right thanks, by the ft_xform() callback is called automatically in every rendering cycle like in glut ? |
| 13:58.10 | abhi2011 | ah ok there is a ft_xform for each type of primitive and the proper one is picked from the function pointers table and called using rt_functab[input->idb_type].ft_xform() |
| 14:01.36 | abhi2011 | reminds me of virtual functions in c++ |
| 14:03.19 | brlcad | that's almost exactly what it is, polymorphic behavior in c |
| 14:04.41 | brlcad | you might get a little lost in the logic, but you can see a transformation applied (eventually) in the inside command, src/mged/cmd.c in the cmd_ged_inside() function |
| 14:05.34 | brlcad | calls transform_editing_solid() which calls rt_matrix_transform() |
| 14:06.03 | brlcad | of course, those are all mged logic -- not useful to you other than as reference |
| 14:07.13 | brlcad | it is a good next step, though -- our moss.g sample geometry has a light source in it, try to move that lightsource down to the ground plate |
| 14:14.14 | abhi2011 | right |
| 14:21.02 | CIA-62 | BRL-CAD: 03erikgreenwald * r45781 10/brlcad/trunk/src/rt/do.c: remove unused variable |
| 14:21.32 | CIA-62 | BRL-CAD: 03erikgreenwald * r45782 10/brlcad/trunk/src/rt/view.c: remove unused variable. fix signed/unsigned issue |
| 16:53.33 | *** join/#brlcad Stattrav (~Stattrav@122.164.241.143) |
| 16:53.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 16:55.30 | CIA-62 | BRL-CAD: 03starseeker * r45783 10/brlcad/trunk/src/other/tcl/ (4 files in 2 dirs): |
| 16:55.30 | CIA-62 | BRL-CAD: Start a clean-up of the Tcl cmake logic, backported from experiments in progress |
| 16:55.30 | CIA-62 | BRL-CAD: with building 8.6. This version of the logic allows XCode 4 to successfully |
| 16:55.30 | CIA-62 | BRL-CAD: build Tcl (not sure about older XCode versions). More work is needed to try a |
| 16:55.30 | CIA-62 | BRL-CAD: broader XCode build of BRL-CAD. |
| 17:17.21 | CIA-62 | BRL-CAD: 03bhinesley * r45784 10/brlcad/trunk/src/libged/edit.c: An argument duplication function was checking the (always empty) destination argument for an object before copying, when it should have been checking the source argument |
| 18:03.51 | bhinesley | is there a way to get the apparant coordinates of an object, as offset by matrices, without stepping through the tree and adding all of them up? |
| 18:07.16 | bhinesley | ex: if a shape is at 0,0,0, but it's inside a combination that is at 1,1,1, which is inside another combination drawn at 2,2,2; what's the best way to get "3,3,3" if I have a db_full_path "comb1/comb2/object" |
| 18:16.58 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:44.00 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 19:05.25 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca) |
| 19:38.10 | *** join/#brlcad merzo (~merzo@9-227-132-95.pool.ukrtel.net) |
| 19:49.43 | CIA-62 | BRL-CAD: 03starseeker * r45785 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add M_LIBRARY to tcl, not just tclstub |
| 20:14.13 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca) |
| 21:28.56 | CIA-62 | BRL-CAD: 03bhinesley * r45786 10/brlcad/trunk/src/libged/edit.c: |
| 21:28.56 | CIA-62 | BRL-CAD: Wrote body of edit_translate command (basically a stripped down version of the |
| 21:28.57 | CIA-62 | BRL-CAD: very first translate command I wrote). Removed all dead/obsolete code. A bit |
| 21:28.57 | CIA-62 | BRL-CAD: more work on path/object to coordinate conversion functions, but it's not usable |
| 21:28.57 | CIA-62 | BRL-CAD: yet, and still a WIP. |
| 22:16.55 | CIA-62 | BRL-CAD: 03starseeker * r45787 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add M_LIBRARY for tclsh too |
| 22:35.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:36.43 | kunigami | brlcad: I think I didn't get how to use this framebuffer server. I have no /dev/ogl (maybe because I did not enabled it when installing brlcad?) and running without setting the framebuffer doesn't work |
| 22:56.07 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3042 10/wiki/User:Bhinesley: /* Log */ Logging last couple weeks |
| 23:15.33 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3043 10/wiki/User:Bhinesley: /* General plan */ was outdated |
| 23:16.27 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3044 10/wiki/User:Bhinesley: /* Development timeline (from proposal) */ rename |
| 23:18.53 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3045 10/wiki/User:Bhinesley: /* Who I am */ |
| 23:21.00 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3046 10/wiki/User:Bhinesley: /* Experience */ Not too shabby at Tcl/Tk/Itcl/Itk |
| 23:25.44 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3047 10/wiki/User:Bhinesley: /* GSoC 2011 Project */ |
| 23:26.29 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3048 10/wiki/User:Bhinesley: /* GSoC 2011 Project */ |
| 23:27.53 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:29.00 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3049 10/wiki/User:Bhinesley: /* Log */ grammar: A'int liking "got" none |
| 23:46.19 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) |
