Intel® Software Network

The following crash happens whenever I add several (half dozen to a dozen) shapes (cylinders) to the world. It seems to happen when the entities are together in one place, rather than spread out.

t:\Build\code\PcXs0\Source\Physics/Dynamics/Constraint/hkpConstraintInstance.inl(96): [0xf056d145] Assert : 'm_internal
You cannot access internal, this constraint is not added to the world yet'

I've tried everything I can think of to affect this in any way, yet the error persists. Any help is appreciated. This has stopped me cold.

Hi,
Do you have the callstack from when the assert happens? If you disable the assert, what happens? (It'll probably crash, but maybe you'll get lucky...)

-Chris

---

Chris Elion
Software Engineer
Havok

This is the call stack:

myapp.exe!errorReport(const char * msg=0x02e1e424, void * __formal=0x00000000)  Line 163 C++
myapp.exe!hkDefaultError::showMessage(const char * what=0x00c32114, int id=-262745787, const char * desc=0x02e1e678, const char * file=0x00c3f920, int line=96, hkBool stackTrace={...})  Line 69 + 0x11 bytes C++
myapp.exe!hkDefaultError::message(hkError::Message msg=MESSAGE_ASSERT, int id=-262745855, const char * description=0x02e1e678, const char * file=0x00c3f920, int line=96)  Line 122 C++
myapp.exe!hkpConstraintInstance::getInternal()  Line 96 + 0x61 bytes C++
myapp.exe!hkLs_toiActivateConstraintsLinkingActivatedEntities(hkArray<hkpConstraintSchemaInfo> & constraintStatus={...}, int & firstNonActiveConstraintStatus=4, hkFixedArray<unsigned char> & entityState={...})  Line 2046 + 0x39 bytes C++
myapp.exe!hkLs_localizedSolveToi(const hkpToiResources & toiResources={...}, hkpConstraintSolverResources & solverResources={...}, hkpToiEvent & event={...}, hkpToiResourceMgr & toiResourceMgr={...}, hkpWorld * world=0x032584c0, hkArray<hkpEntity *> & activeEntities={...}, hkFixedArray<unsigned char> & entityState={...})  Line 2447 C++

I tried disabling the assert, and it still crashes, but as expected, without calling the error handler.

I've made a few more experiments. Substituting boxes for cylinders eliminates the problem. I need the cylinders however. 
Browsing through the demos, I don't see any demos with large numbers (> 20) of cylinders in one place.

Also I have not added any constraints to the world.

Hmm... Are you seeing any warnings before the assert fires?

I tried modifying the SimpleShapesDemo to create a bunch of cylinders in place. I get an assert with a similar callstack, but I also get a ton of "Toi event queue full" warnings before that. If you aren't getting any warnings beforehand, can you modify that demo (or a similar one) to reproduce the problem? You might just have some different world or rigid body settings.

FYI, the constraint it's refferring to it a contact constraint that's created by the engine, not necessarily one that you added.

Just as a general rule of thumb, it's a bad idea to create a lot of overlapping bodies, for a few reasons. Even if it weren't crashing like it is now, it eats up a lot of memory and CPU time to resolve the penetrations, and you'll get a pretty violent (and hard to control) reaction too. If you can disable collisions between the bodies before adding them (e.g. via tweaking layer settings in the hkpGroupFilter), it'd make like a lot easier...

-Chris

---

Chris Elion
Software Engineer
Havok

In my case, the cylinders were not overlapping. I discovered quickly that overlapping while spawning is a bad thing, and is easy to avoid. In my app, I was spawning cylinders via keystroke, and visually observed through the app and the debugger, that they were not overlapping. I would spawn the next one after the previous one fell away. Gravity would draw them to the floor and they would start to collide. Then the assert was thrown.

I was not getting any other errors before the assert, however as a test, I'll force them to overlap and see if I get the toi event queue errors you received.

I'll see if I can update the demo. Maybe you can try also, since you're already close. If you make multiple non overlapping cylinders land on top of each other on a plane, that should duplicate my scenario.

I made some progress. I modified the SampleHeightField demo to spawn cylinders instead of boxes. At first it didn't throw the assert, but after changing the hkpWorldCinfo settings to match what I had been using, it started asserting with the same error. So now I should be able to figure out exactly what was causing it.

Sorry, I was just looking through our bug database and I realized that this is a known bug (HVK-4539 for anybody keeping track). It's fixed in the next relase (6.0, coming "soon"), but I don't think there's an effective workaround in the meantime.

Are you OK with keeping your hkpWorldCinfo changes until then?

-Chris

---

Chris Elion
Software Engineer
Havok

It seems that playing around with m_collisionTolerance and m_gravity can mask the problem. With specific settings, I can get an iteration of the SampleHeightFieldDemo to complete with 128 cylinders, while other settings make it crash. I have not been able to find any settings in my app that bring stability. I guess there's nothing I can do except wait, unless you think a patch can be applied. Otherwise, I'll just wait until 6.0. It's not urgent, but it would be nice to get this out of the way.

Let me know if you want the modified SampleHeightFieldDemo that reproduces the problem.

At least I can set this aside and focus on things that can be solved. Also, I would be willing to beta test if/when the time comes.

 

Yeah, I think tweaking m_collisionTolerance and m_gravity just happen to hide the case that sets up the crash. I bet if you pick up a cylinder and throw it at the ground, you'd get the crash then too.

I'll try to find out if there's a workaround, but I wouldn't hold my breath. Sorry...

-Chris

---

Chris Elion
Software Engineer
Havok