I have a “concept”. I want to create own very simple and user-friendly “3D asset designer” for the game I would like to write. I have my internal data-model mostly worked out, and I need some Java API that can export the mesh, textures and “animation data” in some format appropriate to JME3.
What would you recommend?
huh? well if you use a custom format you need a custom converter. Best would ofc be a proper loader plugin for jme3 (see the current ogre etc. importers for reference) or you just create models “manually” from your data w/o using a loader: https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:custom_meshes
I don’t think you understood me (or possibly I didn’t understand you).
I am going with the assumption that a JME library support for a “standard format” will have been through many reviews and be as efficient as can be. Therefore I am assuming that converting my internal format to a “standard format” will make the rendering faster while the game is running. In fact, it might be that JME uses library implemented in native code, which my Java code could never beat in speed. As far as I know, it is traditional to use a different file format for creating/editing game content, and for rendering the content in the actual game, because you need a lot of meta-data while editing which is useless while rendering. Also, while editing you want a “clean object model”, and while rendering you want something that is optimized for a modern GPU. So I would save my data in my own format until it’s “done”, and then export it as something that runs well in JME. So I need to write the converter myself, of course, but I don’t want to have to write the low-level code that knows where to put which bits in the “target file format”. I am looking for an API that offers me an “Object Model”, so that I can convert my own model to the target format model at runtime, and let the API convert the transformed model into bits and bytes in a file.
That would be j3o files, using the serialization system of jME3. All the work to handle these is already done in the SDK, so creating a plugin for the SDK for this purpose is probably the best choice. I don’t know exactly why you think native code would be faster than java code, normally the opposite is the case as you get on the fly optimization for the platform being run on in java and not for some platform that you set when compiling like in C/C++. So I suggest a) reading more about jME3 and creating plugins for the SDK and b) maybe reading more about java.
1 Like