I was trying to modify certain material of my model loaded from file in OgreXML format and I noticed that material’s name property is always null. I checked the code and to me it seems that MaterialLoader is at fault (assuming that up-to-date code is this one: jmonkeyengine/MaterialLoader.java at master · jMonkeyEngine/jmonkeyengine · GitHub ). During compileMaterial(), where new material is created, there should probably be something like:
mat.setName(this.matName);
Funnily enough, everything works, because materials are seem to be stored in hashMap with matName being the key, so Loader knows materials by name, can apply proper material to a mesh, and everything loads fine, except that material name is forgotten as soon as asset leaves the Loader.
Did anyone else notice this problem before? Is material name retrieved in some other way?
EDIT:
just tested that adding setName works - now I can see materials names after loading my model.
Having the same Problem with the BlenderImporter (which might simply be a wrapper for blend->ogre->jme)
btw: Usually the MaterialName is not really important though. If you want to achieve something like “set Wireframe for all Materials that start with xy”, you might want to export a .j3md File from the Model and manually set the Materials.
The blender importer reads .blend files directly, there is no blender->ogre->jme chain.
“Material names” are not really interesting btw, a blender material doesn’t translate 1:1 to a jME material anyway. Since you should basically only use UV mapped textures anyway they (or rather their names) should be a good enough hint at the “material”. A (jME) Material that uses the same textures and settings as another is considered the same (e.g. when batching) as well.
I general, yes, uv mapped textures are the way, but what I wanted to do is colouring some parts of unit according to player that owns them. For example, say I want units of Player 1 to have red skin, and units of player 2 to have blue skin. I wanted to do this by loading the model, finding material named ‘skin’ and change its’ ambient/diffuse colors accordingly (I don’t want to predefine materials or textures, I want just to apply a color to part of model).
I guess it would make more sense doing that per mesh/object and their names or via extended user properties like a string saying “player_color_change”. After all you want to change the objects properties really. Still, if your “skin” parts use the same texture you can still check by texture name. But I guess it would make sense to allow more than one type of surface being changed by “player color”.
Yeah, you’re right - doing that per object/mesh name makes more sense than per material, I’ll do that, thanks for a suggestion.
Still, having a property ‘name’ in Material class and leaving it null while knowing it’s true value, because it’s “not really interesting” seems like a pretty weak excuse to me
Ok, I stand corrected. It’s probably that I’m not that far into all them material things to see the difference (so far I’ve been using them pretty much 1:1 in my little project). Thanks again for quick solution to my issue.
