Shared compound collsions

[Bird]

Hi Julio,

When making an instance of another body, I re-use the NewtonCollision * from the body being instanced and have had no problems. But I just tried instancing a body that has a CompoundCollision shape and I'm getting crashes that are hard to track down.
I think this might be a threading issue because while the engine is running I make all my body creation calls on Newton's thread during a NewtonListener preUpdate or postUpdate callback and that works just fine.
The crashes happen only when the engine is not running and all my body creation calls are always from the same thread but it is not Newton's thread.

Do you have any idea what might be happening.?

-Bird

[Julio Jerez]

newton does not uses thread memory, all allocation are controlled by the memory allocation driver functions.
I find it weird that is crashes when the engine is no running

Is this only with compounds? can you show the code fragment maybe I can recreate the same in the sandbox?

[Bird]

Is this only with compounds? can you show the code fragment

Yes, it is only with compounds. Here's the function I use to create a collision shape. I re-use the same collision shape for my clones or instances otherwise I create a new one.

Code: Select all

NewtonCollision * IssacBodyHandler::getCollisionShape (IssacEntity * const entity)
{   
   NewtonCollision * collision = nullptr;

   // use the source's collision shape if we're a clone or instance
   // Phantoms must use their own collision shape!
   if (entity->isClone() || entity->isInstance() && !entity->isPhantom())
   {
      PhysicsBody * const from = entity->bodyDesc.instancedFrom;
      if (!from) return nullptr;
      if (!from->isReady()) return nullptr;

      NewtonBody * const newtonBody = (NewtonBody*)from->component->userData;
      collision = NewtonBodyGetCollision(newtonBody);
      if (!collision) return nullptr;
   }
   else
      collision = IssacMeshOps::getInstance()->createCollisionShape(entity);

   return collision;
}

newton does not uses thread memory, all allocation are controlled by the memory allocation driver functions.
I find it weird that is crashes when the engine is no running

Ok I found where the crash comes from now. It's hitting the first dgAssert in the CreateDynamicBody function on line 496 in dgWorld.cpp

-Bird

[Julio Jerez]

Umm some is no right, yo usay lien 496 of dgWord.cpp
but that function in the current version is at line 519 and it looks like this

Code: Select all

dgDynamicBody* dgWorld::CreateDynamicBody(dgCollisionInstance* const collision, const dgMatrix& matrix)
{
   dgDynamicBody* const body = new (m_allocator) dgDynamicBody();
   dgAssert (dgInt32 (sizeof (dgBody) & 0xf) == 0);
   dgAssert ((dgUnsigned64 (body) & 0xf) == 0);

   InitBody (body, collision, matrix);
   return body;
}

are you sure you have the latest version?

There are two assert there and those are very bad because it means that the allocation run out of memory,
or the the size of dgBody is no aligned, or that the start address is unaligned, any one of those would be catastrophic.

maybe something is trashing the stack pointer

[Bird]

are you sure you have the latest version?

I'd been switching back and forth between the latest version and the one I have where painting works. I must have been using the older version then.

I'm pretty certain that this is my bug now. Looks like I had some bad memory management a little upstream before making the compound collision shape using NewtonMeshApproximateConvexDecomposition.

Any chance you can get NewtonMeshSimplify working again? Right now there's an assert at the beginning of dgMeshEffect::CreateSimplification. It's very useful for NewtonMeshApproximateConvexDecomposition operations.

-Bird

[Julio Jerez]

let us solve this after we get the other bug fixed.