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

godot-llightmap vs official lightmapper #4

Closed
patwork opened this issue May 7, 2023 · 2 comments
Closed

godot-llightmap vs official lightmapper #4

patwork opened this issue May 7, 2023 · 2 comments

Comments

@patwork
Copy link

patwork commented May 7, 2023

Hello,

I have a question for you related to the differences between your project and the official lightmapper. From the examples on youtube, your solution is clearly better at lighting dynamic objects.

In official, it looks as if objects going beyond the radius of the lamps in the scene drastically lose illumination.

No lightmap:
https://i.imgur.com/9U9Ywxf.png

Baked lightmap, dynamic sphere outside omni light radius:
https://i.imgur.com/erllWII.png

Baked lightmap, dynamic sphere inside omni light radius:
https://i.imgur.com/UCMf8Yn.png

Have you looked at how the 'Capture' data is calculated in the official lightmapper? Perhaps your experience could help clarify what the problem is? Voxel octree does not take indirect lighting into account? Or perhaps the propagation between cells is too small?

Related issue:
godotengine/godot#69098

I don't currently see a way to properly light a scene in Godot in a project that will run in a web browser. In Godot 3 you can only use lightmaps in GLES2 with the problem as above, on the other hand in Godot 4 light probes only work under Vulcan.

@lawnjelly
Copy link
Owner

I haven't really looked into how the core lightmapper (in 3.x and 4.x) does light probes, there are probably some bugs, it is more JFons and reduz area. I currently have a lot on my plate for 3.6, and I'm not really keen to spend time investigating core lightmapper as it isn't well geared for low end devices (which is more my interest).

Longterm I'll be aiming to move LLightmap (or similar) into my feature fork of 3.x, so it will be available as an alternative, and perhaps I can make it easier to use if integrated more into the engine (rather than just a module). Also bear in mind LLightmap uses some super shortcuts to make lightprobes super compact in terms of data, and fast at runtime. They don't work perfectly in all scenarios.

If you are struggling, I would suggest use LLightmapper rather than core (in 3.x at least, possibly in 4.x if you get creative) or possibly use a mix of the core lightmapper and lightprobes from LLightmap (you can bake lights in both, but only use the lightprobe file). It's a while since I wrote LLightmap (2-3 years ago) so I can't confirm this will work, but from memory it sounds feasible.

@patwork
Copy link
Author

patwork commented May 7, 2023

Thank you for your response.

I will try to work something out. Good luck with your work on 3.6 :)

@patwork patwork closed this as completed May 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants