This is exciting to see what I would be able to do with this in the future!
12 Likes
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.
20 Likes
This is much appreciated. Saves time re-exporting models from blender as either fbx or obj.
8 Likes
Raise the polygon limits. I know you guys have been looking into that, you can’t fool me.
8 Likes
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.
25 Likes
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.
7 Likes
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.
10 Likes
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.
7 Likes
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.
6 Likes
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?
6 Likes
the left leg sliding is most likely a part of the animation
6 Likes
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…)
6 Likes
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!
5 Likes
rare roblox win, hoping for this to be fully functional and performing
5 Likes
How would i get my animation to load in aswell?
4 Likes
Here’s a quick overview from start to finish!
This is likely more detail then you need, but just in case others need a reference as well, I’m going to go through all the steps.
Step 1: Make your animation in your tool of choice
Step 2: Make sure you export animations when you export as .gltf or .glb
Step 3: Open your file in the 3D importer
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
Step 5: Import it!
At this point the animation has been updated to your inventory.
You can find it by opening the toolbox and checking in My Animations.
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:
Then go to the three dots next to the rewind arrows and select Import → From Roblox:
Select your newly uploaded animation and click submit:
Then you should see your new animation in the animation editor and be able to modify or play it as you please!
Feel free to let me know if you’re still having issues or need clarification on anything!
7 Likes
I went through my import process (which I haven’t done since I was frustrated with no scaling for animations sometime around the summer of last year)
However, there were no unanchored animation issues this time. So apparently this has been fixed.
So I checked the animation scale issue, and it works perfectly in studio with imported animations and with saved animation, all matching the ‘Scale’ property of the Model.
I also checked if import of multi part meshes allowed them to remain individual mesh parts, and that worked as well.
So then I checked if an animation that was saved without a preview mesh (considering some preview meshes are over the limit) would import the animation into the animation studio (it used to not) and that works as well.
I honestly cant think of anything that was giving me problems when I was working with meshes, that hasn’t been fixed in the last year.
So… wow, I’m a bit speechless, bravo.
10 Likes
This was actually addressed in the original Beta announcement for this feature:
TL:DR; Some operating systems/devices Roblox supports might have GPUs that do not support numbers that are greater than 16 bits large for the purpose of keeping track of all the vertices a mesh has. Meshes would look quite broken on these platforms if they have more than 21K triangles, and so the triangle limit is 21K.
6 Likes
Thanks, it really started working better!
It would be great to add a preview of automatically generated collisions before importing the model into the editor.
Right now collisions on custom meshes have to be checked after import. After numerous mesh checks in the editor, I end up with hundreds of duplicates of these objects in my account, because I have to keep re-importing them to make sure the collision works well.
4 Likes
I honestly stopped worrying about assets in my inventory and I make sure all of my stuff is either stored in a place, or on a backup of some kind
4 Likes