IRC log for #brlcad on 20120922

05:12.12 *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
05:35.58 *** join/#brlcad elf_ (~elf@92.80.3.25)
10:34.43 CIA-68 BRL-CAD: 03MelinaoewoywpoqcLegge 07http://brlcad.org * r4443 10/wiki/Dog_Collars_-_What_You_Need_To_Know: New page: What's The Best Type Of Dog Collar? Getting the right dog collar for your dog is one of the most important things you can do for your dog. Your dog will probably spend most of it's life w...
10:53.50 *** join/#brlcad yiyus (~124271242@je.je.je)
12:36.11 *** join/#brlcad abhi2011 (~chatzilla@117.200.92.29)
12:41.45 abhi2011 hey elf_
12:56.42 abhi2011 darn I forgot how to setup cmake for compiling with visual studio
12:57.28 abhi2011 I think for the simulate command, the path to the bullet library has to be mentioned for the FindBullet.cmake script to find it
13:01.31 abhi2011 ah the readme is there
13:50.55 *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
15:55.15 *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net)
16:30.57 *** join/#brlcad abhi2011 (~chatzilla@117.200.86.91)
16:38.35 abhi2011 elf_, I am building brlcad now
16:38.38 abhi2011 in windows :P
16:38.46 abhi2011 will test out with your g file after that
16:39.21 elf_ Oh hello abhi, I see didn't try it in windows, I am using linux :)
16:41.21 abhi2011 ok
16:41.43 abhi2011 so it takes 1000 steps for the cube to fall to the ground ?
16:42.09 abhi2011 if thats so then maybe for now, we can drop the cube closer to the ground
16:42.54 abhi2011 I generally dump the output at every step, the lesser the number of steps thats output, the easier it is to track down whats wrong
16:43.01 elf_ Hmm no, the cube is at 50m above the ground, in that g file, it takes 190steps to move the cube 50mm, so to move the cube 50m it will take 190*1000 roughly
16:43.35 elf_ 1k steps moves the cube just a little bit in that simulation
16:43.48 elf_ and for 10k steps the simulation gets aborted
16:44.04 abhi2011 hmm, it should not be that way, if gravity is acting on the cube, it should accelerate faster
16:44.52 elf_ I know
16:45.44 abhi2011 ok, we need to verify some more basic things first
16:45.55 abhi2011 I think what we can do as a test for whether the simulation logic of bullet itself is still working correctly, we can just drop a cube and print its position in mged
16:46.40 elf_ From the last cube simulation I did it looked like the collision point was in the middle of the cube
16:46.41 abhi2011 so lets try to do that first, i.e. comment out everything in ...
16:46.43 abhi2011 let me check
16:46.44 elf_ that it's not right
16:47.32 abhi2011 yeah thats because the overlap detection logic is not working correctly
16:47.50 abhi2011 i had put it in much later but its not tested out yet
16:48.37 elf_ I see
16:48.51 abhi2011 so in simphysics.cpp , run_simulation(struct simulation_params *sp)
16:50.25 abhi2011 I think we can replace it with the code in http://bulletphysics.org/mediawiki-1.5.8/index.php/Hello_World
16:50.41 abhi2011 to test whether bullet is working as it should
16:51.18 elf_ okay will try it
16:51.39 abhi2011 there is a loop in which the physics is stepped towards the bottom of the page
16:51.48 abhi2011 that loop should also be there
16:52.15 elf_ the whole source is at the bottom of the page
16:52.31 abhi2011 cool :)
16:52.43 abhi2011 just plop it in
16:53.28 elf_ yeah
17:01.05 abhi2011 I notice I had set gravity along -ve z
17:01.28 elf_ yeah you put it -10
17:02.24 abhi2011 any luck with the hello world thingy
17:03.19 elf_ It compiled just fine, I tried it on the same g file I send to you but just gets blocked
17:03.39 abhi2011 in the loop ?
17:03.55 abhi2011 try adding prints above it
17:05.58 elf_ Okay so the thing is, it gets the output it is supposed to get from the tutorial for 1 step, 2 steps then when I try with 10 steps it blocks
17:06.24 elf_ mged freezes so I have to kill the process
17:07.46 abhi2011 thats wierd
17:08.06 elf_ very since it works fine for all the numbers lower than 10 O.O
17:08.40 abhi2011 so you change the number of steps in the for loop statement right ?
17:08.46 abhi2011 for (int i=0 ; i<300 ; i++) {
17:08.58 abhi2011 you change it to : for (int i=0 ; i<10 ; i++) { ?
17:10.28 abhi2011 there is one other possibility, I think the simulation may be completing, but since the right data is not returned out if the function, so mged freezes
17:10.30 elf_ not there, it's from somewhere else, I put there 10 indeed, but when I run simulate I run it as "simulate 1/2/3../10" for all of them works for 10 it doesn't
17:11.17 abhi2011 oh ok
17:11.52 abhi2011 the value of 10 is put into sim_params->duration argument
17:12.43 abhi2011 so your loops is something like : for (int i=0 ; i< sim_params->duration ; i++) { ?
17:13.26 elf_ yes
17:13.50 abhi2011 ok, whats happens if you hardcode the number of steps in the function
17:14.01 abhi2011 so hardcode to 300 in the loop limit
17:14.11 abhi2011 then run with simulate 1
17:14.35 abhi2011 it will still execute 300 steps , because its hardcoded, it will ignore 1
17:14.45 abhi2011 do you then get the output for 300 steps ?
17:15.53 elf_ yes it gets the output for 300 steps
17:16.15 abhi2011 ok, and I assume it matches the hello world output
17:16.57 elf_ it does, it's like the one they said it should be
17:17.41 abhi2011 right, so thats good
17:19.04 abhi2011 what the output if you replace dynamicsWorld->stepSimulation(1/60.f,10);
17:19.13 abhi2011 with step_physics(dynamicsWorld);
17:20.01 abhi2011 its rater hilarious, whats happening actually
17:20.16 elf_ why so?
17:20.25 abhi2011 but lets see if you get the right output after replacing it
17:21.23 elf_ I get a seg fault
17:22.00 abhi2011 oh just comment out the 1st bu_vls_printf() line
17:22.09 abhi2011 in step_physics()
17:22.30 abhi2011 its prolly 'cause of the sim_params structure
17:22.50 abhi2011 in fact comment out all 3
17:23.03 abhi2011 and replace with your own print statements
17:23.40 abhi2011 those statements I had put in to mark the beginning and end of each step
17:23.55 abhi2011 so the output from each step is clearly separated in the log
17:24.01 abhi2011 and I can go through it easier
17:26.26 abhi2011 any luck ?
17:26.39 elf_ it's good
17:26.44 elf_ same output as before
17:27.04 abhi2011 ok, so the step_physics() is supposed to be called at every step
17:27.33 abhi2011 that means that there need to be a loop in the run_simulation()
17:28.47 elf_ yeah, right now it the for (int i=0 ; i< 300 ; i++) { } loop
17:29.00 abhi2011 exactly
17:30.02 abhi2011 for some reason we had decided last year, that we would add objects to the bullet dynamics world, do 1 step of simulation, then get the transforms into the sim_params structure, then clear out everything and repeat
17:30.29 abhi2011 that is why you see a for loop in line 503
17:30.37 abhi2011 but its commented out !
17:31.03 abhi2011 my fault, i think that was for debugging something !
17:31.07 elf_ yes wanted to ask you about those commented lines
17:31.30 abhi2011 so simulate has actually been executing just 1 step :P
17:31.38 abhi2011 not 100k
17:32.22 elf_ well it never really got to be executed 100k, but I see your point
17:32.23 abhi2011 the basic way in which the simulate command works now is to load everything that need to be simulated into sim_params structure
17:32.37 abhi2011 pass it to run_simulation()
17:33.02 abhi2011 there cram the shapes from sim_params into the bullet dynamics world
17:33.09 abhi2011 run the required number of steps
17:33.22 abhi2011 grab the transforms at the end of each step from bullet
17:33.27 abhi2011 and put into sim_params
17:33.58 abhi2011 only the last step's transforms actually remain after the simulation
17:34.12 *** join/#brlcad stas (~stas@host-static-92-115-48-61.moldtelecom.md)
17:34.14 abhi2011 the sim_params structure is then accessed back in libged
17:34.33 abhi2011 to read the transforms and update the shapes in mged
17:35.26 abhi2011 there are several improvements to this but I had done it this particularly inefficient way to debug the contact point generation algorithm which is what I was working on last
17:35.31 elf_ it makes sense, you are interested in the initial position of the geometry when you start your simulation, you don't want to save all the intermediate steps your geometry finds itself during the simulation
17:35.44 elf_ only the final state, you save it and then pass it to libged
17:35.44 abhi2011 thats right
17:36.19 abhi2011 also, I don think there is a need to recreate the simulation world each time and add the objects back
17:36.33 abhi2011 but that can be corrected anytime
17:36.38 elf_ what do you mean?
17:36.50 abhi2011 so if you see the comented out for loop
17:37.03 abhi2011 it includes the creations and deletion fo the bullet dynamics worls
17:37.06 abhi2011 *world
17:37.14 abhi2011 btDiscreteDynamicsWorld* dynamicsWorld;
17:37.15 elf_ yeah that must be done outside
17:37.22 abhi2011 yes
17:37.25 elf_ no need for it to be done everytime
17:37.29 abhi2011 it probably was outside
17:37.40 abhi2011 I may have moved it in to debug a single step
17:37.42 abhi2011 anyway
17:37.48 abhi2011 what you can do right now
17:37.59 abhi2011 is remove the comments
17:38.11 abhi2011 move the world creation stuff out of the loop
17:38.20 abhi2011 so we are only stepping inside the loop
17:38.23 abhi2011 and doing nothing else
17:38.37 abhi2011 then use the get_transforms() after the loop body
17:38.45 abhi2011 to get back te transforms into sim_params
17:38.55 elf_ hmm sounds good
17:38.57 abhi2011 and see if things move a bit faster in mged
17:38.58 elf_ let me try it
17:39.03 abhi2011 :P
17:39.44 abhi2011 the cleanup() should be kept
17:39.53 abhi2011 after get_transforms()
17:45.09 elf_ damn I get a weird warning, that I didn't get before...
17:45.51 abhi2011 which is ?
17:45.56 elf_ the size variable is being shadowed O.O
17:45.57 elf_ /usr/local/include/bullet/LinearMath/btSerializer.h:538:36: instantiated from here
17:45.57 elf_ /usr/local/include/bullet/LinearMath/btAlignedObjectArray.h:102:27: warning: declaration of ‘size’ shadows a member of 'this' [-Wshadow]
17:45.58 elf_ /usr/local/include/bullet/LinearMath/btAlignedObjectArray.h: In member function ‘void* btAlignedObjectArray<T>::allocate(int) [with T = const char*]’:
17:45.58 elf_ /usr/local/include/bullet/LinearMath/btAlignedObjectArray.h:287:31: instantiated from ‘void btAlignedObjectArray<T>::reserve(int) [with T = const char*]’
17:46.14 abhi2011 thats in bullet
17:46.16 abhi2011 hmm
17:46.46 abhi2011 lt me check that line
17:46.54 abhi2011 name collision maybe
17:47.53 *** join/#brlcad merzo (~merzo@201-246-92-178.pool.ukrtel.net)
17:48.48 elf_ it was my fault
17:49.19 elf_ forgot when I modified step_physics I modified the way the output it was displayed
17:49.29 abhi2011 ok
17:54.22 elf_ not good, not good at all, now it gets aborted if I run simulate > 100 which is not good
17:54.50 abhi2011 whats happens for < 100 ?
17:56.22 elf_ it ran its course
17:56.26 elf_ so it worked
17:56.36 elf_ but trying with more than 100 it's not working
17:56.40 abhi2011 did the shapes get updated in mged ?
17:57.40 elf_ it did
17:59.07 abhi2011 ok is the movement significant
17:59.12 abhi2011 or still very small ?
18:00.27 abhi2011 hmm I see in simulate.c that I do have a loop
18:00.34 elf_ okay so I think the cube it actually falls out of the simulation for more than 120 or so steps
18:00.42 abhi2011 which calls run_simulation()
18:01.02 abhi2011 that should not happen
18:01.06 elf_ let me try something I have to recreate the .g files cause the db gets corrupt after the cube falls into the ground
18:01.21 elf_ and the movement is significant
18:01.40 abhi2011 ok and I also see that there is a loop in simulate.c
18:01.53 abhi2011 thats calls run_simulation
18:02.09 abhi2011 you can comment out that loop for now
18:02.26 abhi2011 thats causing the huge number of steps
18:02.58 abhi2011 if you see in simulate.c 431
18:03.13 abhi2011 there is a loop there already
18:03.30 abhi2011 just comment out that loop for now
18:13.15 elf_ The loop on line 431 in simulate.c it's actually the one that simulates things, it can't be commented out
18:13.34 elf_ get_bb: Got the BB for "sim_gp.r" as min {-15000.000000 -15000.000000 -1000.000000} max {15000.000000 15000.000000 1000.000000}
18:13.35 elf_ get_bb: Dimensions of this BB : 30000.000000 30000.000000 2000.000000
18:13.35 elf_ get_bb: Got the BB for "sim_cube.r" as min {-1000.000000 -1000.000000 49000.000000} max {1000.000000 1000.000000 51000.000000}
18:13.35 elf_ get_bb: Dimensions of this BB : 2000.000000 2000.000000 2000.000000
18:13.49 elf_ That's the output I get with the whole loop commented out
18:14.02 elf_ and the position is not actually modified
18:14.24 elf_ for simulate 80
18:15.58 abhi2011 yeah, what I meant is either the loop in simulate.c is kept or the one in simphysics.cpp
18:17.05 abhi2011 if both are kept, then the number of steps executed is more than
18:17.22 abhi2011 its = sim_params->duration * sim_params->duration
18:17.30 abhi2011 which is not what we want
18:17.47 elf_ yeah, the one in simphysics.cpp has to go then
18:17.55 abhi2011 yep :P
18:18.01 abhi2011 sorry to mislead you on that one
18:18.14 abhi2011 I had forgotten there was a loop in simulate.c
18:18.25 elf_ so we are basically to the beginning, cause if the loop in symphisics.cpp go then nothing changed
18:19.12 abhi2011 yep, but we know now that the simulation does work
18:19.53 abhi2011 the difference in having the loop in simulate rather than in simphysics.cpp
18:20.03 abhi2011 is that by having the loop in smulate.c
18:20.28 abhi2011 the entire bullet world is recreated each time
18:20.57 abhi2011 but that should not cause the cube to fall slower
18:21.09 abhi2011 because the velocity information gained from the last step
18:21.30 abhi2011 is put into the cube in the current step before being stepped
18:22.03 elf_ well I am running right now the simulate command on the database I sent to you, and the steps are tiny again for the m units
18:22.22 elf_ I am waiting to see if it aborts for the 10k steps simulate
18:22.50 abhi2011 I think the reason the steps are tiny is because
18:22.58 abhi2011 the linear velocity gained in the last sim step
18:23.10 abhi2011 is not being set in the beginning of the next step
18:23.34 abhi2011 this has to be done manually, because now we are recreating the bullet world at each step
18:23.40 abhi2011 and re-adding the rigid bodies
18:23.47 elf_ hmm but if that were the case then wouldn't the same thing happen for mm too?
18:24.02 abhi2011 mm ?
18:24.36 elf_ milimeters
18:24.49 elf_ and I am simulating for meters now
18:25.33 elf_ In the mm geometry there wasn't such a problem as the linear velocity not being set for the next step
18:25.54 elf_ or maybe the units are way too small to observe the difference
18:25.58 abhi2011 yes
18:26.04 elf_ and the simulation aborted for 10k
18:26.11 elf_ trying a lower number
18:26.14 abhi2011 bullet uses a 0.04 meters as the collision margin
18:26.22 abhi2011 its cant simulate for less then that
18:26.59 abhi2011 I dont think testing with mm will work at the moment
18:27.14 abhi2011 I didnt even know the units could be changed at all :P
18:27.24 abhi2011 bullet uses only meters
18:27.34 elf_ well the distance between the ground plane and the cube in the mm sim was 50mm so about 0.05m
18:27.45 abhi2011 yep
18:27.51 elf_ the default it's mm, at least in the build I got
18:27.53 abhi2011 thats the collision margin
18:27.59 abhi2011 ok
18:28.20 abhi2011 yeah mged can show objects in the mm range
18:28.34 abhi2011 but bullet does not simulate at those low dimensions
18:29.05 elf_ I see
18:29.24 elf_ so the mm simulation it's kinda compromised then, meaning the results from there are not conclusive
18:29.25 abhi2011 in fact that bulet uses a 0.04 m collision margin, it would be best to work with objects significantly bigger
18:29.36 abhi2011 I dont think so
18:29.51 abhi2011 *in fact since
18:30.08 abhi2011 lets fix the unit as meters for now
18:31.00 abhi2011 if required bullet can be compiled with double precision and may work with smaller units
18:31.10 abhi2011 but thats for later
18:31.48 elf_ okay so I ran the simulation for 5500 steps and the cube was pretty close to the ground
18:32.08 abhi2011 did it fall at all ?
18:32.10 elf_ then I wanted to see how much closer can I get it so I ran it for another 800 steps
18:33.01 elf_ the cube went back to the top and started falling again to the ground
18:34.37 elf_ like this
18:34.39 elf_ http://imageshack.us/a/img17/2627/simlw.png
18:35.08 elf_ see the doubling of the cube up there
18:35.24 elf_ the original cube the one above and the cube that's falling again to the ground
18:35.40 elf_ at least now I know where it goes when I think it "disappears"
18:36.23 abhi2011 ok
18:36.41 abhi2011 isnt there any movement when run for 300 steps
18:36.49 abhi2011 or less ?
18:37.40 elf_ I am doing that right now, running it for 5800 steps
18:37.49 abhi2011 no i mean
18:37.52 abhi2011 simulate 300
18:38.03 elf_ just 300?
18:38.28 abhi2011 yes
18:40.00 elf_ this is it
18:40.00 elf_ http://imageshack.us/a/img839/2403/sim2g.png
18:40.08 elf_ no big change for the cube position
18:40.41 abhi2011 hmm that definitely should not happen
18:41.04 abhi2011 300 steps is enough steps to see a large change in the position
18:41.47 elf_ I know but still nothing major happens
18:42.07 abhi2011 ok lets try fixing this first
18:42.13 abhi2011 lets print out the position of the cube
18:42.46 abhi2011 so in get_transforms()
18:42.54 abhi2011 in simphysics.cpp
18:43.09 abhi2011 thats the function which get the transform from bullet
18:43.29 abhi2011 and puts it into a struct rigid_body
18:44.21 elf_ okay, so I should be printing the BB position in 3D space, right?
18:44.25 abhi2011 sim_params has a linked list of struct rigid body nodes
18:44.28 abhi2011 yes
18:45.10 elf_ the current_node->btbb_center,current_node->btbb_min and current_node->btbb_dims, right?
18:45.36 abhi2011 print aabbMin
18:45.40 abhi2011 thats directly from bullet
18:47.10 abhi2011 also comment out line 522
18:47.17 abhi2011 in simphysics.cpp
18:47.36 abhi2011 that will take the custom algorithm for cube-cube collisions out of the icture
18:48.49 abhi2011 also comment out lines
18:49.01 abhi2011 537 to 546
18:49.30 elf_ the overlap filter callback?
18:49.39 abhi2011 yes
18:49.54 abhi2011 right upto gContactDestroyedCallback = contact_destroyed;
18:50.53 elf_ about the custom algorithm it is there for when bullet it's not found?
18:51.08 abhi2011 so now we are using the default bullet algorithms for everything and have registered no callbacks
18:51.10 abhi2011 no its for
18:51.20 abhi2011 using ray tracing to detect overlaps
18:51.26 abhi2011 between arbitrary shapes
18:51.31 abhi2011 its based on librt
18:52.00 abhi2011 but we do not need it right now, since the default bullet algos. should also work to move the cube
18:52.16 abhi2011 if the cube is still too slow then we try printing the cube position
18:52.44 abhi2011 if the cube position is changing but mged is not getting updated then there also it may appear that the cube is not moving
18:52.58 abhi2011 that means there is a problem mapping the cube's position into the shape in mged
18:53.31 abhi2011 so we need to go step by step to figure out where the "apparent" slow down is happening
18:53.46 abhi2011 one thing is certain
18:53.56 abhi2011 the cube must fall much faster
18:54.21 abhi2011 and it will collide too, since we are now using bullet's own algos
18:55.24 elf_ I get the shadowing error again
18:56.53 elf_ http://paste.ubuntu.com/1221104/
18:59.34 abhi2011 revert your commented out lines and try to find out which line being commented out cause the error
19:00.19 elf_ I am on it
19:03.46 abhi2011 hmm, getting some errors in the windows build
19:03.55 elf_ like?
19:03.58 abhi2011 lets hope I can get it fixed
19:04.04 abhi2011 got to do with some path not found
19:07.36 abhi2011 http://paste.ubuntu.com/1221121/
19:07.44 abhi2011 52k lines of logs :P
19:08.39 *** join/#brlcad elf (~elf@213.233.85.6)
19:08.58 elf grrr blackout so I only have batery for one hour or so left
19:09.52 *** join/#brlcad elf_ (~elf@213.233.85.6)
19:10.20 abhi2011 ok, I ll continue working on it, its probably something silly since the entire set of calls has worked before
19:11.26 elf_ prolly I am doing definitely something wrong over here since I backed up my comments and now I get all kind of weird errors like not finding anything when I try to compile mged O.O
19:11.44 abhi2011 just revert you changed files
19:11.54 abhi2011 to the latest version
19:11.58 abhi2011 in svn
19:12.06 abhi2011 and start again
19:12.19 abhi2011 thats the safest and fastest way sometimes :P
19:12.43 elf_ yeah that's what I did just now
19:16.55 abhi2011 ok mged is runnig with bullet
19:17.01 abhi2011 so I can at least test
19:17.19 elf_ okay, I get the shadowing error because I added the bu_vls_printf command...
19:17.32 abhi2011 lets see if I can get a simple cube working again with no extra stuff
19:17.33 elf_ I don't understand why though?
19:17.36 abhi2011 ah great
19:17.56 abhi2011 check its source
19:18.18 abhi2011 if you are using eclipse, you press F3 :P
19:18.34 elf_ No, I don't use eclipse :)
19:19.45 abhi2011 hehe
19:20.10 abhi2011 bu.h then i think
19:20.23 elf_ yeah
19:20.48 abhi2011 in libboo
19:24.13 elf_ something's off since bu_vls_printf doesn't use any variable named size from what I can see
19:25.13 abhi2011 those build errors are while building the docs, so it should be ok
19:25.14 abhi2011 hmm
19:25.16 abhi2011 ok
19:25.22 abhi2011 you can try with printf for now then
19:26.49 abhi2011 hmm but I wonder why its happening though
19:27.00 abhi2011 i dont remember seeing that error before either
19:27.03 elf_ yeah printf will do for the moment
19:27.20 elf_ It's strange cause I get it at random times
19:27.25 abhi2011 vls i think is for variable length strings
19:27.36 abhi2011 it may be using size somewhere in there
19:28.56 abhi2011 bu_vls_printf() prints these strings as they are stored and maged differently from char[] i think
19:29.04 abhi2011 *managed
19:29.09 elf_ yeah and it uses a variable len
19:29.22 elf_ What I meant by getting it at random times
19:29.24 elf_ it's that
19:29.33 elf_ I commented line 522
19:29.34 elf_ I didn't get it
19:29.49 elf_ then I commented line 537 and I get it
19:30.06 elf_ if I comment the whole block 537 to 546 I get it
19:35.13 *** join/#brlcad elf_ (~elf@213.233.85.6)
19:35.56 abhi2011 ok, it passed in windows :P
19:36.04 elf_ good :)
19:36.13 abhi2011 hey what was the command for drawing a comb
19:36.36 abhi2011 darn i need that shrtcut list
19:36.59 elf_ r to create a region
19:37.12 elf_ I used regions and c for combs
19:37.17 elf_ if I remmeber correctly
19:37.32 elf_ I still can't figure what's this thing problem is
19:37.57 abhi2011 draw sim.c
19:38.17 abhi2011 hmm, so there are other places where bu_vls_printf is used
19:38.23 elf_ I am taking out things from it, it shouldn't give me errors when I take something that was there and wasn't giving errors about shadowing variables
19:38.58 abhi2011 whats your gcc version by the way
19:39.14 abhi2011 it should not make a difference
19:39.18 abhi2011 but lets see
19:40.59 abhi2011 ah now I remember why we chose to recreate the bullet world and add shapes again every time
19:41.05 elf_ bu_log is used in those lines I want to get out
19:41.11 abhi2011 ok
19:41.14 elf_ and I have the 4.6.1 version of gcc
19:41.32 elf_ Why did you recreate the world every time?
19:41.57 elf_ and it should give me errors when I try to add stuff... not when I take out stuff that it's standalone in there...
19:42.46 abhi2011 yeah
19:42.48 abhi2011 hmm
19:43.45 abhi2011 so which line in that entire bunch of lines in simphysics.cpp
19:43.51 abhi2011 cause the error
19:44.36 elf_ starting with 537
19:44.53 elf_ I even commented out the whole broadphase_call function..
19:44.56 elf_ didn't work obv
19:46.54 abhi2011 ok so lets try to figure out if its the presence of bu_log in other functions or the other bu_vls_printf() for some reason
19:47.02 CIA-68 BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Dog Collars - What You Need To Know]]": spam
19:47.10 CIA-68 BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:MelinaoewoywpoqcLegge]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
19:47.33 abhi2011 so lets comment out all the bu_vls_printf() lines
19:47.40 abhi2011 and check
19:47.48 abhi2011 then bu_logs and check
19:48.13 elf_ in the whole simphysics, right?
19:48.29 abhi2011 yep
19:48.33 abhi2011 its a rute force way
19:48.42 abhi2011 *brute
19:50.01 elf_ I get the error here
19:51.45 abhi2011 even after removing all the bus ?
19:52.01 elf_ even after removing all of them
19:52.49 abhi2011 dont remember seeing that -W shadow flag before
19:52.54 abhi2011 thats the one causing it
19:53.03 abhi2011 will need to check with brlcad
19:53.21 abhi2011 ok, so meanwhile
19:53.29 elf_ where's the flag set?
19:53.40 elf_ Sean? Are you around?
19:53.44 abhi2011 it will be in one of the cmake files I think
19:54.02 abhi2011 the top level one
19:54.10 abhi2011 anyway
19:54.20 abhi2011 its a warning right ?
19:54.40 abhi2011 so you are able to finish the compile ?
19:54.47 abhi2011 oh but
19:54.53 abhi2011 warning are flaggged as errors
19:54.55 elf_ it's a warning but the warnings are errors
19:54.57 elf_ yeah
19:54.58 elf_ that
19:55.02 abhi2011 hmm
19:55.05 abhi2011 :P
19:55.30 abhi2011 so how about not commenting out the lines
19:55.37 abhi2011 but keeping the functions empty
19:55.45 abhi2011 or putting a return as the 1st line
19:56.10 abhi2011 till we fix this shadow warning
19:56.29 abhi2011 we can put returns in the functions that the commented out lines cause to be called
19:56.45 abhi2011 so revert again :P
19:57.01 elf_ done it already
19:57.07 abhi2011 right
19:57.11 elf_ and now the return statements
19:57.18 elf_ for broadphase_callback
19:57.43 abhi2011 ok, so at least line 522 is commented out right ?
19:58.02 elf_ yeah that one works
19:58.07 abhi2011 538 ?
19:58.30 elf_ nope bu_logs all over that one
20:00.08 elf_ I might run out of battery, no energy yet O.O
20:00.36 abhi2011 ad removing the bu_logs from lines 329 to 383 makes no difference ?
20:00.43 abhi2011 ok
20:01.53 abhi2011 I also see that the mass of the body is set to 80000000 kgs
20:01.55 abhi2011 in s3.g
20:01.57 abhi2011 :P
20:02.07 abhi2011 that will certainly stall the sim
20:02.14 abhi2011 lets see if I can hard code the mass for now
20:02.18 elf_ It's not set to that
20:02.21 elf_ I wanted to ask you about it actually
20:02.28 abhi2011 ok
20:02.31 elf_ the mass of the body modifies DURING the simulation
20:02.34 elf_ that's wrong
20:02.41 abhi2011 hmm
20:02.58 elf_ The mass it's the same, the forces applied should modify
20:03.02 abhi2011 I dont remember pulling the mass from the passed sim_params
20:03.08 abhi2011 but let me check
20:03.14 elf_ It gets passed wrong then
20:03.30 abhi2011 i think I was just setting it proportional to the aabb volume
20:03.40 abhi2011 till the other issues got fixed
20:03.54 elf_ Hmm
20:04.06 elf_ let me run it again and see something
20:04.12 abhi2011 line 146
20:04.25 abhi2011 I ll try printing out the cube position
20:04.34 abhi2011 maybe there is a mapping problem back to mged
20:07.06 abhi2011 hmm, the volume is being calculated incorrectly
20:07.20 abhi2011 <PROTECTED>
20:07.27 elf_ I see that in the simulation too
20:07.31 abhi2011 to see if the cube collides properly
20:07.46 elf_ I gt like 8000000000kg...
20:08.22 abhi2011 yeah thats wrong
20:08.33 abhi2011 i hardcoded it to 1 kg for now
20:10.20 elf_ The hardcoded version is not working
20:10.29 elf_ I did it too, put the mass to 1 kg
20:10.33 elf_ but the cube is not movibg
20:10.36 elf_ moving*
20:10.54 abhi2011 whats the position thats printed ?
20:10.58 elf_ the forces are not applied properly I think or something somewhere goes really wrong
20:11.03 elf_ the same as the previous one
20:11.46 abhi2011 whats the linear and angular velocities
20:11.51 abhi2011 try printing out those 2
20:12.44 elf_ do you have a getLinearVelocity function>
20:12.45 elf_ ?
20:13.20 abhi2011 yes there is one like that
20:13.31 abhi2011 its used in the get_transforms()
20:16.16 elf_ can't print them.. the bu_vls_printf is not working again
20:16.16 elf_ grrr
20:16.45 abhi2011 but printf does right ?
20:19.01 elf_ it doesn't print it
20:19.17 elf_ I don't think it ever gets on that else case unless when it sets the mass
20:20.33 abhi2011 hmm but the condition simple says that if the name of the object is not the same as the ground plane name
20:20.36 abhi2011 then goto else
20:20.57 abhi2011 print both current_node->rb_namep and sim_params->ground_plane_name
20:21.12 abhi2011 before the if{}
20:21.12 elf_ It doesn't print this though printf("LinearVelocity %f AngularVelocity %f\n", current_node->linear_velocity, current_node->angular_velocity);
20:21.34 abhi2011 ok, but it enters the else {} ?
20:21.53 elf_ The mass it
20:22.18 elf_ s always the same so the thing that modifies is the velocity
20:22.18 elf_ it
20:22.21 elf_ <PROTECTED>
20:23.44 abhi2011 hmm, if get_transforms() gets called and there is a print statement there
20:23.54 abhi2011 then it should print the velocity
20:24.22 abhi2011 can you trying adding a print statement
20:24.30 elf_ Okay the velocities are both 0
20:24.34 abhi2011 at the beginning of get_transforms()
20:24.34 elf_ So that's not good
20:24.43 abhi2011 so after 2 steps also
20:24.49 abhi2011 the velocity is 0 ?
20:25.44 elf_ http://paste.ubuntu.com/1221254/ there it doesn't move
20:25.53 elf_ The velocity is 0
20:25.53 abhi2011 ok
20:25.54 elf_ both of them
20:27.02 abhi2011 bbmin is really wierd
20:27.38 abhi2011 ok lets hardcode the dimensions too
20:27.51 elf_ BBmax is weird too since the cube position is -1 1 -1 1 49 51
20:27.52 abhi2011 that should be the last piece of info we are transferring
20:28.02 abhi2011 yeah its not getting transferred
20:28.06 abhi2011 correctly
20:28.07 elf_ nope
20:28.19 abhi2011 change line 102
20:28.39 abhi2011 make it new btBoxShape(btVector3(10, 10, 10));
20:29.28 abhi2011 also same change in line 108
20:29.46 abhi2011 current_node->bb_dims[*]/2 with 10.0f
20:29.52 abhi2011 or 10 watever
20:30.14 abhi2011 this is the dimension of the ground plane
20:30.30 abhi2011 it may not match what we have in mged
20:30.35 abhi2011 but that doesnt matter
20:30.59 abhi2011 we are going to test only whether positions get transferred correctly
20:32.28 abhi2011 then in line 138
20:32.50 abhi2011 this is the section for the dynamic bodies
20:33.02 abhi2011 make the dimensions 1,1,1
20:34.23 abhi2011 I ll pastebin the changes
20:37.57 *** join/#brlcad elf (~elf@92.80.23.248)
20:38.59 *** join/#brlcad elf_ (~elf@92.80.23.248)
20:39.08 elf_ damn sorry abhi, just send you an email but I got power back
20:39.31 elf_ so yeah back to that simphysics.cpp file
20:49.51 elf_ This thing is getting stranger by the moment imo...
20:50.19 elf_ here's what the simulation looks like after the changes, hard-codding the dimensions and the mass of the cube
20:50.20 elf_ http://imageshack.us/a/img20/4735/test2r.png
20:50.28 elf_ http://paste.ubuntu.com/1221285/
20:50.40 elf_ it was ran for 30 steps...
20:52.27 elf_ brlcad, do you have any opinion about this? O.o
23:31.49 *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.