Is there a known issue with the 2009 exporter not handling UV maps? It seems to work fine in previous versions of Max, but one of the 3D artists I’m working with has 2009, and won’t switch (sigh), and none of his UV maps work.
Basically, the model acts as if there is no UV unwrap at all when a texture command is called. Again, anything in previous versions has gone through with no problems.
I searched through others’ exporter woes, but didn’t see anything for this. Has anyone tried it?
I don’t know. I don’t have a copy of Max 2009, so I can’t debug it. Someone with that version would need to debug the problem.
I have 2009 and i have some technical knowledge of the EGG format… if you want, i can take a look.
Afaik the exporter can just export one channel. So if he uses more than one, he will run into troubles.
That would be great, thanks. I mostly just want to see if this works for anyone else, and if it’s just something he’s doing differently. As far as I know, it’s only one channel. Have you exported a mesh with UV in 2009 and had it work with Panda?
So, I have done more tests with this, and it’s definitely some sort of inconsistency between the 09 exporter and the previous versions.
When an object is exported with a UV texture, and just the egg is loaded, the object appears perfectly normal. The setTexture() command does not work, however, for that texture or any other image file. If the texture file is renamed or moved, a link seems to be broken between them, and the object never appears normally textured again. In previous Max exporters, I can apply any image as a texture, and it comes up perfectly UV’d.
I am truly baffled here. I’m pretty sure I can’t really debug this myself, but anything to get me pointed in the right direction would be greatly appreciated. Thanks.
Have you tried applying the override parameter to setTexture(), e.g. node.setTexture(newTexture, 1)?
David
That’s what I was doing. I wasn’t aware you could call setTexture() without parameters. Hmm.
EDIT: Does it have anything to do with this?
Under NodePath → setTexture
set_texture in the reference only comes up with “MotionTrail” 
Now I’m even more confused.
There are lots of variants on setTexture. You can call:
np.setTexture(texture)
np.setTexture(texture, override)
np.setTexture(textureStage, texture)
np.setTexture(textureStage, texture, override)None of them have no parameters, however. The first one (and the third one) wouldn’t work if your model already had a texture. The first two are convenience versions of the second two, which assume the default TextureStage.
Still, I was trying to figure out what you mean by “the setTexture() command does not work.” If you have applied an override and it didn’t stick, I suspect then the problem is that the egg file has its texture applied on a named TextureStage, instead of the default TextureStage. In this case, the only way to replace the existing texture is to first get a handle to the existing TextureStage, like this:
ts = model.findTextureStage('*')
model.setTexture(ts, newTexture, 1)David
Sorry, I must not be explaining this properly.
I have no reason to believe that there is any problem with the setTexture command. I have used it with no problems with models exported from older versions of 3D Studio Max. What I was getting at is that when a model is exported from 3D Studio Max 2009 and I try to apply a texture in the exact same way, it does not work. My guess was that there is a problem with the Max09 egg exporter. Here is the exact process we are going through:
-If setTexture is used to apply a different image, the model comes up in a solid color - the UV unwrap seems completely nullified, and it seems to take just one pixel from the image and apply that color to the whole mesh.
-If the texture image file is renamed or moved, it is no longer applied to the model, even if it is renamed or moved back to its original name/place. setTexture will also not correctly apply the image.
Sorry if I keep getting hung up on this, but I feel I need to stress that everything works perfectly fine with older versions of 3D Studio Max. I only have this problem with 2009, which is why I see no reason that it should be a scripting issue.
These are the symptoms of either having no UV’s on the model, or of having named UV’s on the model that are not consistent with the TextureStage you are using.
Since the original texture works fine on the egg file, it follows that you do have UV’s on the model. But since you’re reporting the above symptom, it further follows that you must have named UV’s on the model that are not consistent with the TextureStage you are using.
Thus, the “bug” in the new Max exporter might be simply that it names the UV’s on the model, while the old exporter didn’t.
If you use the original TextureStage from the model to apply your new texture, as I described above, that should obviate this problem, because the original TextureStage will have a reference to the proper UV name. Or, you could simply examine the egg file, and see what the UV name is. It’s the “name” in the string “ name { 0 1 }”.
David
This does seem to be exactly what happened. My apologies, all the work I had done with textures previously has been with the earlier Max exporters, so I never had to use TextureStage before.
Sorry, just one more question on this. Here is the line about the UV in my egg.
<Scalar> uv-name { m1 }In a model with multiple textures/UVs, this line is exactly the same for both. Even after saving the UV and naming it something else, and re-exporting the egg, this line stays the same. If I change anything in here, the UV is completely removed. Any ideas on how to get unique UV names into here?
Huh, that’s weird. At the BVW they seem to have the problem too:
sites.google.com/site/bvwpublic … ax-texture
It’s even weirder considering this is the code to generate a uv texture name:
std::string MaxToEggConverter::get_uv_name(int channel) {
ostringstream uvname;
uvname << "m" << channel;
return uvname.str();
}Furthermore there’s no reference to the string “uv-name” in the max exporter 
The UV-name in the above quoted line is “m1”, not “uv-name” (the quoted line is from the entry, not the vertices, so the name shows up in a different place).
So, the Max exporter names each UV set based on the channel index, not on the name assigned within Max.
David