Hello,
I was doing some digging, and was not finding answers for sever questions I have on the FBX importer.
Thanks,
Trevor
No, afaik.
But you can probably import it into blender and then export it to gltf - and then import it into JME.
Yeah, that is my current work flow. I was hoping that I could skip that step, knowing that jme has a fbx importer.
It would be great to get the fbx importer updated. If time permits I will see if I can make some progress on that.
Failing that it might be easier to run the import / export operation from the command line using blender. I’m quite certain it can be done - and would probably be a lot easier than updating the fbx importer.
as i remember, Riccardo were recently using FBX with new animation system and he had some issues, but fixed them, so you could speak to him.
But it was just about animations, not shape keys tho.
Ah, that is good to know. Tagging @RiccardoBlb. If animations are working, then I think I could probably get shape keys to work.
Oh, actually no. While doing the demo i’ve just showed in the monthly wip thread i tried the various format supported in jme.
To no one’s surprise the one that seems to work best is the gltf importer, but i couldn’t wrap my head around the new animation system…
For my personal project i use a fork of the engine and it has a different animation system and a model format that are both mapped 1:1 with blender, so i just decided to port them (minus some features that require changes in the core) into the current stable release of jmonkey (i will release them both soon). I call it f3b, maybe oxplay is confusing it with fbx.
Ah, that is really cool. Just curious, what features require changes to the core?
I am hoping someone is kind enough to do a wiki page on the new animation system so that I can start wrapping my head around it.
Linked assets: in blender you can link nodes from an external blend file, f3b supports that but it needs a small change in the asset loader to add asset listing.
Mesh lods: you can use different meshes as lod levels, this requires a change to the renderer and mesh classes.
Ah, both of these sound like very useful things. Especially using different meshes for lod, for some reason I thought this was supported already.
The current lod works by rebuilding the indexbuffer to reconnect existing vertices. It uses less memory, but has some limitations.
JMEC can support asset linking from a GLTF file… the problem was that in Blender 2.8’s GLTF export, linking was all messed up. I haven’t tried it again since they fixed some things.
@RiccardoBlb do you think it is possible to add your method of supporting different meshes for lod along side the existing? If so, would you be willing to open a pr for it?
It is a feature that I am extremely interested in for dealing with lod on isosurface meshes, where I have generated meshes of different resolutions that will still fit together correctly.
It is technically possible already. You can have a control that calls setMesh , keep the lod mesh references somewhere so that they don’t get GCed. When they all have been rendered once by the engine (or loaded with preload() ) they will stay in vram (until disposed by the gc), so switching between them will be very fast.
The only problem with this approach is that it is not fully transparent, since you are changing the main mesh. Also batching and instancing won’t work as expected. Depenting on your usecase those limitations might not matter at all.
There are also workarounds for the batching and instancing, you can for example divide your scene in batching-instancing groups, and switch the lod for the entire group (this method would be faster anyway, even with my code).
Porting my code would requires important changes to the renderer, indirect rendering, and occlusion queries. I can’t open a pr for it for now, since i am busy with other tasks. But maybe you can look into the alternative i proposed in this post.
Thanks for the info. I guess I get started building a control then.