Skip to content

Optimize texture allocation for voxels #12570

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jjhembd opened this issue Apr 15, 2025 · 2 comments
Open

Optimize texture allocation for voxels #12570

jjhembd opened this issue Apr 15, 2025 · 2 comments

Comments

@jjhembd
Copy link
Contributor

jjhembd commented Apr 15, 2025

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:

  1. Allow non-square textures. This would increase the number of possible sizes (for example: 128, 192, 384, 512)
  2. Allow non-power-of-two sizes in a WebGL2 context. This could reduce the amount of padded space around the data.
  3. 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

@Hiwen
Copy link
Contributor

Hiwen commented Apr 15, 2025

WebGL2 is now widely supported, I think Texture3D is an excellent choice.

@Hiwen
Copy link
Contributor

Hiwen commented Apr 26, 2025

@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

Image

Image

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants