IRC log for #brlcad on 20120923

00:36.59 *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
05:40.24 *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net)
07:07.36 *** join/#brlcad abhi2011 (~chatzilla@117.200.86.175)
07:23.40 *** join/#brlcad ksuzee (~ksu@193.151.107.42)
07:54.40 *** join/#brlcad abhi2011 (~chatzilla@117.200.83.2)
08:54.51 elf_ hey abhi
09:00.37 abhi2011 hi
09:02.10 elf_ Sorry again for last night, but the hard codding didn't work as expected, there are more problems, here's what I got after hardcodding the lines 102,108http://imageshack.us/a/img20/4735/test2r.png
09:02.11 elf_ http://paste.ubuntu.com/1221285/
09:02.56 elf_ the velocities still on zero, but the real the problem is that th BBmin and BBmax are still strantte
09:02.58 elf_ strange*
09:07.26 abhi2011 ok, yeah I am looking at it now
09:07.53 abhi2011 any luck with the bu_vls_printf() errors
09:10.13 elf_ No, look through the bu_vls_printf() and I can't figure out what the problem is, but the shadowing must happen between one 'size' variable from bullet and something similar from the printf routine, though there they use 'len'
09:11.28 abhi2011 you can also send out a mail in the brlcad mailing list with the error
09:11.39 abhi2011 someone there will have a better idea of whats going on
09:13.24 elf_ Good idea will do it
09:17.14 CIA-68 BRL-CAD: 03Elf11 07http://brlcad.org * r4444 10/wiki/User:Elf11: /* Log */
09:25.57 elf_ send that mail on the mailing list
09:32.08 abhi2011 compiles fine on windows :P
09:38.56 elf_ It does? with the bu_vls_printf?
09:39.29 abhi2011 yep
09:39.30 elf_ If that's the case I can change to windows, and compile it for VS too
09:39.36 abhi2011 err no
09:39.43 abhi2011 lets fix it in linux :)
09:39.59 elf_ okay
09:39.59 abhi2011 lets see when someone replies
09:40.17 abhi2011 the debugger in windows is a bit better thats why i use it
09:40.23 elf_ until then I will use printfs instead of the bu_vls_printf
09:40.28 abhi2011 yep
09:41.08 elf_ The VS ide is pretty nice, I like it too, but I work more in linux that's why I started in here
09:41.54 abhi2011 yeah brlcad should build smoothly in all platforms
09:42.01 abhi2011 thats why we use cmake
09:42.24 abhi2011 it used to build quite well in linux and windows , the last time I checked about a year ago
09:42.38 abhi2011 lot of code has been added since then
09:42.47 elf_ hmm if you say it goes okay in VS, maybe then it has something to do with the gdb config :-?
09:43.22 abhi2011 well I do not use gdb config so I cant say
09:44.27 elf_ hmm anyway, what it doesn't do in my version is that it doesn't calculate the mass correctly
09:44.36 elf_ hard-codded it so now it's 1kg
09:44.44 elf_ then the velocities are still 0
09:44.47 elf_ not good
09:45.05 elf_ also the bbMin and bbMax are all over the place even after hard-codding them
09:45.30 abhi2011 thats fine, the printed bbMin and bbMax are taken from sim_params
09:45.39 abhi2011 which as we know is not havng the right values
09:45.46 elf_ nope
09:46.10 abhi2011 it should and it used to, so I ll have to see later what went wrong
09:46.37 abhi2011 but for now with everything harcoded and just the positions transferred back mged, we should see the cube colliding
09:46.45 abhi2011 I am trying to get that working again
09:47.17 elf_ it uses just the center to collide so far, it should use more than that
09:47.55 elf_ were is the code for shooting rays through the geometry?
09:48.56 abhi2011 simrt.c and simrt.h
09:49.03 abhi2011 no it doesnt use the center
09:49.14 abhi2011 it appears that way because its mapped incorrectly
09:49.26 elf_ hmmm
09:49.53 abhi2011 the only way to debug this, since there is no independent way of looking at the bullet world
09:50.00 abhi2011 is to print out the cube position
09:50.21 abhi2011 and check whether the position stabilizes where the collision is supposed to occur
09:50.27 abhi2011 thats what I am trying to do
09:51.04 abhi2011 in games where bullet is generally used, there is an opengl renderer which provides and independent view of the dynamics world
09:51.12 abhi2011 unfortunately we do not have that here
09:51.57 elf_ well I am trying to say that if the cube would get stabilized where it should, on the ground surface then he won't go half way through the plane, that's not how it should work
09:52.17 abhi2011 yep thats right
09:52.36 abhi2011 so if mged is showing the cube as half through the plance
09:52.41 elf_ so if the bbMin and bbMax are wrong where are the right values?
09:52.52 abhi2011 aabbMin and aabbMax
09:53.16 abhi2011 see line 258 : bb_Shape->getAabb(bb_MotionState->m_graphicsWorldTrans, aabbMin, aabbMax);
09:53.31 abhi2011 thats a function call to bullet
09:53.31 elf_ those are the one that I printed, bbMin and bbMax from the file I pasted to you, in get_transform right?
09:54.13 elf_ so those are the ones that I get strange values for
09:54.13 abhi2011 oh ok
09:54.19 abhi2011 well let me check then
09:54.36 elf_ I thought there was something that I missed and there was someplace else where they were
09:54.48 elf_ sure check it :)
10:02.33 elf_ you know I get the aaBBMin and aaBBMax values printed 2 times for each step of the simulation even though there is only one line that prints them out, same with the Linear velocity and angular velocity
10:03.00 elf_ that means that the portion of code where this happens is called somehow 2 times, why?
10:03.41 elf_ and also the linear and angular velocities are both the same value in the both prints (zero) not the same can be said about the aaBBMin value
10:05.37 abhi2011 darn, the edit/debug cycle is really slow because of this multiconfig_path thing
10:06.06 abhi2011 apparently it makes a list of all files everytime and then compiles
10:06.24 abhi2011 it used to be much much faster :(
10:06.32 elf_ can't you compile just the section that you modified? like just mged?
10:06.40 elf_ I do that in linux
10:06.44 abhi2011 i am compiling only libged
10:07.03 abhi2011 i think thats the smallest target
10:07.11 abhi2011 mged will load libged.dll
10:07.14 elf_ yeah
10:07.18 abhi2011 or libged.so whatever
10:07.38 abhi2011 yeah thats really slow too
10:07.47 abhi2011 anyway
10:07.57 abhi2011 i am trying to figure out whats happening
10:07.59 abhi2011 lets see
10:12.56 elf_ let me know when you get it working
10:13.14 elf_ it should be better to test it for the same simple cube falling on the ground
10:13.18 elf_ I used this
10:13.20 elf_ units m
10:13.27 elf_ in gp rpp -15 15 -15 15 -1 1
10:13.35 elf_ in cube rpp -1 1 -1 1 49 51
10:13.40 elf_ r cube.r u cube
10:13.43 elf_ r gp.r u gp
10:13.46 elf_ ae 35 15
10:13.50 elf_ autoview
10:13.52 elf_ tra 0 10 0
10:13.58 elf_ simulate 30
10:14.23 elf_ for me the cube looks like in the image I send you earlier after 30 steps, halfway though the ground plane
10:14.49 elf_ and if you do it like that we can compare the aaBBMin and aaBBMax values
10:17.39 abhi2011 whats was the 49 and 51 for ?
10:17.46 abhi2011 for a rpp
10:18.11 elf_ well you set the cube up on the Z axis above the plane 50 units
10:18.31 elf_ you get Xmin Xmax Ymin Ymax Zmin Zmax
10:18.34 elf_ for an rpp
10:18.42 elf_ xy the horizontal plane
10:18.50 abhi2011 ah yes right
10:18.53 elf_ Z is the vertical axis perpendicular on that plane
10:19.40 elf_ for the cube with the lenght of 1 it will be like he has the center at 50 units above the ground plane that way
10:20.04 elf_ now that we hard-codded the cube dimensions to 10 it would be much closer to the gp
10:20.26 elf_ like just 1/9 of the cube above the 50 mark and the rest down of it
10:20.58 abhi2011 yep
10:21.00 elf_ but that shouldn't be a problem, since 10 < 50 so the cube should just fall a short way and then stop on the gp not half way through
10:23.39 abhi2011 yeah aabb min of the cube should be same same aabbmax of the ground cube
10:23.52 abhi2011 *same as
10:24.10 abhi2011 on collision
10:26.37 elf_ yep, what values do you get?
10:26.45 elf_ cause I don't get any reasonable ones
10:33.25 *** join/#brlcad Al_Da_Best (~Al_Da_Bes@027b4353.bb.sky.com)
10:40.57 elf_ abhi2011, you said that changing the lines 102 and 108 with the btVector3(current_node->bb_dims[0]/2,current_node->bb_dims[1]/2,current_node->bb_dims[2]/2) to btVector3(10,10,10) will set the cube dimensions to a hard-codded value right?
10:41.14 abhi2011 yes
10:41.31 elf_ I don't think that's right, I think that sets the ground plane dimensions to a hard-codded value of 10
10:41.49 elf_ that's why the simulation looks like the image I showed you earlier
10:41.52 abhi2011 yeah i had added more lines after you left yesterday
10:42.07 abhi2011 wait i ll paste bin the function
10:42.11 elf_ okay
10:42.29 elf_ still the problem is not with the ground plane so that one should be let alone, I think
10:43.01 elf_ the cube dimensions should be hardcodded and that's not the place where it should be done, I think it should be done on the else case
10:43.10 abhi2011 http://paste.ubuntu.com/1222218/
10:43.33 abhi2011 yeah but if the ground planes dimensions are not correct that will afect the simulation
10:43.48 abhi2011 anyway I made the ground plane into an actual static plane
10:43.52 abhi2011 of 0 thickness
10:43.58 abhi2011 and the cube is hardcoded
10:44.07 elf_ yeah I see that, about the ground plane
10:44.29 abhi2011 all the MAT_COPY stuff is commented out
10:44.40 abhi2011 that copies from sim_param
10:44.49 abhi2011 for the initial transform
10:45.04 elf_ hmm yeah
10:45.15 elf_ the cube now it's actually a sphere right?
10:46.33 abhi2011 yes
10:46.42 abhi2011 wont make a difference in the positions
10:47.01 abhi2011 until after collision
10:48.50 elf_ does the simulation run with the changes that you did on your end?
10:49.50 elf_ I am asking cause here it gets aborted once again...
10:51.48 *** join/#brlcad stas (~stas@host-static-92-115-48-61.moldtelecom.md)
10:52.10 abhi2011 comment out lines 466 to 470
10:52.16 abhi2011 in simulate.c
10:52.47 abhi2011 thats to apply the transforms in mged
10:52.55 abhi2011 the abort seems to be happening there
10:53.57 elf_ the rbA and rbB structs?
10:54.22 abhi2011 this part :
10:54.29 abhi2011 rv = apply_transforms(gedp, &sim_params);
10:54.31 abhi2011 if (rv != GED_OK) {
10:54.41 abhi2011 bu_vls_printf(gedp->ged_result_str, "%s: ERROR while applying transforms\n", argv[0]);
10:54.43 abhi2011 return GED_ERROR;
10:54.44 abhi2011 }
10:55.08 abhi2011 you are looking in simphysics
10:56.25 elf_ yeah
10:56.35 elf_ saw after that that you said simulate.c
10:59.34 abhi2011 no more aborts
10:59.39 abhi2011 now lets see
10:59.51 elf_ for me it runs without stopping
11:00.35 abhi2011 simulate 1 also ?
11:00.42 abhi2011 oh do one more thing
11:00.54 abhi2011 comment out line 448
11:01.00 abhi2011 in simulate.c
11:01.08 abhi2011 I am removing all ray tracing stuff
11:01.19 abhi2011 the ray tracing generates too much output
11:01.50 abhi2011 uncomment line 238 in simphysics.cpp
11:01.57 abhi2011 bu_vls_printf(sim_params->result_str, "Position : %f, %f, %f\n", m[12], m[13], m[14]);
11:02.29 abhi2011 or rather make it into a bu_log staement
11:02.31 elf_ to print the final position?
11:02.34 abhi2011 yes
11:03.00 abhi2011 bu_log("Position : %f, %f, %f\n", m[12], m[13], m[14]);
11:03.02 elf_ where is all the rt stuff called?
11:03.07 elf_ yeah did that
11:03.44 abhi2011 it called in simrt.c
11:03.57 abhi2011 which is supposed to have a custom algo based on raytracing
11:04.06 abhi2011 for detecting overlaps between 2 cubes
11:04.17 abhi2011 this algo is no longer registered with bullet
11:04.26 abhi2011 (we commented it out)
11:04.32 abhi2011 so it will no longer be called
11:04.52 abhi2011 apart from the ray tracing is initialized in init_raytrace(&sim_params);
11:05.00 abhi2011 line 448 in simulate.c
11:05.08 abhi2011 but we commented out that too
11:05.20 abhi2011 so now we are using only bullet's default algos
11:05.25 abhi2011 which will do the job too
11:05.46 elf_ so we comment out th init_raytrace(&sim_params) in simulate.c
11:05.54 elf_ and what else?
11:07.19 abhi2011 nothing else
11:07.27 abhi2011 lets try running it
11:11.50 abhi2011 the dynamic rigid body's position needs to be greater than 0
11:12.12 elf_ what's your output? can you paste it somewhere?
11:12.23 abhi2011 i am stil changing it
11:12.31 abhi2011 <PROTECTED>
11:12.33 abhi2011 btVector3(0, 0, 0)));
11:12.35 abhi2011 this is line 151
11:12.39 abhi2011 <PROTECTED>
11:12.49 abhi2011 i am just testing with this
11:19.18 elf_ well the difference I see after running it with that line up there is that now the end position of the falling geometry is inside the ground
11:19.29 elf_ Position : 0.000000, 0.000000, -1.000000
11:19.59 abhi2011 hmm it should be : btDefaultMotionState* bb_MotionState = new btDefaultMotionState(btTransform(btQuaternion(0, 0, 0, 1),
11:20.01 abhi2011 btVector3(0, 10, 0)));
11:20.23 abhi2011 the quaternion is for rotation
11:20.31 abhi2011 the vector3 is for the origin
11:20.40 abhi2011 both combine to make the transform
11:20.56 abhi2011 both are args to the btTransform ctor
11:21.09 abhi2011 darn
11:21.14 elf_ ?
11:21.27 abhi2011 btDefaultMotionState* bb_MotionState = new btDefaultMotionState(btTransform(btQuaternion(0, 0, 0, 1),
11:21.30 abhi2011 btVector3(0, 0, 10)));
11:21.38 abhi2011 10 units up on the z axis
11:21.40 abhi2011 not y
11:21.46 elf_ yeah
11:21.53 elf_ I put them on the Z
11:23.18 elf_ hmmm I get this btDefaultMotionState* bb_MotionState = new btDefaultMotionState(btTransform(btQuaternion(0, 0, 10, 1),
11:23.18 elf_ <abhi2011> btVector3(0, 0, 0)))
11:23.25 elf_ ahh not that one
11:23.30 elf_ Position : 0.000000, 0.000000, -1.000000
11:23.31 elf_ get_transforms: Dimensions of this BB : 1999999968613498880.000000 1999999968613498880.000000 1999999968613498880.000000
11:23.31 elf_ Position : 0.000000, 0.000000, 9.997222
11:23.31 elf_ get_transforms: Dimensions of this BB : 1.000000 1.000000 1.000000
11:23.32 elf_ simulate: The simulation result is in group : sim.c
11:23.35 elf_ tha
11:23.36 elf_ t
11:23.53 abhi2011 try runnign for a few more steps
11:23.58 abhi2011 the 2nd position is the shere
11:24.02 abhi2011 *sphere
11:24.09 elf_ yeah that one looks good imo
11:24.13 elf_ it should be there
11:24.35 abhi2011 unfortunately i do not get any movement :P
11:24.51 elf_ it's really small the movement I mean
11:24.58 elf_ I ran it for another 3 steps
11:25.04 elf_ and this is the new position of the sphere
11:25.05 elf_ <PROTECTED>
11:25.05 elf_ <abhi2011> btVector3(0, 0, 0)))
11:25.09 elf_ not again
11:25.15 abhi2011 ?
11:25.21 elf_ I always forget it doesn't work that way to copy paste from mged
11:25.28 elf_ Position : 0.000000, 0.000000, 9.991667
11:25.32 elf_ that one
11:25.40 abhi2011 ok so it is accelerating
11:25.46 abhi2011 thats how it shud be
11:25.58 abhi2011 check this with the hellow world app output
11:26.01 elf_ yeah I let it run for some more steps
11:26.03 elf_ lets see
11:26.22 abhi2011 it shud stop at 0.5
11:26.34 abhi2011 the center of the sphere will be at 0.5
11:26.39 abhi2011 as the radius is 0.5
11:27.05 abhi2011 darn forgot to save the file
11:27.09 abhi2011 ok lets try again
11:27.12 abhi2011 :sigh:
11:27.49 elf_ I ran it for 30 steps... I got a mess... http://paste.ubuntu.com/1222279/
11:30.30 abhi2011 hmm
11:31.36 elf_ well after 40 steps this is how far it has moved.. Position : 0.000000, 0.000000, 9.944445
11:31.40 elf_ that's not a lot
11:31.44 elf_ and I still get that mess
11:33.50 abhi2011 yeah remove those output lines
11:34.16 abhi2011 the one tha prints : get_transform : aaBBMin -5724593028653935111469506849925777538048616085059274744487769129466414820852884796651876100297183267000396656472042632853955496324592056664064.000000 aaBBMax 0.000000
11:34.18 abhi2011 get_transform : aaBBMin -0.000031 aaBBMax 0.000000
11:34.38 abhi2011 then the output wil be easier to read
11:35.35 abhi2011 http://paste.ubuntu.com/1222294/
11:37.08 elf_ yeah it's similar to what I've got
11:38.12 elf_ Don't you think it still moves too slowly? after 140 steps it got only here
11:38.25 elf_ Position : 0.000000, 0.000000, 9.722222
11:38.51 abhi2011 yeah thats wierd
11:40.24 abhi2011 its prolly got to do with the fact that we are setting the velocity in every iteration
11:40.39 abhi2011 prolly the velocity is not getting set correctly
11:40.44 abhi2011 lets print the velocities
11:41.22 elf_ in simphysics.cpp add rigid bodies on the else case right?
11:41.58 abhi2011 yes
11:42.31 elf_ bbRigidBody has any field linear/angular velocity?
11:42.45 elf_ Or do we take it from the current_node->linear_velocity when we print it?
11:44.08 elf_ found it never mind
11:46.18 abhi2011 oh shoot
11:46.39 abhi2011 we are restarting the sim from 10 each time :P
11:46.50 abhi2011 since we have hardcoded it
11:47.26 elf_ yes we do but after 200 steps it goes jsut till 9.4222
11:47.34 abhi2011 yes thats cause as I have said
11:47.46 abhi2011 we recreate the bullet world in each iteration
11:47.54 abhi2011 we do not run a loop in run_simulation
11:48.03 abhi2011 we call run_simulation itself 200 times
11:48.05 abhi2011 :P
11:48.07 elf_ ahhh I thought you meant something else
11:48.20 abhi2011 the reason we do that is a bit complicated
11:48.26 abhi2011 but I ll try n explain
11:48.35 abhi2011 its got to with the raytracing stuff
11:48.38 abhi2011 1 sec
11:48.41 elf_ okay
11:48.41 abhi2011 i ll go grab some tea
11:51.03 abhi2011 so when simulate 10 is called then ged_simulate() gets called right
11:51.15 elf_ right
11:51.35 abhi2011 ged_simulate() add the regions in the .g file using add_regions()
11:51.42 abhi2011 in line 423
11:52.24 abhi2011 every regions gets its own node in the list of struct rigid_body nodes
11:52.34 elf_ okay
11:52.38 abhi2011 the head of this list is stored in sim_params
11:52.52 abhi2011 in struct rigid_body *head_node
11:53.00 abhi2011 see simulate.h
11:53.02 abhi2011 anyway
11:53.26 abhi2011 so the loop for the simulation is just after that
11:53.57 abhi2011 in the loop we create a combination representing the regions in their new positions
11:54.28 abhi2011 that is there is a comb called sim.c and below it there is a copy of all the regions being simulated
11:54.48 abhi2011 but having transforms as returned by bullet
11:55.12 abhi2011 this is to prevent modifying the original regions and their locations
11:55.28 abhi2011 so sim.c gets created in recreate_sim_comb()
11:55.31 abhi2011 all ok so far ?
11:55.45 elf_ okay
11:56.52 abhi2011 after that we call run_simulation() which simply scans the list passed in sim_params and adds the objects whose information is present at each node
11:57.18 abhi2011 the number of nodes = the number of regions being simulated = the number of rigid bodies inserted into the bullet sim
11:57.38 abhi2011 so in our case there should be 2 nodes
11:57.52 elf_ gp and the sphere/cube
11:58.07 abhi2011 yes
11:58.20 abhi2011 the ground plane has a fixed name as you know
11:58.26 elf_ yes
11:58.48 abhi2011 and in simhysics.cpp i detect this name and make the corresponding object a static object(not dynamic)
11:58.54 abhi2011 so the ground plane never moves
11:59.06 abhi2011 the other objects will be dynamic
11:59.07 elf_ okay, got that
11:59.12 abhi2011 anyway t
12:00.01 abhi2011 so in run_simulation we create the simulation world from scratch and add objects, run the sim for just 1 step and get back the transforms in sim_params
12:00.09 abhi2011 then delete the bullet sim stuff
12:00.16 abhi2011 dynamics world, collision shapes etc
12:00.22 elf_ shouldn
12:00.29 elf_ t we run it all in run_simulation
12:00.35 elf_ I mean for more than one step
12:00.37 abhi2011 yep coming to that
12:00.41 abhi2011 we could do that
12:00.44 elf_ okay :)
12:00.59 abhi2011 and thats the easiest way and I do that for debuggng sometimes
12:01.06 abhi2011 but the problem is
12:01.12 abhi2011 or rather the feature
12:01.24 abhi2011 that brlcad can produce arbitrary shpes
12:01.39 abhi2011 like a arbn
12:01.47 abhi2011 or a tgc
12:01.49 elf_ okay
12:02.03 abhi2011 these shapes cannot be created directly in bullet
12:02.13 abhi2011 bullet has only a limited number of primitives
12:02.29 elf_ right
12:02.33 abhi2011 sphere, cone, cylinder and very few tohers
12:02.53 abhi2011 so the question was how do we support collisions for these shapes
12:03.19 abhi2011 a reasonable (perhaps not the best way) to do it is
12:03.27 abhi2011 to run the simulation for 1 step
12:03.37 abhi2011 then get back the transforms into mged
12:04.06 abhi2011 then hit the overlapping regions with rays
12:04.20 abhi2011 using the fast raytracing library
12:04.23 abhi2011 librt
12:04.30 elf_ okay
12:04.50 abhi2011 so we can get the exact contact points and penetrations information this way
12:05.15 abhi2011 these are put into the proper structures in sim_param
12:05.27 abhi2011 for the next iterations
12:05.43 abhi2011 now the catch here is
12:06.07 abhi2011 if we run the sim loop in run_simulation()
12:06.16 abhi2011 then we cant update mged at every step
12:06.28 abhi2011 we will get only the final position after the simulation completes
12:06.39 abhi2011 for updating mged and using librt
12:06.49 elf_ we need intermediate positions
12:06.50 abhi2011 we need to get out of run_simulation, or return from it rather
12:06.54 abhi2011 yep
12:07.06 abhi2011 so my solution was to
12:07.20 abhi2011 recreate the simulation at every step
12:07.34 abhi2011 with the state information stored in sim_params
12:07.43 abhi2011 in between loop iterations
12:07.51 abhi2011 with the loop being in ged_simulate()
12:08.02 abhi2011 if we are not bothred with ray tracing
12:08.06 abhi2011 then we can run the loop
12:08.12 abhi2011 in run_simulation()
12:08.37 abhi2011 but that will not meet the criteria of supporting arbitrary shapes
12:08.53 abhi2011 there are 4 things in the stae info
12:08.58 elf_ couldn't there be a way to use rt in the run_simulation() loop?
12:09.02 abhi2011 *state info
12:09.18 abhi2011 there could be
12:09.45 abhi2011 but you have to put the updation code in there
12:09.57 abhi2011 to update the raytracing world
12:10.07 abhi2011 right now
12:10.15 abhi2011 what I do is update mged
12:10.35 abhi2011 that also updates the ray tracing world
12:10.46 abhi2011 and allows the rays to detect objects in their new positions
12:11.04 elf_ hmm how exactly updating mged updates the rt world?
12:11.15 abhi2011 i do not know
12:11.32 abhi2011 but when rays are shot then objects are detected
12:11.32 elf_ Oh so it's something that's outside the simulate command
12:11.37 abhi2011 yes
12:11.53 abhi2011 as in the code is outside
12:12.17 abhi2011 but apply_transforms() does the updating
12:12.21 abhi2011 using libged commands
12:12.49 abhi2011 so that updates the internal structures for ray tracing to work on the objects in their new positions
12:13.10 abhi2011 so if you look at the commands you will see that it ultmately updates stuff in the .g file
12:13.16 abhi2011 and librt reads from there
12:13.31 elf_ maybe something like that could be done so that it will work inside the run_simulation()
12:13.34 abhi2011 actually it updates the in -mem representation f the scene
12:13.48 abhi2011 yep
12:13.57 abhi2011 however this appraoch also works :P
12:14.03 abhi2011 just have to fix it
12:14.08 elf_ It does
12:14.09 abhi2011 i remember it working before
12:14.26 abhi2011 but you can try the other approach too
12:14.43 elf_ hmm we'll see
12:14.46 abhi2011 i just found the curent way simpler in the limited time i had
12:14.48 abhi2011 :P
12:15.10 elf_ Yeah, it is a little bit simpler
12:15.37 elf_ now the question is why it's not working properly for the current simulation?
12:17.38 abhi2011 i ll check that in a min
12:17.40 abhi2011 brb
12:18.41 elf_ okay
12:37.52 abhi2011 hm i have an idea of why we get the variation in the position of the sphere
12:38.04 abhi2011 in our current hardcoded state
12:38.17 abhi2011 it should be same each time
12:38.21 abhi2011 since at every step
12:38.32 abhi2011 we start from the same position
12:39.21 elf_ right
12:39.42 abhi2011 the linear velocity is being preserved and saved in sim_params
12:39.55 abhi2011 its being applied to the sphere before each iterations
12:40.00 abhi2011 *iteration
12:40.21 abhi2011 so the linear vel will keep increasing
12:40.53 abhi2011 as would be the case anyway, if the position of the sphere were changing
12:41.13 abhi2011 thats causes a greater drop from 10 each time
12:41.29 elf_ right it would make sense
12:41.42 abhi2011 lets print the lnear velocity just before its set
12:41.50 abhi2011 in add_rigid_body()
12:41.52 abhi2011 else case
12:41.56 abhi2011 see if its increasing
12:42.21 elf_ yeah, so we should print the bb_RigidBody->linear_velocity
12:42.27 abhi2011 yes
12:43.00 abhi2011 the position difference should be 10 - linear_velocity.z
12:43.08 abhi2011 every time
12:45.21 abhi2011 hmm i see we are setting a higher linear vel each time
12:45.36 abhi2011 so there is a higher drop within the timespan of 1 step each time
12:46.00 abhi2011 combined with the fact that we start from 10 each time, that is why movement appears slow
12:46.02 abhi2011 :P
12:46.17 elf_ I got a little problem
12:46.24 elf_ I printed this printf("BEFORE SETTING : LinearVelocity %f AngularVelocity %f\n", bb_RigidBody->linear_velocity.z, bb_RigidBody->angular_velocity.z);
12:46.38 abhi2011 ok
12:46.44 elf_ before the VMOVE(V, current_node->linear_velocity);
12:46.44 abhi2011 i think z()
12:47.01 elf_ ahh that's what I was going to ask if there was a function or just a var
12:47.09 abhi2011 :)
12:47.23 elf_ cause I get an error and can't find it through all the output I get from gdb... about size stuff
12:48.15 abhi2011 yeah gdb produces too much output
12:48.18 elf_ that wasn't it, called it as bb_RigidBody->angular_velocity.z()
12:48.27 elf_ and I still get the error
12:49.28 abhi2011 oh thats cause bb_RigidBody is a struct rigid_body
12:49.46 abhi2011 that my own structure
12:49.49 abhi2011 in it
12:49.58 abhi2011 angular_velocity is defined as vect_t
12:50.10 abhi2011 bu_log("Setting linear velocity as : %f, %f, %f",
12:50.12 abhi2011 <PROTECTED>
12:50.14 abhi2011 <PROTECTED>
12:50.15 abhi2011 <PROTECTED>
12:50.48 abhi2011 oh wait bb_RigidBody is a btRigidBody
12:51.12 abhi2011 well if you print the velocity from bb_RigidBody then you will not get the right velocity
12:51.16 abhi2011 as its not yet set
12:51.26 elf_ hmm you are right
12:51.29 abhi2011 you need to print the velocity in the current_node
12:51.37 abhi2011 as thats where its pulled from
12:51.39 abhi2011 and saved to
12:52.43 abhi2011 so the struct rigid_body (all lower case ) is my own structure
12:53.18 abhi2011 it has a lot of fields specific to our situation
12:53.26 abhi2011 btRigidBody is provided by Bullet
12:53.28 elf_ okay, I used that bu_log statement you pasted
12:53.36 abhi2011 ok
12:53.45 elf_ yeah, figured that all the structures with bt in name are bullet provided
12:53.48 elf_ right?
12:53.51 abhi2011 yep
12:55.52 abhi2011 printf() wasnt printing inside mged
12:56.00 abhi2011 but bu_log() does
12:58.15 elf_ I still get lots of output for it
12:58.16 elf_ http://paste.ubuntu.com/1222440/
12:59.47 abhi2011 yeah you need to comment out those lines in run_simulation()
13:00.12 abhi2011 at least line : dispatcher->registerCollisionCreateFunc(BOX_SHAPE_PROXYTYPE,...
13:00.57 elf_ it's commented
13:01.21 elf_ I mean that's the output I get with that line commented
13:01.46 abhi2011 how about dynamicsWorld->getPairCache()->setOverlapFilterCallback(filterCallback);
13:05.07 abhi2011 also below it : dispatcher->setNearCallback((btNearCallback)nearphase_callback);
13:07.29 elf_ looks better no
13:07.30 elf_ w
13:08.40 abhi2011 can you paste the output
13:08.45 elf_ http://paste.ubuntu.com/1222460/ that's my outpu
13:09.09 abhi2011 yeah
13:09.21 elf_ do you get something similar?
13:09.24 abhi2011 so as you can see the linear velocity is being saved
13:09.25 abhi2011 yes
13:09.28 abhi2011 its same
13:09.47 abhi2011 now
13:10.00 abhi2011 we have to get the objects from mged into the sim
13:10.10 abhi2011 and remove all the hardcoded stuff
13:10.25 elf_ okay
13:10.59 abhi2011 all regions in mged are inserted as cubes in bullet
13:11.08 abhi2011 the region can be any arbitrary shape
13:11.13 elf_ yeah bounding boxes
13:11.20 abhi2011 yes
13:11.57 abhi2011 the idea was to generate the contact points using ray tracing so the actual collision behavior will be according to the true shape
13:11.59 abhi2011 and not a cube
13:12.18 abhi2011 even though we use cubes, or rather cuboids got from the AABB
13:12.27 elf_ okay
13:12.44 abhi2011 so for sphere rolling on the ground
13:13.06 abhi2011 the aabb will look like its penetrated the ground after the sphere rolls by 45 degress
13:13.31 elf_ right that makes sense
13:14.17 abhi2011 right so lets check first whether positions are getting mapped back to mged correctly
13:14.51 abhi2011 i ll try to fix apply_transforms() and let you know
13:15.20 abhi2011 no point in both of us working in lock step :P
13:17.24 elf_ the checking should be done in apply transform right?
13:18.00 abhi2011 umm checking ?
13:18.17 elf_ if the position are getting mapped correctly
13:18.19 elf_ I mean
13:18.35 abhi2011 yes
13:18.39 abhi2011 the mapping
13:18.57 abhi2011 its done in apply_transforms
13:19.09 elf_ okay
13:19.19 abhi2011 i move the shape back to origin using inverse transform
13:19.25 abhi2011 do rotation
13:19.33 abhi2011 then translation
13:21.27 abhi2011 blackout !
13:21.32 abhi2011 see you later !
13:21.38 elf_ okay
13:22.01 elf_ I will look through the apply_transforms too
13:28.37 *** join/#brlcad abhi2011 (~chatzilla@117.200.83.2)
13:28.54 abhi2011 back !
13:30.46 abhi2011 i have uncommented line 257 in get_transforms()
13:30.53 abhi2011 print_matrices(current_node->rb_namep, current_node->m, m);
13:31.01 abhi2011 that causes this output :
13:31.42 abhi2011 http://paste.ubuntu.com/1222497/
13:54.08 elf_ yeah I played with that one too
13:57.02 abhi2011 the error is in insert_AABB()
13:57.06 abhi2011 its not needed right now
13:57.15 abhi2011 prolly can comment out
13:57.44 abhi2011 i mean comment out in apply_transforms()
13:58.00 abhi2011 thats just to display the new AABBs in mged
14:10.03 elf_ hmm wait what should we comment out in apply_transforms()?
14:15.49 elf_ okay hmm I get the same output with and without the insert_AABB line in apply_transforms
14:28.34 abhi2011 ok
14:28.45 elf_ do you get something different?
14:29.00 elf_ I am running a debugger over it right now, step by step
14:29.01 abhi2011 yeah I get a stack corruption with insertAABB
14:29.06 abhi2011 in the cmd_args aray
14:29.09 elf_ hmmm
14:29.12 abhi2011 i can dismiss it and continue
14:29.18 abhi2011 but anyway
14:29.24 abhi2011 thats not needed right now
14:29.33 elf_ maybe you have commented more lines out than necessarily
14:29.43 abhi2011 could be
14:30.11 abhi2011 right now I am checking if the cube is inserted into the dropped position in the 2nd iteration
14:30.21 abhi2011 or the original starting position
14:30.28 abhi2011 it should be at the dropped position
14:32.18 elf_ aha
14:33.43 abhi2011 hmm it is
14:33.51 abhi2011 still its dropping very slowly
14:33.59 abhi2011 its weird
14:35.41 elf_ well then it's from somewhere else
14:36.24 abhi2011 the velocity is going up
14:36.31 abhi2011 but the position is not changing as fast
14:37.05 elf_ where were you updating the position?
14:39.38 abhi2011 apply_transforms()
14:39.46 abhi2011 i am convinced that this is a units issue
14:40.19 abhi2011 bullet is saying its placed the object at : 49,000 someting
14:40.20 abhi2011 Added new rigid body : sim_cube.r to simulation with mass 1.000000 Kg at (0.000000,0.000000,49876.246094)
14:40.25 abhi2011 that should not happen
14:40.38 abhi2011 it means mged is supplying the units in mm
14:40.41 elf_ it should be 49.876
14:40.44 abhi2011 the height is dropping
14:40.50 abhi2011 buts its in the units place
14:40.58 abhi2011 as it shoudl be
14:41.13 abhi2011 ok, but mged has to supply the height in meters
14:41.23 elf_ the units are set to meters if mged is not supplying the units right then...
14:41.24 abhi2011 or we divide by 1000 in bullet
14:41.41 elf_ when you type units in mged window you get something like 1m = 1000mm that's correct
14:42.18 abhi2011 i get
14:42.19 abhi2011 You are editing in 'mm'. 1 mm = 1 mm
14:42.27 elf_ but I think it gets transferred as meters but in mm units, as in we have 49 meters okay then we send 49kmm
14:42.38 abhi2011 hmm
14:42.47 abhi2011 ok
14:42.52 abhi2011 so now matter what units i have
14:42.57 abhi2011 millimeters or meters
14:42.59 elf_ that's wrong, I said that before making a new database you should set units m
14:43.08 abhi2011 its transferring it as 49999
14:43.41 abhi2011 yes it was set to meters
14:44.02 abhi2011 do you see your output as 49.000 something ?
14:44.15 abhi2011 i mean in the bullet matrices
14:44.18 abhi2011 and positions
14:44.29 elf_ that's what I get http://paste.ubuntu.com/1222635/
14:45.08 elf_ but you see the plane dimensions are 15 not 15K so it is transferred in milimeters
14:45.33 abhi2011 yeah thats fine in the bullet matrix outputs
14:45.45 elf_ I am talking about the sim_gp.r and sim_cube.r
14:45.55 abhi2011 as you have the positions hardcoded still
14:46.04 abhi2011 i have reverted to the code in svn
14:46.10 elf_ you mean you get 49k in the matrice?
14:46.11 abhi2011 where I pick up dimensions from mged
14:46.14 abhi2011 yes
14:46.19 elf_ what have you changed?
14:46.39 abhi2011 one sec i ll commit to svn
14:47.25 elf_ okay
14:51.09 CIA-68 BRL-CAD: 03Abhi2011 * r52516 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simutils.c): Fixing the simulate function. There are a number of debugging lines still present. These will be removed soon.
14:51.27 abhi2011 update
14:51.51 abhi2011 there are a lot of indentation related changes
14:51.55 abhi2011 so just ignore those
14:54.13 elf_ kay getting them now
15:00.56 elf_ darn should have just updated my current version not try and get the whole repo again
15:02.58 abhi2011 :P
15:05.15 elf_ ahh you took out the hardcodded parts
15:06.08 abhi2011 yes
15:06.18 abhi2011 does it compile without shadows ?
15:07.08 elf_ I am making another build for that one, since I got it from the latest version of the svn so I have to wait if it compiles without shadow
15:08.04 elf_ anyway I think the shadow problems occur just when I butch on some of the code, I tried using again the bu_logs in my version of the code and it worked, so most probably I was doing something wrong
15:08.08 elf_ before
15:09.34 abhi2011 cool
15:14.10 abhi2011 ok the positions are fine now
15:14.14 abhi2011 I ll commit the new code
15:14.40 abhi2011 its not updating mged yet though
15:14.56 abhi2011 but its coming to a halt at 1.9999
15:15.01 abhi2011 which is correct
15:15.10 abhi2011 as the ground plane in your s3.g
15:15.24 abhi2011 is 2 m in height with center at 0,0,0
15:15.32 abhi2011 and the cube is also 2 m in height
15:15.49 abhi2011 so the center of the cube on collision will be at 1 + 1 = 2 m
15:16.01 elf_ that's right
15:16.14 abhi2011 i ll commit the new code again
15:16.15 elf_ what was wrong with the positions?
15:16.40 elf_ okay I'll wait to finish this building and then update only the changes
15:17.19 abhi2011 yep
15:17.28 abhi2011 and now to fix this mged updating thing
15:17.34 elf_ I mean what did you change for the position to be right?
15:17.38 CIA-68 BRL-CAD: 03Abhi2011 * r52517 10/brlcad/trunk/src/libged/simulate/simulate.c: More fixes. Scaled the mged supplied AABB bounds by 0.0001 to bring it into meters before feeding into bullet.
15:17.50 elf_ ahh you scalled it
15:17.55 abhi2011 yeah :P
15:18.13 abhi2011 what else to do, i dunno what mged is mucking up at the moment
15:18.28 elf_ that's tricky.... maybe the problem wasn't from there, will have to tell Sean about this one
15:18.33 abhi2011 yeah
15:18.42 elf_ if mged is getting the units wrong that's a big problem
15:19.00 abhi2011 we are prolly not executing the right commands
15:19.08 abhi2011 i can see 15 and 50 etc
15:19.16 abhi2011 in the primitive editor
15:19.19 elf_ though I tend to think we are doing something wrong in the code
15:19.23 elf_ 15 and 50?
15:19.33 abhi2011 in mged opengl wndow
15:19.33 elf_ darn this build takes forever...
15:19.42 abhi2011 if you select a primitive
15:19.56 abhi2011 edit > primitve selection
15:20.05 abhi2011 then goto
15:20.14 abhi2011 edit > primitve editor
15:20.24 abhi2011 you can see the details of the object
15:20.34 abhi2011 that does know abut the units
15:21.41 abhi2011 strange
15:21.45 abhi2011 it does about the units
15:21.53 abhi2011 but if i select meters as the unit
15:22.07 abhi2011 the primitive editor shows me .001 m
15:22.15 abhi2011 if i make the units as mm
15:22.18 abhi2011 then it show 1 mm
15:22.35 abhi2011 so the cubes in te s3.g file were created with mm dimensions
15:22.52 abhi2011 hmm
15:22.59 elf_ what does the units command tell you?
15:23.02 elf_ type units
15:23.05 elf_ in mged
15:23.24 abhi2011 You are editing in 'm'. 1 m = 1000 mm
15:23.33 elf_ so it was created with meters not mm
15:23.45 abhi2011 no
15:23.49 elf_ I assume that you didn't select units m before
15:23.55 abhi2011 when I goto primitive editor
15:24.06 abhi2011 i can see the dimensions of the cube as 0.001 mm
15:24.10 abhi2011 so it was made in mm
15:24.25 abhi2011 sprry
15:24.28 abhi2011 0.001 m
15:24.48 abhi2011 umm u understand what I mean ?
15:24.57 abhi2011 see the cubes must have been in mm
15:25.14 abhi2011 else the prim editor would not say the dimension as 0.001
15:25.20 abhi2011 when I am in units = meters
15:25.20 elf_ send you another database, it has the same geometry as the one you got
15:25.40 abhi2011 ok
15:25.42 elf_ I am looking at it right now and I get ARB8 V1:(1,-1,49)
15:25.44 elf_ which is right
15:26.15 abhi2011 yes but what do you see in the primitive editor
15:27.23 elf_ and I am looking at the primitive editor in this one too it looks like this
15:27.24 elf_ http://imageshack.us/a/img826/4358/screenshotat20120923182.png
15:27.26 abhi2011 what was the command for getting ARB8 V1:(1,-1,49)
15:27.39 abhi2011 yes
15:27.48 elf_ if you are getting that it's not right... cause the units used to create the geometry are selected as meters
15:27.49 abhi2011 so that means your units are currently in meters
15:27.53 elf_ so something's wrong
15:27.59 abhi2011 hmm
15:28.31 abhi2011 ok my units are currently st to meters
15:30.06 *** join/#brlcad elf_ (~elf@109.97.187.115)
15:30.14 elf_ and the arb8 thing you get in the mged window with Keypoint:ARB8 V1:(1,-1,49), on the margin of the window, where you get also the az, el and other info
15:34.08 abhi2011 ok there was a command to print out all the vertices i think
15:34.44 abhi2011 for a arb8 i mean
15:36.19 *** join/#brlcad elf__ (~elf@92.80.8.106)
15:36.48 elf__ Grrr damn it keep getting kicked O.O
15:38.04 abhi2011 yeah you are right
15:38.09 abhi2011 I did l cube
15:38.20 abhi2011 its printing the vertices as 1000 etc
15:38.25 abhi2011 while unit = mm
15:38.39 abhi2011 but the prim editor shows it as 1.000
15:38.48 abhi2011 thats weird
15:38.49 elf__ so something's wrong
15:38.59 abhi2011 yeah
15:39.01 abhi2011 well anyway
15:39.03 elf__ I think it's somewhere outside simulate command
15:39.09 abhi2011 yep
15:39.21 abhi2011 so lets see whats up with mged updating
15:40.26 abhi2011 i think if the units are wrong
15:40.36 abhi2011 and the objects are being moved only by 49 mm
15:40.41 abhi2011 then there will a problem
15:40.55 abhi2011 we will have to scale the tranforms back
15:41.01 elf__ I don't think there's anything wrong with the updating actually.
15:41.01 abhi2011 by 1000
15:41.05 elf__ It updates it right
15:41.10 elf__ by the scalling
15:41.14 elf__ I mean for mm it worked
15:41.20 elf__ so now it updates it for mm to
15:41.26 elf__ moving it just a tiny little bit
15:41.35 elf__ if the units it would be right
15:41.41 abhi2011 yep
15:41.43 elf__ then it would update it for meters
15:41.49 elf__ so it would move more
15:42.29 abhi2011 hmm so do we remove the scaling then
15:42.50 elf__ yep no scalling
15:42.57 abhi2011 ok
15:43.33 abhi2011 so now we have to ensure that bullet gets 50
15:43.38 abhi2011 and not 50,000
15:44.59 elf__ hmm we can trick it I guess somehow, maybe the scaling should remain when we get the parameters from mged to bullet and then we will only update what we get from bullet so no need for more scaling
15:45.15 elf__ this should only be something temporal
15:45.53 abhi2011 yep
15:46.15 abhi2011 so when we update back from bullet
15:46.35 abhi2011 now
15:46.43 abhi2011 we have to check whats happening
15:46.54 abhi2011 i have got scaling present only during the input
15:47.04 abhi2011 in get_bb()
15:47.09 abhi2011 no where else
15:48.30 elf__ okay that's good, there should be scaling since that's when we get the dimensions from mged to bullet
15:50.37 elf__ hmm it's still not enough, the scaling is there but the bullet still somehow gets the 49K instead of 49
15:51.06 abhi2011 eh ?
15:51.20 abhi2011 i can see 49 in the matrices
15:52.00 abhi2011 wait i ll post my output
15:52.04 elf__ yes there's 49 in the matrices but it acts as if it's 49k, try and simulate it for more steps 20 or so
15:52.25 elf__ for 20 steps in the mm simulation will move a good deal
15:52.35 elf__ here it barely "trembles" so to speak
15:53.13 abhi2011 ok, but the position is dropping right ?
15:53.21 elf__ how I see it, it's that it should be the same thing only in different dimensions, it moves at one speed in the mm units then the same proportions should be respected in the m unitz
15:53.22 abhi2011 it should drop right down to 1.9999
15:55.29 elf__ that
15:55.32 elf__ s the thing it's not
15:55.33 elf__ http://paste.ubuntu.com/1222766/
15:56.02 *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
15:56.37 abhi2011 here is my output : http://paste.ubuntu.com/1222768/
15:57.09 elf__ see the 49.416668 it got modified just a little bit, I was expecting the 49 to get modified to drop to something like 40 or so
15:57.19 abhi2011 only in 300 steps
15:57.22 abhi2011 see my output
15:57.42 abhi2011 50 m is a long distance to fall :P
15:57.56 elf__ hmm that's better
15:57.59 elf__ let me try it
15:58.01 abhi2011 remember in the hallo world they had it as 300
15:58.24 elf__ yes you are right
15:59.06 elf__ it works
15:59.13 elf__ okay so one out of the way
16:01.00 abhi2011 yah it hits at 227
16:01.13 abhi2011 thats when the linear velocity drops suddenly
16:02.22 abhi2011 so lets run it for 1 iteration
16:02.29 abhi2011 and see how the values change
16:02.34 abhi2011 whats your current units
16:02.39 abhi2011 i ll swithc to the same
16:02.48 abhi2011 so we are on the same page
16:03.06 abhi2011 i am in mm
16:03.40 elf__ I am in m
16:03.49 elf__ I used m all this time
16:04.08 abhi2011 right
16:04.11 abhi2011 so am i now
16:04.12 elf__ but yeah around the 227 velocity goes suddenly near 0
16:04.35 elf__ Question do you actually see the cube on the ground?
16:04.38 abhi2011 yah maybe the 2nd hit
16:04.43 elf__ or near the ground plane?
16:04.46 abhi2011 in the hallo world it hit earleir
16:04.53 abhi2011 yeah
16:04.56 abhi2011 well anyway
16:05.09 abhi2011 so now we have to get mged updating correctly
16:05.18 elf__ mine it's still in the same postion, strange
16:05.25 abhi2011 yeah mine too
16:05.29 elf__ okay let's get mged to update correctly
16:05.47 abhi2011 so run for only 1 iteration
16:05.56 abhi2011 lets see what it says
16:06.01 abhi2011 after that
16:06.06 abhi2011 in mged
16:06.30 abhi2011 i am guessing that since bullet will return in meters
16:06.46 abhi2011 i.e. something like 49.999 after 1st iteration
16:07.00 abhi2011 mged will see it as 49.99 mm
16:07.08 abhi2011 and thats not visible
16:08.44 elf__ okay it gets something as 49.997223
16:09.19 elf__ so 49.99 will be then double precision, so next time the simulate command should start from 49.99 right?
16:10.23 abhi2011 yes
16:10.42 abhi2011 umm
16:10.43 abhi2011 no
16:10.53 elf__ no?
16:11.03 abhi2011 if you run simulate again it will start again from 50
16:11.15 abhi2011 because it makes a copy of the cube each time
16:11.43 abhi2011 the 2nd iteration while running the simuate command will start from 49.99
16:12.04 abhi2011 is that what you meant :)
16:12.57 abhi2011 if you see the output of the simulate command for 2 iterations you ll understand
16:13.25 abhi2011 the output of the previous iteration is the input for the next iteration
16:13.35 elf__ yeah. the second iteration I meant :)
16:15.30 abhi2011 lets try multiplying the translation component of the matrices by 1000 and if there is a change
16:15.47 abhi2011 *and see if
16:18.58 abhi2011 lines 248-250
16:19.09 abhi2011 i undo previous translation
16:19.25 abhi2011 lines 295-297 i apply current translation
16:19.35 abhi2011 in simulate.c
16:21.54 abhi2011 yeah it updates correctly with the 1000 scaling during output as well
16:21.57 abhi2011 i ll commit it
16:24.07 CIA-68 BRL-CAD: 03Abhi2011 * r52518 10/brlcad/trunk/src/libged/simulate/simulate.c: Added scaling for the bullet->mged transform as well. All this scaling should not be needed. We should try testing with another scene where we create the geometry in mm.
16:24.41 abhi2011 i ll try with some of my older .g files
16:36.09 elf__ it looks good on my end
16:37.14 elf__ does it work with your old files as well?
16:37.35 elf__ I will try with the geometry in mm
16:37.43 elf__ there shouldn't be any problems though
16:39.39 elf__ hmm the position doesn't get updated in mged opengl window
16:42.02 elf__ http://paste.ubuntu.com/1222855/
16:42.15 elf__ hmm
16:42.53 elf__ it might be affected by the fact that bullet got that 0.04 tolerance
16:43.04 elf__ will try with larger values
16:46.36 abhi2011 the cube comes to rest on the ground right ?
16:46.47 abhi2011 after dropping 50 meters ?
16:47.01 elf__ in the meters simulation yes
16:47.08 elf__ for the mm one is not working
16:47.11 abhi2011 ok
16:47.20 elf__ how's on your end?
16:47.29 abhi2011 i seem to have the units set to mm
16:47.35 abhi2011 for all my older files
16:47.55 abhi2011 maybe you can create a new .g file
16:48.05 abhi2011 and have the unit set to mm
16:48.09 abhi2011 and try again
16:48.19 elf__ ahh well yeah I don't think there's a way to change it to meters in any other way than to create another .g file
16:48.32 elf__ I am trying for larger geometry in the mm file
16:48.54 elf__ cause the bullet tolerance it might affect the simulation
16:51.11 abhi2011 yes
16:51.44 abhi2011 anything less than 0.1 m might cause issues
16:52.57 elf__ hmm I butched the dimensions for the gp and the supposed cube but it works for mm too even though it doesn't look nice in this simulation
16:52.58 elf__ http://imageshack.us/a/img834/5985/mmtest.png
16:52.59 abhi2011 aha !!
16:53.01 elf__ for 100 steps
16:53.09 abhi2011 now with the scaling in place
16:53.12 abhi2011 i get issues
16:53.15 elf__ like?
16:53.16 abhi2011 in my older files
16:53.25 abhi2011 objects going through the plane
16:53.29 abhi2011 ok let me remove the scaling
16:53.40 abhi2011 i ll send you my older file
16:53.44 abhi2011 you can use that
16:53.44 elf__ okay :)
16:59.31 CIA-68 BRL-CAD: 03Abhi2011 * r52519 10/brlcad/trunk/src/libged/simulate/simulate.c: Removed all scaling stuff. The modeling units for the simulate command is mm. Meters wont work.
17:00.28 elf__ abhi maybe there's something wrong with your old files
17:00.36 elf__ cause at me both the meters and mm work
17:00.42 elf__ here's the mm file sim
17:00.42 elf__ http://imageshack.us/a/img339/2808/150jd.png
17:00.59 abhi2011 thats cause scaling is still in place
17:01.04 elf__ and I ran it for >150 steps and it's still didn't get inside the plane
17:01.10 abhi2011 update the code now
17:01.13 abhi2011 i have removed scaling
17:01.14 elf__ yes but it works for mm and meters
17:01.18 elf__ with scalling
17:01.21 abhi2011 and sent you the older file
17:01.22 elf__ so why removing it?
17:01.52 abhi2011 well we can go with either approach
17:02.00 abhi2011 if we model in meters
17:02.03 abhi2011 then we need the scaling
17:02.07 abhi2011 if we model in mm
17:02.08 elf__ you said that meters don't work, it doesn't work without the scaling, but with the scaling on my end works with meters and mm
17:02.09 abhi2011 then we do not
17:02.20 abhi2011 oh
17:02.20 elf__ I'll send you the .g file I used to make that last image
17:02.22 abhi2011 hmm
17:02.35 abhi2011 ok wait wait
17:02.37 abhi2011 :P
17:02.47 abhi2011 lets pick a simple solution then
17:02.56 abhi2011 either one of the 2
17:03.03 abhi2011 so if you want scaling then fine
17:03.20 abhi2011 I ll test it with mm and m later
17:03.31 elf__ let me see if your .g file works for me with scalling
17:03.35 abhi2011 i am sure it works if you say so :)
17:03.38 elf__ if it doesn't we see what we do :)
17:03.46 abhi2011 just pick which one you want
17:03.59 elf__ double checking is never bad :)
17:04.03 abhi2011 and we can go on to the next issue :)
17:04.06 abhi2011 yep
17:04.12 abhi2011 gotta go have dinner forst
17:04.15 abhi2011 brb :P
17:04.51 elf__ okay enjoy it :)
17:07.49 elf__ abhi? I am only seeing one small kinda blue square o.O
17:08.04 elf__ I ran it for 50 steps first, though you said to run it for 200 steps
17:08.14 elf__ wanted to see something intermediate
17:08.22 elf__ I don't know if that's what am I supposed to se
17:08.23 elf__ e
17:24.12 abhi2011 hmm thats strange
17:24.22 abhi2011 there should be 3 small squares
17:24.31 abhi2011 above each other
17:24.35 elf__ so I get it that I am not supposed to see the only small square...
17:24.44 abhi2011 yep
17:25.07 elf__ can you run rt -W -o test.png
17:25.15 elf__ on your sim.c file
17:25.18 elf__ group*
17:25.26 elf__ after 200 steps and then upload it somewhere?
17:25.30 elf__ imageshack.us...
17:26.06 elf__ I ran it for 50 100 150 steps I still get that one blue small square
17:29.11 elf__ I haven't reverted back the scaling, jfyi but you said the cubes are going below the ground so that shouldn't matter, I should see 3 cubes going below the ground
17:52.41 *** join/#brlcad merzo (~merzo@14-102-132-95.pool.ukrtel.net)
17:58.05 *** join/#brlcad tobiasu (~tobiasu@tin.tmux.org)
17:58.12 tobiasu moin
17:58.48 tobiasu trying to compile brlcad on openbsd, and scratching my head over this error message:
17:58.56 tobiasu /usr/ports/pobj/brlcad-7.22.0/brlcad-7.22.0/include/fb.h:136: error: expected declaration specifiers or '...' before 'Display'
17:59.56 tobiasu The X11 includes are found, everything seems fine
18:05.24 elf__ abhi2011, I might have figured why your old fallsmall.g file is not working when the scaling is present, the whole geometry is really small
18:05.45 elf__ I removed the scaling and tried without it, for 150 steps the cubes fall through the plane
18:05.53 elf__ but like I said they are really small
18:06.13 elf__ maybe doing the same .g file but for bigger geometry values it will work
18:06.22 elf__ it works in that mmm.g file I send to you
18:27.56 abhi2011 maybe you can try to switch the view to left view
18:27.58 abhi2011 by pressing L
18:28.07 abhi2011 then it should frame all the boxes
18:28.12 abhi2011 then run the sim
18:28.16 abhi2011 thats what i do generally
18:29.09 elf__ yeah, well with the scaling even the gp looks really small, I realized after running it without the scaling that the blue square I was seeing was the gp, I wasn't even seeing the small cubes
18:29.22 elf__ how did you create it? Just a gp and 3 cubes at different heights?
18:29.30 abhi2011 yep
18:29.38 abhi2011 you need to click on the mged screen
18:29.42 elf__ that should go in the same region so they fall at the same time?
18:29.44 abhi2011 left clicking will make it zoom
18:29.54 abhi2011 sorry rght click i think
18:29.57 elf__ I did it didn't help :)
18:30.02 abhi2011 oh
18:30.07 abhi2011 wait i ll post a screen
18:31.24 elf__ okay :)
18:31.36 elf__ I can post a screen with the simulation without the scaling too :)
18:33.04 abhi2011 hehe
18:33.05 abhi2011 ok
18:33.44 elf__ here's what it looks like without the scalling
18:33.45 elf__ http://imageshack.us/photo/my-images/29/simulation.png/
18:33.54 elf__ will add one with the scaling too :)
18:34.30 abhi2011 oh hmm
18:34.35 abhi2011 so it goes through
18:34.42 abhi2011 is it the exact same code
18:34.46 abhi2011 as in svn currently ?
18:35.09 elf__ yep without the scaling, but with the scaling I am thinking that maybe the geometry it's too small to act naturally
18:35.17 elf__ yep as in the svn currently
18:35.37 elf__ since it stopped for bigger geometry in mm in my other .g file ....
18:35.39 elf__ will see
18:36.02 abhi2011 ok i ll run it for 300 steps
18:36.06 abhi2011 see what happens
18:41.27 abhi2011 here is what i get after simulate 200
18:41.28 abhi2011 http://imageshack.us/a/img593/70/simulate200.png
18:41.39 abhi2011 i switched to the az 35, el 25 view
18:41.50 abhi2011 from the opengl screen, view menu
18:42.17 abhi2011 it should not be going thru the plane
18:42.33 abhi2011 because that means the collision detection is not working
18:42.46 abhi2011 but if the code is from svn then it should
18:42.56 abhi2011 and the fallsmall.g file should be used
18:43.22 elf__ with the code from the svn it goes through the plane
18:43.47 elf__ with the scaling in place I can't make that geometry large enough to see it
18:43.52 abhi2011 after how many steps does it happen
18:43.59 elf__ tried right button on the mouse
18:44.01 elf__ autoview
18:44.08 elf__ different settings for the view
18:44.11 elf__ nothing
18:44.14 elf__ 150
18:44.32 abhi2011 ok
18:44.47 abhi2011 so if you directly just load the fallsmall.g file
18:45.09 abhi2011 and then draw a.r, b.r , c.r and gp.r
18:45.26 abhi2011 then switch to az 35, el 25
18:45.30 abhi2011 in the view menu
18:45.37 abhi2011 are you able to see anything
18:46.20 elf__ yeah that works
18:46.27 elf__ it shows the 3 cubes and the gp
18:47.30 abhi2011 ok thats good
18:47.38 abhi2011 you are also able to switch to left view ?
18:47.46 abhi2011 by pressing L
18:48.28 elf__ yeah
18:48.43 abhi2011 ok
18:48.57 abhi2011 so now you have the svn code running right ?
18:49.04 abhi2011 in libged
18:49.11 abhi2011 no scaling
18:49.25 elf__ nope, now I have the one with scaling running
18:49.44 abhi2011 ok, so can we try with the svn code only
18:49.58 abhi2011 just to see if we can both get the same output
18:50.05 abhi2011 with the exact same steps
18:50.13 abhi2011 and exact same file
18:50.49 abhi2011 it wil go through with scaling
18:51.03 abhi2011 becuase the objects are too small when scaling is on
18:51.09 abhi2011 then are less than a mm
18:51.24 abhi2011 so lets both sync and run the same code and try the same steps
18:51.29 abhi2011 and compare the output
18:52.03 elf__ okay reverted back to the svn one
18:52.30 abhi2011 ok
18:52.44 *** join/#brlcad crdueck (~cdk@24-212-219-10.cable.teksavvy.com)
18:52.45 abhi2011 let me know when mged is running
18:54.25 elf__ compiled and running
18:55.02 abhi2011 ok
18:55.16 abhi2011 so now if you load that fallsmall.g file
18:55.27 abhi2011 and draw the 3 cubes and the gp and switch view
18:55.34 abhi2011 you can still see them right ?
18:56.11 elf__ yes
18:56.32 abhi2011 ok
18:56.42 abhi2011 so now zap the scene
18:56.45 abhi2011 wth Z
18:56.58 abhi2011 and simulate for 20 steps
18:58.09 elf__ done
18:58.14 abhi2011 the cubes should have moved down
18:58.30 abhi2011 but none should have penetrated the gp
18:58.43 elf__ they did move down :)
18:59.22 abhi2011 ok and you can see them right
18:59.33 elf__ yep none got in the plane
18:59.39 abhi2011 ok cool
18:59.43 abhi2011 so at least that works
18:59.56 elf__ yes it does
18:59.57 abhi2011 see with scaling what happens is the objects sizes are too small
19:00.11 abhi2011 we cannot see what bullet is actually doing
19:00.21 elf__ yeah and they are way too under 0.04 m that's bullet tolerance
19:00.26 abhi2011 so we thing the object size are same as what appears in mged
19:00.32 abhi2011 actually bullet is doing some other stuff
19:00.41 abhi2011 yep
19:00.57 elf__ so that's why I asked you how you made the .g file so I can reproduce it at a bigger scale
19:01.00 abhi2011 and thats cause I use the scaled postion to get the bb
19:01.14 abhi2011 yeah I forgot that it was in mm
19:01.15 elf__ like I did with the other .g file I send to you
19:02.01 elf__ if there are enough mm so that the object are in meters, like 1000mm or so for an object the scaling works
19:03.10 abhi2011 ok
19:04.54 abhi2011 hmm, so then we will need to model objects to be larger
19:05.05 elf__ yeah, that's my idea too
19:05.20 elf__ though I still think it's not right what happens there with the mm/m stuff
19:05.38 abhi2011 ok, so lets stick with no scaling for now
19:05.46 abhi2011 so we have to model with normal numbers
19:05.47 elf__ okay
19:05.52 abhi2011 till we speak to sean about it
19:06.01 abhi2011 no need to complicate the code more than it needs to :)
19:06.11 elf__ well the thing is it will work only for mm with no scaling
19:06.16 abhi2011 yep
19:06.33 abhi2011 :)
19:07.04 abhi2011 hmm
19:07.07 elf__ ?
19:07.13 abhi2011 darn even i am no sure anymore :P
19:07.26 abhi2011 ok fine
19:07.31 abhi2011 lets go with scaling then
19:07.36 abhi2011 to have maximum support
19:07.40 abhi2011 in both units
19:07.49 elf__ haha
19:08.32 elf__ It will be kinda uhmm so and so to explain that you know you should have large objects to simulate the physics
19:10.06 abhi2011 yah, I think if we the unit is chosen to be meters via the units command, then when we create objects we should not need to specify 1000 for 1 meter
19:10.16 abhi2011 thats the whole point of choosing meters as the unit
19:10.23 abhi2011 to not have to specify large numbers
19:10.35 elf__ yeah
19:10.54 abhi2011 but as of now that not the case i think
19:11.01 abhi2011 i havent tried in meters
19:11.17 abhi2011 ok, well we have to move on
19:11.21 abhi2011 lets leave it as it for now
19:11.24 abhi2011 with no scaling
19:11.33 abhi2011 there is the ray tracing stuff to solve
19:11.40 abhi2011 we ll use mm from now on
19:11.49 elf__ okay
19:11.59 abhi2011 right
19:12.18 abhi2011 by the way I guess you know the script
19:12.30 abhi2011 for generatng the images of each frame
19:12.47 abhi2011 you can try it now that mged is getting updated
19:13.06 elf__ hmm what script to be exact?
19:13.21 abhi2011 good question :P
19:14.03 abhi2011 sim.sh
19:14.20 abhi2011 i had mailed it to you earlier
19:14.38 elf__ yeah
19:14.55 elf__ hmm will run it right now, let's see what I get
19:15.10 abhi2011 you may need to modify it a bit
19:15.28 elf__ yep
19:15.29 abhi2011 it has to run from the directory where the .g file is or something
19:15.32 abhi2011 ust check it
19:15.37 elf__ I saw that
19:15.57 elf__ uhmm where is that roll.g file?
19:17.17 elf__ I actually did one of those for the single cube falling on the ground
19:17.29 abhi2011 use your own .g file :P
19:17.29 elf__ anyway I will try it with the fallsmall.g file
19:17.34 abhi2011 yep
19:21.27 abhi2011 irc used to be a lot more busy
19:21.42 abhi2011 i wonder where all the other people went!
19:23.39 elf__ on holiday maybe
19:25.43 abhi2011 anyway, we l continue tomorrow
19:25.49 abhi2011 glad we got something fixed today

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