You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
The CPU lightmapper doesn't have a way to configure how many CPU threads are used. This is problematic when multitasking, since the lightmapper will make background applications or games run slowly or stutter heavily. System audio playback may even stop entirely on some machines when all CPU cores are used up.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add an editor setting to configure how many CPU threads should be used for lightmap baking. This way, the user can find a compromise between system responsiveness and lightmap baking speeds.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
0 (default) uses all CPU threads available.
Positive values specify a number of CPU threads to use.
Negative values subtract from the number of all CPU threads available.
Old percentage-based approach (no longer relevant)
I propose to use a percentage-based approach to choosing the number of CPU cores to use. This adapts well to varying configurations, including CPUs with dozens of threads available. CPUs with high logical core counts (>= 32) generally have worse single-thread performance and are used for multi-tasking more heavily, so freeing up more cores there with the same percentage setting makes sense.
The lower bound is clamped to 1, so there will always be at least 1 thread used even if the percentage is set to 0.0. This can be used to force the lightmapper to run on a single thread for troubleshooting purposes.
Example of CPU thread usage with the value 0.9 on common configurations:
1 logical CPU cores 1 threads
2 logical CPU cores 2 threads
3 logical CPU cores 3 threads
4 logical CPU cores 4 threads
6 logical CPU cores 5 threads
8 logical CPU cores 7 threads
12 logical CPU cores 11 threads
16 logical CPU cores 14 threads
20 logical CPU cores 18 threads
24 logical CPU cores 22 threads
32 logical CPU cores 29 threads
48 logical CPU cores 43 threads
64 logical CPU cores 58 threads
128 logical CPU cores 115 threads
If this enhancement will not be used often, can it be worked around with a few lines of script?
The number of CPU threads used for lightmap baking is currently hardcoded, so no.
Is there a reason why this should be core and not an add-on in the asset library?
See above.
The text was updated successfully, but these errors were encountered:
Is using all of the cores for lightmapping really a problem? I have a 4 core Ryzen 3 1200 and baking lightmaps in Godot never caused any serious performance problem.
Is using all of the cores for lightmapping really a problem? I have a 4 core Ryzen 3 1200 and baking lightmaps in Godot never caused any serious performance problem.
It's a problem if you're looking to do something else remotely demanding while baking lightmaps in the background 🙂
Describe the project you are working on
The Godot editor 🙂
Describe the problem or limitation you are having in your project
The CPU lightmapper doesn't have a way to configure how many CPU threads are used. This is problematic when multitasking, since the lightmapper will make background applications or games run slowly or stutter heavily. System audio playback may even stop entirely on some machines when all CPU cores are used up.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add an editor setting to configure how many CPU threads should be used for lightmap baking. This way, the user can find a compromise between system responsiveness and lightmap baking speeds.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Old percentage-based approach (no longer relevant)
I propose to use a percentage-based approach to choosing the number of CPU cores to use. This adapts well to varying configurations, including CPUs with dozens of threads available. CPUs with high logical core counts (>= 32) generally have worse single-thread performance and are used for multi-tasking more heavily, so freeing up more cores there with the same percentage setting makes sense.
The lower bound is clamped to 1, so there will always be at least 1 thread used even if the percentage is set to
0.0
. This can be used to force the lightmapper to run on a single thread for troubleshooting purposes.Example of CPU thread usage with the value
0.9
on common configurations:If this enhancement will not be used often, can it be worked around with a few lines of script?
The number of CPU threads used for lightmap baking is currently hardcoded, so no.
Is there a reason why this should be core and not an add-on in the asset library?
See above.
The text was updated successfully, but these errors were encountered: