Jump to content
The Dark Mod Forums

rebb

Active Developer
  • Content Count

    716
  • Joined

  • Last visited

  • Days Won

    3

rebb last won the day on July 15 2010

rebb had the most liked content!

Community Reputation

13 Neutral

About rebb

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. 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.
  2. It's not that simple unfortunately. See http://forums.thedarkmod.com/topic/15863-water-and-reflections/
  3. 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 ).
  4. 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.
  5. 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.
  6. This is the map i got ( many portals ) : temp.map.txt
  7. 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.
  8. Looks like it doesn't play well with special internal image identifiers like _white or _black etc, interesting.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...