Open jamie-pate opened 3 years ago
Calinou
commented
3 years ago This lighting restriction is supposed to be removed in the Vulcan renderer, but will also it be removed from the OpenGL renderer for 4.0?
Yes, as any OpenGL renderer that will be implemented in 4.x will use multi-pass lighting to make the renderer more compatible with mobile/Web graphics drivers. Multi-pass lighting is slower, but it won't have a limitation on the number of lights you can apply per mesh.
Calinou
commented
1 year ago @jamie-pate Are you still running into limitations with light count when using GridMaps? This should be much less frequent in 3.3 and later, now that you can use 32 lights per mesh resource (by default) in GLES3.
The 8 OmniLights + 8 SpotLights per mesh resource limitation is still present in the Vulkan Mobile backend, but given that backend's focus on low-power devices, it may not be a good idea to use a lot of lights with GridMap there.
jamie-pate
commented
1 year ago 3.3 resolved my headroom issues with the number of lights.
On Mon., Jan. 23, 2023, 8:58 a.m. Hugo Locurcio, @.***> wrote:
@jamie-pate https://github.com/jamie-pate Are you still running into limitations with light count when using GridMaps? This should be much less frequent in 3.3 and later, now that you can use 32 lights per mesh resource (by default) in GLES3.
The 8-lights-per-mesh-resource limitation is still present in the Vulkan Mobile backend, but given that backend's focus on low-power devices, it may not be a good idea to use a lot of lights with GridMap there.
— Reply to this email directly, view it on GitHub https://github.com/godotengine/godot-proposals/issues/1824#issuecomment-1400671300, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFGVIU4DXFHXW4IGAAKUBLWT22BPANCNFSM4TTWC57Q . You are receiving this because you were mentioned.Message ID: @.***>
Describe the project you are working on: An office layout that uses gridmaps to draw the walls, floors and ceilings
Describe the problem or limitation you are having in your project: Trying to light the space is a nightmare because the octant sizing is not clear. The current 3.2.3 GLES3 renderer places restrictions on the number of lights that can be used for each VisualInstance, and the GridMap node groups tiles by octant size to send them to the VisualServer, but none of this information is presented to the designer.
Describe the feature / enhancement and how it helps to overcome the problem or limitation: Toggle or permanently show a gizmo that visualizes the octant size as it's calculated based on the cell size and octant size settings. This would allow designers to easily visualize how many lights may be placed in one area, and how the engine is grouping the tiles they placed.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: The Editor would gain a new gizmo 'Gridmap Octants' which can be shown/hidden based on gridmap selection etc. The gizmo would draw cubes for each octant so that designers can easily see the boundaries and the effect of changing the cell size and octant size.
If this enhancement will not be used often, can it be worked around with a few lines of script?: It possibly could be implemented as a plugin which adds a new gizmo.
Is there a reason why this should be core and not an add-on in the asset library?: It would be useful for anyone using GridMaps, especially with the current 3.2 limitation on the number of lights allowed to affect the single MultiMeshInstance that's created for each octant. This lighting restriction is supposed to be removed in the Vulcan renderer, but will also it be removed from the OpenGL renderer for 4.0? It'd also be a great way to visualize the complexity of the gridmap because it's currently difficult to guess what happens when you change cell size and octant size without reading the engine source code.