Option for automatic BakedLightmap building

[Shfty]

Should be part of the Static Lighting build options. Create BakedLightmap volume based on AABBs.

Ideally should be available in single, per-entity and per-brush flavours, dependent on how the 'build from node' functionality in the BakedLightmap GDScript interface behaves.

Check the Godot source for the default from-node used when invoking a bake from the editor UI. Will probably shed some light on its behaviour re. Node parents breaking it out of the hierarchy.

[kakoeimon]

BakedLightMap overlooks the CullMask of the lights. This means that the light even if it is not assigned to a CullMask it will paint the BakedLightMap. This is maybe the way for us to "bypass" Godot's lighting limitations. I was thinking that BakedLightmap option must have an option "No CullMask" and set the CullMask of the lights to none. Also some lights we may need to be dynamic or just cast shadows on dynamic objects, so we will probably need a flag for this. There is rlights that had been used for something similar in DarkPlaces but I personaly never used it to comment on this but I believe that it adds a layer of complexity that it is not really needed.

[Shfty]

@kakoeimon

BakedLightMap overlooks the CullMask of the lights. This means that the light even if it is not assigned to a CullMask it will paint the BakedLightMap. This is maybe the way for us to "bypass" Godot's lighting limitations.

I'm not sure I understand what you're getting at here? Baked lighting is in and of itself a way to bypass dynamic lighting limitations.

I presume the cull mask is ignored because you can control baked lighting contribution per-light using the Indirect Energy property, and use multiple lightmap volumes to segregate lights per-area and avoid any bleed-through from adjacent rooms.

I was thinking that BakedLightmap option must have an option "No CullMask" and set the CullMask of the lights to none.

What purpose would this serve?

Also some lights we may need to be dynamic or just cast shadows on dynamic objects, so we will probably need a flag for this. There is rlights that had been used for something similar in DarkPlaces but I personaly never used it to comment on this but I believe that it adds a layer of complexity that it is not really needed.

The light import system is intended to ease bringing existing .map files into Godot rather than as a primary lighting pipeline, given the lack of light rendering in Quake editors.

Since .map lights are all baked in Quake (and Godot has fairly stringent dynamic light count restrictions) the current assumed pipeline is as follows:

• Place static lights in the .map file
• Use func_group to split the .map file into per-room entities
• Use a per-entity pipeline to get room meshes into Qodot
  • Splitting like this means ~7 dynamic lights per room, rather than ~7 per map
• Bake .map lights as static in Godot, then hide them in the scene tree to avoid doubling up
• Place any required dynamic lights outside the QodotMap node in your Godot scene

I'm happy to look at improving this and making it more automatic, but care will have to be taken with introducing things like new flags: Since that changes the semantics of the data contained within a .map file, they would have to be tied to the Qodot game preset in TrenchBroom.

Darkplaces' .rtlights file is a similar case- it would have to be implemented as a Darkplaces-specific build step since it covers a single source port rather than the format as a whole.

[kakoeimon]

Ok will follow those rules, thanks.

[Shfty]

This is outside of Qodot's remit, should be left to the user.