|
|
| (15 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| Shows the following warnings:
| | {{APH|template:warning model lightmaps}} |
| <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|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]]).}}<!--
| |
| -->}}<!--
| |
| -->{{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 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.<!--
| |
| -->{{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>
| |
| 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>
| |
| 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>
| |
| 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.<br>
| |
| <br>
| |
| 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>
| |
Note:Archived rest of page history of page template:warning model lightmaps
Important:These pages are linked often from page history logs so Special:WhatLinksHere will not show anything.