You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #9725, I observed that it would be nice if the (level, x, y, [z]) coordinates from the 3DTILES_implicit_tiling implementation were available in custom shaders.
This should be easy to implement, if the ModelExperimental has a pointer to tile.implicitTileCoordinates, I think this would be implemented by creating an automatic uniform ivec4 with value ivec4(level, x, y, z). Actually... ivec4(x, y, z, level) would be better, then coordinates.x == x, and so on.
Based on the existing limitations with index sizes, the x, y, and z components are under 16 bits, so they could fit in either an ivec4 or vec4
While working on #9725, I observed that it would be nice if the (level, x, y, [z]) coordinates from the
3DTILES_implicit_tiling
implementation were available in custom shaders.This should be easy to implement, if the
ModelExperimental
has a pointer totile.implicitTileCoordinates
, I think this would be implemented by creating an automaticuniform ivec4
with valueivec4(level, x, y, z)
. Actually...ivec4(x, y, z, level)
would be better, thencoordinates.x == x
, and so on.Based on the existing limitations with index sizes, the x, y, and z components are under 16 bits, so they could fit in either an
ivec4
orvec4
@lilleyse @sanjeetsuhag any opinion on which data type to use for this?
The text was updated successfully, but these errors were encountered: