Is it possible to add dynamic lights in large dynamic world?

[blockspacer]

Can we support a lot of moving lights in large dynamic world (like lights from torches, vehicles e.t.c.)?

Godot uses forward renderer, so it can`t handle a lot of dynamic lights. https://godotengine.org/article/godot-3-renderer-design-explained

1 Can we apply some optimizations (light blending e.t.c.?) 2 How to handle moving lights passing through dynamic objects? https://github.com/godotengine/godot/issues/26838

Other solutions:

• Change renderer pipepline in godot to deferred shading.

The reason we chose deferred shading instead of deferred lighting or forward rendering was mainly due to the large number of dynamic lights we had to support in-game and also because the amount of geometry rendered which prohibited us from rendering it more than once. From https://interplayoflight.wordpress.com/2015/04/08/the-rendering-technology-of-skysaga-infinite-isles/

It it possible to modify godot`s pipepline?

• Use Minecraft-like lights. https://0fps.net/2018/02/21/voxel-lighting/ That solution can handle only small amount of lights. Can we combine it with godot lights?

[Zireael07]

I believe this is a wrong place to ask those questions. FYI, work is underway to change Godot engine to Vulkan, which should not have those limitations any longer.

[blockspacer]

I believe this is a wrong place to ask those questions. FYI, work is underway to change Godot engine to Vulkan, which should not have those limitations any longer.

Vulkan can`t support wasm(web/js), so Godot may have those limitations for very long time.

Anyway, is it possible to use godot_voxel in games with dynamic terrain that must have some lights (like Minecraft) or we must change game engine?

[TokisanGames]

I don't know anything about minecraft.

This scene has 500 omnilights in it (one in each sphere which is there just to show the location) and runs at over 150fps @1080p on a GTX1060.

This has 170 lights spread out more so they illuminate the terrain. The large spheres are bullets, physics objects, not lights. Though they are colored themselves, you can see the colors of the lights reflect off them. This runs at over 200fps @1080p.

288 lights at 180fps on blocky.

Here I have 50 lights attached to my player and maintained over 100fps while running around. My shader does wierd things and each chunk takes on a different hue, but that's a different problem. At 100 lights attached to my player I could get 40fps while moving. Once I stopped moving fps went back up.

[afonsolage]

I'm adding voxel lighting to this engine like Minecraft. Since my interest is the blocky world, I'm using a Flood Fill algorithm, like this one.

I plan to make a PR to add it to godot_voxel, but probably I'll have to wait for separation between blocky and smoothy terrains #41 . Anyway, you can checkout my fork, but it is still under development.

[Zylann]

About the issue overall, this module is definitely not dealing in any way with dynamic lighting. That's Godot's job to support that. The only kind of lighting that could be provided here would be derivatives of baked lighting, like the one Minecraft does. I never thought about an architecture for this as I'm focusing on other areas at the moment.

@afonsolage In theory you could already test lighting with a custom generator, which would produce lit blocks when invoked. I haven't read this article yet though, I'm curious how you would handle removal of point lights. I see you use an additional processing thread, do you think it could be part of the updater one on edition? Or it has different requirements?

[afonsolage]

What you mean by custom generator? Streams?

The reason why I created a new processing thread is because it's a different and isolated work, which can be done in parallel, but before the updater. I'm changing the blocky flow to become: LOAD -> SPREAD LIGHT -> UPDATE MESH.

But it can be part of the updater, as longer it runs before the mesh processing, since it produces the color data of vertices.

I tough it would be a good idea to have a processor for each specialized parallel work, because I'm assuming each processor is a green thread.

[Zylann]

Makes sense. I'm not familiar with the green thread term, but BlockThreadManager is just a utility to run an actual thread, or more than one. There isn't any thread pool magic, so there is a chance of thread starvation if too many of them are running. Also, I'm doing a change to BlockThreadManager currently, to make processors accept an array of inputs and outputs so they have a chance to batch some operations.

[blockspacer]

Another approach

According to https://dev.gamedev.net/forums/topic/702924-what-gi-is-usable-right-now/

You can handle doors/windows in other ways. Have two versions of lightprobes near doors/windows with one for open and one for closed, or raytrace only probes that are near doors/windows with only geo primitives, and only when those doors/windows open/close, or etc.

May require ddgi support, that can be built from VCT. (For now Godot uses VCT) https://github.com/godotengine/godot/issues/31405

[blockspacer]

Thanks for responses. Issue resolved.

It is possible to use Godot and godot_voxel in games with dynamic terrain that must have some lights.

[TokisanGames]

Ok. Go ahead and close the issue. Thanks.

[Zylann]

Closing as the issue asks for dynamic lights wich is not the job of this module. Baked lights might be, so if needed please open another issue (although @afonsolage is already working on a baked light system).