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

OpenGL: multiple omni lights render incorrectly #71710

Closed
fracteed opened this issue Jan 20, 2023 · 5 comments · Fixed by #71772
Closed

OpenGL: multiple omni lights render incorrectly #71710

fracteed opened this issue Jan 20, 2023 · 5 comments · Fixed by #71772

Comments

@fracteed
Copy link

Godot version

4.0 beta 13

System information

Windows 10 960m

Issue description

I have noticed that more 3 omni lights will render meshes incorrectly. Initially I thought it might have been a light limit over 8 issue, but increasing it to 16 made no difference.

This is an example of the issue:

omni_8_opengl

This has 8 overlapping omni lights, but it seems like any more than 3 has this kind of incorrect lighting issue. If you toggle on and off random selections of lights in the sample file, there can be seen that some combinations work and some don't.

@clayjohn I am guessing that this is related to the light fix you did for Vulkan recently? I don't usually use opengl in 4.0 but I was trying to use the light limit option to increase it for the vulkan mobile render. Is the opengl light limit render option meant to also work for vulkan mobile?

Steps to reproduce

  • add several plane meshes that butt up against each other
  • add 3 or more omni lights and move them around to see the lighting overlap

Minimal reproduction project

omni_opengl.zip

@Calinou
Copy link
Member

Calinou commented Jan 20, 2023

I don't usually use opengl in 4.0 but I was trying to use the light limit option to increase it for the vulkan mobile render. Is the opengl light limit render option meant to also work for vulkan mobile?

No, it only works for OpenGL. See discussion starting from #70231 (comment) as to why this setting isn't effective on Vulkan Mobile.

@fracteed
Copy link
Author

fracteed commented Jan 20, 2023

@Calinou does that mean an option to increase the limit is not even possible in the future? It seems odd that opengl would have it and not Vulkan mobile, since it is the "higher end" of the 2 renderers.

Or at least some flexibility such as choosing the omni to spotlight ratio. Instead of 8 omnis/8 spots...in my case I only have one spot but lots of omnis. I think you guys are going to find that many people are going to want to use the "mobile" renderer for desktop as well when 4.0 is unleashed. It may very well end up being the most used of the 3 renderers as it has the best performance to feature ratio. I am getting massive gains in the mobile renderer for my game and moving to forward+ just for a few extra few lights is not worth it.

Even if there was a way to have more lights just for specific meshes, like the ground would be useful, since that is where I notice dropouts the most.

@Calinou
Copy link
Member

Calinou commented Jan 20, 2023

does that mean an option to increase the limit is not even possible in the future? It seems odd that opengl would have it and not Vulkan mobile, since it is the "higher end" of the 2 renderers.

Real-time light rendering is expensive on mobile platforms. Lightmaps with fully baked lights should be preferred whenever possible, reserving real-time lights for dynamic effects that can't be created with lightmaps. If you do plan to use real-time lights for everything, you will have to make use of distance fade to ensure the number of lights that need to be rendered at a given time doesn't get too high. (AAA games tend to do this pretty aggressively at lower settings, sometimes while replacing lights with corona sprites in the distance.)

Also, you should split your level into several meshes for culling efficiency reasons anyway. This will allow displaying more lights overall in the scene, since fewer lights will be touching each part of the level.

Or at least some flexibility such as choosing the omni to spotlight ratio. Instead of 8 omnis/8 spots...in my case I only have one spot but lots of omnis.

You can use SpotLights with very wide angles to mimic OmniLights, but only if they don't have shadows.

Regarding customizing the omni-to-spot ratio, I doubt that's feasible without entirely disabling either one of them (or decals/reflection probes, which share similar slots). cc @BastiaanOlij

I think you guys are going to find that many people are going to want to use the "mobile" renderer for desktop as well when 4.0 is unleashed. It

We still intend Forward+ to be the main backend to use on desktop platforms – it will receive optimizations in the future. Using Forward Mobile on desktop is more of a byproduct, and not the main focus of its development.

Some technical decisions in the Forward Mobile backend (such as relying on raster instead of compute and using subgroups) are oriented towards performance on tile-based GPUs, which are only found in mobile devices (and Apple M1/M2). These technical decisions generally have a negative performance impact on GPUs that support compute shaders well and are not tile-based (i.e. desktop/laptop GPUs).

@fracteed
Copy link
Author

I think it would be a mistake to think that most indie devs that use Godot 4 will be wanting the overhead of using the forward+ render. I am getting about 60-70% greater performance between the mobile and forward (with no loss of quality), and most likely many other devs will come to the same conclusion.

I do really hope that features and optimisations are also added to the "mobile" renderer in 4.x as it is very suitable for desktop games that want to target gtx1060 and below performance targets. Unless you really need TAA, GI or some of the screenspace effects it can be hard to justify the performance cost, but hopefully we do see serious performance improvements in the forward + in the future.

@ztc0611
Copy link
Contributor

ztc0611 commented Nov 30, 2023

does that mean an option to increase the limit is not even possible in the future? It seems odd that opengl would have it and not Vulkan mobile, since it is the "higher end" of the 2 renderers.
Or at least some flexibility such as choosing the omni to spotlight ratio. Instead of 8 omnis/8 spots...in my case I only have one spot but lots of omnis.

Putting a +1 on this for what it's worth, I think it is a bad choice to decide for the developer what is best for them. The iPhone 15 can process raytracing and run late-PS4 games. (and Android will not lag far behind) I think they could handle 16 omnilights at once with proper consideration (30fps cap, or only target newest devices). I also think this choice will only age worse with time as mobile devices get more and more powerful. Regardless, in my use case I could live with 16 omnilights and 0 spotlights far easier than a fixed 8 of each.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants