User:SirYodaJedi/Source map compiler wishlist

Features I'd like to see in custom compilers for , , and

See also:  /FGD

BSP / CSG

Note:I am working on a custom fork of VBSP, named YBSP, which will have some of the easier features to implement found here.

• Everything from Mapbase's and DeathByNuke's VBSPs
• 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
• Don't CSG coplanar brushes to prevent Z-fighting when at least one of the materials on said brushes has $decal, as that command prevents the Z-fighting to begin with.
  • Or perhaps a func_decal that acts like a func_detail which keeps all geometry even if it would've been CSGed (and sets contents to CONTENTS_EMPTY).
    • As well as a %CompileNoCSG VMT parm that acts the same way.
• _contents KV in all brush entities (along with func_group, func_detail, and func_ladder), 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 %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 coplanar brushwork.
• _origin KV, which replaces the origin KV once BSP is finished. Useful for shifting entities by microscopic amounts (ex: 0.0625).
• _origin_offset KV, which offsets the origin KV once BSP is finished. Useful for shifting entities by microscopic amounts (ex: 0.0625).
• _noportal, _nodecal, _nodraw, and _nolight KVs that set the applicable surface flags for all faces on the brush entities (including func_group, func_detail, and func_ladder)
• Flag func_ladder as detail unless it would also have CONTENTS_TRANS (Visleaves are used for alpha sorting; offer an additional KV, like force_detail, to always make ladders detail.)
• Don't create unused info_ladder unless keep_info_ladder is enabled.
• _nobmodel KV on brush entities to write mins and maxs KVs indicating the bbox, instead of creating a bmodel for the entity (useful for func_team_wall).
• Merge the brushwork used by unnamed func_null entities which do not have any KVs that start with _ or vrad into a single bmodel, reducing MAX_MAP_MODELS usage.
• _clone and _clonename, like NetRadiant-Custom's Q3Map2.
• _use_lightmap KV for prop_static, which takes a VTF, converts it to PPL (with correct number of LoDs if necessary), and embeds it in the map with the correct filename. This should tick the "no per-texel lighting" flag, so that it doesn't get overwritten by VRAD (the engine doesn't care about the flag).

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:
    • RGB888 (default), RGBA16161616F, DXT1, I8, BGR565, BGRA8888 (RGBM-compressed HDR), DXT5 (RGBM-compressed HDR)
    • BC6H (default), BC7, RGBX8888, RGBA8888 (RGBM-compressed HDR), RGBA16161616F, DXT1, ATI1N, I8
  • 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.
• Support lightingorigin KV on brush entities, like light_origin in GoldSrc.
• _nobounce KV on lights, which disables bounced lighting from the light source.
• _nodirect KV on lights, which prevents direct lighting from being written to the lightmaps.
• _nodynamic KV on lights, which prevents the light source from affecting dlights.
• _onlydynamic KV on lights, which makes the light only affect dlights (like Quake III lightJunior)
• 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.
• %lightmap_normalmap for VertexLitGeneric, which acts like Q3Map2's q3map_normalImage, baking the normal map lighting information into the PPL lightmap.
• 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)
• %CompileNoCastSunlight, which if found in a material for a surface with SURF_SKY or SURF_SKY2D, prevents the given surface from casting sunlight.
• %CompileLightTwoSided, which makes a face receive light from both frontfaces and backfaces. If undefined, defaults to on for $nocull.
  • %CompileLightTwoSided_Bias (default 0.5), only applied if %CompileLightTwoSided present. If greater than 0.5, the face will receive more light from its frontfaces. If less than 0.5, the face will receive more light from its backfaces. Like VHLT's info_translucent.
• light_rect; rename to light_spot after compiling to keep compatible with I/O.
• func_sunlight; like light_environment, but as a pseudo-brush entity; only casts the defined lighting from sky brushes within the brush's boundaries.
• _targetname on lighting entities, which acts the same as targetname. This would reduce edict usage in the compiled map when having multiple lights with the same name, as you would only have one light entity that has targetname, while the rest would have _targetname.