I’ve just taken the first steps to moving JME3’s .blend loader into its own repository. That is, I’ve moved the jme3-blender project under jMonkeyEngine-Contributions into its own BlenderLoader repository:
…and kept all of the history in the transfer.
The next steps will be removing the jme3-blender directory from the main jme repo and fixing the build, tests, etc. to not mention it anymore. In a jme 3.4+ world, the blender loader will be separate.
This has long been on the roadmap as the loader only works for old Blender versions and breaks with each new version. Blender 2.8 is really great and the blender loader doesn’t even support it… meanwhile gltf continues to improve. (Edit: also there is some questionable GPL licensing in there for some removed files that could maybe come back if someone wanted the whole loader to be GPL. Others are of somewhat questionable pedigree as is.)
That being said, if someone wants to pick this up and maintain it, it’s there in its own repo and can have its own release cycles, etc… The barrier to entry for someone managing that project is considerably lower than “getting commit access” to jme’s main repo. If it’s to survive at all, this seems like the best way.
In the immediate term, I could really use someone’s help fixing the build there. It’s build.gradle file is the same one it had in the main jme3 repo and so refers to things that don’t exist, etc… I personally have no interest in fixing it and frankly I’m willing to just leave it in a broken state until it has a proper person to manage it going forward.
…but that seems a bit of a shame if someone is otherwise willing to step forward and at least fix that much. Then, for example, some future JME3.4 SDK could still choose to include it in its separated out form.
Over the next week or so, I’ll start removing the traces of it from the main repo.
Much needed - and much appreciated that you’ve decided to take it on
Long overdue since GLTF is the standard for JME now and has been for some time. I guess pinning a topic would be a good idea to answer the inevitable incoming questions.
Please consider moving the issues between the repos as well, at least I know I’ve opened one about 2.8 compat.
I will also fix the build if I don’t forget it.
What about Ogre, Fbx, etc, though? They are more canonical but they also DO work reliably for some guys. On the other hand they read tutorials from 2003 thinking this is the way to go and thus don’t use GLTF.
Those other formats don’t have their whole own module. Which makes them slightly less of a problem though the lack of their own subdirectory does make them harder to move with history intact. FBX would probably be better served by its own project. I actually thought it already had one… but I see not.
I think we should keep OBJ because its dead simple and like the minimum standard that everything supports. I could see moving ogre out at some point.
I haven’t looked into what it takes to move issues between projects. If someone wants to volunteer for that, too… it would be great.
In response to jme3-blender receiving a new life as a jme contribution, a PR has been created to remove the importer from the engine. This brings up a rather important question. Should the blender demos in jme3-examples be moved also to the importer’s new home, or should they simply be discarded?
Any thoughts regarding the situation?
I’ve identified these. Inside the jme3-examples directory, there is the jme3test.blender package, needing moved completely. And also inside jme3test.model.anim package are two classes that use blender TestBlenderAnim.java and TestBlenderObjectAnim.java. As far as the assets, the entire Blender resource package and Models/TangentBugs need moved from jme3-testdata.
I still use 2.79 and ogre, gltf had issues for that, I make use of the destruction physics of fracture modifier, which isn’t/wasn’t mature for 2.8 last I checked(a month ago) and my project has by this time lost any compatibility with 2.8…really need to get into that, but it made sense to stay 2.79 my purposes
We would be glad to checkout those gltf issues and see if we can fix them!
Usually ogre is the one with limited possibilities, so it’s interesting that it works for you (I also remember some problems with different versions etc).
In any case you can always use jme up to 3.3 to convert ogre to j3o and use those files in newer engine versions (officially j3o is not compatible between versions, but we don’t really change it very often).
Also for the SDK, I will move ogre etc into a plugin, so it should even work on all future versions, I hope.
Hmm that might also be related to the 2.79 gltf exporters (I remember there were two of them).
And yeah that was the reasoning behind my message a few days ago, but I was assuming gltf works flawless
I mean exporting from 2.79 ogre has it’s issues but there are steps\workarounds that usually work. gltf is a bit more shaky…and yeah the destruction physics definitely isn’t going to be working reliably in 2.8 anytime soon
anyway descruction in game could be easly done just by replacing model with “model cut to parts” and enable in-game physics. i would need more detail what you mean by “make use of the destruction physics of fracture modifier” used in JME game?
I mean export the animated destruction and I am familiar with that video, my project is an animated short that depends on blender internal, I thought it would be a fairly straightforward game, given the linear nature of short’s subject matter “escape sequence”, it is highly incompatible with 2.8 at this stage and I would have to spend an inordinate amount of time and effort to get it up to scratch, at this stage it makes sense to avoid all that…FOR NOW, not shouting
plus there is my personal shame of not even downloading 2.8 and it’s what now 2-3yrs since that’s been active, so learning curve issues
and my project has by this time lost any compatibility with 2.8…really need to get into that, but it made sense to stay 2.79 my purposes
