Max2msh exporter opacity problem

[Scrooge McDuck]

Hello,

I've been using Mindblast's great max2msh import/export tool in the past, it always worked good.
For some reason I now encounter the following problem when I try to export various models in 3dsmax to msh:
"Unknown property: "opacity" in ..."

I have seen a question like this on the old orbiter forum, but no answer. On Dan's forum they seem to discuss this problem, but it is all in french, so I wonder if anyone here knows a solution?
I'm not sure if I should change the material in 3dsmax, or change something to the exporter script, tried different things with no luck.

Some information
max2msh version: v1.29b
3dsmax 9

regards,
mcduck

 

[Spike Spiegel]

I ran across this same problem today, using the plugin in 3ds Max 2009. Can anyone offer some advice? Below is the output of the error.

>> MAXScript Rollout Handler Exception: -- Unknown property: "opacity" in #Multi/Sub-Object:body(Standard:red_checker, Standard:blue_checker) <<

The problem appears to lie in this section of code:

-- make sure, transparent objects are generated as the last objects in the mesh file
if(AktObject.material != undefined and AktObject.material.opacity < 100.0) then
(
append arrTranspMeshes AktObject
append arrTranspNames arrObjects[iObIndex].name
)
else
(
append arrMeshes AktObject
append arrNames arrObjects[iObIndex].name
)

I'm not familiar with MaxScript, but I might try hacking on it if no one comes up with anything. Thanks.

 

[Spike Spiegel]

I'm doing a little troubleshooting today on this. I've noticed what seems to be a correlation between the failure and Multi/Sub-Object materials. I made a simple box and tried a max2msh export. I had no trouble when Standard materials were used. When Multi/Sub-Object materials were used, the error occurred.

Perhaps someone can verify? Also, this is the extent of my experience with MAXScript. Perhaps someone with more experience can come up with a solution? I do plan to continue, regardless. I'd like to find a solution, even if it means I have to redo my UVW maps. My experience with other forms of programming tells me there must be a solution to this.

 

[Notebook]

I think you can only use standard materials with max2msh
From the readme.txt file

Known problems:
- Whenever a script error occured during import/export, you will have to close
and reopen the respective rollout before you can start the script again.
- Mirrored copies of objects sometimes appear as inverted meshes in orbiter
(vertex normals turned to inside), this is due to a problem with the mirror
function in gmax, use the mirror modifier instead.
- Multi-Materials are not supported, the export script will stop with an error
message when it encounters any object with a Multi-Material assigned.
- When exporting meshes that were imported with version 1.0 of the scripts
sometimes the export script stops with an error. This seems to be because
the old import script generated lots of smoothing groups on a Mesh.
In this case you should just import the mesh again using the v1.1 import
script. You may also try reducing the number of smoothing groups in the
meshobject that caused the problem.
- Sometimes the file is dumped multiple times to the listener window, not
sure why. I never had this right after starting gmax though. So if you're
experiencing this, just save your scene, restart gmax and try again.
!!! It is generally a good idea to save your scene before starting the
export script !!!

I've only used standard materials so far,

N.

 

[Spike Spiegel]

Notebook, thanks for pointing out my noob mistake. I should have known better than to skip the documentation. I'm always complaining that people don't read the instructions often enough.

Is there any way to verify if this is an Orbiter limitation or if it is a limitation of the script?

Looks like I'll have to redo those UVW maps after all... oh well.

 

[Notebook]

Afraid I can't help much more with this, I try to keep away from opacity problems! Got the same message as you, and couldn't make any sense of the script. So I keep the meshes as simple as possible, and if they need multi-textures, break them up into smaller parts. Tedious, but it works.

I don't know if its related, but another error message that sometimes comes up is "No TVFaces" Usually have to go back and re-arrange the UVMap in the modifier stack till it goes away.

N.

 

[Mindblast]

So max2msh is still used... interesting.

The problem with multimaterials is, that the script would have to break up the mesh according to materials of each face. In Orbiter meshes you have just one material per meshgroup. This is not as easy as it sounds though, as the normals would have to be preserved. Its already quite complicated now when the script has to split vertices that have multiple texture coordinates and also belong to faces of different smoothing groups. So I took the easy route here and only supported single materials. I guess i'll have a look at the multi-materials again when i have the time, i always wanted to support them but i can't promise anything.

As to the No TVFaces problem i'm not quite sure. Maybe you could send me a file where this happens ?

 

[Notebook]

So max2msh is still used... interesting.

The problem with multimaterials is, that the script would have to break up the mesh according to materials of each face. In Orbiter meshes you have just one material per meshgroup. This is not as easy as it sounds though, as the normals would have to be preserved. Its already quite complicated now when the script has to split vertices that have multiple texture coordinates and also belong to faces of different smoothing groups. So I took the easy route here and only supported single materials. I guess i'll have a look at the multi-materials again when i have the time, i always wanted to support them but i can't promise anything.

As to the No TVFaces problem i'm not quite sure. Maybe you could send me a file where this happens ?

It sure is used, tried all the converters for Max/gmax and I think this is the best. The integration into Max is good, makes it easier to use, and once you get the scaling units right. its easy to hop between Imperial/Metric.

Do you mean a mesh file that gives the problem? I can only access a gmax machine at the moment, haven't tried it on Max version 5, which is the last verion I own. Maybe this only happens in gmax.
I can't remember what was going on when the TVFaces message came up, I think I was trying to apply a texture to a polygon face. So its related to the multi-materials limitation?

Its not a problem to me, I don't make complex meshes, and UV mapping is still a black art!

Thanks for making it,
N.

 

[Mindblast]

It sure is used, tried all the converters for Max/gmax and I think this is the best. The integration into Max is good, makes it easier to use, and once you get the scaling units right. its easy to hop between Imperial/Metric.

Ah yes i did that weird scaling conversion in the 1.29b. That was before i realised you can set the scene units as well as the system units to whatever you like so the scaling in the script was completely unnecessary. I guess i could make a release version 1.3 now with the scaling removed seeing that the beta has been out for years.

Do you mean a mesh file that gives the problem? I can only access a gmax machine at the moment, haven't tried it on Max version 5, which is the last verion I own. Maybe this only happens in gmax.

Well yes, if you come across the problem again and can't find a way to solve it you can always send me a .max or .gmax file so i can try to figure out if its a problem with the script or Max or just some missing texture map in the scene.

I can't remember what was going on when the TVFaces message came up, I think I was trying to apply a texture to a polygon face. So its related to the multi-materials limitation?

Its not a problem to me, I don't make complex meshes, and UV mapping is still a black art!

Did the texture on the object show correctly in gmax/3DSMax ? I guess the error would mean that a material with a texture was assigned to the object but texture mapping is missing for some faces of the object. Maybe you added faces using an Edit Mesh modifier on top of a UVW Mapping Modifier, so these new faces wouldn't have Texture Mapping yet ?
Oh well.. if its not a big problem...

 

[DaveS]

Ah yes i did that weird scaling conversion in the 1.29b. That was before i realised you can set the scene units as well as the system units to whatever you like so the scaling in the script was completely unnecessary. I guess i could make a release version 1.3 now with the scaling removed seeing that the beta has been out for years.

Well, it would be nice if the import script would preserve the meshgroup names instead of renaming them "Group x" where "x" is a number. And then the export script would preserve the meshgroup order.

 

[Notebook]

To Mindblast:

If you want to have a go at Version 1.3 please do! There are lost of people here who would take advantage of it, even If I can't.

Thinking back, there haven't been any TVFaces problems since I stopped making every object a "Editable Mesh", and put a UVMap modifier in the stack!
Before I'd just been using the "Coordinates" and "BitMap Paramaters" rollouts in the material editor to work with textures. Now I also use the UVMap rollout to place the textures.

I think you are right, and I have got on the "wrong side" of the modifier stack, and lost some mapping info.

If I get any more of those errors, I'll keep a note of the files and what going on.

Re Scrooge McDuck's OP; you can export opacity with 1.29b, this tower has opaque parts.
http://i89.photobucket.com/albums/k207/Notebook_04/09081709-07-45GL-01.jpg

Of course, I can't remember how I did it...it was six months ago. Good job I took lots of notes...

N.

 

[Mindblast]

Well, it would be nice if the import script would preserve the meshgroup names instead of renaming them "Group x" where "x" is a number. And then the export script would preserve the meshgroup order.

Ah yes there is a small bug that came with the label tag support causing the renaming of the meshgroups. I'll fix that.
As to preserving the meshgroup order from the import, that would probably require some naming convention for the meshgroup names.. i.e. on import the mesh group names could be prefixed with a number and the export would order by that number and remove it from the exported name. New meshgroups added in 3DSMax wouldn't have the number and so could be placed at the end of the file. The script also orders by opacity though, putting transparent meshgroups at the end of the file as required by orbiter.
Probably would be best not to do this with the numbered meshparts then but it could cause some problems.. for example say you have transparent parts in the imported mesh, add an opaque part to the scene in 3DSMax and then export it. By orbiters convention it would have to be inserted before the transparent parts which would put the transparent parts to different group numbers than they had in the imported mesh. When you put the new part at the end of the file it wouldn't interact well with the transparent parts. So theres a little dilemma.

 

[Spike Spiegel]

I just wanted to let you guys know that I went back in and edited things so that there aren't any more Multi/Sub-Object materials in the model. I then tried an export, dumping the output to the listener window. This time there were no breaks or errors. Thanks for all the help guys! Hopefully it will be smooth sailing from here.

I just have to remember: multiple objects can go in one UVW map, but there can only be one map (material) per object.