KeyframeTrack: Option to disable validation/optimization?

By default, the KeyframeTrack constructor calls this.validate() and this.optimize(). Those calls are unnecessary for animations that are already optimized, and problematic if the track is going to be split later, such as in https://github.com/mrdoob/three.js/pull/13430. From the Oat the Goat technical writeup —

THREE.KeyframeTrack’s constructor calls validate() and optimize() in its constructor, which is unnecessary and was costing us half a second of CPU time per scene.

An option in the KeyframeTrack constructor doesn’t really help, because they’re typically not created directly, and the option would need to be passed through all of the loaders. We could disable the optimization and let users trigger it manually, but I do think it’s a reasonable default. What about a (global) opt-out flag?

THREE.KeyframeTrack.autoValidate = false;
THREE.KeyframeTrack.autoOptimize = false;

[donmccurdy]

Ok, thanks! I’d meant to say the default should be to optimize (i.e. keep current behavior) as well, and just provide an option — somewhere — to disable it, so I think we’re on the same page.

[Usnul]

@RemusMar & @donmccurdy

That’s true, but there are millions of assets uploaded on thousands of servers. Do you expect them to be re-exported in the “optimized” way?

It would be ideal for optimization to happen before animation is brought into three.js, but that’s a much harder problem.

Asset pipeline is something everyone has, some put more effort into it that others, some pipelines are completely custom while others are heavily standardized etc. I am not advocating for removal of validation and optimization methods - I think they are wonderful tools that serve real need. I believe that it’s reasonable to assume that once an animation is loaded it is:

• valid
• expressed as desired (no optimization is wanted)

When these assumptions are insufficient, i believe it is reasonable to offer the tools (validate and optimize) to the user in order to deal with such usecases.

Unrelated:

@donmccurdy writeup on GOat was quite insightful, especially part about glTF exporter. They said they wrote 13k lines for that interactive experience which, when reading the writeup, indicated me think that there’s a lot of room for improvement in glTF export as well as animation module and three.js in general.

@RemusMar

The backwards compatibility is (should be) a critical factor in software development.

“Everything in moderation”. I don’t subscribe to your view, backwards compatibility is critical for some applications and harmful for others. Language design is one example where backwards compatibility is a clear net negative for the user, take C++ as example, there are a fraction of a percent of a percent of C++ developers who can rightfully claim to know all of ‘standard’ C++ - thanks to backwards compatibility. Backwards compatibility is expensive, it bloats your code, it takes time, it leads to rigidity in your architecture which strongly opposes evolution and progress. Three.js is not backwards compatible, I enjoy migration and deprecation notices, but that’s not backwards compatibility, I can’t boot up my application written against three.js r50 in three.js r93 and expect it to work - it doesn’t. There is something called “semantic versioning” which might be a good thing for people to familiarize themselves with, if not to practice religiously. /rant