Quote from FourthReaper on April 12, 2012, 2:38 pm

I don't think you'll like this suggestion, so sorry if I can't help you, but when I had this issue with an overbrightened custom testchamber sign texture (with $selfillum) I cheated my way to a solution by adding a Block Light texture in front of the sign.

You could, though, probably use any texture as base instead, and add the custom screen texture as overlay. My test element signage (also with $selfillum) didn't get overbrightened at all, I figure that has to do with those being overlays...

One of my signage vmt's looks something like this:

Code: Select all

LightMappedGeneric
{
$basetexture "FourthReaper/fr_signage_acidious_boxsnatcher"
$surfaceprop glass
$selfillum 1
$decal 1
"%keywords" portal2
}

Hope that helps! If not, sorry... I hope someone with a better understanding of all of this than me comes along.

Quote from weedbeat on April 12, 2012, 5:35 pm

Hey FourthReaper thx a lot for your suggestion and please don't appologyze for not having the perfect solution! At the moment i'll be glad if it works in any way no matter how ugly it will be
Unfortunately it did not work Maybe I also missunderstood you.

First thing I tried was creating an overlay / decal according to your vmt (also with selfillum, not using any other lightsources). Unfortunattely it overbrights as well (allthough I had the feeling that it goes to exposuremin faster)

Second I tried to put the screen texture with $selfillum 0 on a surface that has a white light texture, thereby illuminating the overlay as the overlay had selfillum 1 but the overbright happens anyway..

Third I tried also a texture /overlay with selfillum 0 and indirectly lit it with a spotlight.. unfortunatelly also overbrights..

So it seems no matter how I get the texture lit it will always overbright sooner or later.. alldough to be honest I also testet it with autoexposuremax and min set to 5.. but since I don't want it to get affected by those parameter in any way I guess thats necessary.

Quote from weedbeat on April 12, 2012, 5:44 pm

By the way I also tried to set the minambientlight on a brush which had the texture with selfillum 0 on it.. but also overbrights.. I guess this is really not possible (( damn! when do they begin to implement real physics !

Quote from weedbeat on April 12, 2012, 6:12 pm

Ok i did some more digging and found out that you can control the intensity of the selfillum by using "$selfillumtint" "0.2 0.2 0.2". It is used for the color of the illumination but different greys give different brightnesslevels.. so because my texture is pretty bright this seems to lower its brigtness just enough so that hdr is not overbrightening it.. or overbrigthening it just to the right level. The downside is that on a pc with only ldr enabled the texture will look as if it is not illuminated! Also you'd need to have autoexposuremax and min pretty close to each other but thats exactly what I wanted.. So if there is somebody that knows how to reduce the illumination level only on hdr this would be a improvement otherwise the "few" ldr people will just have to live with it.. at least it is readable not like in hdr before..

Quote from FourthReaper on April 13, 2012, 3:51 am

Hmmm. From this point on I don't really think I can help you... I don't really know much about this. But as for my earlier suggestion, it is possible, though not really likely, that a black or dark texture (try tools_black or a normal metal wall) with the screen overlay material on top. It worked for me, so it might just work for you, too.

Quote from HMW on April 13, 2012, 12:43 pm

Have you added the global_ents instance to your map? I not, put it in and trigger one of its inputs when the map loads. Each inputs makes adjustments to various HDR and fog parameters for a specific map style. (Clean, ruins, old/1940's Wheatley etc.)

The default HDR brightness of the Source engine is a lot brighter than what most of these settings use, so just doing this might solve your problem. (Or at least make it less bad.)