gLTF as a replacement for FBX and Collada?

gLTF as a replacement for FBX and Collada?

Could this new 3D interchange format be used with Cheetah as a means of replacing FBX for exporting animations to other apps? Seems very exciting: Open source and much more compact (designed for streaming and WebGL).

Octane Render is going to be supporting this as an import format so it would be a great way to get Cheetah animations into that as an additional rendering option.

If we had gLTF and Alembic support (or some means of exporting physics sims) then I don’t think I would ever have to leave Cheetah for modeling and animation!

https://en.m.wikipedia.org/wiki/GlTF
https://www.khronos.org/gltf
 
It looks very promising and of course Apple is out to lunch.

Basically if we get a solid, portable reference implementation I would imagine we'd see quick adoption by all the major players (basically if we get support in unity…)

Sadly their headline supporter is Oculus which has lost a ton of credibility over the last year with fumbled rollouts and lackluster products (and pretty much focusing squarely on windows after being all about cross-platform when they launched).

(I've been considering moving from unity to pure JavaScript/WebGL since that's what I do for a living, unity is an expensive hobby, and webassembly means that the performance disadvantage for the web is about to pretty much go away; the lack of a robust file interchange format that works in browsers is a huge sticking point.)
 
Last edited:
Hi,
I have some doubts that this file format will gain too much attention. It's too specific to OpenGL/Vulkan. The Mac is moving away from OpenGL and Windows is dominated by DirectX.

I also can't see a single feature in glTF which isn't already in FBX/DAE. glTF actually offers less functionality.

Last but on least it looks like Autodesk is already working on a FBX/DAE -> glTF converter so it's probably just a matter of time until glTF support shows up in the FBX SDK.

So for the first FBX/DAE will stay the primary exchange file formats.

Bye
Martin
 
(I've been considering moving from unity to pure JavaScript/WebGL since that's what I do for a living, unity is an expensive hobby, and webassembly means that the performance disadvantage for the web is about to pretty much go away; the lack of a robust file interchange format that works in browsers is a huge sticking point.)

Have you checked out three.js . They offer quite good Collada support.

Bye
Martin
 
I have played with three.js but I'm more inclined towards babylon for game stuff. We'll see.

One nice thing with JavaScript is you don't need to settle :)
 
I have some doubts that this file format will gain too much attention. It's too specific to OpenGL/Vulkan. The Mac is moving away from OpenGL and Windows is dominated by DirectX.

I also can't see a single feature in glTF which isn't already in FBX/DAE. glTF actually offers less functionality.

Last but on least it looks like Autodesk is already working on a FBX/DAE -> glTF converter so it's probably just a matter of time until glTF support shows up in the FBX SDK.

So for the first FBX/DAE will stay the primary exchange file formats.
Again Martin thanks for taking the time to elaborate on my questions and, in this case, explain why glTF would not be the best export format for Cheetah. I just got excited when I heard Octane was going to be using it as one of its import formats (currently it only accepts OBJ and Alembic).

Do you have any plans at all to implement Alembic export or explore some other means by which we could use Cheetah particles and physics sims in other applications? If the cache from physics sims could be made accessible to other application in some interchange format that would be so useful.
 
I hope that we get glTF support via the FBX toolkit at minimum (although the dominance of, and our reliance upon, Autodesk in this space remains disturbing).

I did a bit of investigating (basically, I integrated threejs and babylonjs with the framework I'm developing for my day job and did some experimenting).

To say that the pipeline from C3D (or even Blender) to Web is painful is an understatement. Collada support is sadly more fantasy than fact (lots of folks claim to have it, but damned if I could get anything useful to work — it actually makes working with collada and SceneKit seem trivial in comparison).

Even if I could get collada to work, as far as I can tell, I lose Cheetah's takes when I export (I just get the current take) which is going to be pretty hellish to deal with. (Compare this to Unity which is almost painless.)

Blender has a dedicated babylonjs exporter, but I couldn't get it to work. (It spits out useless error messages and fails OR "successfully" produces files that don't load. That said, the obj loader doesn't work on its own demo page.)

OBJ works for static stuff, but I can write an OBJ parser in a couple of hours.

The best demo I've seen (and no, I haven't managed to get this to work myself) is this glTF loader demo for babylonjs (by the way, both babylon and three are supporting glTF; since glTF is JSON this is a no-brainer).

What's truly amazing to me is that these "bleeding edge" 3d frameworks are so far behind the times in terms of code architecture — both install themselves as globals and don't support common.js require. Babylonjs is so primitive I had to write a special extension to my require implementation just to load it.

It's enough to send me back to Unity :)
 
OK I've spent enough time on this today :)

I don't know if Apple will provide some credible alternative to glTF that is Metal-centric. I doubt it, and it's not like Apple's geometry or shader models are going to be that different whatever Apple does. If anything, the industry in converging on the "standard PBR shader" model (which I believe you're planning to support in some way shape or form).

Meanwhile:

  • glTF is remarkably well-supported by WebGL libraries now (better than Collada or FBX)
  • presumably we will get adequate glTF support via the FBX sdk
  • WebGL is the next big 3D runtime platform and it isn't going anywhere no matter what Apple does

glTF is JSON, which is Javascript native. So is .babylon, but that's proprietary and the code does not smell good. JSON would be easy for plugins to emit, parse, and manipulate.
 
Again Martin thanks for taking the time to elaborate on my questions and, in this case, explain why glTF would not be the best export format for Cheetah. I just got excited when I heard Octane was going to be using it as one of its import formats (currently it only accepts OBJ and Alembic).

Do you have any plans at all to implement Alembic export or explore some other means by which we could use Cheetah particles and physics sims in other applications? If the cache from physics sims could be made accessible to other application in some interchange format that would be so useful.

I think we already had that discussion about Alembic in another thread. FBX also allows the export of baked animations and particles. I just haven't found the time to add the functionality yet. There is very little you can do with Alembic which isn't possible with FBX too.

As I already said I will focus on the two most popular 3D exchange file formats and these are FBX and Collada. I can't get lost by adding support for more and more file formats which offer very little advantage over the already existing and well established ones.

Have you asked the Octane developers to add FBX support. FBX is by far the most popular 3D file format at the moment. And they should also have multiple times the humane resources.:wink:

Bye
Martin
 
FBX also allows the export of baked animations and particles. I just haven't found the time to add the functionality yet. There is very little you can do with Alembic which isn't possible with FBX too.
I was not aware that FBX could export particle simulations - that's great news and I certainly look forward to its implementation in Cheetah. Can FBX likewise export physics sims as well?

Have you asked the Octane developers to add FBX support.
Unfortunately they have chosen gLTF as the new interchange format they will be adopting, despite many users' request for FBX. I think primarily because it compresses so well and will work with their ORBX media player, which is a 3D streaming technology they developed.
 
Wow, thanks Martin for letting us know about the future support of animations and particles in FBX. Your explanation about fbx and collada makes sense to me.
 
I've read some of the glTF 2.0 draft this weekend and it looks like that they fixed the biggest weakness of the glTF 1.0 file format spec. In v1.0 materials were exported as .glsl shaders which is just useful for OpenGL apps. But I don't think that non-OpenGL developers find that very helpful.

In glTF 2.0 they simplified the material system to PBR like materials which is way more convenient if the glTF files are used for file exchange.

But in general the file format is quite similar to Collada. Just that Collada is XML while glTF is JSON. And that buffers are saved in Collada as ASCII while in glTF they are base64 encoded.

So maybe I just add an glTF 2.0 exporter sometimes.

Bye
Martin
 
glTF is a content delivery format for OpenGL. A quite nice one but it's not intended to be a full 3D exchange file format like Collada/FBX. Just compare the file format specs of Collada (>500 pages) and glTF (28 pages).:wink:

The complexity of Collada was probably the reason why it never really took off. Writing a feature complete Collada import/export is a hell lot of work.

Bye
Martin
 
gLTF2 support sounds great.

We really need a spec that is text-friendly, simple, but supports reasonably rich shaders and skeletal deformations. FBX and Collada are overkill for that, while OBJ and MD2/3 are inadequate.
 
We really need a spec that is text-friendly, simple, but supports reasonably rich shaders and skeletal deformations. FBX and Collada are overkill for that, while OBJ and MD2/3 are inadequate.

Yes, it's something nice inbetween 3DS and Collada. And since Javascript natively supports JSON it should be pretty easy to parse.

Unluckily the NSJSONSerialization class is missing in macOS 10.6:frown:

Bye
Martin
 
threejs now supports a so-far-undocumented JSON file format that supports skeletons and deformations. I'm guessing it's undocumented because it's still in flux, but it looks pretty straightforward:

Here's a tutorial:

http://unboring.net/workflows/animation.html

And the corresponding repository:

https://github.com/arturitu/threejs-animation-workflow

It seems like something that could be relatively easily implemented as a C3D javascript plugin.

The threejs editor is also very impressive (and it works very well on an iPad):

https://threejs.org/editor/

Interestingly, it appears to support embedding behavior in scenes (the examples include playable arkanoids and pong) but not skeletal deformations. Sadly, it seems partially abandoned (I can't seem to get content exported from it to import into current threejs).
 
I think we already had that discussion about Alembic in another thread. FBX also allows the export of baked animations and particles. I just haven't found the time to add the functionality yet. There is very little you can do with Alembic which isn't possible with FBX too.

As I already said I will focus on the two most popular 3D exchange file formats and these are FBX and Collada. I can't get lost by adding support for more and more file formats which offer very little advantage over the already existing and well established ones.

Have you asked the Octane developers to add FBX support. FBX is by far the most popular 3D file format at the moment. And they should also have multiple times the humane resources.:wink:

Bye
Martin
Hi Martin. Revisiting this thread in light of recent developments with Octane and also the current discussion in another thread regarding Glass Rendering and the removal of Refractive Caustics from Falcon.

As you know I’m really interested in a solution to export Cheetah physics sims to other applications for rendering.

Octane now finally accepts both gLTF and FBX import in their most recent development build (still problems with the implementation but those are being worked out).

In light of current discussion regarding Falcon and third party renderers, are you considering developing the additional export capabilities of FBX you mention is possible?
 
Back
Top