Enabling Bodies

[Yezide]

I have some other stuff to do this week, so will take two weeks or so before I can get a test app up and running, just so you know.

[Julio Jerez]

ok whenever you are ready is fine.

[Sweenie]

I have the same problem when using core 300(revision 1026).
Every object just falls through the floor and bodies attached to joints(custom) won't move at all.
This is with the ReleaseDll.
If I instead switch to using the DebugDll i get this error when running my program.
"Could not find GetThreadId procedure entry point in Kernel32.dll"

I googled about this and it seems that GetThreadId is a function only available in Windows Server 2003.
I'm using Windows XP sp3.

[EDIT]
Ok, found and disabled this line in dgWorkerThread.cpp to be able to use the debugDll
// SetThreadName (GetThreadId(HANDLE (m_threadhandle)), name);
But the bodies still fall through the floor.

[Julio Jerez]

Sweenie do yopu have a test tha I can run and see why this is happenings? My test do no show that so it is diffcult for me to find out.

[Sweenie]

I hope you can run this...

http://www.svenberra.net/testcore300.zip

Open the console by pressing ~ (the key just below escape)
type load world/test

Now you should see a platform(tree collider) with three boxes falling on to it.
The green boxes have a convex hull collider and the blue box has a Box collider.

When I run this, the blue box just falls straight through the green box and the platform(tree collision).
One of the green boxes sinks through the other green box and into the platform, then slowly moving up and down inside the other green box... very odd
type newtondebug in the console to render the collision shapes.

[Julio Jerez]

excelent test, got it running already and I see teh problem, I am debugging it now.

stand by, and
Thank you

[Julio Jerez]

you said this

Now you should see a platform(tree collider) with three boxes falling on to it.
The green boxes have a convex hull collider and the blue box has a Box collider.

but I see the world being made of:
Box, a compound with a box as a child, a convexhull, and collision tree. is this correct?

if this is the case then this not a case bug this is a function that is not fully implement yet.
if you look at the source in file c:\..\coreLibrary_300\source\physics\dgCollisionCompound.cpp

you will find a series of commented out functions.
In core 200 compound collision was very inefficient when the compound had lot of sub shapes.
The reason was I always assumed that a compound was going to be small, but that was not the case and few people made very big compound shapes that slowed down the broad phase
with many unnecessary call to narrow phase contact calculation.

to give you an idea, a lever and has 100 static boxes.
and one dynamics box. this was realizably efficient is core 200 because the multi grid always reported the number of boxes in close proximity to the dynamics Box, in must case just few pairs.

however say you put the 100 boxes in a compound collision, in core 200 the muti grid reported one pair, but the pair reported 100 sub pairs.
let us not even talk of when we had compound again compounds, it was very bad. Late I added a dynamics sweep and prune to make it better
but that was no always good because sweep a prune is a one dimensional algorithm and finding the best axis was time consuming and not a clear which was the best axis.
In fact it always reported many time over more pair for contact calculation.

In core 300, different flavors of the collision tree construction of core 100 and 200 as the core of all of the broad phase collision.

the collision trees as optimal in the same that a Read Black tree algorithm can produced an optimal balance of a binary tree using tree rotation.
This is in fact the secret of why collision tree is so fast (I actually tried to put that against a self appointed expert in one forum that was bragging about his self re-invented Sweep and prune,
but I was dismissed but the crow and the forum n the ground that Newton was no open source at the time as if that was a crime)

Anyway the algorithm is basically the same as that of red black and avl trees. Essentially what is does is the it takes a tree consisting of a root and it left and right child, and a optimization criteria.
then it calculate all possible permutations of that tree, since there are only tree node, there are only three configurations, for each configuration is calculation the cost (the optimization criteria).
The is the configuration for the lowest cost is different than the current configuration, then it apply that tree rotation and continue to the next node.
There are few criteria you can use, the volume of the AABB of the tree node, the surface area, the euclidian distance. My test show that volume is too big of a value and distance is too small, the surface are is best.


after few passed of the algorithm the tree becomes optimized on the criteria. and not oteh configuration of the same tree can be more optimal.
This is in the same way that a Red Black tree is optimal base of the critical that no tow consecutive node can be red (or black), this lead to a tree when the longer branch in no longer that 2 * log (n)
meaning that a red black tree is no absolute optimal since a absolute optimal binary tree is one where the longer branch is log(n) deep.
However there are not know algorithm that can balance a binary tree to have the cost. therefore Red Black tree are optimal for binary tree.
The same goes for my algorithm, the collision tree is perfect according to the criteria that it is the collision tree the has the smaller possible surface area of all of the combined nodes.

basically the collision tree is a tree when the AABB of any two pair of triangle is the one the smallest surface area.

For years I had being trying to make the algorithm Real time. I always thought that it will be too expensive, since it takes several passes to converge to an optimal criteria so for
a tree with several hundred thousand nodes (some time millions) it was out of the question.
However it occurred to me that not always the number of nodes is as large as in a collision tree, so at least making one pass is not that expensive.
It also occur to me that in a dynamics tree (like the broad phase collisiion ) in general there is lot of coherences, meaning that from updates to updates, the number of leaves nodes move relative to their current position.
so the net cost changes by a small amount.
so for core 300 hundred I decided to generalize the collision tree for Scene collision, the broad phase and compound collision.
To make the algorithm dynamics I borrow from another idea of general programming which is Garbage collected memory management.

basically instead of the broad phase and the dynamic phase of the engine doing the maitanace of these opjects,
each one of these objets have a function called ImproveFitness that is run periodically and does what I explain before.

This is beautiful become it completely decouple the maintenance of the broad phase from the engine
(it can even be placed its own thread and it can even run with multicourse) and it reduce teh number of critical sections, each time a body moves, to almost zero, making the algorithm ideal for dedicated hardware.

so to resume in core 300, the collision tree algorithm is the core of the collision system, it is dynamics,
(this mean that it is possible to add an remove faces and or shape to a collision tree at run time)
this feature will be use for soft bodes meshes made of triangular meshed in the future.

Anyway I will complete those function for the compound and all shoul be fine.

[Julio Jerez]

Ok problem solved. sync to svn.

also can you put more than one compound so tha I can enable an dtest the other compound/compound routine?
It will same me from having to setup a test demo just for that?

[Sweenie]

Awesome!
I will make another test scene with just compounds then.

[Sweenie]

There... you can download the same file again.

I've added another scene called test2, so just type load world/test2
This world contains two compound bodies with 3 sub shapes in them.
Also added another scene called test3 which is the same as above but with an extra body with a Convex hull.
As a "bonus" I've also added two of my more complex scenes called raycast(load world/raycast) and forklift(load world/forklift)
These contains a raycast vehicle and a forklift(multibody vehicle) using several custom joints and compound bodies.

[Julio Jerez]

Ha very good.

I fixe the compopund now, if you sync again the test2 and test3 soudl be working.

I now will see wht is teh boug with forklift,

Hey the ray cast car is very cool, is there a problem with it? I did not see what it was.

[Julio Jerez]

Upps, Oh never mind I just foudn teh Bug with ray cact car demo, here this function.

Code: Select all

void dgBilateralConstraint::JointAccelerations(dgJointAccelerationDecriptor* const params)
{
_ASSERTE (0);
/*
..

I will enable that now.


Hey tell me this, is that the C4 game engine, that you are using?

[Sweenie]

Well, the raycast car works as long as it doesn't flip over. If it does, it sinks through the ground, and it's not a compound object just a convex hull.
That scene also contains a pyramid of compound bodies(boxes).

and yes, this test demo is using the C4 Engine.

[Julio Jerez]

Ha Sweenie I am so glad you made that demo,
It took me a while to fidn this bug but it was worth,
when I mode from core 200 to core 300 a low leve funtiob that I changed was this

Code: Select all

   DG_INLINE dgInt32 BoxIntersect (
      const dgTriplex* const vertexArray,
      const dgVector& min,
      const dgVector& max) const
   {
      dgFloatSign tmp0_x;
      dgFloatSign tmp0_y;
      dgFloatSign tmp0_z;
      dgFloatSign tmp1_x;
      dgFloatSign tmp1_y;
      dgFloatSign tmp1_z;

      const dgTriplex& minBox = vertexArray[m_minIndex];
      const dgTriplex& maxBox = vertexArray[m_maxIndex];

      tmp0_x.m_fVal = maxBox.m_x - min.m_x;
      tmp0_y.m_fVal = maxBox.m_y - min.m_y;
      tmp0_z.m_fVal = maxBox.m_z - min.m_z;

      tmp1_x.m_fVal = max.m_x - minBox.m_x;
      tmp1_y.m_fVal = max.m_y - minBox.m_y;
      tmp1_z.m_fVal = max.m_z - minBox.m_z;
      return tmp0_x.m_integer.m_iVal | tmp0_y.m_integer.m_iVal | tmp0_z.m_integer.m_iVal | tmp1_x.m_integer.m_iVal | tmp1_y.m_integer.m_iVal | tmp1_z.m_integer.m_iVal;
   }

in core 300 is now like this

DG_INLINE dgInt32 dgOverlapTest (const dgVector& p0, const dgVector& p1, const dgVector& q0, const dgVector& q1)
{
return ((p0.m_x < q1.m_x) && (p1.m_x > q0.m_x) && (p0.m_z < q1.m_z) && (p1.m_z > q0.m_z) && (p0.m_y < q1.m_y) && (p1.m_y > q0.m_y));
}

DG_INLINE dgInt32 BoxIntersect (const dgTriplex* const vertexArray, const dgVector& min, const dgVector& max) const
{
dgVector boxP0 (vertexArray[m_minIndex].m_x, vertexArray[m_minIndex].m_x, vertexArray[m_minIndex].m_x, dgFloat32 (0.0f));
dgVector boxP1 (vertexArray[m_maxIndex].m_x, vertexArray[m_maxIndex].m_y, vertexArray[m_maxIndex].m_z, dgFloat32 (0.0f));
return dgOverlapTest (boxP0, boxP1, min, max) - 1;
}


the secund may be less effiecnt but it si more standard,
bowever I made a mistake when takin that Box form teh vereyx list I wrote
dgVector boxP0 (vertexArray[m_minIndex].m_x, vertexArray[m_minIndex].m_x, vertexArray[m_minIndex].m_x, dgFloat32 (0.0f));

inesated of
dgVector boxP0 (vertexArray[m_minIndex].m_x, vertexArray[m_minIndex].m_z, vertexArray[m_minIndex].m_z, dgFloat32 (0.0f));
and the intruced those ranom collison misses, now tah ray cast car work everywhere
and the cool thong is that in is faster overall.

now I will move to see what is wrong wit the forklift.

If you sync to SNV you should get a woking version of test 1, 2, 3 and Raycast (Y did noit test forklift because I have no reason to think it wil work, I will woirk on it this afternoon)

I am curios Is the ray cast car the newton joint or your own?

[Julio Jerez]

Hey guess what, I run the forklift demo and it runs fine.

I cannot I operate the lifter, I touched few keys but nothing happens, is that a Bug of it is not operational?

edit:
never mind I thonk I figure out, is teh keys R, e, F, G, ext.

I notice someth funny when I let go of teh Key, it kepes moving and is it has extra inertial is that right? or is that a Bug.
I would think that the moment you let go of the key it should stops so that t is useful.

Anyway when you have time please test it and given some feedback. ther may be still a bug.


Hey now that I drive more, the fork lift is very cool, you can actually pick up stuff.
I can see that it even has suspension, can you say how are you doing it? are those you joints of soem variation of the joint in the Joint library?