Drop in framerate when hkpExtendedMeshShape and hkpBoxShape rigid bodies collide

Drop in framerate when hkpExtendedMeshShape and hkpBoxShape rigid bodies collide

Hi, I can drop randomly sized boxes on to my terrain mesh at the moment..it's quite a large mesh though (65536 vertices).

Everything runs smooth until the collision. The framerate becomes poor until the box(es) fall off the corner of the mesh. The boxes spin around after the collision and framerate is smooth again straight after, unless a box stays on the terrain mesh.

I'm using XHk to set up my hkpWorld like so:

HkpWorld::HkpWorld(HkpWorldCinfo^ info)
{
info->m_native->m_info.setBroadPhaseWorldSize(5000.0f);
info->m_native->m_info.m_broadPhaseBorderBehaviour = info->m_native->m_info.BROADPHASE_BORDER_FIX_ENTITY;
m_world = new hkpWorld(info->m_native->m_info);

m_world->markForWrite();

hkpAgentRegisterUtil::registerAllAgents(m_world->getCollisionDispatcher());

RigidBodies = gcnew System::Collections::Generic::List();

{
hkMemory::getInstance().preAllocateRuntimeBlock(512000, HK_MEMORY_CLASS_BASE);
hkMemory::getInstance().preAllocateRuntimeBlock(256000, HK_MEMORY_CLASS_BASE);
hkMemory::getInstance().preAllocateRuntimeBlock(128000, HK_MEMORY_CLASS_BASE);
hkMemory::getInstance().preAllocateRuntimeBlock(64000, HK_MEMORY_CLASS_BASE);
hkMemory::getInstance().preAllocateRuntimeBlock(32000, HK_MEMORY_CLASS_BASE);
hkMemory::getInstance().preAllocateRuntimeBlock(16000, HK_MEMORY_CLASS_BASE);
hkMemory::getInstance().preAllocateRuntimeBlock(16000, HK_MEMORY_CLASS_BASE);
}

hkpMultithreadingUtilCinfo threadInfo;
threadInfo.m_world = m_world;
threadInfo.m_numThreads = 1;

threadInfo.m_enableTimers = true;

multithreadingUtil = new hkpMultithreadingUtil(threadInfo);

m_world->unmarkForWrite();
}

and hkBaseSystem:

hkPoolMemory* memoryManager = new hkPoolMemory();
hkThreadMemory* threadMemory = new hkThreadMemory(memoryManager, 16);
hkBaseSystem::init(memoryManager, threadMemory, errorReport);
memoryManager->removeReference();

char* stackBuffer;
{
int stackSize = 0x100000;
stackBuffer = hkAllocate(stackSize, HK_MEMORY_CLASS_BASE);
hkThreadMemory::getInstance().setStackArea( stackBuffer, stackSize );
}

hkError::replaceInstance( new hkEventError() );

I also tried using a hkpMoppBvTreeShape but I'm not sure it [XHk's wrapped function] works correctly yet. It caused HkpWorld::Update to crash
with a System.AccessViolationException.

Thanks in advance.

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Sorlaize,

You really do need to use a hkpMoppBVTreeShape for a mesh this large. Doing a collision test with a plain hkpExtendedMeshShape will cause a collision agent to be created for each triangle in the mesh once the narrowphase check is started between the mesh and the box. The hkpMoppBvTreeShape greatly reduces the number of collision checks that have to be done by encapsulating the hkpExtendedMeshShape and creating an optimized bounding volume heirarchy for it.

If XHk does not support Mopps then it does not support Mopps. XHk is not part of the Havok packages that were released through Intel.

For more information on Mopps, specifically for landscapes, you should check out the documentation under Havok Physics/Collision Detection/Creating Shapes/Landscapes.

I hope this was helpful,
Sean

Developer Support Engineer
Havok
www.havok.com

Yea that helped a lot, the performance is very smooth now =D, thanks for the quick reply. Should I be worried about further optimizations taking into account the patterns in height distribution? And, is this suitable for a much larger terrain mesh if that's what I want to use (rather than splitting it)?

XHk has a few minor problems, but maybe Intel should look into helping develop this or a similar managed wrapper. It would mean game development could move from c++. I feel that XHk would be much improved if only a few Havok developers looked over it or gave a little guidance =)

Hi Sorlaize,

The Mopp should be what you need for doing optimized terrain. It is best to do all your terrain with a single Mopp. Dividing up the terrain into smaller meshes will create more checks in the broadphase. It would be like adding another layer of bounding volumes above the Mopps, when a single mopp will already take care of doing those checks in a more optimized way.

As for Intel or Havok working with XHk, I can't really speak on the matter. I wouldn't get your hopes up though.

Thanks,
Sean

Developer Support Engineer
Havok
www.havok.com

Leave a Comment

Please sign in to add a comment. Not a member? Join today