The asset pipeline is our biggest issue… and so far all of the other efforts seem to have stalled exactly at proper animations. There are three or four exceedingly good ways to get static content in but only none ways to nicely import animations.
Ah,
I use a custom small converting applications,
that first of all, circumvents bad texture paths, by brute force scanning most of the assetfolder for a texture correctly named (they have unique names in my case)
Then following that, it replafes the default textures with dds texturs it convertes.
After this it fixes common problems, like bad vertex colors ect.
The results from this is a really nice static asset pipeline, that even works a build server by now, I only need to commit my files to the input svn, and get them a few minutes later in the output one.
Only thing it cannot do magic with is the animations, I’m pretty at a loss on how to do this properly.
I mean I could take a look at how UE4 does this in source, but then all code I might ever write for this has potential license problems, so I prefer to not look at it.
Unity seems to use FBX for all import and export problems maybee this is were the solution lies, I dunno.
There has been attempts with fbx, and it works great…as long as you don’t have bone animations 
Bone animations are quite complex and every format has it’s own way of dealing with it, that doesn’t easily translate to JME’s bone animation structure.
I’d like to try another route with BVH. Maybe we should load everything as static and then import animations and retarget them to the skeleton.
Though the static loader has to at least properly load the skeleton…
Most of the time the animations issues come from the use of inverse kinematic. IMO they have to be backed in the exported format so the loader doesn’t have to care about it… and Blender’s BVH exporter does that.
I guess @momoko_fan got pretty far in getting an FBX importer beefed up… just short of animations. So basically not very useful.
@david_bernard_31 was working on a more direct path from blender to JME that looked really promising. I can’t remember what it’s called but I think he even got some way towards animations working. I don’t remember the status of that either but to me that’s the best path now.
I used to be a big fan of a blender importer but it seems impossible for some reason. Every new version of the importer seems to break models that worked fine before… so either the format is very fragile or our approach is or the test procedure is. Probably a little of all three. I know if I were working on it, I’d get really frustrated having to retest a bunch of models every time I moved.
A blender exporter seems like the ‘right’ approach in that it’s best situated to deal with the data and either leave out stuff that won’t work or somehow notify the user. (Though given the fact that I’ve never seen a blender plugin notify the user of anything then I wonder if it’s even possible… but whatever.) David’s work even had something where you could use JME to view your model in real time or something.
We should send lots of beer and encouragement his way, perhaps.
1 Like
Well, it might be crazy, but why not simply create one package/class per format? Abstract as much as you can in one upper class so the maintenance is easier and then make a specification in the lower levels. I mean it could cause some maintenance problems and everything but hey, at least I would be feasible… maybe? I don’t know, am far from good whit all that 3D stuff xD
Anyway one thing is sure: JME need to make it easier to import assets. I mean just think about it one sec, JME could become an anti-game engine: as every other game engine works so you basically don’t need any programmers, in JME you would simply don’t need any artist, simply using free/paying assets on the web and work on the code so the mechanics are actually more original than a plane shooter whit zombie.
And it might be a bad idears for my credit card but lord would id love to use some of those pretty unity market assets. As must as I dislike unity way to deal whit the code and everything, you gotta admit, they have a pretty solid community of artist, and somehow connect JME whit it could be realy good for the quality of the games on the engine.
At the limit, and it kind of sound like a pack whit Satan but proposing to unity the up in those sales, biggest source of revenue for them I believe, in exchange of some help whit the format integration could be an idear. The two engine don’t target the same audience at all anyway.
Thats why i mentioned fbx, everyone working with unity already knows how to export to that.
If we would make a compatible importer, that can be feed the same stuff unity can use it would be great 
I would not count on theri help however.
As for the multiple formats, we had that in jme2, basically you had the coice of even more formats, that worked worse.
Well what worked worse? Cause here 2 format would be largely enouf. Plus as i said am pretty sure ogre is dead right now, so you could actully simply direct the evolution in one direction intead of 2. Then again i do realise that this is a lot of work, but it would just be so much fun!
Xbuf yeah. I have to test it since a long time I really should try that.
Not only a lot of work. It’s an extremely difficult work.
But we really need a solution because as you said ogre exporter is almost dead.
Do you plan to make only exporter/importer to current JME format? Or to change/extend the current format too? I’m asking because I’m a bit scared of moving to 3.1 with my current custom rendering.
The problem with models isn’t exactly the format but how you create the models. Models for gaming use a texture atlas, color, normal and specular maps and are created from one mesh with bone animation. In a 3D editor you can do all kinds of things like projective mapping, creating “materials” that are picked up by some raytracing system and whatnot. All of that doesn’t translate to a game ready model and isn’t meant to be used for that. If you ignore the kinks some exporter chains etc. have these basic things work quite well with almost every format.
1 Like
Except the blender importer… which breaks on models that worked fine before every second or third version.
Ogre format has a limited lifespan and none of the other formats (except maybe xbuf) do animations properly.
If you don’t have animation then importing works pretty well in a variety of formats.
If you are talking about 3D file formats then this is the kind of thing that sounds really logical until you actually look at the formats. They are about as different as you can get without becoming extradimensional.
You’d have an easier time getting humans to all speak one common language all the time, I think.
1 Like
Theres no need to move to 3.1 if 3.0 works good for you, especially for games that are shipping or are almost ready to ship.
Yeah, exactly because the blender importer tries to mitigate the issues with Blenders extended functionality its getting unstable. Ideally it would put importing “correct” models at the top of the priority list instead of trying to convert extended features and thus failing to import the model completely.
Nan, I actually mean to go completely the other way around: create new bone object for each format and in this case only fbx. Just keep the really basic stuff and then start new. No matter how bad is the idea, JME still need a new format for animation, and because builds something cohesive whit the old version seem unfessable well… what other solution do JME have?
Blender import
I’m convinced that a custom exporter is the only best way. It has the best chance of being able to mitigate or error things long before the ‘import’ ever sees them. It gets the data before it’s been reduced and obfuscated and theoretically it’s easier to keep an exporter up to date with blender changes than to try and deal with X number of different blender file versions.
As we see with the current Ogre exporters?
a) ogre is still the best format for getting assets into JME despite being broken (points toward exporters)
b) the fact that the ogre exporter is dying I think has everything to do with it basically getting abandoned and little to do with the practicality of the problem.
I remember back in the day, your asset pipelines almost always had tom 3ds max plugin or so for exporting the right format… whether quake models or NWN models. The NWN exporter was nice because it even had little checkboxes for things to include and not.
To me, “in the tool” seems the best place to figure out if a model is going to work or is not yet game ready… rather than trying to interpret the tool’s specific format that potentially has made information really hard to find in the name of a compact format. Essentially, you rewrite a bunch of blender just to extract the 10% of stuff you are actually interested in… and then when you miss 1% or have a bunch of garbage in the other 90% you have no recourse but to write mountains of code or fail those files with a “don’t be so stupid in the tool” message.
Not friendly.
Friendly is:
-edit the model in the tool
-try to export to .JMEsuperawesomefile format.
-error pops up that I need to collapse transforms
-I collapse transforms and try again.
…repeat
When I get an export I know I will be able to import it again… and now I can save my .blend file for tweaks later.
The thing I don’t know is if blender plugins have a mechanism for showing such errors to the user because I’ve never seen one do it… even when it should have.
1 Like