meshShape building

Hi, I've just started NxOgre today, although I've had a lot of past experience in NovodeX. I'm attempting to make a meshShape with an already-loaded entity, although it's breaking in the function: MemoryWriteBuffer::storeBuffer() at this line: memcpy(data+currentSize, buffer, size);

Is there any restrictions / limitations that the *.mesh file needs to have to properly build this body off of? I currently have mesh files w/positions, normals and texcoords [2 units] in each vertex. Is there anything else that needs to be in there?

Or any other suggestions...
Thanks.

P.S. I also noticed the ability for PMaps is currently not in there, or at least in the tutorials it's gone. This is a major part of NovodeX, or at least what I'd be using it for; is there any information on these making it back in anytime soon?

That sounds like a debug crash there, you should be using NxOgre in release, because of the release libraries that come with PhysX.

As for PMaps, I've decided not to support them, apart from the cryptic code to create one, they are slow and not very good. I'd use a shapeGroup/convex combination instead.

Great. Thanks for the input.

Unfortunately now, when switching to the Release mode, I'm getting an error creating the world on:
mWorld = new world(mRoot, mSceneMgr);

I agree about PMaps insanity; we used them for an old project, and oh dear they were a pain. Haha.
Anyway, thanks for your great work thus far.

I swapped the mSceneMgr to the Scene now because of Dagon having multiple scenemanagers, NxOgre can use them now.

So it now goes:-


world* mWorld = new world(mRoot);
scene* mScene = mWorld->createScene("MyScene",mSceneMgr);


I noticed that code earlier somewhere... I tried it and got compiler errors:

'nxOgre::world::world(const nxOgre::world &)' : cannot convert parameter 1 from 'Ogre::Root *' to 'const nxOgre::world &'
'nxOgre::world::createScene' : function does not take 2 arguments

What version of NxOgre are you using?

Version: 0.5.Preview 3.0 "Spoon"

Alright, I suggest you upgrade to the CVS, it's more stable than Spoon.

Ok, Installed the CVS today, linked it up and no longer getting an error loading the world... but it's still blowing up on the creation of a new meshShape:

shape *mShape = new meshShape(objEnt, mScene);

Okay, it usually crashes when it runs in debug mode. Can I assume your running in it in debug?

I'm running the build off a Debug for my program itself, but the NxOgre lib I'm linking/testing with is the Release version.

Alright, it's best to run in release program and release libraries. PhysX really hates debug for some reason.

I've tracked the problem down to the memory manager a while back but can't understand why it crashes. I think debug mode is over protective with things like that.

ahh, I see. Because when I switch to Release mode of NxOgre, it explodes on creating the actual world, in a debug statement:
#ifdef NXOGRE_DEBUG
Ogre::LogManager::getSingleton().logMessage("[NxOgre] NxOgre Log started.");
Ogre::LogManager::getSingleton().logMessage("[NxOgre] Starting up PhysX SDK");
#endif
Then when switching to Debug mode, it explodes on:
memcpy(data+currentSize, buffer, size);

It crashes when it writes to the log manager!?

Have you created Root before you created World?

With memcpy:

Yep, that's the error that I and everyone else gets.

Yeah, as it doesn't blow up in the Debug mode...
The mRoot is definitely created, I checked it all through a breakpoint.

So let's get this straight:

Your application is ran in Release.
NxOgre is compiled in Release.
Ogre is compiled in Release.

And it crashes when it writes the log?

Yes that's correct.
- Project release.
- OGRE release.
- NxOgre release.

All of it using the properly linked LIB/DLL's, and still blowing up making the body in the release ver.

Right, it's crashing when the meshShape is being created? Or the printing out to an Ogre log?

Crashing right in the constructor, very first logging call. D:
I did notice, when compiling my NxOgre build, that I had an error on the fopen_s function not being found. So I commented that out and uncommented the one to swap above that.
Would that perhaps be the root of this problem writing to the logger? I believe the actual debugging error was an 0x000000 null pointer error. Which makes sense if this swapped out function caused a problem.

I'm not sure. I can't see why the Ogre::LogManager would be any problem, many people have used NxOgre and never had that problem.

You could try adding a comment to all of the Ogre::LogManagers in the NxOgre source.

Also I've verified that the meshShape does work on 3.0 and the CVS versions. But I have some questions about that.

- Does the mesh you load have double vertices (two vertices sharing the same location), if so PhysX crashes on site of them.
- Does the mesh work with Ogre normally?

- Does the mesh you load have double vertices (two vertices sharing the same location), if so PhysX crashes on site of them.
I'd have to check with the artists on that. As far as I know they just export them straight out of Maya using the OGRE exporter plugin.
- Does the mesh work with Ogre normally?
Yes, all of these meshes are working fine w/OGRE.

I was first leaning on the meshes being the problem, since on a past project NovodeX was quite picky about the information supplied, so we ended up writing our own loader for that.

What all does NxOgre depend on the mesh having, besides not having shared verts?

Nothing really, it just hates shared vertices.

You could try out using nx.stairs1.mesh which comes with NxOgre and see if crashes on that.

nx.stairs1.mesh loaded fine.
It must be shared verts [or something else] that're exploding on the models we have.
Thanks so much for sticking with my problem and limiting it down, I really appreciate it.
I'll post results to this thread when I get info from the animators @work tomorrow.

No worries. If there is a bug, I like to track it down, incase it's not a user error but something to do with NxOgre.

But shared vertices seem the problem here.

Yepyep, that was the problem.
We've been exporting using the Maya->OGRE exporter, with "shared geometry" clicked. D'oh!
I think I made all the animators very sad today haha.
Thanks again, betajaen.

Well I think there spirits may pick up again when they see thousands of cubes splattering all over their work

This is very true
We're mainly using it for a lot of raycasts and such; object picking. But yeah, I'll throw a nice little demo together to make 'em happy.

I guess I do have one additional question about a sceneNode:

Currently, through just OGRE code, I have [loading from a database, so I kind of want to stay away from scripted XML files and whatnot, but rather a very dynamic database-pulling structure in C++], a bunch of sections of a house; e.g. ceiling, walls, floor, and so on...

There's many material aspects to all these, so keeping the mesh object w/their material is quite needed [colourmap+lightmap, shaders, etc.]. Is there any way to just use NxOgre to base a body off the geometrical data from an objEnt and use that for things such as object picking, raycasts, etc.? Or will this basically double-render the mesh?

Also, would you recommend, for object picking and collisions [which is pretty much the extent of the physics we're gonna need], to use a ContactReporter and hook a body to the camera and test it with the objects? Or perhaps Raycasting?

I'm also noticing the NxScene which looks cool, and perhaps fixing to implement that in with these bodies as well.

Yep, load the static body as normal, but instead of giving out a mesh filename for the body; just set the string to blank.

As for collisionReporters v.s. ray picking - You could try both and see how it turns out. But I have no definite answer either way.

NxScene should be able to support the basics of map loading, except it doesn't support joints or convex shapes yet, but it'll help you long at least.

Yep, load the static body as normal, but instead of giving out a mesh filename for the body; just set the string to blank.
Awesome, I got it to a point at least where it won't blow up; testing on a couple [non-shared geometry] models. Unfortunately my mWorld->debug(true); isn't working -- and I've been reading lots of threads to try and fix this problem.

As for collisionReporters v.s. ray picking - You could try both and see how it turns out. But I have no definite answer either way.
Yeah, I figured as much. Benchmarking will tell.

Thanks for the input.

Yep, load the static body as normal, but instead of giving out a mesh filename for the body; just set the string to blank.
Awesome, I got it to a point at least where it won't blow up; testing on a couple [non-shared geometry] models. Unfortunately my mWorld->debug(true); isn't working -- and I've been reading lots of threads to try and fix this problem..

When you go into Debug Mode does it crash then? Cos I think may have the fix for that, else you may have to use a newer than CVS NxOgre I found.

Got raycasting to work perfectly; flawlessly. Quite nice benchmark too.

When you go into Debug Mode does it crash then? Cos I think may have the fix for that, else you may have to use a newer than CVS NxOgre I found.

It doesn't crash or anything. I checked the materials being loaded, even changed the material in the core code... but it just doesn't show up or anything.