-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
Comments
No, it only works for OpenGL. See discussion starting from #70231 (comment) as to why this setting isn't effective on Vulkan Mobile. |
@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. |
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.
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
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). |
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. |
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. |
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:
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
Minimal reproduction project
omni_opengl.zip
The text was updated successfully, but these errors were encountered: