increase morph targets to 256 #21421
Conversation
robtfm
force-pushed
the
more-morph-targets
branch
from
979ab11 to
d72f486
Compare
alice-i-cecile
added
A-Rendering
|
This is very controversial: see the discussion in #21256 and the objections from @james7132. I agree that we need to allow users to lift this, but y'all need to come to a consensus about the best approach forward. |
alice-i-cecile
added
S-Needs-Design
|
it looks like the controversial aspect was exceeding 64kb uniform buffer size, i don't believe we'd do that until we went past 16384 max morph targets (@james7132). apologies if i'm missing something. |
alice-i-cecile
added
S-Needs-Review
|
The core limitation for morph targets is the texture array layer limit, which defaults to 256, so I think this bump is probably OK, albeit as I've mentioned here, I think we should dynamically set these limits based on what's observed by wgpu. Unity's approach is to use compute shaders to compute morph targets offsets on platforms that support it, which we can probably consider enabling for platforms that support them. |
Objective
our current morph target / blend shape limit is 64 per model, documented as "to support all hardware". many assets use more than this ("over a hundred" is common), so i'd like to increase this limit.
the relevant hardware constraint is uniform buffer size (usage in morph.wgsl). morph targets use 4 bytes per entry, and wgpu's downlevel uniform buffer size limit is 16k so we have a lot of room from the 256 bytes we are currently limiting to, while still supporting the vast majority of hardware.
Solution
increase the limit to 256 targets / 1k.
we also increase the input to the buffer to this 1k size: this was not done previously but worked as long as the min buffer alignment was 256 (which it probably always is at the moment) as it was sized up to match alignment previously.
there may be a slight performance impact from using a larger size in all cases but it should be negligible.