rebb

You could also try enabling "Adaptive VSync" in the NVidia Driver options. That shouldn't halve framerates when dropping below the thresholds like standard VSync does.

It's not that simple unfortunately. See http://forums.thedarkmod.com/topic/15863-water-and-reflections/

Afaik Sikkpin's fix is not about removing the issue of things in front of a refracted surface being picked up, but about multiple _currentRender using materials overlapping each other. Something like heat-distortion over a refracting water-shader for example. It's likely doing a _currentRender update after every pass of rendering a material that uses _currentRender, but i might be wrong. It would be possible to reject "things-in-front" inside the shader though, with some extra engine changes ( minor ).

It's showing up proper in a different TDM build ? Probably worth looking into that too then. Off-Grid can happen in different ways, non axial clipping for example.

I'm getting a lot of missing faces in the map Ferret posted, including the large missing room part now. I got the large room disappearance fixed, but my approach was different to Ferret's. There are a few very-offgrid brushes that sit on the border of the problem. Moving these back onto the grid ( even just the 0.125 one ) fixed the problem in the large room after a recompile. Haven't checked out the other missing geometry parts yet. However in Quake for example, off-grid geometry is also known to cause Vis problems due to floating point errors, it's something to generally look out for and try avoid as much as possible.

This is the map i got ( many portals ) : temp.map.txt

The "enhanced" interaction shader derives the glossiness part from the color-values of the specularmap, which were normally just driving the specular strength as you mentioned. The non "enhanced" shader does not do this and uses a preset gloss value instead.

Looks like it doesn't play well with special internal image identifiers like _white or _black etc, interesting.

Thinking about it some more it should actually be fine to re-enable it but move the instruction into the right place first, so the shading stays in line with the whole "if something has a high specularmap value, assume that it is also more glossy" idea behind it. # read specular map TEX R2, fragment.texcoord[5], texture[5], 2D; to # read specular map TEX R2, fragment.texcoord[5], texture[5], 2D; MUL R2, R2, program.env[1]; But again, since this shader has been in place for so long, there is the possibility that this may affect other existing materials that have since been authored.

Correction : I was wrong on what actually maps the final power-values - the specular-power values are not based on the specular-multiplier but on the color of the specularmap. So as it is now it looks like the specular multiplier is only ever used for the "is there a specularmap in the material" detection. In the previous shader incarnations it was also used to multiply / color the final specular value down. That means the problem ungoliant is seeing is because the rgb keyword is not doing what is expected when used in a specularmap stage in the material. This also means that the suggestion of using the scale() image function will have the side-effect of broadening the highlight of the specular, since that is derived from the specular-image. Which is technically fine because that's the idea behind the shading system. I don't know what the exact reasoning is behind disabling the multiplier, or how many materials may be affected where rgb-like keywords are used for the specular stages. @SpringHeel : Basically the "rgb" keyword in specular stages does not do what it does in default Doom3. Glossiness and Strength come from the specularmap.

Specular Intensity controls how much of the specular color arrives. Specular Power controls the "size" of the highlight. "Power" because in simple Specular Calculations a Power Function is used, maybe the term "Glossiness" or "Specular Exponent" makes more sense.

As mentioned, above 0.001 it starts mapping between specular power values. 0.002 maps to a very low powervalue. Low power values mean very broad specular highlights. In the case of using _white as the specularmap this means you get a very broad and strong specular. Note : Specular Power != Specular Strength/Intensity It seems that JC Denton has disabled the actual use of the specular multiplier further down in the shader, which would normally cause the final specular to be toned down almost to invisible values when rgb 0.002 is used. That could be re-enabled but may have impacts on other materials that have been authored since JCDenton introduced this shader.

It simply uses the specularmap you provided. Before this piece of code, the specularmap color has been read into R2. CMP chooses between 2 values to assign to the output variable based on whether a certain parameter is less than 0.

There shouldn't be any randomness, it's a function that scales the color-data of an input image creating a new image in memory for the shader to use.

It was a typo, sorry. I meant 0.001. The verdict remains the same. Part of the shader in question : SUB R1, program.env[1], 0.001; # See if there's a specular map for this material CMP R2, R1, .026, R2; # If not then give a constant artifical value as spec.

Why do i even bother

The shader assumes that if the specular-multiplier ( your rgb 0.1 drives this ) value is below 0.1 ( floating point rounding error is probably causing your 0.11111etc value here ), that there is no specular-map at all and it then uses an artificial specular value instead, and not what you were actually supplying as your specular ( _white ). Afaik JCDenton introduced this so that everything has some specular to it. However once you go above that multiplier-value it will fully use what you have supplied as your specular again, while also mapping between preset specular power values. The default Doom3 interaction shader does not do this, it uses the same specular power everywhere. You could try using the scale() image function instead of the rgb keyword, that shouldn't trigger this test. map scale( _white, 0.1, 0.1, 0.1, 0.1 ) So it's not actually an error that is to be fixed, just the way this in-shader test approach works. Something that could be done is lowering the test-value to something below 0.1 but then it's just a question when someone else accidentally sets their rgb value below the new limit.

What is the exact problem again ? What does "full blast" mean in regards to specularity ? Very broad / narrow specular highlight ? Very bright specular highlight ?

Strange, i definitely see a difference when adding these keywords to the material, the parts that were normally "caulked away" show as proper sky after a compile of the testmap. The only artifacts that remain are due to PVS culling. Oh well, maybe the func_static workaround is the better approach in your case.

Dmap apparently uses cached versions of the materials, so it will still have the unedited skyPortal material when you run it again without doing reloadDecls first.

Did you reload the materials ( reloadDecls in console ) and then recompile the map too ?

The skyPortal func_static is just triangles to draw for the engine, caulk doesn't actually draw anything at all and in the case of these "holes in the sky" it seems to write the depth of the void behind it which is used by the fog and causes it to draw a strong fog color value. One thing i'm not entirely sure of is if these func_statics may disappear if the leaf that contains their origin gets closed, or if the engine properly takes the model-bounds into account. Please try the approach with the edited portalSky material too, if that turns out to fix the problem completely then that's the preferred way imo as it requires no in-map workarounds.

It's a very basic example but the basic idea is there - i've edited your attached map again with a similar approach ( this time just using caulk behind the func_static sky parts ). Another thing worth trying would be adding the following keywords to the skyPortal material : noFragment qer_nocarve Then reloading the material and recompiling the map. It causes the skyPortal brush to not be "cut away" where caulk touches it - that may or may not already be enough to fix the problems in your case. sky_fog_caulk3.map.txt

If you have func_statics that physically intersect the sky then that could potentially be a problem with this approach. Small example-map ( it's very artsy ) in the attachments. It has 2 sides of map with the same setup, but one side uses func_static over the skybox. It's just a fast example, this can probably be done much cleaner, possibly by turning the sky behind the func_static skybrushes into caulk. sky_fog_caulk.map.txt