| 06:18.08 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:18.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:58.40 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 07:03.34 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:35.41 | d_rossberg | starseeker: the STRICT_FLAGS is a little bit disturbing to MSVC |
| 09:54.36 | *** join/#brlcad Stattrav (~Stattrav@122.178.209.201) | |
| 09:54.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:12.24 | abhi2011 | ok thanks bhinesly and brlcad |
| 10:41.07 | abhi2011 | bhinesley: db_lookup(dbip, argv[2], 1) is correct then as db_lookup works on objects inside the database, and sph1.s is an object inside the sphere.g database |
| 10:41.54 | abhi2011 | however it seems that ged_bb() treats the command line differently from what I expect |
| 10:42.32 | abhi2011 | so I give the db name first and the object name 2nd which is argv[1] and argv[2] respectively |
| 10:43.35 | abhi2011 | but it treats argv[1] also as an object name in the currently open db, so I modified the code to pass argv+1 instead and argc =1, so that only 1 object name (sph1.s) gets passed |
| 10:44.13 | abhi2011 | like this : if ( ged_bb(gedp, 1, argv+1) == GED_OK){.... |
| 10:45.26 | abhi2011 | ged_bb() still doesnt return GED_OK though, so I am checking if something else is going wrong |
| 11:08.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:19.11 | abhi2011 | ok I got the bb now ! |
| 12:19.27 | abhi2011 | but it seems I cant print the bound by just printing the gedp result string |
| 12:19.53 | abhi2011 | so if i try printf("%s\n", gedp->ged_result_str); |
| 12:20.09 | abhi2011 | then i get �;3� !! |
| 12:20.44 | abhi2011 | I ll check if its actually a char* |
| 12:37.46 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:49.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:08.57 | abhi2011 | ah ok its a variable length string to save memory |
| 13:13.12 | abhi2011 | YES!!!...finally got the bb printed :P |
| 13:13.20 | abhi2011 | printf("%s\n", ( ((gedp->ged_result_str)->vls_str) + ((gedp->ged_result_str)->vls_offset) ) ); |
| 13:13.38 | abhi2011 | output is same as in archer for a unit sphere centred at the origin |
| 13:15.39 | abhi2011 | perhaps not the most efficient but works : http://bin.cakephp.org/view/1085618267 |
| 13:46.31 | starseeker | d_rossberg: "disturbing?" |
| 13:52.21 | d_rossberg | MSVC does not know how to handle a "STRICT_FLAGS" compiler switch, so it tries to open a file with this name |
| 13:53.24 | d_rossberg | probable a problem in cmake: not STRICT_FLAGS is meant but its value |
| 13:55.44 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 14:56.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:12.18 | brlcad | abhi2011: so this is going to be a learning experience, but good work figuring out how to print the bb |
| 15:13.21 | brlcad | your end result uses the libged API, which is a very high-level interface |
| 15:13.32 | brlcad | a few "mistakes", one being what you did with ged_result_str |
| 15:13.57 | brlcad | it's a struct bu_vls ... and accessing the internal vls_str and vls_offset is a no-no |
| 15:14.16 | brlcad | there are printing routines for that |
| 15:14.32 | brlcad | you'd either use bu_log() instead of printf() where you can use %V to print them |
| 15:15.11 | brlcad | or you'd call printf() with bu_vls_addr(dedp->ged_result_str) to get the underlying char * |
| 15:16.22 | brlcad | abhi2011: so then the next useful step is to compute the bounding box without calling ged_open() or ged_bb(), using the lower level librt API that libged is using |
| 15:24.05 | CIA-62 | BRL-CAD: 03kunigami * r45767 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): changed the field reflection by ray_type so that it can also represent transmission rays. I hope this way the logic gets clearer |
| 15:40.28 | abhi2011 | brlcad : right will try that |
| 15:43.44 | brlcad | so, db_open(), and other db_*() and rt_*() api calls, no ged_*() functions |
| 15:44.03 | brlcad | that will be what your physics command will need to do |
| 15:44.10 | abhi2011 | yes, that was my other option if libged were not to work, but chose the easy way out first :P |
| 15:44.23 | abhi2011 | yes right |
| 15:44.47 | brlcad | nothing wrong with that approach |
| 15:45.08 | brlcad | and in most other contexts, calling libged would be fine too |
| 15:45.26 | abhi2011 | umm so why not in this case too |
| 15:45.33 | brlcad | if anything, you can read the source for ged_bb() and follow the functions to see how it computes the bb |
| 15:45.42 | abhi2011 | yes i did that |
| 15:45.52 | abhi2011 | i know how to use the librt functions now |
| 15:46.01 | brlcad | so then it should be very clear and trivial to convert ;) |
| 15:46.09 | abhi2011 | yep :) |
| 15:46.25 | brlcad | this case is different because you're also implementing a libged function |
| 15:46.49 | abhi2011 | so we cannot use other libged functions ? |
| 15:47.04 | abhi2011 | that are exported...just curious |
| 15:47.04 | brlcad | ged functions shouldn't be built on other ged functions when the common functionality has already been refactored into librt |
| 15:47.10 | brlcad | it just adds layered complexity |
| 15:47.11 | abhi2011 | ah ok |
| 15:47.22 | abhi2011 | and will introduce delays |
| 15:47.23 | brlcad | as well as slows things down |
| 15:47.25 | brlcad | nods |
| 15:47.27 | abhi2011 | yep |
| 15:47.55 | brlcad | the slow down in negligible for interactive use, but is significant for programmatic use |
| 15:48.14 | abhi2011 | yah...we want real time motion..yay ! |
| 15:48.18 | abhi2011 | :) |
| 15:49.16 | abhi2011 | by the way I was wondering, brl cad was used before my usmil right |
| 15:49.35 | abhi2011 | so they moved on to other software and open sourced this ? |
| 15:50.40 | abhi2011 | I was looking for some of the full forms of the primitives like tgc in google and I came across this : http://www.digitaldogma.org/archive/MikeMuuss/papers/brlcad5.0/html/mged/tableofcontents2_1.html |
| 16:16.49 | *** join/#brlcad survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net) | |
| 16:17.05 | *** part/#brlcad survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net) | |
| 16:21.16 | bhinesley | abhi2011: that makes sense. I was looking for calls directly to db_lookup in your pastbin; I didn't catch that. Glad you got it working. |
| 16:24.39 | abhi2011 | bhinesley: yep, converting to use only rt now |
| 17:22.49 | CIA-62 | BRL-CAD: 03starseeker * r45768 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Was getting too clever for my own good. If ADD_NEW_FLAG comes in empty, don't do anything - should avoid the error on Windows |
| 17:28.03 | CIA-62 | BRL-CAD: 03r_weiss * r45769 10/brlcad/trunk/include/raytrace.h: |
| 17:28.03 | CIA-62 | BRL-CAD: Added an entry into the 'raytrace.h' header for a new function 'nmg_keu_zl' |
| 17:28.03 | CIA-62 | BRL-CAD: which removes all zero length edgeuse from an nmg shell. This function is |
| 17:28.03 | CIA-62 | BRL-CAD: disabled by default and is a work in progress. This function supports the |
| 17:28.03 | CIA-62 | BRL-CAD: prototype version of 'nmg_triangulate_fu'. |
| 17:31.08 | CIA-62 | BRL-CAD: 03r_weiss * r45770 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: |
| 17:31.08 | CIA-62 | BRL-CAD: Added a new function 'nmg_keu_zl' which removes all zero length edgeuse from an |
| 17:31.08 | CIA-62 | BRL-CAD: nmg shell. This was added into file 'nmg_mk.c'. This function is disabled by |
| 17:31.08 | CIA-62 | BRL-CAD: default and supports the prototype version of 'nmg_triangulate_fu'. This is a |
| 17:31.08 | CIA-62 | BRL-CAD: work in progress. |
| 17:42.59 | CIA-62 | BRL-CAD: 03r_weiss * r45771 10/brlcad/trunk/src/librt/primitives/tor/tor.c: (log message trimmed) |
| 17:42.59 | CIA-62 | BRL-CAD: Updated function 'rt_tor_tess' within file 'src/librt/primitives/tor/tor.c' by |
| 17:42.59 | CIA-62 | BRL-CAD: adding a call to function 'nmg_keu_zl' which removes all zero length edgeuse. |
| 17:42.59 | CIA-62 | BRL-CAD: Under certain conditions the function 'rt_tor_tess' will create a tessellated |
| 17:42.59 | CIA-62 | BRL-CAD: torus which contains zero length edgeuse which is invalid and causes a crash in |
| 17:43.00 | CIA-62 | BRL-CAD: later functions. An example of a torus which causes a crash during 'facetize' is |
| 17:43.00 | CIA-62 | BRL-CAD: object 'old.s82' within the 'm35.g' sample model. This change is disabled by |
| 18:18.57 | CIA-62 | BRL-CAD: 03kunigami * r45772 10/brlcad/trunk/src/rt/view.c: added a dedicated buffer to keep partial sums on multi-sample modes |
| 18:24.54 | CIA-62 | BRL-CAD: 03kunigami * r45773 10/brlcad/trunk/src/rt/view.c: had left behind a debug message |
| 18:27.20 | ``Erik | mysql removed from osX.7, nice |
| 19:04.33 | CIA-62 | BRL-CAD: 03brlcad * r45774 10/brlcad/trunk/include/vmath.h: add missing zero macros, HNEAR_ZERO(), VZERO(), V2ZERO(), & HZERO() |
| 19:04.43 | CIA-62 | BRL-CAD: 03r_weiss * r45775 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 19:04.43 | CIA-62 | BRL-CAD: Added new functions 'print_loopuse_tree', 'nmg_classify_pt_loop_new', |
| 19:04.43 | CIA-62 | BRL-CAD: 'nmg_classify_lu_lu_new', 'insert_above', 'insert_node' and |
| 19:04.43 | CIA-62 | BRL-CAD: 'nmg_build_loopuse_tree' to file 'nmg_tri.c'. These function are prototype |
| 19:04.44 | CIA-62 | BRL-CAD: functions which support the prototype version of 'nmg_triangulate_fu'. Some of |
| 19:04.44 | CIA-62 | BRL-CAD: these functions may have their names changed or moved to a more appropriate |
| 19:04.45 | CIA-62 | BRL-CAD: location within the code. These functions are the beginning of code which |
| 19:05.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:20.56 | brlcad | kunigami: it might be beneficial in the long run to use a long or floating point accumulation buffer |
| 19:21.31 | kunigami | yup I'm using long |
| 19:21.47 | brlcad | awesome, missed that ;) |
| 19:24.41 | brlcad | that means we'll be able to accumulate about 16M passes before the buffer is "full" (at 32-bit) .. that's a lot of hypersampling ;) |
| 19:25.59 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:27.04 | kunigami | when adding inside sh_osl, I could have values greater than 1.0, but with averages bellow 1.0. Thus, it was not "clamped". now, if I have any component greater than 1.0, it will be clamped and the average will be near 0 if the other components are 0. I have a test Scenesthat relies on strong brightnes. It was rendered nicely before, but now it is too dark. Would be wrong if I avoid clamping the components of the sum, but only the sum itself? |
| 19:38.58 | brlcad | kunigami: if I understand you correctly (and I'm not 100% sure that I do), then yes.. you can use the buffer as an accumulation buffer and clamp/average/downsample at some later processing stage |
| 19:42.24 | brlcad | for hypersampling, for example, instead of accumulating "value/#rays" for each hypersample ray (i.e. val/#rays * #rays => final_value), it would accumulate "value" as-is (resulting in "value * #rays" in the buffer), then divide by the #rays at the end or scale to 255 or whatever |
| 19:45.46 | CIA-62 | BRL-CAD: 03brlcad * r45776 10/brlcad/trunk/BUGS: a torus with a zero sized inner diameter results in zero-length edges during tessellation. nmg_keu_zl() could remove them, but it implies there is a flaw in the rt_tor_tess() logic not accounting for the edge case. |
| 19:46.43 | brlcad | kunigami: did my response make sense about the two different options? |
| 19:50.42 | kunigami | brlcad: yes, that makes sense. I'll do the same way as hypersampling, thanks |
| 20:40.49 | *** join/#brlcad merzo (~merzo@59-47-132-95.pool.ukrtel.net) | |
| 21:26.36 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:46.33 | CIA-62 | BRL-CAD: 03kunigami * r45777 10/brlcad/trunk/src/rt/ (do.c view.c): changed the accumulator buffer to float so that it saves the raw components of ap.a_color before theyre clamped. We only expand and clamp it when moving the partial sums to scanline |
| 22:01.47 | *** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 22:14.43 | abhi2011 | so I am trying to get the bb now using librt only |
| 22:14.52 | abhi2011 | here is the code so far : http://bin.cakephp.org/view/570066725 |
| 22:15.12 | abhi2011 | I run it as ./a.out dome.g sph2.s rcc2.s |
| 22:15.34 | abhi2011 | the objects are present in the dome.g database file as I can see them in archer |
| 22:15.58 | abhi2011 | yet : db_lookup(sph2.s) failed: sph2.s does not exist |
| 22:16.07 | abhi2011 | so I am debugging with gdb now |
| 22:16.53 | abhi2011 | and I saw that inside db_lookup there is a line that tries to hash the name 'sph2.s' (when its being looked up) |
| 22:17.56 | abhi2011 | line 230 : dp = dbip->dbi_Head[db_dirhash(name)]; |
| 22:18.38 | abhi2011 | the hash for 'sph2.s' is 747 which is why dbip->dbi_Head[db_dirhash(name)]; returns null and consequently the lookup fails |
| 22:23.15 | abhi2011 | probably the hash value can be anything, but perhaps its out of range in this case of the array dbi_Head[] |
| 22:31.29 | abhi2011 | perhaps its because the objects sph2.s and rcc2.s are leaves, that is they are not children of higher levels groups |
| 23:01.48 | abhi2011 | probaly the directory is not built up already as in the rtexample.c |
| 23:13.24 | abhi2011 | ok easier to use rtip = rt_dirbuild(argv[1], title, sizeof(title)); |
| 23:13.47 | abhi2011 | and rt_gettree(rtip, argv[2]) with bb calculated using rt_prep_parallel(rtip, 1); |
| 23:24.19 | ``Erik | *reads he pastebin* yeah, you do need an rt_prep somewhere in there, that's where the bb gets set |
| 23:25.28 | abhi2011 | well yes, but I did not reach that far in that code, the db_lookup() called from db_string_to_path() in line 50, barfed well before that ! |
| 23:25.40 | abhi2011 | I guess cause there was no directory built up |
| 23:26.14 | abhi2011 | this command would normally get called from inside mged when rtip would have a valid directory setup containing the structure of the model |
| 23:26.44 | abhi2011 | but for the command line program its probably not so, so I have to start by calling rt_dirbuild() |
| 23:27.36 | ``Erik | hm, yeah (not too familiar with the very early stages of opening/parsing a .g, myself), I think you're right |
| 23:28.23 | ``Erik | some of the src/conv/ programs use prepared geometry and are quite a bit simpler than the src/rt stuff... might be worth poking around in there for examples |
| 23:28.49 | CIA-62 | BRL-CAD: 03bhinesley * r45778 10/brlcad/trunk/src/libged/edit.c: |
| 23:28.49 | CIA-62 | BRL-CAD: Started on functions that convert db_full_path objects to points (natural |
| 23:28.49 | CIA-62 | BRL-CAD: origin/bounding box center); WIP. edit() was getting a bit difficult to read, |
| 23:28.49 | CIA-62 | BRL-CAD: which has led to several bugs, so I broke out batch expansion code into |
| 23:28.49 | CIA-62 | BRL-CAD: edit_arg_expand(). There are still some problems preventing this from working, |
| 23:28.50 | CIA-62 | BRL-CAD: but I haven't commited in a while and need to. Several changes to struct |
| 23:28.51 | CIA-62 | BRL-CAD: edit_arg helper functions; needed more versatility |
| 23:29.07 | abhi2011 | ah ok, umm why the 'conv' are they converted from some other library or something ? |
| 23:30.05 | ``Erik | converting between formats |
| 23:30.38 | bhinesley | abhi2011, the HACKING file tells you what the major directories are for |
| 23:31.05 | ``Erik | g-shell-rect.c fires rays to solve new geometry |
| 23:31.35 | ``Erik | um, also; the rtcmp toplevel project has an rt directory with a VERY minimal and simple example of how to get rt firing rays at geometry |
| 23:33.09 | abhi2011 | ah yes right thanks Erik and bhinesley |
| 23:33.13 | ``Erik | which is rt_dirbuild(); rt_gettree(); rt_prep_parallel(); |
| 23:34.45 | abhi2011 | the rtcmp sounds interesting, will have a look |
| 23:36.01 | ``Erik | it's minimal and hackish, was to compare performance/correctness between 3 raytracing engines |
| 23:36.14 | ``Erik | not "production" code :) |
| 23:36.57 | abhi2011 | ok, yah I just need a quick intro to raytracing using brlcad |
| 23:40.13 | ``Erik | http://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030&view=markup |
| 23:40.52 | ``Erik | that's about as simple as it gets... the hit() function is a bit more than you might need, but the rest... :) |
| 23:47.00 | abhi2011 | hmm I understand most of it except the hit function |
| 23:47.22 | abhi2011 | seems its partitioning the 3d space around the point where the ray hit some geometry |
| 23:47.46 | abhi2011 | and calculating the outward pointing normal at that point on its surface....wild guess |
| 23:48.45 | ``Erik | yeah, rt_shootray() needs hit and miss callbacks set in the application structure and calls one of them depending on what happened |
| 23:49.00 | ``Erik | the hit function gets fed a boolean evaluated "partition list" |
| 23:49.28 | ``Erik | my hit() function there is solving normals and repacking the results into a different partition list format (for comparison) |
| 23:50.00 | ``Erik | if a_onehit is set, it'll only fill the first partition, useful for visual raytracing |
| 23:50.36 | abhi2011 | ok so these partitions represent cubiodal regions in 3d space ? |
| 23:51.29 | abhi2011 | i am thinking in terms of partitioning of the 3d space into 8 different regions around a point |
| 23:51.47 | abhi2011 | around the 3 axes |
| 23:52.06 | ``Erik | no, they're segments along the ray where it intersects geometry |
| 23:52.26 | abhi2011 | ah ok |
| 23:52.41 | abhi2011 | so some segments will be inside the geomtry and some outside |
| 23:53.06 | abhi2011 | which can be decided using the equation of a sphere for example if a sphere is the geometry |
| 23:53.28 | ``Erik | it does boolean evaluation before generating the partition list (using the boolweave() function in rt), so that's actual solid geometry in those partitions |
| 23:54.02 | abhi2011 | ok |
| 23:54.36 | ``Erik | if you have a 1 radius sphere at the origin and subtract an arb8 that's across an origin plane and shoot perpendicular to that plane, you'll see a partition that says "I hit a sphere from 1,0,0 to 0,0,0" |
| 23:54.47 | ``Erik | is that confusing enough? :D |
| 23:56.02 | abhi2011 | no I am getting it slowly :P, but I am familiar with all the short forms of the primitves yet, so arb8 is a rectangle or a plane ? |
| 23:56.19 | abhi2011 | *not familiar |
| 23:56.19 | ``Erik | arb8 is a box |
| 23:56.22 | abhi2011 | ok |
| 23:57.04 | abhi2011 | right i get it |
| 23:57.32 | abhi2011 | but wait we have subtracted an arb8 |
| 23:57.36 | ``Erik | http://brlcad.org/gallery/d/170-2/primitives.png |
| 23:57.48 | abhi2011 | so there is a hollow region inside the sphere |
| 23:57.56 | ``Erik | well, a sphere cut in half |
| 23:58.04 | abhi2011 | ah yes right |
| 23:58.42 | abhi2011 | ah cool thats handy |
