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
As my scene grown complex VoxelGI started showing some weird behaviour.
In editor VoxelGI appears way too bright, and in game - "normal amount".
At first I worked almost 3 weeks on a scene thinking "VoxelGI is just exaggerated in the editor, should keep checking lighting at runtime after scene changes".
To my horror, I noticed something today. Just for the sake of experiment while playing the scene I unchecked and checked VoxelGI node visibility in the editor.
It appears, VoxelGI was not even turned on at runtime (despite the fact that it is visible in editor in local and remote tabs, eye icon is lit). Only unchecking and checking in editor, while game was up, connected to the editor, I learned that I worked on a "usual" lighting without VoxelGI all that time!
No errors in console, nothing. At the moment I have 300+ objects when VoxelGI is baking, it takes approximately 3-4 seconds to bake. Objects of a different size.
Only baking at runtime or checking in editor while game is up - helps.
Video of me baking manually in code at runtime, difference is visible (freeze is the moment of baking at runtime):
This seems like some kind of elusive bug, since there are no errors in the console. I hope someone else would have more information about this behaviour (to confirm it), and at the moment all I can do is bake at runtime.
Workaround:
Place this script on VoxelGI:
extendsVoxelGI# Called when the node enters the scene tree for the first time.func_ready():
get_tree().create_timer(2.0).connect(
"timeout",
func():
print("Making GI visible!")
self.bake()
)
Steps to reproduce
Unfortunately I cannot give steps to reproduce, since it happens only in my scene and basically you will need to do a lot of different kind of actions to achieve the problematic behaviour.
Minimal reproduction project
Again, I can't give minimal reproduction project. I tried to reproduce it with new scene and CSGBoxes, a lot of them - no luck.
The text was updated successfully, but these errors were encountered:
Godot version
4.0.3, 4.1 beta 3
System information
macOS Ventura 13.0
Issue description
As my scene grown complex VoxelGI started showing some weird behaviour.
In editor VoxelGI appears way too bright, and in game - "normal amount".
At first I worked almost 3 weeks on a scene thinking "VoxelGI is just exaggerated in the editor, should keep checking lighting at runtime after scene changes".
To my horror, I noticed something today. Just for the sake of experiment while playing the scene I unchecked and checked VoxelGI node visibility in the editor.
It appears, VoxelGI was not even turned on at runtime (despite the fact that it is visible in editor in local and remote tabs, eye icon is lit). Only unchecking and checking in editor, while game was up, connected to the editor, I learned that I worked on a "usual" lighting without VoxelGI all that time!
No errors in console, nothing. At the moment I have 300+ objects when VoxelGI is baking, it takes approximately 3-4 seconds to bake. Objects of a different size.
Only baking at runtime or checking in editor while game is up - helps.
Video of me baking manually in code at runtime, difference is visible (freeze is the moment of baking at runtime):
https://imgur.com/a/25KSZ4X
This seems like some kind of elusive bug, since there are no errors in the console. I hope someone else would have more information about this behaviour (to confirm it), and at the moment all I can do is bake at runtime.
Workaround:
Place this script on VoxelGI:
Steps to reproduce
Unfortunately I cannot give steps to reproduce, since it happens only in my scene and basically you will need to do a lot of different kind of actions to achieve the problematic behaviour.
Minimal reproduction project
Again, I can't give minimal reproduction project. I tried to reproduce it with new scene and CSGBoxes, a lot of them - no luck.
The text was updated successfully, but these errors were encountered: