Giters

KhronosGroup / glTF-Sample-Assets

To store all models and other assets related to glTF

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Models that challenge engine's performance or runtime limits

lexaknyazev opened this issue · comments

commented

This issue may lead to greater questions and maybe even spec updates.

API Limits

Percentages mean hw/impl caps of WebGL 1.0 clients.

Texture size

Here're max texture sizes according to WebGL Stats:

  • 2048 - 100,0%
  • 4096 - 99,9%
  • 8096 - 30,5%
  • 16384 - 22,3%
  • We need models that contain huge textures to check engines' behavior. Btw, JPEG dimensions are limited to 65535, and PNG to 4294967295.
  • Maybe, validator should warn on images with dimensions bigger than 4096.
  • Maybe, spec should advice runtimes to rescale too big textures (like NPOT notice).

Vertex attributes

Here're max numbers of vertex attributes according to WebGL Stats:

  • 8 - 100,0%
  • 10 - 100,0%
  • 16 - 30,5%
  • 32 - 22,3%
  • We need models that utilize more than 10, more than 16, and more than 32 vertex attributes per primitive. The simplest way to achieve that is to add lots of active morph targets (each one takes up to three attributes). Also, such models may feature 8 influences per vertex by using JOINTS_1 / WEIGHTS_1.
  • Maybe, validator should warn on exceeding these limits.
  • Maybe, spec should advice exporters not to write more than 16 attributes.

Vertex Uniforms

Here're max numbers of vertex uniform vectors according to WebGL Stats:

  • 128 - 100.0%
  • 251 - 75.7%
  • 253 - 75.6%
  • 254 - 70.4%
  • 256 - 70.3%
  • 512 - 44.1%
  • 768 - 40.8%
  • 1024 - 40.5%
  • 4096 - 17.1%
  • We need models that utilize more than 128 and more than 256 uniforms per primitive. The simplest way to achieve that is to have more than 32 and more than 64 bones per skinned mesh.
  • Maybe, validator should warn on exceeding those limits.
  • Maybe, spec should have some advice on this.

Performance-oriented models

These are less obvious and may be very subjective. Feel free to discuss.

Static

  • A model that challenges maximum number of indexed vertices (i.e. actually using all four bytes of the index buffer elements).
  • A model that features so many instances of the same mesh that the engine has to use hw instancing to get acceptable framerate.

Animations

  • A model with an animation that targets all nodes at once to invalidate cached tree transforms on every frame.
  • Same as previous, but each channel has a separate time input and those inputs are not aligned with each other (so engine is forced to look for proper position in each input or to build some acceleration structure).
  • Same as previous, but sample-rate isn't constant within each input (so an engine may need to resample everything).
  • There should be versions of the examples above with all interpolation modes.
commented

@lexaknyazev good ideas - this will really tighten up the validator/spec.

Sounds like glTF-Asset-Generator will be useful here.

CC @bghgary

commented

Sounds like glTF-Asset-Generator will be useful here.

Sure. @kcoley Can you add this to the roadmap or add an issue?

commented

A "low-hanging" (but nevertheless interesting) challenge that would fall into the "Static" category: Scenes with complex graph structures in general. These could have trivial geometry, to focus on the graph structure itself. I'm thinking of a root node with 10000 children, or a chain of 10000 nodes (with one leaf). But one could certainly argue about whether this can still be considered as a core/realistic use case for glTF.

commented

I would vote that we focus energy on examples that test engine limits rather than hardware limits. For example, assets that may work in Unreal or Unity but are not currently supported in WebGL engines. There doesn't seem to be much benefit from demonstrating limits engines can't do anything about, like 16K textures or 10K draw calls.

For example, I think the Animations and Static sections in the OP are more compelling than the other sections. Also:

  • greater than 16 morph targets, controlled by an animation where <=4 are active at one time. This tests that an engine can optimize to only apply active morph targets. We have many examples of this: mrdoob/three.js#14747
commented

@lexaknyazev @donmccurdy @bghgary : Has this issue been resolved or acted-upon/transferred? If so can it be closed or should it move to glTF-Sample-Assets repo? Default operation is to close this between 20 & 27 November.

commented

This should be transferred.