Template:Archived Page History/Warning model lightmaps: Difference between revisions
Jump to navigation
Jump to search
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 RGB888 (24-bit SDR) PPL files which can result in noticeable color banding when brightly lit in HDR mode.Workaround:Warning:Models using $bumpmap cannot receive lightmaps, they will fall back to vertex-lighting based upon the models' origin.
Note:There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader cannot simply use both as there are a dozen technicalities that have to be overcome.
SirYodaJedi (talk | contribs) m (Link to PPL) |
m (some improvement) |
||
| Line 1: | Line 1: | ||
Shows the following warnings: | <noinclude>'''Shows the following warnings:'''</noinclude> | ||
<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!}}<!-- | ||
| Line 9: | Line 10: | ||
-->}}<!-- | -->}}<!-- | ||
-->{{warning|Models using [[$bumpmap]] cannot receive lightmaps, they will fall back to vertex-lighting based upon the models' origin.<!-- | -->{{warning|Models using [[$bumpmap]] cannot receive lightmaps, they will fall back to vertex-lighting based upon the models' origin.<!-- | ||
-->{{note|There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader cannot simply use both as there are a dozen technicalities that have to be overcome. | -->{{note|There is an in-engine check that confirms whether or not the {{ent|$bumpmap}} parameter is defined for a material, a custom shader cannot simply use both as there are a dozen technicalities that have to be overcome. | ||
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> | {{Expand|noborder=1|title=Technical| | ||
If {{ent|$bumpmap}} or {{ent|$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> | |||
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.<br> | 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.<br> | ||
This may be prefered as the static light information is | 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.<br> | ||
No light direction means no bumped lighting from the lightmap. Aka no specular highlights.<br> | No light direction means no bumped lighting from the lightmap. Aka no specular highlights.<br> | ||
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. | 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.}}}}<!-- | 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.}}}}<!-- | ||
-->}}<!-- | -->}}<!-- | ||
--></onlyinclude> | --></onlyinclude> | ||
Revision as of 05:56, 23 February 2024
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 RGB888 (24-bit SDR) PPL files 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 to this accurately.
- 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 based upon the models' origin.Note:There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader cannot simply use both as there are a dozen technicalities that have to be overcome.
|
If $bumpmap or $phong is defined, the engine will not send the lightmap data to the shader. 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. |