JME3 Fileformat *.j3m

First thing, I love jME3! Great work!

I dare to say it's by far faster than jME2, because big and heavy Ankhel scenes, which cause problems in jME2, are smoothly rendered.





I miss only one thing. Sometimes models use not only one but many textures(color textures).

j3m Files seems to only allow one texture. It would be great to define textures only for special model parts.



And why doesn't j3m use the xml format? :expressionless:


Material BlackHawk : com/zero/material/phong_lighting.j3md {
    MaterialParameters {
         m_Shininess: 1.0
         m_DiffuseMap:  data/mesh/blackhawk/blkhwkm.jpg
         m_NormalMap:   data/mesh/blackhawk/blkhwkm_NRM.png
         m_SpecularMap: data/mesh/blackhawk/blkhwkm_SPEC.png
    }
}

<Material name="BlackHawk"  file="com/zero/material/phong_lighting.j3md">
<MaterialParameters>
<m_Shininess>1.0</m_Shininess>
.....
</MaterialParameters>
</Material>

You will have to write your own materialdef file for that (or maybe theres even one already), look at the "Common/" folder in the jmonkeyengine3 jar file or the currently implemented ones. Then you reference that in your material file.



In effect the material is a result of shaders, a matdef file and parameters that are filled in the final material file. The matdef and material syntax is based on the glsl syntax using {} brackets etc. And personally I think using xml would probably make it harder to read/write.



Cheers,

Normen

I guess its possible to make J3M store more than one material, but many parts of the system assume it only contains one, so I don't think it's feasible. Either way when you export to J3O the J3M files are included so its not like its higher overhead.



It's not using XML, because you're expected to write it by hand, rather than simply view it. It will be possible to edit it in the JMP though.

One short question!



Is jME3 capable to read or write xml? I found some DOM classes, but i'm not sure :?

In jME2 I used jDom to read and write xml files. It would be nice to use a built in solution, otherwise I will stick to jDom, but there should be some methods included, since you use "xml" for ogre and the nifty gui





I only write the first xml prototyp, afterwards I feed a tool with it and let the tool do all the work xD

OgreXML is only used for importing, in a game you would not want to do the conversion each time the game loads. And the binaryexporter can export binary and xml jme3 object files.

Oh, that's not what I want to do :stuck_out_tongue:

OBJ is my choice!



I want to create xml files for different purpose! Like saving a high score or to create a savegame :wink:

DarkPhoenixX said:

OBJ is my choice!

Well the same accounts for obj, its unnecessary conversion. To extend the materials you could extend the Material class and make the additional properties savable.

You can always implement the Savable interface and export your objects as either binary or XML that way.

Hey, me again :smiley:



I've realized, that the OGRE Material Loader is anything but ready to be used.

Since I need it, I would be willing to implement it to support most Texture features, Colors, etc…



I've already implemented Ambient Color loading into it, and fixed the bug, that the Colors aren't set on the created Materials in the OGRE Loader.



Is currently anybody else developing on the OgreXML importer?

If not, I would take care of the OGRE Material Loader :wink:

tim8dev said:

Hey, me again :D

I've realized, that the OGRE Material Loader is anything but ready to be used.
Since I need it, I would be willing to implement it to support most Texture features, Colors, etc..

I've already implemented Ambient Color loading into it, and fixed the bug, that the Colors aren't set on the created Materials in the OGRE Loader.

Is currently anybody else developing on the OgreXML importer?
If not, I would take care of the OGRE Material Loader ;)

Okay, that's fine. Just don't add an extra 20 to it ;)