We are excited to announce the full release of glTF support for the 3D mesh Importer. The 3D importer supports glTF files containing 3D meshes, textures, rigged models, skinning, and animations. glTF support has been in beta for the last few months, and we’ve been hard at work addressing stability issues, and adding new features!
Throughout the process, we’ve appreciated hearing all your thoughts and have done our best to address all your feedback. We look forward to hearing how glTF support improves your workflows and will continue to look for ways to improve them further!
What is glTF?
For those of you who missed the beta announcement, glTF is a simple but powerful 3D scene format that’s been gaining popularity as an interchange format, especially in web applications and 3D marketplaces.
A glTF file can come in one of two flavors: a JSON format (.gltf) with binary data buffers and optional external files, or a pure binary format (.glb) packed into a smaller byte array. The latter is especially powerful as it allows you to pass around entire scenes in a single file (no more zipping and unzipping multiple files or dealing with incorrect texture paths)!
What do we mean by glTF support?
We mean that any avatars, animations, and meshes that are found on the internet should now be able to be imported to Roblox via the 3D importer found on the Home and Avatar tab in Roblox Studio. We hope this will increase the number of assets you can use to build your experiences in Roblox, and will save you time converting assets to other formats.
Dynamic Heads support: Although we now support skinning, rigging, avatars, and cage meshes for glTF, we still don’t support dynamic heads. But fear not as we are actively working on it, and should have more news soon!
Further bug fixes and improvements: We have done our best during the beta to fix all the issues that were reported, but as is always the case there’s no doubt other bugs lurking around the corner. We will continue to squash those pesky issues as they come up.
Now that we have import parity with fbx (or something close to it!), better export is definitely something that’s on our mind, and we’ve even had some noise about internal uses for it. That said (afaik) it’s not on our roadmap right now, and I don’t have any concrete details for you.
It really should be. I’m a bit surprised that you can import an FBX and not get a FBX back if you export it. I could understand if this was for things that were not previously FBX but, to not be able to export a previously imported FBX is stupid.
If I import something as an FBX and I get an OBJ back, I lose valuable metadata in the process. Which makes it hard to move across games or platforms if I am not the original source creator.
OBJ also provides the bare minimum and is borderline useless for most things these days. Hard to believe that’s de-facto here.
Completely agree that the current OBJ export is lacking many of the export features that we now support for import (Joints, skinning, PBR, animation… ). glTF would be a perfect replacement as it’s goal is to be a simple (mostly human readable) exchange format in much the same way OBJ is.
Unfortunately it’s not just as simple as switching our export from OBJ to glTF (or FBX). Because the OBJ importer was written a long time ago -around 9 years at time of writing- it’s hard coded to use our rendering pipeline to export the geometry directly to a file. This was a logical simple solution at the time, but you can imagine that as soon as you add in animation, bones, or any kind of dynamic mesh into the equation, things don’t play out so well (much less dynamic heads or any of our other newer shiny features).
For this reason supporting more complex exports will require more or less a full rewrite of our existing code. This is not impossible, given time and engineers it’s totally doable, however the call we have to make is around prioritization. Export is great, it lets you move your project to other platforms, edit existing meshes, and make amazing thumbnails; but lacking a good importer directly effects experience quality on the platform. To this end we’ve prioritized working on improving importing vs exporting thus far.
tl;dr we’d like to, but we’ve been prioritizing on better supporting import. As we reach our importer goals it will be more feasible for our team to spend the time needed on export.
My only understanding is that we should ultimately use the .glb format since it’s more performant? I experimented with the collisions, but it seems the collisions don’t change too much depending on the format. I tried using complex geometry and applying precise convex to it, but both FBX and GLB solve it the same with minor differences. Is there a plan to make the collisions even more precise? I’m tired of floating on convex curved surfaces despite using precise convex as an option.
In most cases, artists change the details of items on existing finished products rather than creating or finding a new item. This requires more support for exporting, not just obj. This is currently not possible. Not only importing, but exporting can help the market thrive.
Wow huge news, once we have exporting as well as source transfer through allowing direct share and/or public animations as well as maybe onsite distribution of fbx/obj files then it will make Roblox a feasible platform for designers to specialize in
So close, really excited for this!!
Ya it’s not only faster but smaller. However, gITF is more readable, easier to remodify and stands to be much more popular as a standard format. If I am a developer just trying to get talent, I want to be able to communicate and exchange on the same formats as developers from other niches or communities to avoid issues.
That’s great to hear! In all reality there isn’t really anything stopping anyone from making their own FBX exporter, or GLTF even I myself have been trying to interpret smoothgrid and make my own terrain importer/exporter tool.
Nearly there, just haven’t been able to spend much time on it, but in a way thanks to Roblox not having “fbx/gltf” exporting I’ve been able to learn things I never thought I’d be be able to learn.
If you notice in the original post, the vid of the character bowing, the character’s left leg is sliding forward when the animation is being played.
This means the animation is supposed to have some sort of root, or anchor point, so that most likely the left foot would be more stationary thus causing the right leg and the body to pivot and move backwards.
I have had a lot of problems importing animations where studio does not recognize an anchor point and my animations do as the example above, slide around.
Is there any option in the new import to fix this, or any plans to address this?
There’s no difference in how .gltf and .glb are handled once they’re in the importer, it’s just a matter which file you’d like to work with. In general .glb is smaller because it’s a binary file, and .gltf is human readable. But functionally it’s the same data either way!
I tend to use .glb when I want to send someone a file because I can embed the texture files within and send the whole thing so I don’t have to worry about also sending the texture files, but I like using .gltf when I’m the only one working on them so that I can easily edit the files with a text editor if I wanted to.
Unfortunately in this particular case I was the one who made that animation, and I’m just not very good at animating yet . But I’d love to hear more about this issue, right now we just use the root node as the anchor point, but it sounds like you have an animation work flow where you’re using another node as your anchor?
(as an aside there’s also a known issue right now where root motion can play funky in the import animation preview window, so that probably doesn’t help…)
Agree, the polygon limits are too low. This is the biggest issue for me at the moment. Other than that, finally having animation support on import for the gltf format is awesome. Great job getting this released!
Step 4: Make sure your file has an animation node in it, and that the animation looks correct when you click on it. If you don’t see this node make sure you exported your animation from your 3D software correctly
You can also open your animation in the animation editor and preview it in studio by opening your new rig in the animation editor and then creating a new animation:
. But I’d love to hear more about this issue, right now we just use the root node as the anchor point, but it sounds like you have an animation work flow where you’re using another node as your anchor?
