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 #91676

Closed

Conversation

RisingThumb
Copy link

@RisingThumb RisingThumb commented May 7, 2024

This will resolve #59217
This partially resolves godotengine/godot-proposals#8656 . It exposes bake() for scripting, however there isn't any cancelling or aborting yet. Additionally it does not currently work for exported projects. It also works for exported projects

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.
  • Is there a better way of converting from an image to a texturelayered?

This can only be used in editor plugins or when running
an editor build.

In an exported project, this functionality is not currently available.
@RisingThumb RisingThumb requested review from a team as code owners May 7, 2024 19:54
@Calinou Calinou added this to the 4.x milestone May 7, 2024
@jcostello
Copy link
Contributor

In which cases you will bake lightmap in runtime?

@passivestar
Copy link
Contributor

In which cases you will bake lightmap in runtime?

In custom level editors built with godot

Also when reimporting levels in godot while the game is running. Here's me taking advantage of the fact that VoxelGI can be baked at runtime: https://twitter.com/passivestar_/status/1780433192211612039

@RisingThumb
Copy link
Author

RisingThumb commented May 8, 2024

In which cases you will bake lightmap in runtime?

This opens up the opportunity for having a script that goes through all your maps/scenes and baking these lightmaps, rather than doing it in-editor, since the editor process is manual currently. So if you want a lot of high quality lightmaps for a lot of scenes, you can go away and do something else in the meantime. Additionally, it also opens it up for custom map makers in a similar way to Quake, where the lightmaps need to be baked(however this would require additional work for it to work in exports).

Note that bake() will still not work in exported projects, as lightmapping and automatic UV unwrapping (xatlas) functionality is only available in the editor to decrease binary size. bake() will only work in projects run from the editor, as well as the editor itself.

That said this is currently for runtime with the editor, not currently in exported builds(quoted from #59217 ), so it doesn't get us all the way there yet, but at least to the same state Godot 3.X was at which for projects like func_godot, is still very helpful

@nklbdev
Copy link
Contributor

nklbdev commented May 13, 2024

I'm joining the topicstarter.

I'm creating an engine for a game based on Godot, but the maps are outside the resource file system. They are located in the next folder with the executable file. They are created in TrenchBroom (*.map-files). I use my own parser for these files. Not Quodot and not func_godot. To build them, I call the game executable file via the command line:

> game.exe --headless -- build path/to/file.map

Here a packed scene is created and saved to another external *.scn-file. The scene stores the geometry, light, physics and location of the player, monsters, game objects as well as the conditions for switching to another map. The map file does not embed textures, materials and internal details of game objects.
Everything goes fine and after that the scene can be opened and played.

I really miss the ability to bake light in map building script.

@Calinou
Copy link
Member

Calinou commented May 13, 2024

Please discuss the feature itself in the proposal, as comments on the pull request should only refer to the implementation.

@sourcelocation
Copy link

Hi, I tried compiling this fork and I was surprised to find that the exported project (at least the debug build, haven't checked release yet) actually can bake lightmaps into .res file format, however they don't look right. I assume it's due to slice counts. The first screenshot is a lightmap compiled from within the editor, and the second is from the game.

image
image

(Temporarily disabled denoiser)

What leads me to believe this is an issue with slices is the fact that if I change the vertical slice count from 2 to 1, I get a rather similar broken lightmap to the one I got while baking in the game.
image

As there aren't any import options for .res files, I'm not sure what the issue could be here. I want to contribute, I just can't figure out this problem. Do you have an idea by any chance @Calinou?

@sourcelocation
Copy link

Update: I got it working in the exported project here RisingThumb#1. This is my first ever contribution to the Godot's codebase, so probably a lot of things are wrong there. I need some assistance.

sourcelocation and others added 2 commits July 25, 2024 17:21
Expose runtime baking functionality in LightmapGI
@RisingThumb RisingThumb requested a review from a team as a code owner July 26, 2024 21:27
@RisingThumb
Copy link
Author

Thanks @sourcelocation , I've merged your changes into this PR which make it possible to bake at runtime for exported projects into this PR. Also means it addresses the original issue more completely now, as it works for exported projects if module_lightmapper_rd_enabled and module_xatlas_unwrap_enabled are enabled 👍

@sourcelocation
Copy link

When can we expect this PR to be reviewed?

@Calinou
Copy link
Member

Calinou commented Jul 28, 2024

When can we expect this PR to be reviewed?

4.3 is in feature freeze, so new features can only be merged in 4.4 at the earliest.

Also, there are merge conflicts that should be resolved. See Pull request workflow for instructions 🙂

Comment on lines +23 to +24
Bakes lightmaps (requires meshes to have UV2 unwrapped) for [param from_node] and its children to [param image_data_path]. [param image_data_path] must end with an [code].exr[/code] or [code].lmbake[/code] file extension. If [param from_node] is [code]null[/code], lightmaps are baked from the [LightmapGI] node's parent. Baking lightmaps can take from a few seconds to several dozen minutes depending on the GPU speed and quality settings chosen.
[b]Note:[/b] [method bake] only works within the editor, and when running a project from the editor. [method bake] will do nothing when called in a project exported in either debug or release mode. This limitation is in place to reduce the binary size of exported projects.
Copy link
Member

@Calinou Calinou Jul 28, 2024

Choose a reason for hiding this comment

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

Suggested change
Bakes lightmaps (requires meshes to have UV2 unwrapped) for [param from_node] and its children to [param image_data_path]. [param image_data_path] must end with an [code].exr[/code] or [code].lmbake[/code] file extension. If [param from_node] is [code]null[/code], lightmaps are baked from the [LightmapGI] node's parent. Baking lightmaps can take from a few seconds to several dozen minutes depending on the GPU speed and quality settings chosen.
[b]Note:[/b] [method bake] only works within the editor, and when running a project from the editor. [method bake] will do nothing when called in a project exported in either debug or release mode. This limitation is in place to reduce the binary size of exported projects.
Bakes lightmaps (requires meshes to have UV2 unwrapped) for [param from_node] and its children to [param image_data_path]. [param image_data_path] must end with an [code].exr[/code] or [code].lmbake[/code] file extension. If [param from_node] is [code]null[/code], lightmaps are baked from the [LightmapGI] node's parent. Baking lightmaps can take from a few seconds to several dozen minutes depending on the GPU speed and quality settings chosen.
[b]Note:[/b] [method bake] only works within the editor, and when running a project from the editor. [method bake] will do nothing when called in a project exported in either debug or release mode. This limitation is in place to reduce the binary size of exported projects. You can [url=$DOCS_URL/contributing/development/compiling/index.html]compile custom export templates[/url] with the [code]module_lightmapper_rd_enabled=yes module_xatlas_unwrap_enabled=yes[/code] SCons options to remove this limitation.

Comment on lines +8 to +15
envvars = Variables()
envvars.Add(
BoolVariable(
"lightmapper_rd",
"Enable Lightmapper functionality in export template builds (increases binary size)",
False,
)
)
Copy link
Member

@Calinou Calinou Jul 28, 2024

Choose a reason for hiding this comment

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

I'm confused why we need a separate lightmapper_rd option for this, considering we already have module_lightmapper_rd_enabled option that is True by default in editor builds and False by default in export template builds.

See also #73003.

Comment on lines +8 to +15
envvars = Variables()
envvars.Add(
BoolVariable(
"xatlas_unwrap",
"Enable xatlas unwrapping functionality in export template builds (increases binary size)",
False,
)
)
Copy link
Member

Choose a reason for hiding this comment

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

Same as above.

Choose a reason for hiding this comment

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

Will work on it! Thanks.

@AThousandShips
Copy link
Member

@RisingThumb please confirm you have abandoned this PR

@RisingThumb
Copy link
Author

Hi, I'm happy for this PR to be superseded by #94965

@AThousandShips AThousandShips removed this from the 4.x milestone Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants