Skip to content
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

Voxel light-emission rendering #390

Closed
3 of 4 tasks
kpreid opened this issue Aug 28, 2023 · 3 comments
Closed
3 of 4 tasks

Voxel light-emission rendering #390

kpreid opened this issue Aug 28, 2023 · 3 comments
Labels
kind: incomplete A feature is partially implemented; the current state of the code is inconsistent

Comments

@kpreid
Copy link
Owner

kpreid commented Aug 28, 2023

Commit 761b4b1 revised the world model so that light emission is a property of individual Atoms rather than BlockAttributes, so recursive blocks can be partially lit. However, this is currently only interpreted by light propagation (and that in a non-directional way), not for renderers. Tasks:

  • Implement in raytracer. (Code is pushed in commit 39f8db0, but disabled for now.)
  • Implement in wgpu renderer. Preferably without allocating twice the texture space, but that would require being able to split meshes by material (which would be useful, but hairy).
  • Implement in glTF export; ditto regarding texturing.
  • Update example content as needed so it looks right under these new conditions.
@kpreid kpreid added the kind: incomplete A feature is partially implemented; the current state of the code is inconsistent label Aug 28, 2023
@kpreid
Copy link
Owner Author

kpreid commented Nov 3, 2023

Preferably without allocating twice the texture space, but that would require being able to split meshes by material (which would be useful, but hairy).

From discussion with Ralith on the Rust GameDev Discord server: Note that we don't have to entirely split meshes and use separate draw calls. We can just have multiple bound textures, and store in the vertices an index of which texture set, if any, to use, like so:

  • 0 = use vertex color
  • 1 = use (reflectance atlas 0, constant emission zero)
  • 2 = use (reflectance atlas 1, emission atlas 1)

My other idea prior to this was to indirect through a table of texture coordinate offsets, so that the emissive data could be written to the same texture in a different location; that would have the advantage of fewer textures and supporting things like defragmenting the texture atlas, but is likely to cost more.

@kpreid
Copy link
Owner Author

kpreid commented Nov 5, 2023

As of commit 2e9f6c6 we have a plan for how to allocate textures as above, by having the mesher tell the allocator what Channels are needed.

Next steps:

  • Have the allocators actually allocate separate textures (and designate them in the vertex coordinates)
  • Implement emission in the shaders
  • Have the mesh generation switch to textures even for simple blocks if there is an emission value (this way, we don't need two vertex colors).

@kpreid
Copy link
Owner Author

kpreid commented Nov 8, 2023

As of commit a2fd653, emission rendering is active. It is not yet implemented in the glTF export, but since texturing is still generally a work in progress there, I'm going to call this done.

@kpreid kpreid closed this as completed Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: incomplete A feature is partially implemented; the current state of the code is inconsistent
Projects
None yet
Development

No branches or pull requests

1 participant