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
VoxelPrimitive currently allocates a large Megatexture for each metadata property, which is frequently much larger than the input data (256 MB texture for a 20-30 MB tileset).
The sizing of the texture is constrained by several factors:
The texture is 2D. The 3D metadata is stored in 2D slices.
The texture is required to be square. This results in sub-optimal arrangement of the slices, since tiles can have different sizes along each axis.
The size of the texture is required to be a power of two.
As a result, we are effectively choosing from a very sparse set of tile sizes, i.e., 4, 16, 64, or 256 MB. And with the inefficiencies of the slice arrangement, most real-world tilesets (including small 20-50 MB datasets) will usually allocate the maximum 256 MB texture.
A few peculiarities of the availableTextureMemoryBytes argument in the Megatexture constructor:
The hardcoded maximum 512 MB is actually rounded down to 256 MB because of the requirement to be square.
The default 128 MB is also not a square, so it is rounded down to 64 MB.
Options to improve:
Allow non-square textures. This would increase the number of possible sizes (for example: 128, 192, 384, 512)
Allow non-power-of-two sizes in a WebGL2 context. This could reduce the amount of padded space around the data.
Use 3D textures, and drop support for voxels in WebGL1. This could significantly reduce the amount of unused memory, and potentially also improve rendering times -- see Voxel rendering performance #11086
The first two options would require us to revisit the slice arrangement code, which is somewhat messy. The best ROI might be to jump straight to 3D textures. See #12550
The text was updated successfully, but these errors were encountered:
@jjhembd@ggetz How about we first expand the basic 3D Texture support? And then consider how to modify the rendering of Voxel in the next step?
This only requires modifying two files:
packages\engine\Source\Renderer\createUniform.js
packages\engine\Source\Renderer\createUniformArray.js
And add a new file:
packages\engine\Source\Renderer\Texture3D.js
VoxelPrimitive
currently allocates a largeMegatexture
for each metadata property, which is frequently much larger than the input data (256 MB texture for a 20-30 MB tileset).The sizing of the texture is constrained by several factors:
As a result, we are effectively choosing from a very sparse set of tile sizes, i.e., 4, 16, 64, or 256 MB. And with the inefficiencies of the slice arrangement, most real-world tilesets (including small 20-50 MB datasets) will usually allocate the maximum 256 MB texture.
A few peculiarities of the
availableTextureMemoryBytes
argument in theMegatexture
constructor:Options to improve:
The first two options would require us to revisit the slice arrangement code, which is somewhat messy. The best ROI might be to jump straight to 3D textures. See #12550
The text was updated successfully, but these errors were encountered: