| 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) |
