Corrupt mapping issues on .msh

[Scarecrovv]

Hey there,

Bored one day I decided to have a look at making a model to pop into orbiter.

I have an old model I made for Celestia allready in 3DS format. So I ran it through Msh_Maker and dropped it in the mesh folder and (using the UFO config files) I ran Orbiter.

Voila. I had a model but no textures.

After a bit of tweaking I discovered that I can't use JPGs - no surprise there. Neither can I use BMPs (in 24bit mode) - bit of a surprise but undaunted I downloaded the nVidia DDS plugin for Photoshop and converted the textures to DDS.

Hooray one ship, textured.

Unfortunately whilst the correct textures seem to be applied to each seperate mesh group, the UVW mapping appears to be completely screwed. It looks as if it's actually inverted.

Any suggestions as to what's going on here?

The model is exported from Studio MAX 8.0. It has 9 mesh groups with a seperate BMP file assigned to each.

The debug.txt file that is created by Msh_Maker references the BMP files but obviously the versions in the Orbiter texture folder are DDS files.

All texture files are either 64x64, 128x128 or 512x512 with no mip maps.

Is this a discrepancy caused by having more than one texture file assigned to the mesh?

Regards

Crow

 

[jedidia]

having more than one file is no problem, as long as you don't have submaterials in the same group. But I think you wouldn't be able to convert the file if that was the case.

I never had problems with the UVW-map getting screwed. What converter are you using? You said something about inverted... is it possible that not the Map is inverted, but the normals instead?

 

[Scarecrovv]

I've quick-fixed it by flipping all the textures vertically but the images and text are all mirrored now!

It could be the normals. It is possible that the X-Form needs resetting in MAX. I'll look into that first

Yeah each section of the model is divided into shell groups corresponding to the texture applied to it so there's never more than one DDS assigned to each shell. This was done for Celestia because having more than one texture per shell freaked it out and screwed the mapping up.

Crow

 

[Coolhand]

Is it something to do with mirroring the ship? But then i guess your normals would be quite clearly flipped in that case.

Your name is familiar btw. didn't you used to post on SFM? I remember you had some neat traveller / elite ships.

 

[ar81]

When you load the mesh in MeshWizard, check the flip UV option before loading mesh. Then you can save the mesh and overwrite it. That will correct your corruption problem. It seems that MshMaker converts texture coordinates as 3DS without knowing that MSH format needs them to be flipped.

Mesh Wizard also has an option to flip visible side of groups.

 

[jedidia]

I've quick-fixed it by flipping all the textures vertically

No, doesn't sound like the normals... No Idea what could be the issue.

..erm... wait. Random thought: BMPs are written backwards, in Photoshop you have the ability to switch that. If you converted your DDS out of an inverted bmp, what you described could happen.

Then again, probably not... The UV-Map wouldn't have the right positions anymore, and you'd get a complete mess instead of just mirrored textures... :huh:

Edit: I think ar81 got it pinned down... I never worked with Meshmaker, so I don't know. When you work with Max, there's a script for importing and exporting .Msh-files which works really well.

 

[Scarecrovv]

Coolhand, yeah that'll be me.

ar81 - that sounds exactly like what the problem is. I've had a play with meshWizard and found the 'flip UVs' switchbox. It didn't actually appear to make any difference but I was working fast at the end of lunch so I'll have another proper go later.

Jedida, I might have a look at the MAX exporter, that might make things easier. It's a shame there's not a Maya exporter as that's my modeler of choice.

Cheers for the responses everyone.

Crow

 

[DaveS]

Jedida, I might have a look at the MAX exporter, that might make things easier. It's a shame there's not a Maya exporter as that's my modeler of choice.

Here you go: http://www.nestadlinn.de/orbiter/downloads/max2msh129b.zip

I use it all the with GMAX and the only thing you need to stay away from is Multi-materials as Orbiter doesn't support them so the script will complain if you you're using one!

 

[ar81]

ar81 - that sounds exactly like what the problem is. I've had a play with meshWizard and found the 'flip UVs' switchbox. It didn't actually appear to make any difference but I was working fast at the end of lunch so I'll have another proper go later.

I did not add a checkbox like "fix MshMaker mesh" since such message would have caused problems, since if you load a mesh without problems it would flip UVs, since there is no way for the program to know if the mesh is wrong.

Also, I guessed that if some other converter had that problem, adding such label would add some bias.

This feature is documented in the manual.

If you see the manual of Mesh Wizard, you may see how to recognize problems with normals, and you will learn great many things on meshes.