Unity, Autodesk announce work on a full integration between their apps.

Okay, this is a good example of what I’m talking about. We need to be thinking much bigger than this. An asset coming from substance would just be a static model with some textures on it. Why do you even need GLtf for that? And, as you pointed out, it’s even more useless given the fact that there are no GLtf importers (that I know of) for Unreal and Unity.

A truly universal game exchange format has to handle so much more than just moving geometry and textures back and fourth. There are already enough static game asset exchange formats. The issue is that FBX, for better or worse, can exchange skinned, rigged, and animated characters and objects.

GLtf needs to be so much more that FBX. It currently has a lot of what is needed but they need to take it to the next level. I know it’s hard to develop these kinds of features but that’s what it takes to dethrone FBX. They also need to be reaching out to the different 3D communities and listening to what they need. Figure out how to add support for all the most popular engine’s most advanced features and no one will deny it’s superiority.

By it’s nature glTF is going to be slow moving for a while. It’s basically in the Kronos groups hands and they aren’t exactly known for being speedy. What I mean by that is that by the time Adsk is implementing some new bleeding edge feature that is needed, glTF still has to work with 4-5 vendors (minimum) to see if it’s a good idea. That’s the same issue that happened with DirectX versus OpenGL.

I would love it if Unreal or Unity added glTF to their engines if for nothing else to keep Adsk in check.

If you would like to see GLTF in Unreal Chime in here

…won’t exist. Real game studios will write the toolchain for getting exactly the required data for their purpose in and out of their content-creation tools. It’s not rocket science and it’s a small part of the work developing a major title.

Everyone else can just use FBX. It’s not great, but it works well enough - even for Blender.

…than just moving geometry and textures back and fourth. There are already enough static game asset exchange formats. The issue is that FBX, for better or worse, can exchange skinned, rigged, and animated characters and objects.

glTF has support for animations/skinning, but it’s not an interchange format, it’s the kind of data you can more or less directly give to your GPU without conversion and even then it’s not necessarily what you actually want.

GLtf needs to be so much more that FBX.

If you want another “universal” interchange format, that will run into the same problems as Collada - too grandiose to ever be implemented properly, yet too limited to solve everyone’s problems.

It currently has a lot of what is needed but they need to take it to the next level. I know it’s hard to develop these kinds of features but that’s what it takes to dethrone FBX. They also need to be reaching out to the different 3D communities and listening to what they need. Figure out how to add support for all the most popular engine’s most advanced features and no one will deny it’s superiority.

Who actually has a strong issue with FBX? It’s only the Blender users/developers, as far as I can see. Blender has never been developed with a huge focus on interop in the first place. From a developers perspective, FBX has a whole SDK to work with that is ready to use. Where’s the incentive to support something else?

The problem is that the Blender developers can’t legally make use of the SDK due to the GPL, that is also a major point in why the BF has a major issue with FBX and puts more focus in promoting open formats.

Now if that is a dealbreaker for people using Blender, I’m sorry to say that they will have no choice but to abandon FOSS completely for 3D work (you can try BForartists, but Tiles can’t do anything about the SDK issue either). Building a new FOSS application from scratch meanwhile (with a more permissive license) will take a very long time to get to Blender’s level (if it does at all since it will depend on the development rate).

It is possible to use the FBX SDK to write a standalone converter from .blend/.glTF to .fbx or communicate via IPC with an blender addon.

THis is the never ending topic

  • LGPL
  • C++ API (to make modifiers or more functionality that only tools)
  • FBX

BF must admit that GPL could destroy or limit blender. At least if we will have a better api to make plugins integrated in the system… Because I understand that Blender must be GPL, but why it’s not possible make a plugin that connect with blender and use FBX libraries? why nobody can create a modifier in some language and blender use it? that you need to make a custom branch to make this.

As far as I understand the legal situation (but I am not a lawyer!!!), it is not possible to bundle e.g. the FBX SDK with Blender due to the license issues. It would be possible to have it as an addon which is downloaded separately and then link it at runtime through an API which is released e.g. under MIT/BSD/… . With this, it could also become possible to natively use Allegorithmic’s Substances.
There is one main issue: Someone would need to implement an API for all the necessary functionality and certainly some functionality which could load (maybe unload) the libraries at runtime. This would likely require some testing functionality to make sure it works on all platforms and can easily be compiled.

It may sound easy, but if you have a look at everything that would be required, it ends up being a huge amount of work. It is totally understandable that the Blender Foundation is not doing that in my opinion. A stakeholder would be needed with a strong interest who would work with the Blender Foundation. E.g. if Unity wanted to have the same workflow as with other 3d solutions and does not want to wait for GLTF, they might consider it. But that seems unlikely. Allegorithmic has considered an integration. They even talked to Ton if I remember correctly, but likely they didn’t have enough interest to take the more complicated native path.

They can’t integrate it into the Blender binary, otherwise there isn’t really much of an issue with providing a converter as a separate program. Why must the .blend format near-impossible-to-use unless you are using Blender itself? Why isn’t there a .blend SDK with a permissive license, or some other intermediate format that is actually usable as an interchange format?

The possibility is there, the will is not. The RNA system is actually powerful enough to generate export of data in a very flexible way, since it provides all the metadata describing the data itself. It could be used to provide an intermediate format.

After aska few also they cannot link libraries… the GPL is a cancer…

The BF have tried to change to LGPL? or directly have told “impossible” and don’t tried?

Again, I am not a lawyer, but what I have read, there are some ways to work around the GPL. If you implement the API and release it under MIT/BSD/… , you can integrate it into Blender. It is also possible to implement the API with the proprietary code and to create a library with it. There is not issue with those things, because they are independent.
It is not allowed to ship the proprietary library with Blender, but it could be downloaded separately and then it could be automatically loaded at runtime.
Just to make it clear, I have read about this idea, it is not really mine. So far I haven’t seen anything that speaks against it. I can’t find the original source anymore. Since this is too off-topic in my opinion, this is my last comment in this thread about it.

I’m not entirely sure you’re first comment is actually the case but the rest is all totally true. I would still like there to be an open exchange format so I’m holding out hope. :wink:

This is a really great idea!

gltf was even from conception a real time run time format, in other words it was about importing a fbx, or 3ds,or obj etc etc for realtime engine environments to efficiently use the model and texture info in a run time situation. Game engine.

gltf was never aimed from the beginning to be an intermediate DCC app format, It’s a run time format. Small and fast as possible, not bloated like all other intermediate formats.

If you want a intermediate format replacement like FBX look to pixar USD or some others i cant remember off the top of my head right now, but there’s a lot of company’s released their model formats. Problem is how to get everyone to agree to go in the same direction.


The amd-tootle repository includes the source code of the AMD Tootle library and an application command line tool.
AMD Tootle (Triangle Order Optimization Tool) is a 3D triangle mesh optimization library that improves on existing mesh preprocessing techniques. By using AMD Tootle, developers can optimize their models for pixel overdraw as well as vertex cache performance. This can provide significant performance improvements in pixel limited situations, with no penalty in vertex-limited scenarios, and no runtime cost.
AMD Tootle Features

  • Vertex cache optimization: Triangles are re-ordered to optimize for the post-transform vertex cache in modern GPUs. This will yield significant performance improvements in vertex-tranform limited scenes.
  • Overdraw optimization: To reduce the pixel cost of rendering a mesh, the AMD Tootle library further re-orders the triangles in the mesh to reduce pixel overdraw. Significant reductions in pixel overdraw (2x or higher) can be achieved. This can yield significant performance improvements in pixel-limited scenes, and incurs no penalty in vertex-limited scenarios.
  • Vertex prefetch cache optimization: Triangle indices are re-indexed in the order of their occurrence in the triangle list. The vertex buffer is re-ordered to match these new indices. Thus, vertices are accessed close to each other in memory. This optimization exploits the input vertex cache because vertices are typically fetched in a cacheline (that may contains more than one vertex data).

AMD Tootle supports Microsoft Windows and Linux platform.

I would suggest people play around with Tootle just to get the point im making. In a UE4 test project running my models through tootle gave me a 30 FPS speed increase in UE4.

Just as a test, I also used it for models rendered in Blender which when using GPU also gave me speed increases, I actually tried asking some devs on chat how Blender internally stores model data once imported from a specific model format like fbx, Blend, Obj, DAE etc etc but never got a reply. If someone could explain tome how Blender Stores model data internally you could easily have tootle (open source) convert the model data automatically when storing into blenders internal model format for realtime or rendering. That could give a very substantial speed up in viewport and BGE performance.

But i couldn’t find for shit where and how Blender is storing internal model data. If you know, please let me know and ill take another look.

Last I left off, and it was a while ago, Blender + Unreal Engine were working quite well together. It was at first janky, and development to fix things was slow going, but after some time and effort on both Blender and Epic’s side of things it was great.

Are there actual ongoing problems? Or is (FBX import/export) aka. Blender + UE4 / Blender + Unity struggling again?

Again, last I left off, it was not just reasonable, but actually in a very good state on the FBX/Blender/UE4 side of things.

It also MAY not be 100% necessary to update to the latest version of FBX at all times, because unless they are wildly changing their format for rigging and animation, some of the added features to FBX won’t apply (think for example, just as a guessing example, integration with proprietary Autodesk cloth/hair solvers (again just speculation))

I do agree however that some fear is justified and that in addition to the internal GPL FBX solution, someone(s) should make an external/downloaded separately solution that can just integrate directly with Autodesks SDK. It will provide seriously needed coverage (insurance/fallback/backup) if anything goes awry, and that is needed if Blender is to be a serious tool for it’s many uses/needs.

Unreal just implement Alembic. Works great with Blender. Why depend on FBX, or is it just an issues with Unity.

WHen you work with fifty partners you need to use the same pipeline and you cannot be original.

I’ve always wondered why Blender didn’t take the intiative years ago and released .blend as an interchange format of sorts or at least try to make it a standard. Blender is the perfect project for something like that, imo. Could there be technical reasons we don’t know about?

Mostly because the .blend file format on its own isn’t great for interchange, being basically a structured memory dump. And the difficulty in creating an API is the fact that someone would then have to maintain that API (and be checked with each time things are added to Blender that requires changing/updating the .blend format). Basically… it’s work, not particularly exciting/interesting work, and most Blender developers (and users) would rather spend their time on more interesting things.

… For those which are blaming the gpl license for the poor blender code not be graced with the fbx sdk code… As far as I know the sdk actually makes very little difference, and the main problem is that different programs even when using the sdk still interpret the data that fbx stores differently, at the least, that’s what Cambell and I think Bastien have said on the subject.

This is also why the w3c specs are so dry: to make sure the way the data is interpreted is fully unambiguous.