Compute average luminance of current display.

[ENBSeries]

I've answered you already. Why the heck you want to do the same thing which is already made internally? Just for fun? I said it's impossible, you can't do multiple passes with reading back data from previous in enbeffect.fx. Any attempt to get average data and ignoring mine computed leads to vertex shader computation as cycle of texture reading there. Reading all pixels in vertex shader is bad idea (performance is ok, but shader can't execute so many cycles), but nobody need every pixel, use constant step.

[Phinix]

I don't mean to be a pest, I'm just a perfectionist!

Like I said, it is impossible to get universally acceptable balance with adaptation alone due to the weird lighting in Dawnguard DLC areas. The only other thing I haven't tried is if there is a range between the cutoff where Vanilla adaptation kicks in and ENB adaptation kicks in, if maybe applying a floating pow to that range might allow it to boost these ugly vampire castle areas without affecting others.

If in the future you ever decide to add a per-cell option, that would be excellent and could work as well. Just to have the cell ID as it is read by the helper .DLL in the status monitor of the in-game editor like it currently shows active weather ID's, and allow people to make a cell list just like the weather list of any cells they want to do custom editing for.

Speaking as a config author myself, I would gladly take the time to do custom configurations for the few problem cells that exist. It wouldn't be much extra work for me at all, as 90% of places in Skyrim work without any custom edits needed.

Anyway, I appreciate your taking the time to post feedback.

[ENBSeries]

Per cell is definetly not acceptable. I tried all available IDs and worldID (implemented) is the only valid for any kind of setting, others bring unstable results, you move in the world a little and it switch to different, what should i do then, interpolate smoothly? User may enter/exit too fast.

You've mentioned vampires, if it means that place desighned for vampire or khajiit vision, it can't be fixed via adaptation and the problem is in the setting of the game (imagespace if i remember). Shader variables (used in original post processing) changing a lot to compencate brightness and i can't do anything with them, because other types of color manipulations apply changes to same variables. Using them directly the same way is also impossible by quality reasons (corrupted post processing, basically). Try to search fixes for vampire and khajiit vision, i saw posts here long time ago, so they exist.

[kingeric1992]

You can already make per cell/event effect through register _c5 in enbeffect.fx.
All that required is to use CK to make a mod that changes <ImageSpace Modifiers> --> <Cinematic> --> <fade>
It can be utilized as flag for all the cell/event effect u want like number6's khajiit nighteye mod for ENB.


also about bad lighting, that is the reason why some enb presets list lighting mod as requirements.

the choice is a simple fix through .esp or excessive lines in enb that only applied to one or two cell.

[Phinix]

@ENBSeries : The per-cell problem makes perfect sense the way you described it. I see the same issue with the mod I was testing to run game script when cells change (it fires just wandering around the same world space).

@kingeric1992 : This sounds like a perfect (and rather genius) solution. Assuming I already have the mod built that applies the ImageSpaceModifier when I enter a target cell, how would I go about checking this in enbeffect.fx?

I tried this:

Code: Select all

	float4 phicheck = float4(1, 0, 0, 0); //I set the Fade to 255, 0, 0, 0 in the CK.
	float phiTest = 0.0;
	if (phicheck==_c5) phiTest=1.0; 

But that just causes an instant crash on load.

What is the proper way to compare the _c5 fade register to a set of values expected from my mod?

[ENBSeries]

Code: Select all

if (phicheck==_c5)

This is the reason of crash. Only scalar values can be compared this way. Also string comparison not works i suppose, make some math to check which values are desired. For example:
color=abs(dot(_c5, 0.25)-tempF1.x)*10.0;
and tweak f1 variable till you find which values of _c5 is correct for triggering. Then replace tempF1.x by constant and do something like this as interpolation factor:
interpolator=saturate((dot(_c5, 0.25) - someconst) * hardness);

[kingeric1992]

About the flag,
I prefer using > < instead of == to include margin of errors.
Also recommend to use temporary sliders to find thresholds,
there seems to be some bias in those values judging from enb diagnoses mod by number6 that display c0~c5 on screen.

but again, imho the better way to fix individual cell is through editing imagespace parameters instead of switching to specific input set in ENB.
And since you're testing with CK now, you might as well check if the problem can be fixed though mod alone.

[Phinix]

Thanks for the help guys!

I am happy to say I managed to find what was causing this. Helios Double Six (number 6?), HD6, etc. has some excellent code (he called it "mode 5") for ENB, but hasn't been around to update in a while. In this case he has a section related to adaptation intended to "Ligthen if dark, but do not darken if too light." He was using this code:

Code: Select all

r1.xyz = lerp( min( 0.28, r1.xyz ), 0.5, hnd );

Which does an excellent job correcting for too dark areas at night, particularly indoors, but only applied a flat 0.5 correction to daytime, which was why certain areas like this with extreme low light conditions still looked too dark. They needed more of a gamma shift like extreme dark nights did.

I modified the code slightly, to keep the flat shift to 0.5 for daytime, but also apply the same low clip for interior day as interior night.

Code: Select all

r1.xyz = lerp( r1.xyz, 0.5, hnd );
r1.xyz = lerp( min( 0.28, r1.xyz ), lerp( min( 0.28, r1.xyz ), min( 0.5, r1.xyz ), hnd ), pi );

Everything now looks just about perfect.

I did have another shader code question. When you set a float4 to a value like that, does the compiler multiply each of the RGB values by that value, add to each value, or hard set each value? I am assuming multiply but I'm not sure. Also, what about the alpha value, is it simply ignored?

[ENBSeries]

Alpha ignored in computations for these two examples:

Code: Select all

r1.xyz = lerp( r1.xyz, 0.5, hnd );
r1.xyz = lerp( r1, 0.5, hnd );

Compiled shader code use vector math for all ops you did, but modern videocards compute everything as separate scalars, so having color.xyz=color*2.0; means it's 3 times slower than color.x=color.x*2.0.

[Phinix]

Cool. That's sort of what I understood, but I like how you explain it in terms of performance. So...

Code: Select all

color.xyz=color*2.0;

...is 3 times slower than color.x=color.x*2.0 because it is actually doing:

Code: Select all

color.x=color.x*2.0
color.y=color.y*2.0
color.z=color.z*2.0

I made some changes to the previous code I posted so that it accounts for the different scenarios of daytime/night, interior/exterior. (The value "pi" is just EInteriorFactor inverted (1-EInteriorFactor), just for grins. The "hnd" is HD6's copy of ENightDayFactor that I left in there since it takes less space.)

Code: Select all

r1.xyz = lerp( 0.5, lerp( r1.xyz, 0.5, hnd ), pi );
r1.xyz = lerp( lerp( min( 0.2, r1.xyz ), min( 0.28, r1.xyz ), hnd ), lerp( min( 0.28, r1.xyz ), min( 0.5, r1.xyz ), hnd ), pi );

With everything else the shaders are doing I don't notice any performance hit at all, though I have fairly decent hardware.