Adding Rigid Bodies In A Loop Cause An AccessCheck Breakpoint To Be Hit

Adding Rigid Bodies In A Loop Cause An AccessCheck Breakpoint To Be Hit

Portrait de edcampion
edcampion
lun, 09/04/2012 - 06:33

Hi, I'm trying to add rigid bodies in a loop as in the Rope Bridge demo. I have a wrapper class which attaches a graphical representation to them. If I try and add 20 of them all is fine, 40 and above and I hit an accessCheck breakpoint, even though I am not steppingmultiThreaded, and I thought I had markedForWrite and unmarked correctly.The breakpoint is hit when physicsWorld->stepDeltaTime(secTime): Here is how the body is created. 

void OgreRigidBody::createBoxHavokRigidBody()

{
	hkpConvexShape * shape = new hkpBoxShape(mSize, 0.0f);

	hkpRigidBodyCinfo boxInfo;

	boxInfo.m_shape = shape;

	boxInfo.m_position = mPosition;

	boxInfo.m_contactPointCallbackDelay = 0;

	//fill in the rest of boxInfo

	createAttributes(boxInfo);
	mHavokBody = new hkpRigidBody(boxInfo);

	mHavokWorld->markForWrite();

	mHavokWorld->addEntity(mHavokBody);

        mHavokWorld->unmarkForWrite();

	mHavokBody->;removeReference();
	shape->removeReference();
}

Here is createAttributes: 

void OgreRigidBody::createAttributes(hkpRigidBodyCinfo & boxInfo) {

 boxInfo.m_mass = mMass;

 hkpMassProperties massProperties; hkpInertiaTensorComputer::computeBoxVolumeMassProperties(mSize, boxInfo.m_mass, massProperties);

 boxInfo.m_mass = massProperties.m_mass;

 boxInfo.m_centerOfMass = massProperties.m_centerOfMass;

boxInfo.m_inertiaTensor = massProperties.m_inertiaTensor;

boxInfo.m_solverDeactivation = boxInfo.SOLVER_DEACTIVATION_MEDIUM;

boxInfo.m_motionType = mBodyType == Box ? hkpMotion::MOTION_BOX_INERTIA : hkpMotion::MOTION_SPHERE_INERTIA;

 boxInfo.m_linearDamping = mLinDamp;

 boxInfo.m_angularDamping = mAngDamp; }
Here is the loop that creates the bodies

for( int i = 0; i < iNum; i++ )

	{
		        OgreHavokBodyAttributes boxAttr;

			boxAttr.SceneMgr = sceneMgr;

			boxAttr.World = physics.GetPhysicsWorld();

			boxAttr.BodyType = OgreHavok::Box;

			boxAttr.BodyName = "BridgeBlock" +  StringConverter::toString(iNum);

			boxAttr.Size = halfExtents;

			boxAttr.Position = basePos;

			boxAttr.MeshName = "cube.1m.mesh";

			boxAttr.MaterialName = "";

			boxAttr.Mass = 20;

			boxAttr.angDamp = 2.0f;

			boxAttr.linDamp = 0.5f;

			boxAttr.angDamp = hkpMotion::MOTION_SPHERE_INERTIA;

			bridgePieces.push_back(new OgreRigidBody(boxAttr));
			rb = bridgePieces.back()->getRigidBodyPtr();
			rb->setCollisionFilterInfo( filter->calcFilterInfo( ROPE_BRIDGE ) );

Here is the call stack. HavokTest.exe!hkMultiThreadCheck::accessCheck() Line 254 + 0x71 bytes C++ HavokTest.exe!hkpWorld::getMemoryWatchDog() Line 2855 C++ HavokTest.exe!hkpSimulation::stepDeltaTime() Line 377 + 0xe bytes C++ HavokTest.exe!hkpWorld::stepDeltaTime() Line 2437 C++ HavokTest.exe!Physics::Simulate(float secTime) Line 192 + 0x11 bytes C++ HavokTest.exe!HavokTest::frameRenderingQueued(const Ogre::FrameEvent & evt) Line 144 C++ 

void Physics::Simulate(float secTime)

{
	if(secTime>0.00001)// time of zero causes an exception

		hkpStepResult hr= physicsWorld->stepDeltaTime(  secTime  );
	stepVisualDebugger(secTime);

}
The solution may be quite simple, the rope bridge had been working perfectly(I've removed statements from the above sample to trackdown the error). I then tried to add multithreaded and included in my Havok includes, almost instantly things fell apart. I have since commented this out, and cleaned the solution multiple times, to no avail. This collection of rigid bodies are the only things in the world, their graphical update is not being called(read the position of the rigid body and applied it to the Ogre node).

RSS Haut
4 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de havokTyler
havokTyler
mar, 10/04/2012 - 17:53

You say you "tried to add multithreaded" and removed it later? It sounds like this is where things went wrong. What exactly did you change and then remove?

If you're hitting multithreaded access checks then the hkpWorld was constructed with a multithreaded simulation ( check hkpWorldCInfo::m_simulationType when you're creating hkpWorld ). But if you're not doing a multithreaded step and don't want to worry about the access checks then you should be using SIMULATION_TYPE_CONTINUOUS not SIMULATION_TYPE_MULTITHREADED.

Cheers,
Tyler

Haut
Portrait de edcampion
edcampion
jeu, 12/04/2012 - 06:23

Thanks Tyler, I was single threaded stepping, but with a multi-threaded world, because neither DISCRETE or CONTINUOUS worlds updated. What I mean by that is that in the visual debugger, the bodies would show, but they would not move. What simple mistake am I making? EDIT- Ran it again, seems to work, the mark calls are designed to provide exclusive access, so using them in a single threaded sim blocks the simulation? EDIT TO THE EDIT Just an FYI adding the 50 bridge pieces kept freezing the simulation, I doubled the amount of allocated memory to hkMemoryRouter* memoryRouter = hkMemoryInitUtil::initDefault(hkMallocAllocator::m_defaultMallocAllocator, hkMemorySystem::FrameInfo(1000000)); This fixed it, but should I be allocating that much. 

hkpWorldCinfo info;

			info.m_gravity.set(0, -9.8f, 0);

			info.m_collisionTolerance = 0.1f; // Default value 
			info.setBroadPhaseWorldSize(10000.0f);

info.setupSolverInfo(hkpWorldCinfo::SOLVER_TYPE_4ITERS_MEDIUM);

			info.m_simulationType = hkpWorldCinfo::SIMULATION_TYPE_CONTINUOUS;

			physicsWorld= new hkpWorld(info);

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

Haut
Portrait de havokTyler
havokTyler
ven, 13/04/2012 - 18:42

"Ran it again, seems to work, the mark calls are designed to provide exclusive access, so using them in a single threaded sim blocks the simulation?"
- The markForRead/Write calls are simply for debugging purposes and do not actually lock or unlock anything. In a single threaded sim these mark calls actually do nothing.

"Just an FYI adding the 50 bridge pieces kept freezing the simulation, I doubled the amount of allocated memory tohkMemoryRouter* memoryRouter = hkMemoryInitUtil::initDefault(hkMallocAllocator::m_defaultMallocAllocator, hkMemorySystem::FrameInfo(1000000));"
- That sounds okay. We typically allocate a 2+mb buffer for the solver frame just to be safe. Although you should be getting a warning msg and an assert if you run out of solver memory.

-Tyler

Haut

Connectez-vous pour laisser un commentaire.