I try to always update that doc with everything perf related:
Yes, and I keep reading that page – it’s a great resource. But perhaps code could get automatic performance improvements with a higher level API, instead of the developer reading that page to find something new.
While new docs would certainly help (and I’ll try to send some PRs soon), I still maintain that as a user I’d like a call that unified the optimization APIs. I am no strange to profiling (see Animation performance drop by translation/rotation, which you have helped me before, thanks again!. In fact that PR for the material plugins is in part because I’m expecting it to be much more efficient than a separate RTT pass), but the problem is that it’s not always easy, as a user not profoundly familiar with the API, to know how to solve a bottleneck with BJS. And I’m not claiming that it should be easy – optimization is hard by nature, and abstractions always pay a performance price.
And if you are GPU bound, profiling is actually hard. Spector.js is low level, and translating it to a sensible optimization on your high level code is not trivial.
I just feel that the API could be easier to peruse. Some things that optimize are flags, other are methods. I know freezeNormals is useless, but I thought bakeCurrentTransformIntoVertices would save a transformation. And even with much improved documentation (and BJS has pretty decent docs IMHO) it’s still hard to find all the calls by the very nature of code. I maintain that a mesh.optimize call would be very helpful and more easily translate a “my bottleneck is this” to “this is what I should do”. It would give devs a single point of optimization with IDE auto-complete, so the options to optimize are easy to find. Then you can read the docs to get details. But look at the difference between a mesh.optimize({completelyStatic: true}) to what is necessary now, something like 4 calls and 3 flags?
Besides, I still think that the SceneOptimization classes could benefit from the high level information too. If you look at MergeMeshesOptimization, it sensibly avoids merging if there’s a skeleton. But maybe the mesh has a skeleton but it’s not being animated – as a dev I’d only know it’s not being merged if I read the Optimization code, and documentation about it would be as long as the code itself. Or TextureOptimization, which could get info per mesh or material as to how much texture could be downsized.
Still, only my two cents! It’s very easy to write a long post here saying how things should be 