Properly Deleting bodies in NXOgre

jchmack

11-08-2007 06:50:45

For the longest time my game has been crash free. But recently when working with something completely unrelated (sound) i get crashes referring back to this line in NXOGRE:

NxOgreScene.cpp:


void Scene::simulate(NxReal time) {

mScene->simulate(time);
mScene->flushStream();
while (!mScene->fetchResults(NX_RIGID_BODY_FINISHED, false));

for(Actors::Iterator it = mActors.items.begin();it != mActors.items.end();++it) {
(*it).second.first->simulate(time); <-- it points here!!!!
}
...


with these data errors:
first CXX0030: Error: expression cannot be evaluated
second CXX0030: Error: expression cannot be evaluated

and some times it says that the time expression cannot be evaluated.

its getting really annoying lol i believe that it could be because i am not deleting my projectiles bodies correctly:


mScene->destroyBody(mBody->getName());


i think i might be destroying the wrong body or something and the pointer in NXOgre is still trying to reference it. It seems to delete 99% of my projectiles properly w/out any crashes.

What could i do better to reduce these crashes?

i did upgrade to 0.9-24 a while back and didn't really test the engine out like i did with previous versions. The method mentioned above worked fine before but maybe now its... outdated?

Well ty to all who help in advance =)

betajaen

11-08-2007 09:28:44

I haven't had a problem like that. I would upgrade to the latest 0.9 though. But I'll make some tests later and see if I can replicate the error.

Aiursrage2k

11-08-2007 19:59:10

I was running into the similar problem.

from the ageia forum: Tom Lassanske

Modifying the PhysX simulation between simulate and fetchResults will fail for most every operation (such as creating joints). The frequency of failure will depend on your framerate and what you are doing, when you are doing it, and from which thread you are doing it. In some cases, you may get lucky and see success most all of the time (for very simple simulaions, usually), in others, you'll get mostly failures (complex simulations where much of your frame is spent simulating.

So you need to batch scene modificaions and issue them just after fetchResults. We will have an asynchronous API starting in 2.7.2, which will take care of this batching for you.

betajaen

11-08-2007 20:35:57

I've noticed this as well with creating many Actors at once (at least 20), and the PhysX SDK crashed. But ever since I introduced the new simulation code which is (sort of asynchronous) it works better.

Perhaps there should be some sort of system where we can push Actors into deletion, not at once but eventually deleted when the time is right.

jchmack

12-08-2007 20:29:00

I've noticed this as well with creating many Actors at once (at least 20), and the PhysX SDK crashed. But ever since I introduced the new simulation code which is (sort of asynchronous) it works better.

Perhaps there should be some sort of system where we can push Actors into deletion, not at once but eventually deleted when the time is right.


i have many situations where i create 20+ (36 exactly) actors all at once and it seems fine. Except a small jump when my framerates are low. I guess im semi glad that others are experiencing something similar and ageia has plans to fix it.

on a side note has anything been changed with the character class since 0.9 - 24?

jchmack

13-08-2007 08:59:01

Ok after looking into this a bit deeper. I believe that the problem might be isolated to the newer versions of nxogre (i am using 0.9-24 and will port to the latest asap). I ported BACK to 0.6 (UGH) and i get no crashes. Ill port to the latest version and report back. In hindsight i could have spent this time porting forward to 0.9-latest

edit: Ive upgraded to 0.9-33 and while there are some things i love (ultra high framerates lol) my crashes aren't gone... now its pointing to a line about disabling gravity or something... Well its 4am and as much of an owl as i am i probably should get some sleep. On a sidenote great job with NxOgre betajaen wtf did u do to get these sorta framerates? Big ole leap for me lol keep up the good work.

edit2: lol i dont want to go to sleep lol. The problem seems to be when i access my bodies actor:

mBody->getNxActor()->raiseBodyFlag(NX_BF_DISABLE_GRAVITY);
NxShape* const* s = mBody->getNxActor()->getShapes();

is it not wise to access the actor like this anymore?

edit3: sigh i fixed the jitteryness of my app with this method:
mScene = mWorld->createScene("Main", mSceneMgr, "gravity: yes, floor: yes, time-step-method: variable");

from this thread:
http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=5049
and my framerates are back to normal =(

betajaen

13-08-2007 10:55:27

Good man. Did you try the other fix there? I suspect that's problem for many things we are having with '33.

jchmack

13-08-2007 11:38:13

im trying to run in debug to find out whats wrong and i get these ugly guys:

BetaGui.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
1>NXOgreAbstractor.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
1>Program Entry.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
1>Tools.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
1>SoundManager.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
1>GameCharacterManager.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
1>Game4.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: void * __thiscall Ogre::MemoryManager::op_new_sc(unsigned int,unsigned int)" (__imp_?op_new_sc@MemoryManager@Ogre@@AAEPAXII@Z)
........... and so on

anyone know what these are?

Good man. Did you try the other fix there? I suspect that's problem for many things we are having with '33.

i didn't read the entire thread ill take a look now.

edit: i looked at the full thread and got my fixed timestep to work well =). But i still get the crashes now pointing to something in ogreroot.cpp:


bool Root::_fireFrameStarted(FrameEvent& evt)
{
// Increment frame number
++mCurrentFrame;

// Remove all marked listeners
std::set<FrameListener*>::iterator i;
for (i = mRemovedFrameListeners.begin();
i != mRemovedFrameListeners.end(); i++)
{
mFrameListeners.erase(*i);
}
mRemovedFrameListeners.clear();

// Tell all listeners
for (i= mFrameListeners.begin(); i != mFrameListeners.end(); ++i)
{
if (!(*i)->frameStarted(evt)) <- points here...
return false;
}

return true;

}


bah i wish it would just point to something in my code lol. I really don't understand what is going on here.

betajaen

13-08-2007 12:33:54

I got those first errors too. I had to clean the solution of Ogre, NxOgre and Cake then compile in order to get rid of those.

Second bit, I've seen before. I don't think it's NxOgre, are there any NULL or invalid pointers when you look around in the Visual Debug thingy?

jchmack

14-08-2007 12:43:14


Second bit, I've seen before. I don't think it's NxOgre, are there any NULL or invalid pointers when you look around in the Visual Debug thingy?


hmmmm I am not entirely sure how to look... sorry could you please be more specific?

if i break during the debug crash and look through the variables there are tons of red !s. All having to do with ogre and nxogre none of my actual variables are there.