New XML IO based on JME(Im|Ex)porter and compatible Blender exporter

The subject sums it up pretty well: I finally decided to work a little bit on a new XML IO system.

It turned out to be less coding work than I thought - but far more copy and paste code than I'd like. But at least the xml readability is OK. Working so far:

The code is not very clean and a lot of things that are in the Interfaces are not implemented yet, but the most important stuff is working already:

















Feature jME Import jME Export Blender Export
Local transforms Yes Yes Yes
Coordinate system conversion N/A N/A No
TriMesh geometry Yes Yes Yes
Multiple Texture coordinates Yes Yes No
Materials Yes Yes Yes
Textures Yes Yes Yes (one per mesh)
Shaders Yes Yes N/A
Object animation (SpatialTransformer) Yes Yes No
Morph animation (KeyframeController) Yes Yes Yes
Skeletal animation Untested Untested No
Cameras Untested Untested No
Lights Untested Untested No
Lots of other stuff Untested Untested No


The java code is here:
http://code.google.com/p/jmexml/
In the cvs repo, package "newxml". Test class included. The partially updated Blender exporter lives in the svn trunk root directory, by the name of jmeXMLExport_V2.py.

BTW, has anybody started something similar yet?
Multiple Texture coordinates Not supported in Blender

didn't blender introduce multi uv in 2.44 or something or are u referring to something else

nice work by the way it would be nice to use blender as a/the level designer it would compliment l3dt and maybe mw3d very well.

Sounds great, I can't wait to check it out! :slight_smile:

mcbeth said:

didn't blender introduce multi uv in 2.44 or something or are u referring to something else

You are right! That feature addition somehow slipped by me. OK, so multi uv is possible in blender - which is pretty awesome for lightmapped geometry! I think that will be one of the next features to add.

Hi,



We have actually used it already in MW3D via something called extension points, where you can basically create an extension point for your own loader in which MW3D will understand it for loading and saving. We also used it to show the scene graph into readable xml formate. So now we have both binary and xml formate as well. I believe it will help you in debugging it, but I will also try to point out any issue.



Thanks havee :D.

Outrunner said:

We have actually used it already in MW3D

You mean you already integrated the XML IO code in the six hours it's been there now? Wow, you guys are fast!

Hi,



nop I meant the old stuff :D. we are not that fast.

Any updates on this?  I'm still behind on checking it out.

what said light and cameras would be nice, would settle for lights though

i would like to know if skeletal-animations and skinning works when the XML scene is imported into jME.

is there a schema or DTD for the exported XML file available ?



greets

koal

renanse said:

Any updates on this?  I'm still behind on checking it out.

Yes, there is a new tcp connection feature - it consists of a server on the jME side, which the blender exporter can send an xml scene to. I figured that artists could save a few mouseclicks that way, because they don't have to export/import/verify-if-it-looks-right a couple of times but get the blender scene over to a jME window with one mouseclick.
Other than that, no new features yet.

mcbeth said:

what said light and cameras would be nice, would settle for lights though

OK, so that'll be one of the next features to add. However I am not sure when this is going to happen, because I don't know how well blender lights translate to jME lights yet.

koal said:

is there a schema or DTD for the exported XML file available ?

No. The format is not yet set in stone in all details, there is still some optimization potential regarding xml readability and maintainability. For your first question, please check the feature table in the first post.

Hi havee,



I have managed to get the new stuff up and running with the editor, now we have two xml file reader, writers :D. But I have faced one issue though:



In class DOMInputCapsule you have used the system class loader, which cased me a trouble while instatiating objects, classes where not found :/, Vardamir suggested to use the context class loader instead of the system class loader.



tmp = (Savable)Thread.currentThread().getContextClassLoader().loadClass(className).newInstance();



That really worked like charm. Is there any chance that you change it this way ?



Thanks in advance.

Outrunner said:

Is there any chance that you change it this way ?

Commited. Thank you for pointing that out!

Thanks havee.

Tried this out yesterday, it works great but I have a question



I have a terrain built with l3dt and imported from .obj into blender to cut it into pieces, uv map, and texture so that I can use the l3dt texture map each piece is separated to it's own model object with uvs intact load it in and it works fine.



the question is, will my texture load once per object even if it is common to each piece of terrain, I ask because the first time I loaded it, texture wasn't where it was supposed to be and I got 16 missing texture messages the same number as my terrain pieces.

 

@mcbeth: TextureManager should take care of not loading the same texture twice. It is quite possible that TextureManager will try and load a missing texture over and over again, if it does not cache a missing texture entry for it.

To make sure your app can load all textures, check their paths in the xml file, and set an appropriate ResourceLocator.

thanks man much appreciated

Hi,

is there a build for pre alpha of JME?  :?



TIA,

Niggle

I tested this yesterday. It doesn't load at all because GeomBatch class is missing. Guess we'll have to wait till jME-2.0 gets it's own XML format.

Exact.



Now this means current code using JME 1.X GeomBatch will not work anymore with JME 2.0. Is it easy to migrate?



Is there some example?



(sorry to ask again for doc  :P)