[Idea] func_detail_null

[SirYodaJedi]

Or just func_null. An internal entity that has its bmodel written to a separate compiler-only BSP, saving bmodel slots and clipnodes/brushsides for when a brush is only needed by the lighting compiler and not the game proper. The func_detail_null's KVs would be handled however you usually pass func_detail's KVs to the lighting compiler.

Examples of where this would make sense:

• Casting shadows from nothing (see Let misc_model cast shadow? #247 (comment) )
• Using texlights to accentuate the lighting that comes through a window (similar to https://developer.valvesoftware.com/wiki/Window_lighting )
• Texlights that are made to appear like they're cast by models (not of much use for Quake, but useful for compatible higher-fidelity games like Day of Defeat or Condition Zero)

It might be a good idea to still light the extra bmodel alongside the actual map, so that it can affect bouncing when colored bouncing is enabled.

[ericwa]

Implementation wise what I'm thinking of is:

• new (compile-tool private) BSPX lump, EWT_TOOLFACES. meaning "faces that are only intended to be used by the compile tools, not the game".

The format would be:

for i in 0..bsp->nummodels:
    int32_t modeli_firsttoolface;
    int32_t modeli_numtoolfaces;

This lets them be associated with a specifc bmodel if needed; this could come in handy for making switchable shadow bmodels with invisible faces, for example.

The EWT_TOOLFACES lump would be the only place these faces would be referenced in the bsp, so they wouldn't appear in any node's face ranges or marksurfaces/leaffaces lists.

The interpretation of the faces (i.e. whether they cast shadows, bounce light off, etc.) would be out of scope of the EWT_TOOLFACES lump, and would be using our existing mechanism (extended json texinfo).