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