-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Expose runtime baking functionality in LightmapGI #91676
Conversation
This can only be used in editor plugins or when running an editor build. In an exported project, this functionality is not currently available.
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 |
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).
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 |
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:
Here a packed scene is created and saved to another external I really miss the ability to bake light in map building script. |
Please discuss the feature itself in the proposal, as comments on the pull request should only refer to the implementation. |
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. (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. 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? |
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. |
Expose runtime baking functionality in LightmapGI
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 |
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 🙂 |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
envvars = Variables() | ||
envvars.Add( | ||
BoolVariable( | ||
"lightmapper_rd", | ||
"Enable Lightmapper functionality in export template builds (increases binary size)", | ||
False, | ||
) | ||
) |
There was a problem hiding this comment.
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.
envvars = Variables() | ||
envvars.Add( | ||
BoolVariable( | ||
"xatlas_unwrap", | ||
"Enable xatlas unwrapping functionality in export template builds (increases binary size)", | ||
False, | ||
) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
There was a problem hiding this comment.
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.
@RisingThumb please confirm you have abandoned this PR |
Hi, I'm happy for this PR to be superseded by #94965 |
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 projectsImplementation notes:
environment_bake_panorama
orsky_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.