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

Expose runtime baking functionality in LightmapGI #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sourcelocation
Copy link

Hi ReDot community 👋

This PR implements .bake() for script usage on LightmapGI.

Implementation notes:

  • As .exr files cannot be imported at runtime, I save as a .res. This is also because when the lightmapper is available in exported projects, we can use .res files, while we can't save .exr files
  • The radiance changes setting to Radiance 128, and then resetting back to what it was, is because the lightmaps were not generating correctly at runtime using the Scene/Custom Sky environment options. Setting it to 128 fixes this. I am not sure what is causing this, possibly something related to environment_bake_panorama or sky_bake_panorama. There is a related Size2i parameter for this radiance size, but setting that to 256 while using a radiance size of 256 doesn't fix this issue.
  • module_lightmapper_rd_enabled build parameter has to be enabled for runtime baking to work
  • module_xatlas_unwrap_enabled, build parameter has to be enabled for runtime unwrapping to work

Demo video:

352137190-3a768b3d-a05e-4001-9207-d0ef824f93a7.mp4

Project for testing: https://github.com/sourcelocation/lightmapruntimebakingtest/

Originally made for Godot, but their latest decision lead me to contribute to ReDot instead.

@sourcelocation sourcelocation force-pushed the expose-runtime-lightmap-baking branch from 42b4f43 to c811399 Compare September 30, 2024 21:04
@sourcelocation sourcelocation force-pushed the expose-runtime-lightmap-baking branch from c811399 to 87469db Compare September 30, 2024 21:21
@Capewearer
Copy link

Capewearer commented Oct 1, 2024

By the way, could it be used except the case for procedurally generated levels? Like the way to calculate rarely changing dynamic lighting for breakable light sources? E.g. Thief clone, but you have many lights that give indirect lighting, and when one of sources is broken, a lightmap for small part of level is rebaked.
Basically raytracing, but at slow speeds.

@sourcelocation
Copy link
Author

@Capewearer I don't see a reason why not! I'm personally already using it for user generated content, and it works perfectly.

@TheRektafire
Copy link

While we're at it, how hard would it be to add a way to overlay dynamic lights onto a lightmapGI'd surface? Specifically one that's been baked using the "all" bake mode? There are other engines that can mix static baked lighting with dynamic lights (mostly older ones from back when that was more necessary) so it would be nice to mix dynamic direct lighting and static baked lighting in godot as well. Currently I'm pretty sure you can only mix the two if no lights in the scene are set to bake all

Bioblaze added a commit that referenced this pull request Oct 6, 2024
@Redot-Engine Redot-Engine deleted a comment Oct 6, 2024
Bioblaze added a commit that referenced this pull request Oct 7, 2024
Will have errors, but need to see it all pushed to identify the errors to fix.
@sourcelocation
Copy link
Author

Still no merge?

@Spartan322
Copy link
Member

We've been a little busy with the rebranding and preparing a 4.3 release, while I would prefer to try sending PRs upstream to Godot first and see if it languishes or is rejected first, if you feel you don't want to submit anything to Godot in that case, then we'll see about implementing it and minimizing the chance of merge conflicts when we merge the master branch from Godot.

@sourcelocation
Copy link
Author

Awesome. The latter option sounds way better to me 👍

Copy link
Contributor

@SkogiB SkogiB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

Comment on lines +1871 to +1872
#else
SWAP(light_accum_tex, light_accum_tex2);
Copy link
Member

@Spartan322 Spartan322 Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should put a warning for if denoiser somehow equals 1 that the oidn denoiser can only be used in tool builds and that it will only use the JNLM denoiser.

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

Successfully merging this pull request may close these issues.

5 participants