Template:Archived Page History/Warning model lightmaps: Difference between revisions
SirYodaJedi (talk | contribs) (Collapse technical workaround mambo jumbo) |
ShiroDkxtro2 (talk | contribs) m (Clarifications) |
||
| Line 2: | Line 2: | ||
<onlyinclude><!-- | <onlyinclude><!-- | ||
-->{{warning|Models use the same UVs for lightmaps as [[$basetexture]]; as such, lightmapping on models with overlapping or tiling UVs may not appear as intended!}}<!-- | -->{{warning|Models use the same UVs for lightmaps as [[$basetexture]]; as such, lightmapping on models with overlapping or tiling UVs may not appear as intended!}}<!-- | ||
-->{{warning|Lightmaps for models with multiple materials do not compile properly in [[VRAD]]! | -->{{warning|Lightmaps for models with multiple materials do not compile properly in [[VRAD]]! A lightmap will only be compiled for the first material on the model, that is a combined version of all the UV's used by all materials.<!-- | ||
-->{{workaround|Define a pre-baked {{ent|$lightmap}} in the [[VMT]] of the [[VertexLitGeneric]] material (can be obtained using {{code|-dumppropmaps}} in [[VRAD]]).}}<!-- | -->{{workaround|Define a pre-baked {{ent|$lightmap}} in the [[VMT]] of the [[VertexLitGeneric]] material (can be obtained using {{code|-dumppropmaps}} in [[VRAD]]).}}<!-- | ||
-->}}<!-- | -->}}<!-- | ||
-->{{warning|Model lightmaps generated with [[VRAD]] are compiled as RGBX8888, which can result in noticeable color banding when brightly lit in HDR mode.<!-- | -->{{warning|Model lightmaps generated with [[VRAD]] are compiled as RGBX8888, which can result in noticeable color banding when brightly lit in HDR mode.<!-- | ||
-->{{workaround|<ul><li>Define a pre-baked | -->{{workaround|<ul><li>Define a pre-baked RGBA16161616f {{ent|$lightmap}} in the [[VMT]] of the [[VertexLitGeneric]] material. A custom-coded compiler would be required for this.<li>Increase lightmap resolution (results may vary).<li>Move light source further away from the lit surface.</ul>}}<!-- | ||
-->}}<!-- | -->}}<!-- | ||
-->{{warning|Models using [[$bumpmap]] cannot receive lightmaps, they will fall back to vertex-lighting.<!-- | -->{{warning|Models using [[$bumpmap]] cannot receive lightmaps, they will fall back to vertex-lighting.<!-- | ||
-->{{note|There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader | -->{{note|There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader can not simply use both as there are a dozen technicalities that have to be overcome.<br>{{Expand|noborder=1|title=Technical| | ||
If $bumpmap or $phong is defined, the engine will not send the lightmap data to the shader.<br> | If $bumpmap or $phong is defined, the engine will not send the lightmap data to the shader.<br> | ||
For $bumpmap, a workaround for this is to use a differently named parameter. ( $NormalTexture ) to get the normal map and undefining $bumpmap.<br> | For $bumpmap, a workaround for this is to use a differently named parameter. ( $NormalTexture ) to get the normal map and undefining $bumpmap.<br> | ||
Revision as of 08:49, 29 December 2023
Shows the following warnings:
Warning:Models use the same UVs for lightmaps as $basetexture; as such, lightmapping on models with overlapping or tiling UVs may not appear as intended!Warning:Lightmaps for models with multiple materials do not compile properly in VRAD! A lightmap will only be compiled for the first material on the model, that is a combined version of all the UV's used by all materials.
Workaround:Define a pre-baked $lightmap in the VMT of the VertexLitGeneric material (can be obtained using -dumppropmaps in VRAD).Warning:Model lightmaps generated with VRAD are compiled as RGBX8888, which can result in noticeable color banding when brightly lit in HDR mode.Workaround:- Define a pre-baked RGBA16161616f $lightmap in the VMT of the VertexLitGeneric material. A custom-coded compiler would be required for this.
- Increase lightmap resolution (results may vary).
- Move light source further away from the lit surface.
Warning:Models using $bumpmap cannot receive lightmaps, they will fall back to vertex-lighting.
Note:There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader can not simply use both as there are a dozen technicalities that have to be overcome.{| class="mw-collapsible mw-collapsed" style="background:transparent ;float:no;margin-bottom:1em;margin-left:0;padding-right:0.5em;"
|+ style="text-align:left; white-space:nowrap; font-weight:bold; color:#ddd; " | Technical
|
If $bumpmap or $phong is defined, the engine will not send the lightmap data to the shader.
For $bumpmap, a workaround for this is to use a differently named parameter. ( $NormalTexture ) to get the normal map and undefining $bumpmap.
However no static lighting data can be received by the shader, if the $bumpmap parameter is not set to anything. This refers to lights that are not named and are not inherently dynamic.
This may be prefered as the static light information is ALREADY prebaked in the lightmap, however it means you cannot receive direction information from the lights.
No light direction means no bumped lighting from the lightmap. Aka no specular highlights.
A fix for this would be modifying VRAD to spit out a lightmap that is *2 the size on the U axis and then storing an average light direction there or doing some other smart technique to 'memorize' light directions.
This in-engine check also exists for $phong, however getting around the issue is more tricky. The default value of the integer parameter will be 0 even if not set in the vmt. Thus making $phong always be defined in a way.