User:SirYodaJedi/Source map compiler wishlist: Difference between revisions
Jump to navigation
Jump to search
SirYodaJedi (talk | contribs) m (→RAD) |
SirYodaJedi (talk | contribs) m (→RAD) |
||
Line 48: | Line 48: | ||
* {{code|%CompileIgnoreNormals}} [[material map compile flag]], like the equivalent [[static prop]] lighting flag (on both brushes/disps and MDLs) | * {{code|%CompileIgnoreNormals}} [[material map compile flag]], like the equivalent [[static prop]] lighting flag (on both brushes/disps and MDLs) | ||
* In a similar vein, {{code|%CompileNoSelfShadowing}}, which prevents surfaces with the given material from receiving shadows cast by another surface with the same material (on both brushes/disps and MDLs) | * In a similar vein, {{code|%CompileNoSelfShadowing}}, which prevents surfaces with the given material from receiving shadows cast by another surface with the same material (on both brushes/disps and MDLs) | ||
* {{ent|light_rect}}; rename to {{ent|light_spot}} after compiling to keep compatible with I/O. |
Revision as of 19:42, 22 May 2024
Features I'd like to see in custom compilers for ,
, and
BSP / CSG
- Everything from
Mapbase's VBSP
- Generate a file alongside the BSP (or in the zip lump) containing KVs for func_group, func_detail, and prop_static, for use with VRAD.
- The brushes would be stored as a comma-delimited list of brush numbers, indicating which brushes are in the group.
- KVs which are used by the static prop lump are stripped, along with targetname, mindxlevel, and maxdxlevel, and any KVs which are only used by VBSP.
- func_group
- _contents KV in all brush entities (along with func_group and func_detail), which overrides the contents of contained brushes which would otherwise be CONTENTS_SOLID (ex: for grates using CONTENTS_GRATE, stairs using CONTENTS_DEBRIS, or nonsolid func_train using CONTENTS_EMPTY).
- _illusionary KV on func_detail which disables generation of brushsides for the given brushes, resulting in the geometry being purely visual and not having any collision whatsoever (ex: for foliage). This would be cheaper than CONTENTS_EMPTY, since it doesn't eat up brushsides, but probably would be buggy on entities.
- func_illusionary_visblocker like in ericw-tools - A world brush that blocks vis but is non-solid.
- detaillevel KV for func_detail, which affects how it would chop or get chopped by other brushes. 0 = vanilla behavior; 1 = chopped by world, chops all else; 2 = chopped by world and level 1, chops all else; etc.
- Ability to toggle
Quake II-style detail brush behavior for func_detail (in a KV), wherein it still chops underlying world brushes, even though it doesn't affect VIS. This fixes some lighting bugs caused by the world brush lightmap bleeding underneath the func_detail, at the expense of additional drawn faces.
- This could be done by setting the aforementioned detaillevel KV to -1.
- You can manually do this with nodraw brushes on stock compilers, but that eats up more brushsides.
- Ability to set DeathByNukes's (also in
) %compileChopHigh, %compileChopLow, and %compileChopAll settings directly in func_group and func_detail's KVs, so that the same material can have different chop settings in different situations (improving runtime performance). Useful for coolanar brushwork.
- _origin KV, which replaces the origin KV once BSP is finished. Useful for shifting entities by microscopic amounts (ex: 0.0625).
VIS
- Rename
vvis_dll.dll
to allow installation alongside vanilla compilers.
RAD
- Rename
vrad_dll.dll
to allow installation alongside vanilla compilers. - 64-bit executable, regardless of whether engine is 64-bit
- bounced prop_static lighting (bouncing both ways between props and lightmaps); this would be really beneficial on lightmapped props
- Ability to select texture format for PPL files:
- Recommended formats to allow:
- This could possibly be noted by using lightmap resolutions higher than 4096 (reading the three most significant bits as a separate value, with 0 being the default RBG888).
- Alternatively, unused static prop flags could be used, but VBSP would need to be modified to properly write them.
- Or just use the extra data I suggested writing in VBSP.
- _nobounce KV on lights, which disables bounced lighting from the light source.
- _nodirect KV on lights, which prevents direct lighting from the light source from being written to the lightmaps.
- _nodynamic KV on lights, which prevents the light source from affecting dlights.
- bounced named lights (could also have radius-based control over how far they are allowed to bounce)
- toggleable shadows for brush entities, handled in a similar manner VHLT's light_shadow (so they'd be controlled by a regular light entity in-game)
- toggleable texlights, handled in a similar manner VHLT's light_surface (so they'd be controlled by a regular light entity in-game)
- %lightmapmask for VertexLitGeneric, which dictates locations of the PPL lightmap to mask out and replace with a dialation fill like xwad does for index 255 of transparent textures.
- An equivalent to ericw-tools's -dirtdebug command, which disables standard lighting and only puts generic ambient occlusion on edges to prevent the unsealed fullbright map from looking bad.
- Colored texture shadows.
- Texture shadows from Refract materials.
- _minlight on prop_static, func_group, and func_detail
- _maxlight wherever _minlight is available
- _minlight_color and _maxlight_color, which control the color of _minlight and _maxlight
- %CompileMinLight, %CompileMaxLight, %CompileMinLight_Color, and %CompileMaxLight_Color material map compile flags, which function like the equivalent KVs, but on a per-material basis.
- Half Lambert flag for per-vertex and lightmapped static props
- %CompileIgnoreNormals material map compile flag, like the equivalent static prop lighting flag (on both brushes/disps and MDLs)
- In a similar vein, %CompileNoSelfShadowing, which prevents surfaces with the given material from receiving shadows cast by another surface with the same material (on both brushes/disps and MDLs)
- light_rect; rename to light_spot after compiling to keep compatible with I/O.