Collision Against Uniform Grid (Voxel) Without Creating Mesh

[Julio Jerez]

woooww I got it!!, the moment I set the mass to the compound box teh fps dropped to bellow 2,

I beleive that's teh bug, you say that you set the mass using NewtonBodySetMassProperties and it was fast, this is how I did it?

Code: Select all

// set the mass here
NewtonBodySetMassProperties (compoundBody, 1.0f, NewtonBodyGetCollision(compoundBody));

// adding some visualization
DemoMesh* mesh = new DemoMesh("geometry", NewtonBodyGetCollision(compoundBody), "smilli.tga", "smilli.tga", "smilli.tga");
DemoEntity* const entity = new DemoEntity(matrix, NULL);
entity->SetMesh(mesh);
mesh->Release();
NewtonBodySetUserData(compoundBody, entity);
scene->Append(entity);

when I do that I see the huge slow down.
if you did it diffrently, can you please show me hwo were did you set it up, in the demo?

I am guessing that the scale is acting on the single child shapes but it not working on the compound pruner, so the huge box is see all of the children of the secung compound. all 100,000 of them.
It is very eassy to fix, I will fix, but it will be tonight I have to go to work now.

[Layla]

Oh man I'm glad it's not just me then, I was starting to go crazy. It will be great to get it fixed

[Julio Jerez]

yes the scale is not being applied to te OBB of the chidlers, this function
bool dgCollisionCompound::dgNodeBase::BoxTest (const dgOOBBTestData& data, const dgNodeBase* const otherNode) const
is reportion all of the children as overlaping, you cna see that teh aabb of box shape is abput (50 x 50) units

Code: Select all

      handle1   CXX0017: Error: symbol "handle1" not found   
      handle2   CXX0017: Error: symbol "handle2" not found   
+      otherP0   {x=-25.062500 y=-15.062500 z=-25.062500 w=1.0000000}   dgVector
+      otherP1   {x=25.062500 y=35.062500 z=25.062500 w=1.0000000}   dgVector
+      p0   {x=-25.312500 y=-10.312500 z=-25.312500 w=0.00000000}   dgVector
+      p1   {x=24.812500 y=-9.6875000 z=24.812500 w=0.00000000}   dgVector

That is whay explaing that it works depeniong on hwo you set teh scale, it seems that seting scale globally is no recalcualtion the AABB.

[Julio Jerez]

Ok fixed, the ironi is that you are the first person who uses a scale compound with one child shape
I never tested that, has you compoudn have more that one shape it would work and we will nevr foudn out. Better safed than sorry

[Layla]

Thanks a lot! Works perfectly. Yeah it is a bit silly to have one shape in a compound but it's just because I have a class which is a bunch of convex shapes to make a concave prop but some props only need 1 convex.

[Layla]

Okay so having played around with the scene collision to handle this, I've decided the memory required is just far too much. I'd have to drastically limit my map sizes, something I can't justify doing for just client side effects like debris and ragdolls. As much as I'd like a specialized voxel collision I can't justify the time and effort needed for it. Although this is something I'd be willing to work on but with my limited math knowledge I'm not sure how far I'd get and if it would be any better. I think physics is just something I'll have to do without for my game.

[JoeJ]

Have you thought about merging adjacent cubes - say at upwards z direction - to single tower-shaped bodies?
That would reduce memory to something like x*y*5, instead of x*y*z.
And the preferable octree idea should be easy to implement too...

I'd not give up so fast. Those physics seem to make your game outstanding.
Imagine destroying a bridge and fraging multiple opponents at once...

[Layla]

I should try that before giving up but it's still potentially a lot of memory and slower to edit the map. I'd only be using the physics for effects, until I figure out a way to solve collisions directly from the cell array I already have then I don't think it's worth the trouble. Newton is almost perfect for a normal game environment but for something like this I really think it needs to be handled differently. At the very least I know how to raycast against my geometry because I already do that in the game, I just need to figure out what else I need to handle in newton to have shapes colliding against the level. (which I'm assuming is a crazy amount of maths that I don't have the skills for)

[Sweenie]

Maybe NewtonCreateUserMeshCollision could be used for this?

[Julio Jerez]

yes the user mesh collision, may be the solution you seek. if you can make the patch of faces, for rendering then you can make the patch of faces for the user mesh collision.

basically the user mesh use a const amount o memory, you pass a box size, and some call backs, (one for rat cast, one for face path around an small aabb box, some other that I do no remember)
The user mesh collision is use internally for terrain high field collision. it surely should work for you case.
that will only use a few hundred extra bytes, of memory for the whole thing, and it is unlimited, the time it will take is only how fats you can regerate the path of face around the Box of a colliding face.
which as I understand is very fast for your game engine.

the user Mesh let you have all the physics, with no memory, and very lithe time, at the expense of you writing the call backs.

see the demo void UserPlaneCollision (DemoEntityManager* const scene)
file ../newton-dynamics\applications\demosSandbox\sdkDemos\demos\UserStaticCollision.cpp
for a very simple example

[Layla]

From the looks of it this could be what I want. UserStaticCollision crashes for me though, is this a known issue?

It looks like User Collisions are completely broken? One of the callbacks needs a NewtonUserMeshCollisionCollideDesc pointer but dgCollisionUserMesh is passing it a dgPolygonMeshDesc reference. Two completely different data structures.

[Julio Jerez]

oh I have the ray cast comment out, I see what is wrong

Code: Select all

dgFloat32 dgCollisionUserMesh::RayCast (const dgVector& localP0, const dgVector& localP1, dgFloat32 maxT, dgContactPoint& contactOut, const dgBody* const body,   void* const userData) const
{
   dgAssert (0);
   return 0;
 

[Layla]

The demo is crashing in the PlaneCollisionCollideCallback callback because the user data is invalid.

NewtonCreateUserMeshCollision function is casting a NewtonUserMeshCollisionCollideCallback to a OnUserMeshCollideCallback which are two completely different things, I don't understand why. It had to be working at one point but I can't go back far enough in the svn to find out when.

[Julio Jerez]

I probably made a change, and some how that broke. I said that I will fixed it.
Basically the collision tree and the Terrain are UserMesh collision. By I have made mode optimization to those and I never updated the user Mesh.

[PJani]

There is one overhead i see with UserMesh that is the m_faceVertexIndex are mixed values(I0, I1, I2, I3, ..., M, N, E0, E1, E2, ..., A) the indexes for rendering are I0,I1,I2,I3...just saying
When i enable voxel terrain(displayed using polygon faces) my memory usage goes to 1GB and sometimes beyond i need to keep vertex information in memory for newton and render vertex information in gpu ram. so yeah eatherway is futile xD.

How is A defined?
N i know is normal of whole polygon
now E0,E1,E2 are normal of vertexes if i understand correctly. Why are these needed in newton?