| 00:00.17 | brlcad | the goal, to me, is to get the sim working for the purpose of demonstrating contact/collisions and having objects respond |
| 00:00.51 | brlcad | so I can drop a box onto a ground plane, and watch it tumble after hitting the ground |
| 00:01.01 | abhi2011 | ok |
| 00:01.47 | brlcad | or simulate a virtual brl-cad pool table with accurate friction resistance, spin, n-body collisions |
| 00:02.12 | brlcad | the goal is the sim itself :) |
| 00:02.37 | abhi2011 | ok yes I understand |
| 00:03.37 | abhi2011 | by the way I was trying to have some fun with the current state of the simulate command :P |
| 00:03.44 | abhi2011 | so I was running the simulate command in a tcl loop in mged the other day, and the positions were not getting updated till the loop completes |
| 00:04.02 | abhi2011 | but that I guess is due to the change you mentioned a while back that is required to made |
| 00:04.25 | abhi2011 | before position updates can occur |
| 00:05.39 | brlcad | yep |
| 00:07.00 | brlcad | if you want to see the updates now, you could write a shell script that invokes mged for each iteration and renders a frame |
| 00:08.08 | brlcad | or you could write a tcl proc that invokes your tcl script for just one timestep |
| 00:08.47 | brlcad | iirc -- it should update interactively, just not via the 'source' command |
| 00:10.47 | abhi2011 | ok |
| 00:11.20 | abhi2011 | I noticed the line SET(GEDSIM_LIB libgedsim) was added to the simulate/CMakeLists.txt file |
| 00:11.49 | abhi2011 | so do I still proceed with changing the name of the build target to simulate ? |
| 00:11.59 | abhi2011 | like so : BRLCAD_ADDLIB(simulate "${SIMULATE_SOURCES}" ${BULLET_LIBRARIES}) |
| 00:12.20 | brlcad | same reasonsing still holds true :) |
| 00:13.08 | brlcad | it's not a library, don't want to start a convention for libged commands |
| 00:14.13 | brlcad | it's only being built as a library due to cmake limitations -- and it might still get folded into the parent SOURCES with different rules later |
| 00:14.29 | abhi2011 | yes, ok then I will proceed with the change to the target at both places, libged/simulate/CMakeLists.txt and libged/CMakeLists.txt |
| 00:18.25 | abhi2011 | umm by parent sources you mean mged's code ? |
| 00:18.36 | brlcad | libged |
| 00:18.40 | abhi2011 | oh ok |
| 00:26.00 | CIA-62 | BRL-CAD: 03brlcad * r46423 10/brlcad/trunk/TODO: |
| 00:26.00 | CIA-62 | BRL-CAD: need to create a class that inherits from ON_Brep so we can cleanly implement |
| 00:26.00 | CIA-62 | BRL-CAD: methods that openNURBS intentionally removes. that way we won't have to fork |
| 00:26.00 | CIA-62 | BRL-CAD: and merge changes each time openNURBS is updated, our additions can be managed |
| 00:26.00 | CIA-62 | BRL-CAD: more easily, and our changes can be consolidated. |
| 00:49.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:58.34 | CIA-62 | BRL-CAD: 03brlcad * r46424 10/brlcad/trunk/src/librt/opennurbs_ext.h: if the child node being added is null, do nothing |
| 01:03.24 | CIA-62 | BRL-CAD: 03brlcad * r46425 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: |
| 01:03.24 | CIA-62 | BRL-CAD: so the big crash is happening due to the surfaces being NULL after a call to |
| 01:03.24 | CIA-62 | BRL-CAD: Split(). not yet at all clear how that's happening so add debug abort code, |
| 01:03.24 | CIA-62 | BRL-CAD: return null, and protect against null derefences. would be cleaner to ensure |
| 01:03.24 | CIA-62 | BRL-CAD: that subdivideSurfaceByKnots() will never return NULL (and someone (tm) should |
| 01:03.24 | CIA-62 | BRL-CAD: fix that) but it's not immediately clear to me what the Split() failure means |
| 01:03.25 | CIA-62 | BRL-CAD: yet. |
| 01:13.13 | CIA-62 | BRL-CAD: 03brlcad * r46426 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: ws indent consistency cleanup |
| 01:16.47 | CIA-62 | BRL-CAD: 03brlcad * r46427 10/brlcad/trunk/src/librt/pr.c: why hasn't this missing semicolon caused a build failure before now?? |
| 01:21.35 | abhi2011 | regarding the cmake target changes for simulate, I wanted to confirm that these were the desired changes |
| 01:21.40 | abhi2011 | here is the diff : http://bin.cakephp.org/view/269125967 |
| 01:23.03 | abhi2011 | I removed SET(GEDSIM_LIB libgedsim) as the new target 'simulate' can be directly specified everywhere instead of another variable ${GEDSIM_LIB} ..or ${SIMULATE} |
| 01:23.05 | CIA-62 | BRL-CAD: 03brlcad * r46428 10/brlcad/trunk/src/librt/primitives/ (4 files in 3 dirs): more missing semicolons.. wtf. |
| 01:25.35 | brlcad | abhi2011: most of the devs receive an e-mail for every commit that includes the diff -- if there's a problem, someone will usually say something or fix it |
| 01:26.01 | brlcad | so don't hesitate on committing unless you've not tested it or know it'll break something |
| 01:26.44 | abhi2011 | ok, yes I have tested it, since its the build system, being careful :) |
| 01:30.22 | CIA-62 | BRL-CAD: 03abhi2011 * r46429 10/brlcad/trunk/src/ (3 files in 3 dirs): Changed the name of the simulation sources build target to simulate, removed GEDSIMLIB |
| 01:30.51 | brlcad | being careful is good, but being productive is better ;) |
| 01:31.36 | abhi2011 | true :) |
| 01:31.42 | brlcad | no worries, someone will let you know if it's messed up, and if it is then it definitely is your responsibility to fix (ideal) or revert (if you can't fix it immediately) |
| 01:32.44 | CIA-62 | BRL-CAD: 03brlcad * r46430 10/brlcad/trunk/src/libwdb/pipe.c: aha! it was the (void *)0 change to the runtime-debug disabled mode macros (knew it would catch if-statements, did not expect it to catch missing semis). awesome side effect. :) |
| 01:40.42 | brlcad | woot, raytrace works! |
| 01:45.43 | CIA-62 | BRL-CAD: 03brlcad * r46431 10/brlcad/trunk/src/conv/patch/patch-g.c: last one, another semi missing. |
| 01:57.52 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 01:59.42 | abhi2011 | hmm, trying to find out how you resolved that missing semi colon issue , looking at pipe.c and magic.c, so NO_BOMBING_MACROS is used when runtime debug is disabled ? |
| 02:03.01 | abhi2011 | * is defined |
| 02:03.31 | brlcad | disabling runtime debug sets NO_BOMBING_MACROS (among others) |
| 02:03.53 | brlcad | the macros used to be empty when disabled, so no problem |
| 02:04.06 | brlcad | likewise, when enabled, it was an if {} so no problem |
| 02:04.19 | CIA-62 | BRL-CAD: 03starseeker * r46432 10/brlcad/trunk/src/ (4 files in 4 dirs): Make a stab at a CMake setup for libged commands in subdirectories. |
| 02:04.32 | brlcad | turned into a no-op statement, though, it became a syntax error and the missing semis could be detected |
| 02:08.07 | abhi2011 | brlcad: ok |
| 02:18.45 | CIA-62 | BRL-CAD: 03brlcad * r46433 10/brlcad/trunk/NEWS: |
| 02:18.45 | CIA-62 | BRL-CAD: due to the slew of 'i seemed to encounter bad geometry' messages that print out |
| 02:18.45 | CIA-62 | BRL-CAD: during raytracing, note that the fix for the m1151 geometry that made rt stop |
| 02:18.45 | CIA-62 | BRL-CAD: crashing was probably due to bad geometry. either way, it was a crash case that |
| 02:18.45 | CIA-62 | BRL-CAD: is no longer crashing. |
| 02:32.18 | starseeker | abhi2011: give that a a shot for ged simulate building - I can't test it on this machine (no bullet) but hopefully that will be cleaner |
| 02:33.24 | brlcad | heh, 5 hours to prep if it were single cpu |
| 02:33.30 | brlcad | (nurbs) |
| 02:34.47 | starseeker | winces |
| 03:43.06 | CIA-62 | BRL-CAD: 03starseeker * r46434 10/brlcad/trunk/CMakeLists.txt: Fix comment - we aren't interested in setting for debug on Windows at the moment - usual pattern there is to run from build directory and then create the .exe installer |
| 04:00.59 | CIA-62 | BRL-CAD: 03starseeker * r46435 10/brlcad/trunk/src/libged/CMakeLists.txt: Ah, right - need to format this so that the BRLCAD_ADDLIB macro is OK with it. |
| 04:11.24 | starseeker | there we go - simulate command builds on my home box now |
| 07:19.20 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 07:29.56 | CIA-62 | BRL-CAD: 03jordisayol * r46436 10/brlcad/trunk/sh/make_rpm.sh: Add "ISO-8859-1 75dpi fonts" for fedora rpm building dependency. |
| 09:21.13 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:53.15 | abhi2011 | starseeker: yes the changes built cleanly on my machine as well |
| 11:44.20 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:13.43 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) | |
| 12:36.27 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 12:43.57 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:01.05 | *** join/#brlcad plaes_ (~plaes@gn237.zone.eu) | |
| 14:06.29 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 14:28.28 | *** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:37.35 | brlcad | gmornin peoples! |
| 14:44.25 | *** join/#brlcad CIA-62 (~CIA@cia.atheme.org) | |
| 15:10.03 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:26.57 | abhi2011 | goedemorgen brlcad :P |
| 15:33.16 | abhi2011 | hmm RT_GET_TREE(tp, &rt_uniresource); doesnt appear to be setting a good magic number when I try to create a rt_comb_internal by manually filling up a tree |
| 15:34.44 | abhi2011 | got something like this now : http://bin.cakephp.org/view/151711593 |
| 15:35.39 | abhi2011 | RT_GET_TREE() sets a wierd magic number like ((tp))->magic = 0x91191191 |
| 15:36.02 | abhi2011 | there is probably a version specific marco for setting a valid number |
| 15:47.27 | abhi2011 | will try RT_TREE_INIT(tp); |
| 15:49.57 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 16:18.27 | abhi2011 | brlcad: is there a reason why OP_DB_LEAF is not handled in rt_bound_tree() ? |
| 16:19.06 | abhi2011 | I use it when filling up the values in a rt_comb_internal for primitives |
| 16:28.18 | abhi2011 | tp->tr_l.tl_op = OP_SOLID does not work , and that is the closest case I can see(to primitives) |
| 16:32.24 | abhi2011 | hm, maybe I should start with an union op in the tree |
| 16:48.27 | CIA-62 | BRL-CAD: 03n_reed * r46437 10/brlcad/trunk/src/librt/prep.c: Removed dead code from rt_clean_resource_basic. It was an uncompiled duplication of the code in rt_clean_resource_complete. |
| 17:04.04 | abhi2011 | ok I need to use OP_SOLID and somehow I need to convert the idb_meth member in rt_db_internal * to the a struct soltab *stp; so rt_bound_tree() can get the bb |
| 17:04.22 | abhi2011 | aaaargh....almost there |
| 17:22.29 | CIA-62 | BRL-CAD: 03n_reed * r46438 10/brlcad/trunk/src/librt/shoot.c: rt_res_pieces_clean was dereferencing rtip without checking for NULL value. |
| 17:38.30 | abhi2011 | well it seems the struct soltab is not needed and nor is rt_bound_tree() for primitives, a simple call to ip->idb_meth->ft_bbox(ip, &rpp_min, &rpp_max) suffices for getting the bb of primitives |
| 17:38.33 | CIA-62 | BRL-CAD: 03n_reed * r46439 10/brlcad/trunk/src/conv/obj-g_new.c: Cleaning rt_uniresource after it's no longer needed. |
| 17:52.45 | abhi2011 | its onto regions now |
| 18:29.06 | *** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 18:38.55 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:48.13 | abhi2011 | hmm, no , cant just insert a new OP_DB_LEAF case into rt_bound_tree() , seems even after I reach the leaf, the most information I can get from the leaf node is the name of the primitive, with no other information , like points etc |
| 19:02.47 | abhi2011 | seems a rt_db_internal representing a region has only information about the operations that build the region and the primitive names, not the shape information about the primitives themselves |
| 19:11.58 | CIA-62 | BRL-CAD: 03n_reed * r46440 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser_state.h): indent/ws cleanup |
| 19:13.28 | CIA-62 | BRL-CAD: 03n_reed * r46441 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Applied standard headers and footers. |
| 20:12.29 | starseeker | abhi2011: that bbox interface is brand new, and some of them (BoT for certain) aren't really correct yet |
| 20:12.49 | starseeker | abhi2011: if you want to use that, you probably need to start by fixing rt_bot_bbox |
| 20:15.06 | CIA-62 | BRL-CAD: 03starseeker * r46442 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: stray character |
| 20:18.40 | abhi2011 | starseeker: oh shoot, no easy way out then :P |
| 20:19.21 | starseeker | abhi2011: well, fixing rt_bot_bbox is definitely the right way to go - the intent is for rt_*_bbox routines to be a fast way to get a correct bbox |
| 20:19.58 | starseeker | would suggest looking at what rt_bot_plot does - it can draw lines, so it must have logic for visiting the data structure |
| 20:20.24 | abhi2011 | ok, by the way do you have any idea about the other issue, about the op_db_leaf case |
| 20:20.39 | abhi2011 | i though OP_SOLID would be used uniformly for primtives |
| 20:20.46 | abhi2011 | in the tree nodes I mean |
| 20:21.08 | starseeker | not offhand - would have to study the code, and unfortunately I'm in the middle of house stuff |
| 20:21.16 | starseeker | (nice big storm on the way...) |
| 20:21.30 | abhi2011 | ah yah i heard |
| 20:22.38 | abhi2011 | irene ? |
| 20:26.36 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 20:30.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:43.06 | *** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 22:40.08 | CIA-62 | BRL-CAD: 03n_reed * r46443 10/brlcad/trunk/src/conv/obj-g_new.c: Removed call to perror after syntax error. Error message is already printed elsewhere, and errno is not set. |
| 22:50.51 | CIA-62 | BRL-CAD: 03n_reed * r46444 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Making return codes clear. |
| 22:50.57 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:30.41 | *** part/#brlcad roberthl (~robert@mediawiki/RobertL) | |