Crash in nxOgre::convexShape when calling NxCookConvexMesh

Hi,

I'm trying to construct a convex shape from a mesh, as in tutorial 104, but I have a mysterious crash inside Novodex when trying to cook the mesh.

I pass my array of vertices (a hexagonal prism) into convexShape() and the crash occurs somewhere inside this function, seemingly while trying to write something to "buf"

bool status = NxCookConvexMesh(sd,buf);

Feels like a memory overwrite but without the Novodex source its hard to see whats going on.

As far as I can tell the vertices that I'm passing in seem to be perfectly formed.

Hope you can help (if not, tips on debugging this kind of problem would be just as good)

thanks

Gila

i'm not nxogre guy ,but i know PhysX Pretty much when you recieve error at this position this means that NxCookingInit() was not call to initialize the mesh cooking library .may be it's a bug .

state the steps or the code may be it helps.

@ahmedismaiel
NxCookingInit is one of the first thing NxOgre does when it's started, and any NxOgre developer shouldn't need to call it by hand anyway.


@Gila
Anyway, are any of your vertices repeated (i.e. two the same), PhysX is really picky about that?

Also there is hard limit of 1000 vertices in PhysX and around 200 in NxOgre.

But with debugging, PhysX is pretty much a black box with that function, but my advise if it still doesn't work, try cutting down the vertices or try different shapes to see if it's NxOgre or PhysX at fault and not your convex.

Yeah I thought it might have been a missing NxCookingInit too but that is definitely called on start-up.

I'm passing in verts from a mesh - I don't think any are duplicated but there are definitely two (the centre points of the top and bottom of the cylinder) that would be redundant as far as making a convex hull goes.

I'll try with only the first 4 verts and work up from that, good idea

Bit of a shame Novodex doesn't have any error logging there...

Thanks for the replies, I'll let you know what happens in a bit

Bah, still didn't work, and neither did using the vertices from tutorial 104.

Here's the code... The first section (before "//verts from NxOgre tutorial 104") is concerned with getting the vertex data from the mesh, and the crash happens without using this, so it's probably not relevant. (It's based on some code from meshShape if it looks familiar)



cHex::cHex(cSimulation* pSim, const Ogre::String& name, cHexProperties* pProps)
{
// this should exist if the PSM was inited ok
Ogre::MeshPtr pHexMesh = Ogre::MeshManager::getSingleton().getByName("PlainHex");
assert(pHexMesh.getPointer()); // fail gracefully?

Ogre::SubMesh* pHexSubMesh = pHexMesh->getSubMesh(0);
assert(pHexSubMesh); // should never fire unless PSM has been messed with

// build a vector of Vector3 to build the convex shape
std::vector<Ogre::Vector3> convexShapeVerts;

// get pointers to the various bits of submesh guts
Ogre::VertexData* vertex_data = pHexSubMesh->useSharedVertices ? pHexMesh->sharedVertexData : pHexSubMesh->vertexData;
const Ogre::VertexElement* posElem = vertex_data->vertexDeclaration->findElementBySemantic(Ogre::VES_POSITION);
Ogre::HardwareVertexBufferSharedPtr vbuf = vertex_data->vertexBufferBinding->getBuffer(posElem->getSource());
unsigned char* vertex = static_cast<unsigned char*>(vbuf->lock(Ogre::HardwareBuffer::HBL_READ_ONLY));

float* pReal;

// verts from the Ogre::Mesh
//for( size_t j = 0; j < vertex_data->vertexCount; ++j, vertex += vbuf->getVertexSize())
//{
// posElem->baseVertexPointerToElement(vertex, &pReal);
// Ogre::Vector3 thisVert(pReal[0],pReal[1],pReal[2]);
// convexShapeVerts.push_back(thisVert);
//}

// verts from NxOgre tutorial 104:

convexShapeVerts.push_back(Ogre::Vector3(0.5,-0.5,-0.5));
convexShapeVerts.push_back(Ogre::Vector3(-0.5,-0.5,-0.5));
convexShapeVerts.push_back(Ogre::Vector3(-0.5,-0.5,0.5));
convexShapeVerts.push_back(Ogre::Vector3(0.5,-0.5,0.5));
convexShapeVerts.push_back(Ogre::Vector3(0.25,0.5,-0.25));
convexShapeVerts.push_back(Ogre::Vector3(-0.25,0.5,-0.25));
convexShapeVerts.push_back(Ogre::Vector3(-0.25,0.5,0.25));
convexShapeVerts.push_back(Ogre::Vector3(0.25,0.5,0.25));


// Create the Convex shape, using the vertices and number of vertices as arguments.
mpConvexShape = new nxOgre::convexShape(convexShapeVerts, convexShapeVerts.size());

// Create the convex body.
mpTempBody = pSim->getPhysicsScene()->createBody(name + "_body","PlainHex",mpConvexShape,10,Ogre::Vector3(4,10,4));


}



(Oh, and the reason I'm not using the createBody(?) method is that cHex will eventually not have a body of it's own, just a shape...)

Hmm....Are there any messages being written to the console (assuming your compiling it as a Console application)?


Second, stupid question but you are compiling it as Release and not Debug?

I don't think there was anything in the output window. ...By which I mean the VC8 output pane, I don't have a DOS window, which I guess means it's not a console app. Sorry, I'm a bit rusty on this sort of thing... Would you expect the same messages in both places?

Also the various .log files seem to have nothing untoward.

My app is compiled as Debug, and using the debug NxOgre and Ogre libs and dlls. It's using the Release (only?) Novodex dlls. It could be some kind of dodgy linking perhaps, although I've not seen that kind of thing appear like this before.

I'll have another stare at the code later tonight

I don't think there was anything in the output window. ...By which I mean the VC8 output pane, I don't have a DOS window, which I guess means it's not a console app. Sorry, I'm a bit rusty on this sort of thing... Would you expect the same messages in both places?

Also the various .log files seem to have nothing untoward.


I think all you have to do is change the Sub-System from Windows to Console, in the Project settings.



My app is compiled as Debug, and using the debug NxOgre and Ogre libs and dlls. It's using the Release (only?) Novodex dlls. It could be some kind of dodgy linking perhaps, although I've not seen that kind of thing appear like this before.

Bingo!

There's your problem. PhysX is really really iffy when it's run in Debug mode, especially baking convex, meshes or anything. It tends to do some weird things that Release mode doesn't even care about or ignores, but with debug it makes it crashes.

I've been trying to track down what it does for a while now, but for now the fix is to work in Release mode.

Do you mean use release NxOgre?

As far as I can tell I'm already using release PhysX, as I could only find one set of DLLs in the SDK and there doesn't seem to be any associated symbol information. I could certainly be wrong though.

How can I specify which version to link with?

By the way, in case this is some kind of version conflict, I'm using...

Ogre 1.0.7
NxOgre 0.5.Preview 3.0
Novodex 2.3.2

EDIT:

Another thought: Could it be some thread-safety issue? Does Novodex use threading at all?

Thanks!

No, it isn't thread related, PhysX does can use threads but NxOgre does not make use of that feature.

When you compile NxOgre, instead of setting it as Debug, set it as Release.
Then compile your application as release also, and copy over the release nxOgre.dll over the debug nxOgre.dll when you try it all out.

Still having problems...

I've sorted out the release configuration of my app (and made sure I link with release NxOgre) but I get runtime errors which seem to be related to Ogre not initialising properly. (I removed the #define NXOGRE_DEBUG from nxOgre_configuration.h as well - it seemed to be attempting to access the ogre logging manager)

However, is there a way to compile my app in debug (so I can debug it! ) but still link to release libs? Linking to release Ogre from a debug app seems like a no-no (according to the wiki and various forum posts).

One combination that seemed promising was Debug app, Debug Ogre and Release NxOgre, but it still seems to go down in NxCooking.dll.

Surely there must be a way of running a debug app... otherwise how do you develop and debug with Novodex?

Alternatively, is there a way of working around the problems in NxCooking, i.e. import a convex hull from somewhere or something like that?

Hmm, it's getting really weird now, so let's get this straight:

- Your Application is in release
- Ogre is in release
- NxOgre is in release
- PhysX is in release

All of the dll's are copied over, and it still crashes? But the crashes seem to be related to Ogre?


As for working with debug application and release NxOgre, you could try but it'd probably crash.

Unfortunately debugging with Release is harder; but not impossible I put std::cout's around my code which I think is causing the crash. I've gotten used to it now so working debug is strange to me

But at this point, would you post your Ogre and NxOgre initialising code and the code causing the crashing?

Ahhhhhhh it worked... I found that my release build crash (after making sure I was looking at the right thing and there were no errors in the release config) was because I was trying to load the Debug Ogre plugins rather than Release, which it didn't take kindly to.

Not so sure about not being able to debug - I like my watch windows, modifying variables at runtime, etc... Putting printfs all through the code sounds like the bad old days to me

I might try and hassle Aegeia about the problem... and failing that maybe work around the cooking problem by using a bunch of cuboids for each object. What do you reckon?

Thanks a lot for the help!

I don't think Ageia will give you any help either they'll refer you to the SDK documentation or to the support section.

Besides NxOgre may be at fault, who knows?


As for your cuboid idea, sure but only for debug mode only, then for releases just use the convex shape instead. (I think you can use pre-processor directives for this)

#ifdef DEBUG
....new cubeShape(...)
#else
...new convexShape(...)
#endif

But I know what the problem is and what/why it crashes. It's the UserStream class in NxOgre which is from the PhysX tutorials, there is a second "version" used with the Linux demos which writes the convex to disc and works from it from there which I could try but with my PC out of action it may take a while to fix.

I wrote some code some time ago to track the problem when I was trying to fix it but it's doing something that Release mode doesn't care about or Debug mode is over protective with.