Andreas Atteneder

glTFast Next Steps

State of glTFast

A while back I started a mini-series, in which I document my aspiration to get my Unity package for loading glTF (glTFast) more efficient, modern and elegant.

I'm far from running out of ideas yet, but I have to balance backwards compatibility vs. innovation speed.

First of all, due to excessive profiling I figured out where the biggest potential for improvements is and followed the trace. I started using Unity's new advanced Mesh API and was making first progress (up to 45% faster loading of big meshes). I also figured that in order to get ideal results and to not introduce regressions, I have to do a significant refactor.

I wasn't in the mood for that yet, so I did a quick stab at Unity's new Burst compiler. Again I could strip off some milliseconds and retrieving data from buffers got ~50% faster in a test case. But again, this is not backwards compatible to the currently supported 2018.2.

Next I tried to tackle some last, missing features (outside of animation; like support for multiple UV sets), but the thought that this is not important (to me) and possibly obsolete in upcoming tech stacks did not appeal to me at all.

So what to do then

Today (on Friday the 13th) I freeze glTFast's feature set and release version 1.0.0! 🎉🎉🎉

I think the project is at a point where it can be used in production. Possible fixes will be released in 1.0.x cycles.

Future development will be based on Unity 2019.3/4 and break backwards compatibility with older versions. Dropping the baggage of legacy support allows me to innovate faster. Focus will be speed and efficiency foremost. I think about:

Secondary features/goals that might come in are

I'll release those innovations in a 1.x cycles until it is ready for production in a final 2.0 release.

I think this project has some exciting times ahead. I'd be glad if you follow and star it on GitHub.


Follow me on twitter or subscribe the feed to not miss updates on this topic.

If you liked this read, feel free to