The IgnoreWeatherSystem settings are great, however, from my perspective what would be most useful for me is to have ability to Ignore Interior settings only. Not sure about anybody else so I only speak for myself here, but I do not tweak interior settings based on current weather and thus all of my interior settings across all of my various weather ini's are identical. If I do decide that an interior setting needs to change, I now have to apply that change to every weather ini. While this is workable it is not ideal. My thoughts on how to implement something like this would be for ENB to work on a setting priority system whereby if a certain setting is not present in a weather ini, ENB would use the default ENBSERIES value for that setting. For example, if weather1.ini does not contain the DirectLightingIntensityInteriorDay setting, ENB would apply DirectLightingIntensityInteriorDay from ENBSERIES.INI. Not sure the best way to represent this type of situation in the GUI, perhaps the Weather GUI window would display "OVERRIDE" beside this setting to indicate ENB is using the value from ENBSERIES.
The above might sound more complicated than it is but I believe it would provide a fairly flexible approach for ENB to determine which settings are to be "ignored" by the weather system.
In any case, this is just a suggestion from my perspective and how I am approaching tweaking multiple weathers, other tweakers may disagree to this type of approach.
Another aspect that I was hoping could be applied to enhance multiple weathers is to provide ability for ENBEFFECT (and other shaders perhaps) to have knowledge of the current weather. This has been discussed before and aborted due to perceived complexity of ENBEFFECT to react to multiple values. However, the way that I would approach this from a code perspective (I am not a coder, just a hacker) is as follows:
ENB to provide the following new variables into ENBEFFECT:
1. Incoming Weather ID_INDEX
2. Outgoing Weather ID_INDEX
3. Current transition point.
For the above, I would suggest using the weatherlist.ini group title number for ID_INDEX variable of each weather, therefore,
[WEATHER001] makes ID_INDEX = 1
[WEATHER002] makes ID_INDEX = 2
etc.
ENBEFFECT variables could then be kept in arrays to accommodate any number of different values (within reason).
Code: Select all
/* Day Night Interior */
float3 gamma[TOT_WEATHERS] = {
/* SUNNY */ float3(1.00 , 1.00 , 1.00 ),
/* FOGGY */ float3{0.75 , 0.60, 1.00 ) };
/* etc */
float3 saturation .....
float3 brightness .....
float3 contrast .....
int in_w_id = EIncomingWeatherId - 1;
int ou_w_id = EOutgoingWeatherId - 1;
float trans = EWeatherTransition;
float in_gamma = lerp( lerp( gamma[in_w_id].y, gamma[in_w_id].x, ENightDayFactor), gamma[in_w_id].z, EInteriorFactor );
float ou_gamma = lerp( lerp( gamma[ou_w_id].y, gamma[ou_w_id].x, ENightDayFactor), gamma[ou_w_id].z, EInteriorFactor );
float new_gamma = lerp( ou_gamma, in_gamma, trans);Clearly having all current ENBEFFECT parameters applied this way will likely result in decreased performance, but I believe that most configs will only concern themselves with the major ones such as Gamma, Contrast, Brightness and Saturation which makes it quite feasible. That being said, this approach does not limit what the user wants to include.
I have not thought it through entirely but this does seem workable. Just some suggestions that may be worthy of consideration for you. The current implementation is certainly very workable as is.
