Unity support for the glTF format by default (to replace Collada and FBX)

I don't know when/if it will be a package in package manager. It's available now if you don't mind getting the code from GitHub and producing your own .unitypackage from it to use elsewhere.

 

There's no reason there has to be ONLY ONE FORMAT. No one format is right for everything, and certainly GTLF is not right for a lot of things. If Unity were to remove support for OBJ/FBX/DAE they would be shooting themselves in the foot. It's fine to support GTLF, but it shouldn't the ONLY format.

Also there's nothing "Closed" about FBX. it's a very well understood format, plenty of open source versions of it, hell, even Blender (an open source and very anti closed source group) has FBX read and write capability. So it's silly to act like it's somehow 'evil' or something. it's a very popular, well rounded, and well supported format that pretty much EVERY 3d creation program uses. dropping that would be cutting off your own nose to spite your face.

 

What are you so angry about?

No one is saying that glTF should be the only format supported. No one except the original poster suggested replacement of FBX and Collada, and no one thinks replacement is a great idea.

FBX is definitely NOT open. It's well understood, yes. It's popular, yes. It has wide tool support, yes. It's not "open" though. Adobe owns it completely. Try getting an official specification document in any form. Try getting an official SDK in C# or any other language other than C++.

FBX is a comprehensive format, but it takes AGES to parse compared to glTF. FBX is an interchange format, and glTF is a runtime delivery format. Those are two ENTIRELY different approaches to data optimization. There's room for both formats.

 

ANybody know of any 3ds Max Exporters (2010) for GLTF Format? I have found this one for 2018 but not for any older ones. Thanks.

 

Pretty sure one doesn't exist going that far back. Most things from that era of 3DS Max are super deprecated at this point.

 

offloading bandwidth costs to sketchfab is the main point. Having high costs associated with self hosting 3d assets in the cloud is the main concern.

 

So the root of your problem isn't sketchfab, but your willingness to pay for a service you require.

 

A) that's a pretty dishonest approach, trying to offload costs to someone else without their consent. Pretty sure their terms of use would prevent it legally, even if their APIs did not prevent it.

B) bandwidth from AWS S3 isn't as much as you maybe think it is.

C) it's up to the people who need the hosting to pay for it, not you, the consultant. If they can't afford it, then they don't need it. If they simply don't want to pay for it, then they are not doing business in good faith, which does not bode well for you, the consultant. That business will screw you over at some point.

 

> If Unity were to remove support for OBJ/FBX/DAE they would be shooting themselves in the foot. It's fine to support GTLF, but it shouldn't the ONLY format.

Just to be clear: we have no plans to remove support for any of those formats.

We (Unity) are actively participating in improving Unity's glTF support. I don't have a timeline for when glTF could become a package, but it's something we're looking into.

 

I'm looking forward to seeing this progress. Runtime loading of glTF supported natively by Unity (via a package or not) would be wonderful, indeed.

 

Google Drive is to file storage and transfer as sketchfab is to 3d model storage and transfer.

Its dishonest to use a service created for distribution, to be used for distribution?

Im not going to run up a big bandwith bill just because clients want their 3d models in the cloud.

Anyone who uses gltf or asset bundles runs into a "netflix" problem of costs, when you get past implementing your entire app around asset streaming.

 

Yes, this is dishonest. It's called "exploiting a potential loophole."

 

"Almost 6 years ago, we embarked on a journey to let people easily publish, share, and discover 3D content; and become the ultimate home for 3D on the web." -sketchfab

rolling my eyes @ you, sketchfab, and jeremy

gltf is cool, but you won't see a big adoption from indies until you solve the cost associated with switching your entire app around asset streaming. Same problem as previous 3d asset streaming implementations.

What I am describing is the only way you will see a HUGE adoption around gltf for indies. Sketchfab, or someone else picking up the bandwidth costs associated with being the 3d repo of the internet.

 

Indies... don't really have a huge stake in content streaming. For the most part, engines themselves will handle the local streaming factor and most simply don't really need or care about it from a web perspective.

What WILL help a huge adoption for indies is gltf being supported in 3D modelling software.

 

Something being technically possible does not mean you are allowed to do it. I guarantee that Google Drive will not let you serve up millions of models per day, even though it can easily handle that load, technically. There are administrative limits to use of those services, and if you start sucking up bandwidth they will serve up HTTP error codes until you are back within whatever limit was exceeded.

Your use of online services is bound by the terms outlined in the EULA and/or Terms of Use document(s) that you agreed to abide by when you signed up for the service.

If you don't like those limits, don't sign up for or use the service. It's literally that simple. If you are going to write an application for a business and that business needs somewhere to host those models, then that business needs service level guarantees and other promises from the service provider that the service will be available, and that it will maintain the service you pay for. That's what you pay for when you pay for content hosting.

Content hosting is not a "get rich scheme" and you and your client(s) are not "suckers" for paying for content hosting. It's the cost of doing business, and if you can't afford to pay (or are unwilling to pay) then you can't afford to be (or are not willing to be) in business at all.

 

Mozilla (weirdly enough) have launched an effort to improve the gltf support in Blender:

https://medium.com/mozilla-open-innovation/gltf-import-export-tool-ca0932b0ce76

 

sorry @markvi BUT: @Linkooo started this thread october 2017 -> one year later, you gave a first official answer to this topic. And NO: it's not about removing something, the primary questions is: when will Unity support GLTF -> in the editor? I'm NOT talking about runtime. I'm talking about drag and drop gltf/glb files in the editor and work with them.

Since 2.8 Beta Blender supports Import and Export from GLTF by default (https://wiki.blender.org/wiki/Reference/Release_Notes/2.80) Yes! It's just integrated, because they can... or better: they wanted. Please compare teamsize and income from Blender Foundation and Unity! I'm really interested in what "actively participating" means and why there's no timeline for integration of this amazing open source format which has support for so many features... not only PBR Materials.

I'm really upset, that there is no progress... some months ago I said to colleagues and myself: Unity will definitely support this format soon, this year (2018)" -> now, after the blender beta release I exported a *.glb, dropped to Unity 2018.2.15... and: Nothing! Then I realised... Unity Editor has no idea, what this is. Then I came to this thread and... wow!

To sum up (Dezember 2018):
- The GLTF 2.0 stable release was 5 June 2017 -> 17 months ago
- Unity is not able to import a GLTF file in December 2018!
- Windows 10 opens a gltf in 3D Viewer and 3D Paint -> I can even edit and paint the objects
- Blender 2.8 Beta has a GLTF im/export
- Sketchfab: "glTF is a one-size fits all file format designed to let you move 3D files seamlessly between applications while retaining a consistent PBR workflow." (https://sketchfab.com/features/gltf)

-> isn't this something, which should be a high priority? Mh... which is the most used 3D fileformat in unity? FBX! What was the company behind... ah.... Autodesk. Is it really so simple?

Sorry for being upset, but my "let's try a great Model -> PBR Material -> Rig Workflow Test" ends here. And Paint 3D won against Unity... I mean: I love Unity but... you should drag some AAA mega high end super realistic pipeline things down on the list a put open source support higher in the list of priorities.

 

That beta came out less than a week ago and also it's a beta.

 

It's not native, but the Khronos plugin (I linked it above) supports drag and drop in the editor for .glb files. Paint3D models specifically should work fine here.

 

Thank you @thinksquirrel_lily for the hint... in all this entries I missed yours. Good to read, that there is a solution to fix the lack of support from Unity, but I couldn't test it yet. On the linked repository they write:

"Open GLTFSerialization\GLTFSerialization.sln and compile for release. This will put the binaries in UnityGLTF\Assets\UnityGLTF\Plugins"

I'm not used to compile plugins for unity. I open the *.sln file in visual studio code and... don't see the build compile button. I'm not bad in searching and finding a solution. "Compile in visual code" give > 100 million results... there are extensions, build tasks, videos... but in most cases, I just feels way too complicated for this task or it just didn't work for me.

Do you have direction to go for someone, who's basic idea was to import a 3D model? Wouldn't it be nice to create some binaries from time to time and put them online next to the repository. So people could start creating and not compiling....

best regards
Simeon

 

Hi @noemis,

There's a release here that might be up to date? It's been a while so I'm not 100% sure.

https://github.com/KhronosGroup/UnityGLTF/releases

If not, you should be able to import the Unity-related bits as scripts. I'm not sure how in-flux the API for the DLL is though. There's an open issue to make releases more often (I agree that it's a bit too much work to import) that I'd keep track of.

 

Thank you @thinksquirrel_lily ! This helped a lot. I downloaded the release and imported the package to Unity 2018.2.18. After import I see this error:

"Assets/UnityGLTF/Scripts/Tests/Integration/GLTFExporterIntegrationTest.cs(20,4): error CS0103: The name `IntegrationTest' does not exist in the current context"

I deleted the integration folder and now it seem to work. I could drag and drop a test *.glb (from blender 2.8 beta) into Unity. Great! Now I can go into deeper tests.

Thank you very much for your help!

 

Agreed.

However Unity kinda collaborate with AutowreckDesk

Soo yeah, that was like a year ago now. Not sure why Unity doesn't work with Blender more or provide more seamless integration with that, seeing as it is opensource they could do a plugin... I mean they could something.

It's almost like Blender has a fresh set of developers who aren't complete morons and actually want to embrace industry standards like left click to select.. amazing, instead of being idiots and basing things off of weird and obscure lets do things our own 'special' way design (translation fking awful) ux workflow methods. ...what will they do in 2019 I can only guess, so Autodesk should be worried, they still don't even provide a gpu based renderer while Blender does, clearly something went wrong with that place.

So yeah GLTF,

 

I don't know if there has been anything official regarding support commitments here, so giant grain of salt, but developers at Unity have at least looked into the open source implementation. Maybe something's cooking Speculation, but I would be surprised if they haven't at least tried some things. Keep in mind that in-engine support for everything comes with a lot of requirements like performance, platform compatibility, editor tooling, etc.

In the meantime (also for folks skipping to the end of the thread), the UnityGLTF Khronos repo is the way to go. It's under active development, so there are some moving parts, but I imagine it will be supported well up into (and possibly after) any native Unity integration.

Regarding FBX and other formats: glTF right now works best as a transfer format at runtime, and export/viewer format, or for minimal edits on game-ready stuff, so I definitely welcome the improved FBX workflow as well. That format isn't going anywhere for a while (maybe when the extension ecosystem for glTF adds some more standardized authoring-focused features), so the more support for different formats the better. Especially considering the wide range of customers Unity supports, with most of them likely using these other formats.

 

Looks like glTF is actually missing a lot of important stuff:

http://opengex.org/comparison.html

 

Jesus

Yikes

Hahaha WHAT

 

Not true. You can have as many weights as you want per vertex.

Not true. There is no limit on uv channel count. It may be true for vertex colors, but most engines don't support that either.

 

You're right! It looks like that was a recent upgrade to the glTF spec. I do remember it being limited to 4 in the past.

Edit: They added support for more than 4 joints on July 6, 2018:

https://github.com/KhronosGroup/glT...b5e9cf4#diff-754ca5ce2ca9fef97dbac5ed2340e40e

I'm not sure how they can just keep calling it the "2.0" spec when things like this are changing.

I think they were talking about how position, normal, tangent, can't have multiple values per vertex. In particular, if you're doing bump mapping with two sets of uvs, then you need two tangents, but there's no way to put them in a glTF file.

 

In my years as a 3d modeller I have never encountered anyone asking for such thing, nor have I seen it as a feature in any program. So why should glTF support it?

(Your bumpmap example confuses me. In my experience you don't need two sets of tangents)

 

Good for you.

 

It's still backwards compatible (unlike 1.x). I'm not sure if they're using semver precisely, but I believe that's what they are saving major version bumps for.

--

While I'm also a little confused about two tangents for two normals (are they in different spaces?), I defer to full-time artists to answer that question I seem to recall an issue being raised along those lines—it may be worth checking those issues out in the spec repo, and seeing if there's either an accepted standard extension-based solution or reasoning behind not supporting it.

One of the benefits of glTF is that development is done completely in the open. Since the format is dead simple to parse, implementations are getting updated fairly quickly as well. They're even working on things such as generated implementations from the spec to keep everything up to date. So if something seems missing, starting or contributing in a discussion for that can make a real impact.

 

Is there any news on the glTF supports? It is not on the 2019 roadmap: https://unity3d.com/unity/roadmap

Unreal Engine has it since 1 year and Godot since mid-2017, it was integrated few weeks after the file format was released with a single full time developer behind the engine! Production tools support it like Blender 2.8 and Substance Painter. Unity doesn't have it planned for this year still.
I start to believe that Unity keeps delaying it since their collaboration with Autodesk on FBX.

Also Blender 2.8 will drop FBX support. (it was a fake news finally)

 

Yeah it's too bad that the official Khrono's group plugin for unity doesn't actually work with GLTFs, only with GLBs (even in their example scenes).
It's about time Unity incorporated GLTF natively (only mentioned in one of their 2018 talks about the 2019 roadmap but it doesn't actually appear in the published roadmap as Linkoo pointed out).

Also, the alternatives to the UnityGLTF plugin don't have dynamic runtime GLTF/GLB loading (and Khrono's plugin is super slow when loading GLBs, mostly because of the way texture compression and text parsing is being handled).

C'mon unity we need GLTFs!

 

Please provide a link that supports this comment.

 

There isn't one. It's all based on a dramatic misinterpretation of this:
https://lists.blender.org/pipermail/bf-committers/2016-February/046630.html

Which was clarified here:
https://lists.blender.org/pipermail/bf-committers/2016-February/046710.html

It's been two years and people are still on the whole "BLENDER IS DROPPING FBX SUPPORT" thing.

 

Yea... I figured that was the case, but thought I would them a chance to back up the claim before removing it. Last I read, they were planning on improving compatibility for that and other formats for 2.8, but I don't check all that often.

 

My bad I saw that on this thread from several posts and thought it was true, I have edited my post.

 

You bet!
They're well aware, that Blender is one of the most popular 3D packages, especially among indies. If not the most popular. And yet,they partner up with Autodesk to shove their proprietary format down our throats.

 

Ugh...

I don't like .fbx, I wish it was replaced by an open standard. Collada wasn't it, (too many variations, too much complexity, even software that were really enthusiastic about Collada (like modo) didn't manage to have perfect support for the format).

Sadly it seems gITF isn't it either.

 

At some point

Care to elaborate?

 

Hi, someone has made a video tutorial on how to export from Blender 2.8 Eevee to Unity in .glb:

Each time Unity will detect a glb or glTF it will generate a prefab automatically from it. I recommend you to avoid glTF with separated files because Unity creates a lot of folders already for the prefab so use glb.

He uses the UniGLTF, you just need to double click it to install the package in your project (it's made by a community member): https://github.com/ousttrue/UniGLTF/releases

 

How Unity handles last year of glTF development makes me sad.
Is there some information about activities or a roadmap available.

The good thing is that some of the devs i know who spent years of their life by reverse engineering fbx stuff know start start constr to glTf development.

 

I've also begun working on a GLTF importer/exporter for unity. It's not finished, but it's looking promising so far.
https://github.com/Siccity/GLTFUtility

 

How do I use this package?

 

Just follow the installation steps in the readme. After that, .glTF and .glb models in your project should import automatically just like .fbx or .obj would

 

Unreal is now officially handling glTF imports via Datasmith... which is a bit weird, since that solution was especially made for CAD imports and may come with a license fee in the future, but at least they're doing something.

Does Unity have any official plans for glTF yet?

 

I find it funny Autodesk is joining the Khronos Group and showing interest in glTF while at Unity we heard nothing about it so far.

https://www.khronos.org/blog/autodesk-joins-the-khronos-group

We can only hope for Unity 2020.1 at the earliest.

I really like the size improvements and native pbr texture and material support w/ animation and even rigging 'n all.

Much less hassle during import, I hope Unity natively integrates all that so devs can *finally* drop a file in the editor and get their assets all hooked up & ready to go without further tweaks.

 

Isn't Unity using Autodesk's FBX importer? Maybe if Autodesk adds support for gITF for it, we'll also get it in Unity.

 

I wouldn't say Unity has been sitting around. Maybe they haven't said much publicly, but not only is Unity a member of Khronos, several employees have had a hand in the development of glTF. Everyone will get on board with this one, it just takes time for things to settle

 

Looking forward to "experimentail gITF support" in the package manager that will stay that way until the day its deprecated.