Organized way of dealing with NXS shapes w/ material

Hello, Its been a while since I've posted, but I just can't continue coding until I share this issue with you guys.

From what I know NXS file shapes can contain information about the material index that the shape is using, right? But this material can't (maybe I don't know how) be embedded on the file itself. I have been living with that for some time now, but I just can't take it anymore, its getting really awkward cause I have to keep the count of my material index when designing my physx meshes? And I have to make sure the material order doesn't change too, that make the whole workflow very tight and unmodulated.

So... maybe thats not the way of doing things. Have you ever needed to embed the material indexes on physic shapes? Is it possible to create and attach material to shapes in a data-driven way? Or something less painfull?

This begun after betajaen told me that the only way I could assign materials to triangle meshes (NxOgre 0.9) was through the NXS file and fluor (worked perfectly).
viewtopic.php?f=6&t=11491

It would be cool to hear what you think. Thanks!

Unfortunately not, it's a PhysX limitation. I have two ideas though:

Hashes

Treat the MaterialIndex as a hash; it's an unsigned short - so you will have collisions, and you need to find an appropriate hash function (one that has few collisions). When saving your mesh in your modeller just give the hashed name to each face for the material index. Then re-create them in your program (just read them from a text file). It's simple and likely to work.

Re-cooking

Another way would be to save the mesh normally, but carry around a file with what the name of material index is in that mesh. Then use another converter to re-cook them with a master list of all your materials; so material index 0 would be changed to 39; if the name was grass.

I prefer hashes idea myself.

[Edit]

Have a look at MD4 for hashing, it seems reasonable, and if it works for you I'm willing to implement the idea into NxOgre.

Thanks, the hash way looks good, still seems weird that PhysX doesn't propose a more elegant way of dealing with that. Looks like they don't think its a good idea to cook nxs files with material in the first place.

Well, if you think about it.

Say; a typical mesh says has 300 faces. So that's 300 * 3 integers representing them. On top of that, you have the collision information per face; all 300 of them. PhysX has to be fast and not use a lot of memory, so it can't look up on strings or use structs, and using pointers would have some overhead (and have serialisation problems). So they use unsigned shorts, which is looked up on a hidden NxMaterial array somewhere.

The problem with that is, then you need some organisation to keep up with things, I suppose they assume that we'll just have it written down somewhere; 0 = is rubber, 1 = is glass, 2 = is wood and so on. But it doesn't really work like that in reality.

Hashes is a good idea though, I'm glad I thought it up. Please tell me if it works, as I will put it into NxOgre.