| 00:02.17 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 01:41.26 | abhi2011 | starseeker: is the header simphysics.h not required to be mentioned in the CMakeLists.txt file for libged ? |
| 01:42.18 | abhi2011 | I am trying to add a new source and header in the simulate command, and I think only the cpp file needs to be included in the libged/CMakeLists.txt file |
| 01:42.23 | abhi2011 | at SET(ged_ignore_files simulate/simphysics.cpp simulate/simulate.c) |
| 01:43.50 | abhi2011 | so I ll change it to SET(ged_ignore_files simulate/simphysics.cpp simulate/simulate.c simulate/simcollisionalgo.cpp simulate/simcollisionalgo.h) |
| 03:14.02 | brlcad | abhi2011: how'd that new render animation turn out? |
| 03:14.26 | brlcad | was showing a bunch of folks your previous animation earlier this week, they love it! :) |
| 03:14.39 | abhi2011 | yes it turned out fine |
| 03:14.49 | abhi2011 | I ll make a movie over the night today :) |
| 03:15.42 | abhi2011 | pentium dual core :P |
| 03:25.14 | ``Erik | abhi: if you have something scriptable you can give us, we can throw a LOT of cpu into making you up a movie |
| 03:26.23 | ``Erik | like a stack of 16 core xeons :) |
| 03:54.14 | abhi2011 | oh wow! |
| 03:54.25 | abhi2011 | umm but u wud need bullet installed and working too |
| 03:54.50 | abhi2011 | which reminds me, does the simulate command work on any other system correctly |
| 03:55.21 | abhi2011 | also I have got a database and 2 tcl scripts |
| 03:55.45 | abhi2011 | so I ll put these in the samples and tclscripts folders if i want to share it ? |
| 03:59.43 | abhi2011 | well database not needed actually, since the script can be run from a new database and creates everything |
| 04:00.23 | abhi2011 | right, so i ll give clean up the script and pastebin it for now |
| 05:02.56 | CIA-133 | BRL-CAD: 03abhi2011 * r46728 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simcollisionalgo.h): Added 2 files for containing a RT based contact manifold generator |
| 05:26.35 | abhi2011 | ok here is the tcl script for generating the scene : http://bin.cakephp.org/view/350938158 |
| 05:35.14 | abhi2011 | := |
| 05:36.08 | abhi2011 | and here is the shell script |
| 05:40.17 | abhi2011 | http://bin.cakephp.org/view/572543350 |
| 06:07.42 | CIA-133 | BRL-CAD: 03abhi2011 * r46729 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simphysics.cpp simulate/simulate.c): Began rt integration into the bullet collision pipeline, added callback to show aabb overlaps and contact points |
| 06:27.02 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3164 10/wiki/User:Abhijit: /* Log */ |
| 06:28.47 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3165 10/wiki/User:Abhijit: /* Log */ |
| 06:38.56 | abhi2011 | the minute i submit the shell script the laptop fan ramps up a few notches |
| 06:38.58 | abhi2011 | :P |
| 12:47.28 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 13:04.43 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 13:23.00 | brlcad | senses a big remrt session in his near future |
| 13:45.43 | ``Erik | abhi: is it possible to run a bullet simulation and export a series of 'geometry at time X' definitions? so a single machine can generate the 2000 or so 'states' to be farmed out for raytracing? |
| 13:48.23 | brlcad | pretty impressive scripting |
| 13:49.16 | brlcad | ``Erik: he's not here right now, but it is possible -- his script could just call clone before running simulate |
| 13:50.35 | brlcad | then his rt script could be issued for all 2000 frames at once for remrt instead of one at a time (which will kick rt into multi-frame render mode to make sure there isn't temporal tearing across frames) |
| 13:57.41 | ``Erik | cool (didn't think he was here, but y'know, post and wait) |
| 14:21.00 | CIA-133 | BRL-CAD: 03d_rossberg * r46730 10/brlcad/trunk/CMakeLists.txt: |
| 14:21.00 | CIA-133 | BRL-CAD: a non visible function prototype yields a warning "warning C4013: 'hypot' undefined; assuming extern returning int" => turned the warnings into errors |
| 14:21.00 | CIA-133 | BRL-CAD: a possible consequence of missing prototypes is a floating point stack overflow (as it happened in this case) |
| 14:54.59 | brlcad | ouch |
| 15:17.24 | CIA-133 | BRL-CAD: 03tbrowder2 * r46731 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: corrected image file references for cuurent file structure |
| 15:27.44 | *** join/#brlcad b0ef (~b0ef@166.195.251.212.customer.cdi.no) |
| 15:29.20 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r3166 10/wiki/ESA_Summer_of_Code_in_Space: update with post-selection details -- link to abhijit's log |
| 15:45.24 | brlcad | where's the b0ef! |
| 15:59.05 | CIA-133 | BRL-CAD: 03tbrowder2 * r46732 10/brlcad/trunk/doc/docbook/fop.xconf.in: get the base URL for fop back to its rightful place |
| 16:23.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 17:04.37 | CIA-133 | BRL-CAD: 03tbrowder2 * r46733 10/brlcad/trunk/README.cmake: some more details for newbies |
| 17:32.28 | brlcad | hm, not so fond of so much irrelevant info before getting to the heart of the readme .. |
| 17:35.19 | brlcad | jordisayol: thx for being patient :) |
| 17:35.25 | brlcad | he's learning |
| 17:35.40 | jordisayol | brlcad: I see |
| 17:35.44 | jordisayol | :-) |
| 18:22.22 | abhi2011 | any luck running those scripts on the server |
| 18:25.43 | CIA-133 | BRL-CAD: 03tbrowder2 * r46734 10/brlcad/trunk/doc/docbook/articles/en/pipes.xml: adding unicode point for two symbols |
| 18:26.46 | brlcad | abhi2011: was looking them over earlier today while you were out |
| 18:27.19 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) |
| 18:27.24 | yukonbob | hello, #brlcad |
| 18:27.29 | brlcad | abhi2011: nice work, btw .. impressive scripting pulling things together exactly the way they're supposed to be |
| 18:27.34 | brlcad | howdy yukonbob |
| 18:27.58 | yukonbob | hey brlcad -- how're things? |
| 18:28.34 | brlcad | abhi2011: with only a few modifications, those two scripts will work pretty well for setting up a completely distributed rendering |
| 18:29.29 | brlcad | yukonbob: good as ever, lots of skewers in the fire |
| 18:29.40 | brlcad | what are you working on these days? |
| 18:30.13 | abhi2011 | brlcad: yep learning :) |
| 18:30.43 | yukonbob | head-down in Tcl/C whenever I can, and started w/ Apache working on Tcl bindings for search-engine-in-development |
| 18:30.55 | yukonbob | <-- bch@apache.org :) |
| 18:30.57 | abhi2011 | so what modifications would u do for distributed rendering ? |
| 18:31.03 | brlcad | abhi2011: for the distributed render, you'd want to clone each object before running simulate so that you keep all timestep revisions, then make the rt script one *mega* script that renders all frames in sequence with only one call to rt |
| 18:31.30 | yukonbob | poking at my local brlcad/tcl/nbsd integration when I get chances... |
| 18:31.56 | brlcad | that will kick rt into a video-rendering mode where it becomes frame-aware and can apply tricks to make the frame-by-frame output better |
| 18:32.23 | yukonbob | and actually stumbled on an omission on my part that should help push that ahead -- took a while to get a version a few months old up/running, and now need to do a smaller leap fwd and getting running w/ latest brlcad code again... |
| 18:32.52 | brlcad | then it's as simple as copying the db to your render clients, replacing 'rt' with 'rtsrv' and running remrt some place to collect all of the results |
| 18:33.00 | abhi2011 | oh ok, so as I understand you generate all the different position the objects are in by running simulate for 1 step, 2 steps , 3steps.....300 steps and record them in different dbs |
| 18:33.12 | abhi2011 | so 300 dbs |
| 18:33.14 | brlcad | they can be in the same db |
| 18:33.21 | abhi2011 | ah yes right |
| 18:33.25 | abhi2011 | but with different names |
| 18:33.26 | brlcad | scene.001 scene.002 .. whatever |
| 18:33.41 | abhi2011 | oh the db supports scenes too |
| 18:33.45 | abhi2011 | didnt know that |
| 18:33.56 | yukonbob | <PROTECTED> |
| 18:34.37 | brlcad | abhi2011: you'll notice in rt script that it has a bunch of lines starting with viewsize, then start 0; clean; |
| 18:34.51 | abhi2011 | yes right |
| 18:34.58 | brlcad | that actually is a command to start frame 0 .. |
| 18:35.15 | abhi2011 | ok |
| 18:35.17 | brlcad | so after clean, you can load the next object, start 1, etc |
| 18:35.27 | abhi2011 | ok |
| 18:35.55 | brlcad | pretty much exactly what you have, just pulling the rt command outside that for loop |
| 18:35.56 | abhi2011 | and by default..the way I have been working with mged so far, that just creates 1 scene : scene 0 and puts everyting there |
| 18:36.02 | brlcad | and building up the command inside the for loop |
| 18:36.38 | abhi2011 | ok |
| 18:37.05 | brlcad | abhi2011: another thing I noticed is the hard-coded hack you have in there for knowing what is what in the db :) |
| 18:37.25 | abhi2011 | in the c code ? |
| 18:37.33 | brlcad | for starters, you should pass the list of objects to be simulated as a parameter to the simulate command :) |
| 18:37.37 | brlcad | yeah |
| 18:37.41 | abhi2011 | ok |
| 18:37.52 | abhi2011 | ah yes right |
| 18:38.01 | brlcad | sim_gp.r :) |
| 18:38.19 | abhi2011 | yeah that needs more flexibility :P |
| 18:38.21 | brlcad | that way you know which object(s) to work on |
| 18:38.42 | abhi2011 | so all the objects to be simulated get passed as paramters |
| 18:39.03 | abhi2011 | but then i would need to know which one of the passed objects is the ground plane |
| 18:39.21 | brlcad | maybe Usage: simulate timestep(s) object0 [object1 ...] |
| 18:39.31 | brlcad | right |
| 18:39.37 | abhi2011 | ok |
| 18:39.39 | brlcad | that brings me to my next suggestion :) |
| 18:40.09 | brlcad | so there's two concepts that I think bullet represents, correct me if I'm wrong |
| 18:40.18 | brlcad | one is this concept of a ground plane |
| 18:40.29 | brlcad | which is defined by a plane equation vector |
| 18:40.47 | brlcad | then it's marked immutable (i.e., with 0 volume) |
| 18:41.39 | brlcad | that being the second concept |
| 18:41.43 | brlcad | yes? |
| 18:41.55 | abhi2011 | welll almost , actually its more general, there can be 2 types of objects in bullet : static objects (with mass 0) and dynamic objects (with non zero mass) |
| 18:41.58 | CIA-133 | BRL-CAD: 03tbrowder2 * r46735 10/brlcad/trunk/TODO: add tasks to be done to clean up DocBook source |
| 18:42.08 | brlcad | s/volume/mass/ .. that's what I meant ;) |
| 18:42.24 | abhi2011 | yes right |
| 18:42.31 | abhi2011 | so I can actually mark any object as static |
| 18:42.33 | brlcad | but a ground plane isn't just a mass 0 entity iirc, no? |
| 18:42.41 | abhi2011 | true |
| 18:42.41 | brlcad | you have to say "this is ground" too, no? |
| 18:42.51 | abhi2011 | no there is no need to say so |
| 18:42.55 | abhi2011 | i just have to make it static |
| 18:43.00 | abhi2011 | that is fixed in space |
| 18:43.07 | brlcad | otherwise if I put an immutable box above your boxes, they'd have gravity pulling them in two directions |
| 18:43.08 | abhi2011 | there is no separate concept of ground |
| 18:43.40 | abhi2011 | no becuase the gravity is specified independently for the entire world |
| 18:43.45 | abhi2011 | there is no concept of ground |
| 18:43.54 | abhi2011 | if i have a plane that is rigid |
| 18:43.55 | brlcad | so gravity is global |
| 18:44.00 | abhi2011 | then it appears as the ground |
| 18:44.11 | abhi2011 | but its not specfied as such |
| 18:44.21 | brlcad | mm, okay |
| 18:44.39 | brlcad | so then all you need is some means to designate or calculate an object's mass |
| 18:44.57 | abhi2011 | yes, right now i use the volume of the objects bb and density of 0 |
| 18:44.58 | brlcad | we have a tool that does that (gqa) calculating mass, but it's not yet an API function |
| 18:45.00 | abhi2011 | sorry 1 |
| 18:45.05 | brlcad | nods |
| 18:45.05 | abhi2011 | oh ok |
| 18:45.07 | abhi2011 | cool |
| 18:45.21 | brlcad | so how about this |
| 18:46.00 | brlcad | you assume all regions specified for simulation (via specifying a given scene/combination/group) have a mass of 1 |
| 18:46.10 | brlcad | unless a mass-value is set |
| 18:46.22 | abhi2011 | ok |
| 18:46.26 | abhi2011 | yes |
| 18:46.35 | brlcad | that way all you need is some means to set an object's mass |
| 18:46.46 | abhi2011 | however a larger object may appear to have the same mass as a smaller object |
| 18:46.54 | abhi2011 | yes , the mass can be set |
| 18:46.56 | abhi2011 | true |
| 18:47.04 | brlcad | which fortunately there is a system already in place for :D |
| 18:47.06 | abhi2011 | if the user want more realistic simulation |
| 18:47.12 | abhi2011 | yes :) |
| 18:47.46 | abhi2011 | so i guess i can call upon the code in the gqa thingie to get me the mass |
| 18:48.00 | brlcad | nah, that'd be hell |
| 18:48.12 | abhi2011 | ok :P |
| 18:48.27 | brlcad | it's not API yet and it'd take a week or more to make it proper API |
| 18:48.47 | brlcad | your time is better spent getting collisions working ;) |
| 18:48.51 | abhi2011 | right ok, so i ll make it trhe way we dicusssed then |
| 18:48.57 | abhi2011 | assume mass of 1 |
| 18:49.03 | abhi2011 | unoless specified |
| 18:49.12 | brlcad | right, but then you need a way to specify mass :) |
| 18:49.18 | abhi2011 | yes |
| 18:49.23 | abhi2011 | so a -m flag |
| 18:49.24 | brlcad | do you know how already? :) |
| 18:49.30 | brlcad | no no |
| 18:49.31 | abhi2011 | with the masses in order |
| 18:49.45 | brlcad | object-oriented, you want objects to specify themselves |
| 18:50.06 | abhi2011 | ok but the user is going to pass the mass right |
| 18:50.29 | brlcad | pass the mass .. hehe |
| 18:50.29 | brlcad | yes :) |
| 18:50.45 | abhi2011 | ok |
| 18:50.51 | brlcad | so the missing piece of this puzzle... |
| 18:50.55 | brlcad | perhaps a new brl-cad concept, we have an attribute system where you can store key=value on arbitrary db objects |
| 18:51.10 | abhi2011 | ok |
| 18:51.17 | brlcad | that will probably work perfect for this |
| 18:51.22 | abhi2011 | right |
| 18:51.26 | abhi2011 | like the avs thing |
| 18:51.35 | abhi2011 | for the attributes of an object |
| 18:51.38 | brlcad | what avs thing? |
| 18:51.47 | abhi2011 | there is this avs variable all over the c code |
| 18:51.52 | brlcad | ah, yes |
| 18:51.53 | brlcad | that's this |
| 18:51.59 | abhi2011 | its used to access the attributes |
| 18:52.00 | brlcad | avs == attribute value system |
| 18:52.04 | abhi2011 | yes |
| 18:52.06 | abhi2011 | :) |
| 18:52.10 | abhi2011 | so not so new after all |
| 18:52.12 | abhi2011 | :P |
| 18:52.26 | abhi2011 | well yeah but i understand what you are saying |
| 18:52.28 | brlcad | yeah, so just need to use it for your own settings :) |
| 18:52.28 | abhi2011 | :) |
| 18:52.57 | abhi2011 | ok |
| 18:53.06 | abhi2011 | now about passing the mass while invoking the command |
| 18:53.06 | brlcad | attr set ground.r simulate:mass=0 |
| 18:53.17 | abhi2011 | oh ok |
| 18:53.19 | abhi2011 | ah now i get it |
| 18:53.19 | brlcad | then in the code, just look up the "simulate:mass" attribute and use the value |
| 18:53.26 | abhi2011 | right |
| 18:53.28 | abhi2011 | cool |
| 18:53.40 | brlcad | can use that for a whole slew of things then :) |
| 18:53.45 | abhi2011 | so its like any other attribute of the object, like radius etc |
| 18:53.47 | abhi2011 | yes |
| 18:53.51 | abhi2011 | we can specfiy friction |
| 18:53.54 | abhi2011 | for custom materials |
| 18:53.58 | abhi2011 | or density |
| 18:54.13 | brlcad | just prefix your variables so they can be conceptually grouped together |
| 18:54.19 | abhi2011 | ok |
| 18:54.40 | brlcad | but you should always have a "default" too .. so if nothing is set, it'll do something sane |
| 18:54.49 | abhi2011 | ok |
| 18:54.55 | abhi2011 | now about the ground plane thing |
| 18:55.19 | abhi2011 | see the user will invoke the command like : simulate a.r b.r |
| 18:55.22 | brlcad | like maybe if there is no immutable mass=0 objects being simulated, it defaults to making the biggest one be mass=0 |
| 18:55.33 | abhi2011 | ok |
| 18:55.42 | brlcad | simulate 10 scene |
| 18:55.54 | brlcad | or simulate 10 grp1 grp2 grp3 ... |
| 18:56.10 | brlcad | not necessarily just the region objects |
| 18:56.13 | abhi2011 | ok |
| 18:56.19 | abhi2011 | 1 more question |
| 18:56.21 | brlcad | trivial to walk the object(s) specified, get a list of all regions |
| 18:56.30 | abhi2011 | right |
| 18:56.37 | abhi2011 | i guess a scene's objects can be accessed |
| 18:56.44 | abhi2011 | not yet worked with scenes |
| 18:56.45 | brlcad | if there are no regions, maybe treat the object specified as a region or error out if you have to have a region |
| 18:56.59 | brlcad | db_walk_tree() is your friend |
| 18:57.02 | abhi2011 | cool |
| 18:57.52 | abhi2011 | umm so about scenes, if i want to create a new scene |
| 18:57.58 | abhi2011 | there is an mged comand for it ? |
| 18:58.01 | brlcad | that way your code doesn't even need to know the name(s) of anything |
| 18:58.14 | brlcad | 'g' ? |
| 18:58.25 | brlcad | scenes are just logical groupings of objects |
| 18:58.41 | abhi2011 | oh ok |
| 18:58.46 | brlcad | you can group a bunch of regions and groups together with the 'g' command |
| 18:59.00 | abhi2011 | yes of course :) |
| 18:59.08 | abhi2011 | thought they were a new kinda thing |
| 18:59.16 | abhi2011 | :P |
| 18:59.17 | brlcad | they're implicit |
| 18:59.20 | abhi2011 | ok |
| 18:59.44 | abhi2011 | ok there is 1 other thing |
| 18:59.53 | abhi2011 | about custom forces |
| 19:00.07 | abhi2011 | so suppose i want some impulse applied on a specfic object |
| 19:00.08 | brlcad | objects above the region level are groups, groups are "assemblies" in CAD terminology -- a scene is just another assembly |
| 19:00.16 | abhi2011 | can be used to shoot a sphere at a cube stack for example |
| 19:01.52 | abhi2011 | ok about the assemblies, so about the custom forces should I consider at this stage , something liek this : simulate 10 -f{obj, 10,0,0} grp1 grp2 .... |
| 19:02.33 | abhi2011 | so that would apply a force of 10 newtons on the region/group named as 'obj' only |
| 19:02.43 | abhi2011 | the remainign objects stay the same |
| 19:02.52 | CIA-133 | BRL-CAD: 03tbrowder2 * r46736 10/brlcad/trunk/doc/docbook/articles/en/mgedrc.xml: adding unicode point for two symbols; lifting XInclude namespace to root element |
| 19:02.59 | abhi2011 | obj should appear somewhere in grp1, grp2 etc |
| 19:03.03 | brlcad | abhi2011: I'd probably still use the attributes for that |
| 19:03.11 | abhi2011 | ah yes of course |
| 19:03.13 | brlcad | because you need to persist the force across frames |
| 19:03.31 | abhi2011 | yes true, that would be much easier then parsing comples flags |
| 19:03.43 | abhi2011 | yes |
| 19:04.06 | abhi2011 | interesting and very useful this attributes thing :) |
| 19:04.13 | brlcad | granted, that means you'll have to read all objects to see if any have forces applied, run the simulation step, then write out any remaining/residual forces (for the next timestep) |
| 19:04.29 | CIA-133 | BRL-CAD: 03tbrowder2 * r46737 10/brlcad/trunk/TODO: add another task to be done to clean up DocBook source |
| 19:04.43 | brlcad | becomes a persistent database for any values you need during the sim |
| 19:04.52 | abhi2011 | yes |
| 19:04.53 | CIA-133 | BRL-CAD: 03starseeker * r46738 10/brlcad/trunk/README.cmake: Toplevel readme probably isn't the place for these details. Also, if the environment variables may cause a problem, the thing to do is to have CMake check them as part of the configure process and warn about them. |
| 19:06.15 | abhi2011 | yes, that is another thing which was bothering me actually, see there are 2 options, to run all the simulation timesteps without any thing else happening. or run 1 timestep, do overlp checks then run the next steps |
| 19:06.26 | brlcad | starseeker: if CMake is a faithful conversion of configure, there should already be a big honking warning about BRLCAD_ROOT being set ;) |
| 19:06.44 | abhi2011 | but if there is break between the steps and i have to recreate the entire scene again , then all the dynamic foce and acceleration info would need to be persisted |
| 19:06.53 | abhi2011 | can use the attributes for that |
| 19:06.58 | brlcad | sure |
| 19:07.28 | abhi2011 | right so a whole slew of new attributes to be added |
| 19:07.39 | abhi2011 | for all objects in brl-cad |
| 19:07.54 | abhi2011 | force , mass, |
| 19:07.56 | brlcad | all regions objects |
| 19:08.02 | abhi2011 | yes ok |
| 19:08.15 | abhi2011 | yes true |
| 19:08.17 | abhi2011 | only regions |
| 19:08.40 | brlcad | pretty limited subset, and only after simulate has run once (and there are forces remaining) or as part of scene setup to override defaults |
| 19:09.21 | brlcad | e.g., you wouldn't want to write out simulate:force=0.0 .. you'd delete the attribute |
| 19:09.31 | abhi2011 | yes |
| 19:09.41 | brlcad | (assumes default force==0.0 of course) |
| 19:09.57 | abhi2011 | yes, so all these attributes are listed in a header, and i just go add to them |
| 19:10.29 | CIA-133 | BRL-CAD: 03tbrowder2 * r46739 10/brlcad/trunk/doc/docbook/articles/en/projection_shader.xml: adding unicode point for two symbols; lifting XInclude namespace to root element |
| 19:10.53 | abhi2011 | and maybe increase a counter which currently tracks the number of attributes that can exist for a region |
| 19:10.53 | starseeker | brlcad: yeah, yeah... :-P |
| 19:11.08 | starseeker | is catching up on backlog... |
| 19:18.08 | CIA-133 | BRL-CAD: 03tbrowder2 * r46740 10/brlcad/trunk/doc/docbook/articles/en/build_region.xml: lifting XInclude namespace to root element |
| 19:22.16 | abhi2011 | on thinking more about it, the velocity of the objects, both rotational and translational needs to be persisted for the next frame, and if any custom force should still to be applied in the next frame(since there is no concept of a residual force as such like 10 newtons force is applied and 5 newtons is left for next frame, that would result in wrong physics ) |
| 19:25.01 | abhi2011 | ok so I ll proceed with adding the new attributes : translational velocities in x y, z directions and rotational velocities for the 3 axes , and see if I can store then after 1 frame and reload them at the beginning of the next frame and see if physics continues properly |
| 19:26.08 | abhi2011 | this can then be extended to calling rt at the end of a frame to create the contact manifolds , which can then be inserted into the collision pipeline befpre starting the next frame, so collision proceeds according to rt output |
| 19:26.41 | CIA-133 | BRL-CAD: 03tbrowder2 * r46741 10/brlcad/trunk/doc/docbook/articles/en/build_pattern.xml: adding unicode point for one symbols; lifting XInclude namespace to root element |
| 19:31.56 | CIA-133 | BRL-CAD: 03tbrowder2 * r46742 10/brlcad/trunk/doc/docbook/lessons/en/mged01_creating_primitive_shapes.xml: lifting XInclude namespace to root element |
| 19:56.17 | brlcad | starseeker: if you knew the support hell that was when BRLCAD_ROOT was the norm, it probably would have been one of the first things you added |
| 19:57.30 | brlcad | how many times I'd spend half a day debugging some really bizzare bug or crash only to discover they were running a 7.4 binary but using 7.0 libraries |
| 19:58.50 | CIA-133 | BRL-CAD: 03starseeker * r46743 10/brlcad/trunk/CMakeLists.txt: Get a version of the warnings about BRLCAD_ROOT into CMake, as well as (reluctantly) using the environment variable if it's defined. |
| 20:00.56 | brlcad | abhi2011: couldn't you have a situation like where you'd have an electromagnetic field applying some force but then the force on the next frame would be different because of the different position in the field? |
| 20:01.23 | brlcad | the idea being that you'd have some sort of force emitter objects, of course, with some sort of parametric force being applied |
| 20:01.30 | brlcad | not just impulse or load |
| 20:02.27 | brlcad | abhi2011: I'd suggest combining the xyz velocities into one attribute (one for linear, one for rotational) |
| 20:02.49 | brlcad | should limit the number of writes if values naturally group together |
| 20:04.17 | CIA-133 | BRL-CAD: 03starseeker * r46744 10/brlcad/trunk/CMakeLists.txt: /usr is bad whether or not it came from BRLCAD_ROOT, adjust warning. |
| 20:06.11 | brlcad | starseeker: you missed the warning part |
| 20:06.46 | brlcad | "if test ! "x$BRLCAD_ROOT" = "x" ; then" ... |
| 20:07.11 | brlcad | that's the important part |
| 20:07.15 | starseeker | that's IF(BRLCAD_ROOT) |
| 20:07.47 | starseeker | SET(BRLCAD_ROOT "$ENV{BRLCAD_ROOT}") get's it from the environment variable - if that variable is empty, the if test fails. otherwise, the warning proceeds |
| 20:08.15 | brlcad | not following |
| 20:08.33 | starseeker | we're warning if BRLCAD_ROOT is set, correct? |
| 20:08.39 | brlcad | correct |
| 20:08.44 | starseeker | this will do that |
| 20:09.03 | abhi2011 | brlcad : about the electro magnetic fields, yes true |
| 20:09.41 | brlcad | ah, I see it.. the logic is further down .. I was expecting statement parity, or close to it |
| 20:10.00 | brlcad | a quiet little "BRLCAD_ROOT is not necessary and may cause unexpected behavior" is not parity at all... |
| 20:10.00 | CIA-133 | BRL-CAD: 03starseeker * r46745 10/brlcad/trunk/CMakeLists.txt: comment first, then code |
| 20:10.37 | starseeker | has tested it - seems to do the trick |
| 20:11.20 | brlcad | that's probably the distinction |
| 20:11.30 | brlcad | there's no indication on the severity of the messages being printed |
| 20:11.40 | CIA-133 | BRL-CAD: 03tbrowder2 * r46746 10/brlcad/trunk/HACKING: add reference to more DocBook details |
| 20:12.31 | brlcad | configure had something like four output levels, regular print message, warning, severe warning, and error (halting) |
| 20:12.48 | starseeker | yeah, I don't think cmake has warning vs. severe warning |
| 20:12.53 | brlcad | otherwise the messages will just get lost in the noise |
| 20:13.31 | brlcad | the }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} markers screamed out "this is really bad" .. and it worked |
| 20:13.33 | starseeker | heh - I'm calling sleep on the first one, and flat out exiting with failure on /usr (with a message that tells them how to get it to go forward if they're really that stubborn) |
| 20:13.40 | starseeker | ah, k |
| 20:13.51 | CIA-133 | BRL-CAD: 03tbrowder2 * r46747 10/brlcad/trunk/doc/docbook/README: add more details on DB character code requirements |
| 20:15.15 | brlcad | the only half-severe }}} message I think we ever reported was about the IEEE encoding, which I'm just not sure what it means in terms of valid calculations |
| 20:15.28 | CIA-133 | BRL-CAD: 03tbrowder2 * r46748 10/brlcad/trunk/doc/docbook/README: correct typo |
| 20:22.40 | CIA-133 | BRL-CAD: 03starseeker * r46749 10/brlcad/trunk/CMakeLists.txt: Make warnings noiser, also complain about BRLCAD_DATA |
| 20:23.45 | brlcad | starseeker: er, BRLCAD_ROOT doesn't set prefix in configure ... |
| 20:24.35 | starseeker | ah, my mistake |
| 20:24.39 | starseeker | wasn't parsing the m4 logic right |
| 20:25.25 | brlcad | it pulls the value from prefix (setting BRLCAD_ROOT) .. but that's os we set BRLCAD_ROOT as a define in the config header (so things like bu_brlcad_root() work correctly) |
| 20:25.33 | brlcad | s/os/so/ |
| 20:26.19 | starseeker | nods - I never use BRLCAD_ROOT as a variable at all in CMake - it gets set to CMAKE_INSTALL_PREFIX in the config header |
| 20:27.00 | brlcad | "it" being BRLCAD_ROOT? |
| 20:27.06 | starseeker | yes |
| 20:27.40 | brlcad | yeah, I wouldn't have expected you to use it as a var |
| 20:29.44 | CIA-133 | BRL-CAD: 03starseeker * r46750 10/brlcad/trunk/CMakeLists.txt: My mistake, we're not setting CMAKE_INSTALL_PREFIX to BRLCAD_ROOT. Tweak the logic and warnings accordingly |
| 20:31.19 | brlcad | it was needed for the m4 logic because BRLCAD_ROOT exists as a shell variable, an m4 variable, a make variable, and a #define -- cmake effectively eliminates the m4+make cases (unless you allow the same make-time override) |
| 20:31.21 | CIA-133 | BRL-CAD: 03starseeker * r46751 10/brlcad/trunk/CMakeLists.txt: match closing tag |
| 20:31.29 | brlcad | does miss the various make-time overrides |
| 20:34.05 | brlcad | e.g., make TCLDIR= TKDIR= (skip rebuilding tcl/tk even if dependency tracking wants to rebuild them) |
| 20:34.34 | starseeker | winces - not sure how I'd make that work |
| 20:34.40 | brlcad | make CPPFLAGS=-w (skip strict for this pass) |
| 20:34.56 | brlcad | no worries, not a major feature |
| 20:35.08 | brlcad | just one of those things :) |
| 20:35.53 | brlcad | overriding the dependency tracking system wasn't something universal, there had to be a make variable defined for the directory |
| 20:36.01 | brlcad | getting that in cmake terms would probably suck |
| 20:36.39 | brlcad | because it'd probably take some round-about checking mechanism instead of just letting make do what it does |
| 20:37.02 | CIA-133 | BRL-CAD: 03starseeker * r46752 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: That's actually CXXFLAGS, not CXX_FLAGS... |
| 20:37.18 | brlcad | one of the merits of automake+make .. but not one that trumps the windows portability aspect of cmake |
| 20:37.22 | starseeker | probably mattered more when build times were slower |
| 20:37.41 | brlcad | nah, still matters .. I used it just last week :) |
| 20:38.13 | starseeker | shakes his head - I think my developer skills are going to forever remain at the "midrange" level |
| 20:38.40 | starseeker | can get there eventually, usually... |
| 20:39.00 | brlcad | think if you're working on building a proc-db or something simple, find out you need to add a libbu function that begs for a new configure/cmake header test, .. it's going to rightly want to rebuild everything |
| 20:39.47 | starseeker | make -j9 procdb_target would build only what that proc-db needs, I'd probably call that close enough... |
| 20:40.07 | brlcad | you don't care about rebuilding everything in that moment, whether it's 2min or 10min .. your procdb builds and links in 2 milliseconds and that's what you're focusing on :) |
| 20:40.31 | starseeker | make procdb_target/FAST I think might do what you want there |
| 20:40.43 | brlcad | maybe |
| 20:40.51 | brlcad | but I *did* need libbu rebuilt :) |
| 20:41.12 | brlcad | just not every f'n thing that uses libbu, and certainly not all of src/other :) |
| 20:41.40 | starseeker | nods |
| 20:41.51 | brlcad | like I said, not a huge deal .. just something different |
| 20:41.57 | starseeker | maybe if you describe the scenario to the CMake devs they could come up with something... |
| 20:42.10 | brlcad | not even that important |
| 20:42.49 | brlcad | might even be something similar in cmake terms that will work "good enough", like make libbu/FAST && make my_proc/FAST |
| 20:43.20 | starseeker | thought about suggesting that, but assumed it would be rejected for "too much typing" reasons :-P |
| 20:44.17 | brlcad | it's better than waiting 2-10min :) |
| 21:30.59 | starseeker | tcl/tk 2011 schedule is up: http://www.tcl.tk/community/tcl2011/schedule.html |
| 22:02.19 | brlcad | looks like Cliff F. is all over the place in the schedule this year |
| 22:02.32 | brlcad | quirky funny guy :) |
| 22:03.33 | brlcad | at least in a geek humor kind of way :) |
| 22:03.38 | brlcad | bets $20 that he says "Any questions? Any answers?" at least a few times during the week |
| 22:57.25 | brlcad | oh snap! |
| 22:57.33 | brlcad | thank you tom browder! |
| 22:58.01 | brlcad | looks like sourceforge folks made ideatorret an option, that's outstanding! |