Surface Order Keeps changin! (help)

Dear All,

Let's say I have a (3ds) model that has 3 surfaces/materials.
Recently I noticed that when I load that model the ORDER of it's 3 surfaces is NOT always the same! Sometimes it is, sometimes it isn't.

For example:
Surface 1=brick, 2=water, 3=ground

Then sometimes when I load it it's:
surface 1=water, 2=ground, 3=brick

Is this 'normal' blitz behaviour or is this out of the ordinary?

Currently this effect is a complete showstopper for my vertex lighting system (i manually load/save the vertex colors so I don't need to rerender them - which could take minutes).

Anyone encountered this before? Is there some other way to identify a surface in a UNIQUE way?

Any help or tips appreciated!
Danny.

Ok I should have done a proper seach before, and this 'changing surface order' seems to be a Blitz 'feature' :(((

Several people recommend to 'find something unique' like a surface's vertex count or texturefilename.
But that's not a very realistic and full-proof approach. Since it would be more than possible to have surfaces with similar vertex counts and or similar texture filenames...

So has anyone ever found a solution to this problem?
I can't imagine there's no workaround to this...

D.

Not sure if this is a blitz feature or a DirectX feature. sounds more like "Gates" than "Sibly" IMHO. I mean, seriously, could you imagine Mark adding a "RAND(index)"? But I definitiely can image the guys at redmond are doing such things :) just remember: executing native code found in jpgs - how stupid can somebody be anyway.

Personally I'm using texture names/paths as the identifier. This works well for my needs. If you need a bulletproof system then how about tags. If you load the mesh then you could use LoadAnimMesh instead and use the Entity Name$ to store their index.

Finally, if you need total control then you still can define your custom mesh file format. This way you can "reconstruct" (using CreateMesh, AddSurface etc.) a mesh instead of using the internal LoadMesh command.

ok cheers,

Yes it's probably some DX stuff. Any logic behind it totally fails me..

I think I'll do some more research because I get the impression that the actual ORDER of surfaces remains the same - but only 'which surface is FIRST' changes...!

But I need to test this to be 100% sure about that. If that's true it would be a hell of a lot easier to figure it out..

cheers,
d.

I had this problem too, if memory serves you need to use

GetEntityBrush
GetSurface
GetSurfaceBrush
GetBrushTexture

Then you find the texture name and can identify what surface is what.

I'll try and dig the code out tonight.

Yes that's basicly the method I use a well. It's part of the original SaveB3D example from the code archives.