Strange Pure Call exceptions in GetPickedNodeBB

[robmar]

In CSceneCollisionManager.cpp, line 102, where there is the call objectBox = current->getBoundingBox();, I´m getting occasional purecall exceptions which abort the Visual Studio 2010 application - as I´ve no idea how to handle this so I´ve not added a handler.

I´m using getSceneNodeFromRayBB function as is used in the Irrlicht examples, the exception occurs infrequently, in debug mode I can´t see anything wrong... "*current" is a valid scene node when the purecall is detected.

Why should this usually work and then sometimes not?

I mean the class is either derived and implements the virtual function, or it doesn´t... how can "current" for example no longer be derived?

[CuteAlien]

This happens usually when your library headers and your library dll have different versions. Check the console output on start and make sure your include path, library path and your dll all point to the same version.

[robmar]

No but it only fails 1 time in 500, how could that be dll version mismatch related?

Its a recursive procedure, could that cause a problem under VS2010?

[CuteAlien]

No, recursive functions work pretty well since around the 60's I think :-)
Don't really know what else could cause it, so far every time we got that error it turned out to be a version conflict. But I suppose there can be other reasons. But that needs some reproducible test then or we can't help much.

[CuteAlien]

Hm, wait, there might be another reason for this kind of error which is related to this bug: http://sourceforge.net/p/irrlicht/bugs/304/
Are you using a custom scenenode or a custom gui element?

[robmar]

I didn´t grasp the bug mentioned on the link, something about parent-child?

My scene nodes are standard, but there is casting to ISceneNode from derived nodes, such as IAnimatedSceneNode, which is caused by getSceneNodeFromScreebCoordiantesBB() as it only returns the ISceneNode pointer.

[CuteAlien]

No, casting is not a problem as long as your cast is correct. Maybe ensure to check this with node->getType() before you do the cast. If you cast the wrong object then all kind of stuff can happen.

[robmar]

Mainly it just that getSceneNodeFromScreebCoordiantesBB() returns ISceneNode, and the node is an IAnimatedMeshSceneNode, although I think I have a couple of (ISceneNode*)pAnimatedMeshSceneNode type casts, is that a safe method or should I use a dynamic cast?

[CuteAlien]

You should never use a dynamic cast with Irrlicht types as it's compiled with rtti disabled (so you would just get 0). Instead if there's a chance a type is not of the correct type you should check with getType(). Downcasting to ISceneNode from a derived type will always work. But upcasting from ISceneNode to IAnimatedMeshSceneNode you should check if getType() == ESNT_ANIMATED_MESH. And if it's not then find out what kind of type you get.

[robmar]

Thank for the tips, I never upcast as that seems definitely unsafe without know the type as you mention.

I made some code changes as there was a possible race condition which could have caused the node to be deleted during the getscenenodecall from another thread.

I´ve noticed that if I run my app multiple times they all run fine, no overload, I see the cores load up as I run more apps, seems to indicate the bottleneck with Irrlicht isn´t at the GPU but on the core being used... multitasking has to be a good area to boost performance.

Any threads on handling that?