glTF vs FBX threadLooking forward to see Autodesk lose its biggest grasp on the industry
I know this board is supposed to be satire, but I can't but agree with you 100%. FBX is cancer.
>>647715why is the Khronos Group so based lads
But can glTF be a full replacement for FBX? Isn't it supposed to be more of a "closer-to-the-GPU" storage format, rather than as a scene exchange format?
>>647720I think it's 'supposed to', yes. But it has the capability of also being an exchange format. It uses a very strict format (forcing swizzle setup, unit setup etc) making writing importers easier, as there are less variables to account for.
>>647720i though the main focus was efficient data transfer so you dont have to wait 5 minute to load web games. It still have some strange limitations like 4 influence joints
>>647832The basic glTF is designed with peculiar choices like 4 influences per vert so a standard glTF can be uploaded almost directly to GPU memory. However, the format can be extended with extra features. Allowing more than 4 additional influences would involve designing a standard JSON format to store more than 4 influences, and getting it approved. I doubt it would be be too hard since it is already https://github.com/KhronosGroup/glTF/blob/master/extensions/README.md
>>6479204 influences per vert has been the standard since forever for games which is the target for this. Any less weight influences and you get limited, any more and it doesnt matter since the weighting is so spread out
>>64793I dont understand the whole basis of this discussion.>4 influences per vert has been the standard since forever for games which is the target for this. Any less weight influences and you get limited4 influences/vertex are the standard yes, but its already limited as fuck and modern engines can deal with more nowdays. >any more and it doesnt matter since the weighting is so spread outAnd what is that supposed to mean
>>647717>I know this board is supposed to be satire>newfags actually believe thisThat explains what keeps happening to this place for years now
>>647942>but its already limited as fuck and modern engines can deal with more nowdaysits not, and you cant tell the difference. Literally everything you see in vidya is 4 infl
>>647942>And what is that supposed to meanWeights are normalized. The more you have, the less each contributes to the total effect. That doesn't mean that having a fifth, sixth, or even higher n-th weight isn't going to make a difference, though.
>>647949>>647945>its not, and you cant tell the difference. Literally everything you see in vidya is 4 inflIm actually a rigger working in the game field. Ive had to deal with different szenarios: Film rigs with no limits, game rigs with 8 influences and rigs for other game projects with 4 influences.If the customer is actually aware of their limitations and doesnt push the target quality too far then its quite fine to work with 4 infs, but in the past ive also had to push character deformation beyond the limits of 4 infs and I can tell you, its not fun going to the max and then bringing the bad news that its not gonna get any better. Our current stuff runs at 8 and im pretty fucking happy about it.I mean, you're also right, in most games it doesnt matter but since our current project requries the character deformation to hold up in close-ups and extreme poses going for 8infs is quite essential at least for the LOD0 meshes.
>>647920>tfw first sentence of overview literally said glTF™ (GL Transmission Format) is a royalty-free specification for the efficient transmission and loading of 3D scenes and models by applicationsMy impression is that the first and foremost concern is transmission and everything else is secondary, including things like number of infl limit in favor of load speed. If the main concern is data transmission then this format is the right choice. while as a general data exchange format, idk
>>648001I'm actually working with parsing the glTF format, and adding 4 more weights is easy as fuck. Influences are stored in sets of 4 as JOINTS_0 and WEIGHTS_0. To add another 4 influences you just add WEIGHTS_1 and JOINTS_1. Simple as that. Blenders glTF exporter does this by default and you can simply ignore these extra influences if you can't support them in your application.
>>648169What exactly is the benefit of gITF over fbx then?Why would I want to replace fbx if it works exactly as I want it to and my pipeline revolved around its behavior works efficiently.
>>648180None of that propriety format shenanigans. For the longest time .FBX support in Blender was trash and it's importer was non-existent or useless (no rigging/animation support) up until recently because "muh GPL".
>>648184>For the longest time .FBX support in Blender was trashIf the main advantage is that it will work better than FBX in Blender, no one will care. There must be real technical benefits in using glTF over FBX, without losing any of the exchange/scene storage capability.From what I read, it would seem that USD is better suited as an FBX replacement than glTF.
One thing that might be interesting:fbx seems to be at least semi binary to me. Which is a point, where gltf or collada for that matter might provide an upside: version control systems, like git or svn can diff those, so they can be stored and transferred quite efficiently. It's kinda hard to diff a binary format. I think this is the main point behind the ascii maya format as well.
>>648180If the only means to transport full 3d scenes from one program to another is owned by a corporation with selfish interests, you'd reckon they might use that to their own advantage, right? Fbx is closed and only Autodesk chooses its fate. Then there is all the licensing and whatnot if you interested in including their SDK in your application.Here are some technical advantages:glTF is more 'rigid' meaning it is easier to import, making it potentially more useful on a wider range of platformsglTF is smaller in filesizeglTF is extendable, something that has long been requested by bigger companies like Disney/Pixar, causing them to invest in their own formatsglTF is simple to understand, effective at what it does, and free for everyone. It is future proof.
>>648241glTF is also binary. It comes with JSON info on how to read the binary. Pure ASCII would be very slow and large in size
>>648245Those are some very good points man.Got me conviced this stuff needs to be worked on further. I hope it makes a valid alternative to fbx.
>>648246Thanks for that bit of info, good to know
>>647715Have you also checked out Pixar's USD?https://graphics.pixar.com/usd/docs/index.htmlhttps://github.com/PixarAnimationStudios/USD
>>648330I have. It looks like a decent competitor. But I have noticed it has drawn a lot of attention and support from Apple, so I'm cautious about it. We all know they aren't known for their openness.
>>648330>>648332USD and glTF aren't exactly the same thing, I wouldn't see them as competitors at all.glTF is intended as a portable description of renderables, tailored to how GPU graphics libraries work, however USD is a plain scene description (with a lot of optimisations around it's file formats and data structures). There's overlap obviously but they're not the same and my guess is they'll diverge further. For one glTF bakes state into it's format (e.g. you have to describe if you're rendering lines, polys, tris etc.). It make sense for what glTF is for while any worthwhile scene description would separate scene from state.Different jobs, different tools.
>>648670Can you come up with a clear example of where glTF falls short compared to USD?I've been reading up on both formats. glTF is crystal clear and easy to understand. USD not so much. I'm honestly having a hard time wrapping my head around USD from a developers perspective.
>>648888gITF is for the final result (in an realtime environment)USD is for scene management over many pipeline tools.( Like Maya>Houdini>Katana) USD is much more complex since it unites many standards and ways of doing things under one umbrella. Its not just one file format.
>>648893Yes I've read that too. But what are the concrete differences that makes USD better for scene management? glTF has scene structure/hierarchy, complete with instancing, skeletons, morphs, textures, materials, etc and room for extensions. What it doesn't include is stuff that's usually non-standard between programs, like rig constraints, which I've read isn't part of USD either.
>>648906It's not that glTF "falls short" compared to USD, it's that they're trying to solve different problems.>>648893 explained the difference between a file format and a scene description well.If you're trying to figure it out from a developers point of view, perhaps understanding why scene descriptions became an industry standard over file formats would make things clearer?Firstly, a file format says nothing about the runtime. It's just a file format description. It's entirely down to an application to implement it's own interpreter, data structures and memory allocaters. This becomes kind of a problem because you end up supporting an interpreter for every runtime (which is now houdini, nuke, maya, prman, offline renderers, online renderers, any number of proprietary tools and growing). Even with a diverse runtime environment, this still mostly works when the file format is something simple (usually the complexity is hidden by caching, that's another story), but becomes exponentially more complicated once we start talking about scene hierarchy, forgetting even evaluation. Exposing something like that to the hosts runtime and tooling it is very, very complex to do in a truly scalable way, and then figuring out how to do it for every host only explodes the cost.So a more modern approach was taken to provide a runtime with a file format describing the scene hierarchy. A scene description.
>>648997(cont.)This way, rather than having to inject your scene hierarchy into the evaluation model of different runtimes, you plug straight into the renderer and draw directly from your scene description. Your file format interpreter gets implemented once for everything ever (because it's embedded within the scene descriptions runtime). This pushes the problem from an evaluation integration problem to a renderer integration problem, which is a lot easier to solve generically since everything looks the same at the mouth of the real time renderer - it's all arrays of points, indices etc. That's why Pixar implemented Hydra in the way they did. It still comes with some complexities on the rendering side which I wont go into, but it scales orders of magnitude better than the file format approach.glTF provides that description for a renderer but without the runtime or the renderer. Which is by design - it's a file format.It doesn't entirely get you away from host exposure tooling, but it gives you a baseline of being able to visualise you scene in any application easily without affecting the runtime, so it make tooling easier to develop in an iterative fashion. Also because you have an application independent runtime, you can have an option of being able to develop tools in that, which will then be common across all integrated hosts.Hopefully that made sense. A lot of this stuff only starts to matter with massive graphics pipelines in big studios. If all you're doing is exporting some stuff from Maya for a WebGL app, glTF is what you want.
>>648997>>648999I read up on scene descriptions. It sort of makes sense. Instead of trying to generalize the format, an USD stores code that can be parsed by mostly any renderer. This code can't be edited directly, but instead you do it through the original model files which are stored within the usd in their original formats (.mb .3ds .blend etc.). USD doesn't allow you to edit a file you exported from maya in blender, but it allows you to render the model in any program with a renderer exactly the way it was rendered in Maya. This is useful if you have a pipeline of a lot of different types of programs but not as a format you'd put on turbosquid, which was my original intent when comparing to FBX.USD seems to excel in big pipelines, while glTF excels as a general transmission (Ignoring WebGL because that's irrelevant to this discussion)Or did i misunderstand something?
>>649009No, you've pretty much got it.The key is that the host, like Maya or Blender, doesn't own the USD scene in memory, the USD runtime owns it. The host has no idea USD even exists. That's why you have to go though USD to make any edits, which means native tools in the host wont work easily with it.But to make things more complex, you can edit USD files in certain hosts in certain ways. You can find some youtube videos on Animal Logic's USDMaya plugin which exposes USD editing to Maya.
>>649009Also although the USD data can be loaded in an opaque way, the file format does have its own internal formats for poly geo, xforms, animation, skinning etc. so it can serve as a transmission format as well. The Animal Logic USD plugin makes it easier to import and export geometry through USD.
Can someone explain to newbie, why people even use glTF today? Recently i dled a bunch of files in glTF format and i can't even do anything with them. Except some buggy blender plugin that i couldn't get to work, seems like nothing even imports/exports glTF. No game engine uses it. What's the point?
>>649051glTF has only been around for about a year. Plugins are currently in development for most programs including blender which will officially support it in 2.8.Godot engine uses it, and both UE4 and Unity have shown support for the format.I've been trying the blender plugin out myself and I've had no issues with it apart from a few missing features being currently developed.The point is to have an open format that is compatible with all relevant programs, and we're getting there.
I'm looking at the documentation of gltf and I don't understand how skinned meshes are stored. Could someone explain how it works?
>>650322The scene description contains a mesh node, the mesh node contains attributes named WEIGHTS_0 and JOINTS_0. These are both float4 arrays, WEIGHTS_0 specifying 4 weights per vertex index, and JOINTS_0 specifying 4 bone indices per vertex index.