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:
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.
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.
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.
This will make it so that when you import a glTF (or FBX) file, the first time, it will create a single package asset, but for subsequent imports, instead of creating a new asset, it will update the package with a new version.
This is also great if you are working on something that is copied in many places around your world.
I don’t know when the 3d Importer started moderating the names of things uploaded, but it’s become very frustrating. I’m trying to upload meshes with 80 animations and I keep getting errors “The file name has been moderated, import failed.” - This is 80 animations with normal names, and I have no way to tell which animation names are failing, and no way to fix it.
I don’t care if it replaces the names with #### or something, but there’s no reason for the upload to outright fail because it doesn’t like the name. I think an ideal solution would be some prompt “select another name” and it gives the current name and asks you to select a new name until the name successfully processes, however, as long as the behavior doesn’t outright stop me from importing objects, I don’t care what it is.
. 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?
Goated. This will solve a lot of my problems.