Mangaclub wrote:But anyhow, would it be possible to add SSAO and Skylightning also as own weather option ? Often those ned to be reduced an certain situations like Foggy weathers or Snowstorms.
Hmmm... Good idea, but I doubt (unless I'm mistaken, only Boris can tell) that SSAO-SSIL could be weather dependant, especially with transitions.... I don't know a shit about HOW it's computing inside the algorythm itself but I don't think it can be possible. Maybe something that could intervene *between* the weather conditions and the SSAO code, kind of added fog control. but does the game engine allow for this ?
Skylighting, this I don't know either...
_________________ Lian Li PC011 Dynamic, Corsair AX 1500i PSU, i9 10850K @5.0 Ghz, Aorus Z490 Ultra, RTX3090 MSI Gaming X Trio, 32GB Corsair Vengeance Pro RGB RAM@3600, Corsair MP600 1TB NVME System Drive, 10 TB Storage, W10 Pro 64, Custom Hard Tubing Watercooling Loop
I think i found a bug. Either in skyrim or in the weather recognition.
It seems that weather, wich is iniciated by external modules like Climates of Tamriel or expanded snow systems (or what ever) is load order dependand.
That means if i want to call for example a snowstorm with the console from CoT with the ID 047E31 , i wont work becasue the actual id is 09047E31. The 09 inidcates as we all know the actual load position, in this case position 9. As a result the weather recognition in ENB wont know the weatherID "047E31" in the weatherlist.ini. As a sollution I suggest that the ENB Weather recognition ignores the first 2 digits of the weather ID's so it recognises external weather's brougth in by mods properly.
Mangaclub
This is sofisticated for me, have no idea what to ignore for sure. If some paper exist with description, i'll do changes, but now afraid to bring more issues.
Entire day and night lost for searching precision bug and solutions to it. If i touch matrix of helper object (even set it's position to constant), then small random wavy shifting on screen occur with temporal aa enabled (like grass on wind), because of restored world space positions from depth. Found out that bug unfixable and it's not only because of matrix, but because of depth, it also changing the same way, so if matrix not modified the bug is compensated. In first person mode camera not shacking like this, so no issues. For temporal antialiasing did workaround by using relative world positions of non modified matrices (two of them instead of single), but for other future effects which may require real world position it's not fixable (may be only very huge objects like clouds or fog may look without shacking). I'm so much tired to spend time with bugs in games, useless life.
A bit too much, huh ?
I can understand HOW it may be hard to fight against the "Bug" part of Bugthesda
Thus said, just tell them to send the source codes right over and learn them how to work wisely !
Don't burn yourself Boris... rest a bit.
_________________ Lian Li PC011 Dynamic, Corsair AX 1500i PSU, i9 10850K @5.0 Ghz, Aorus Z490 Ultra, RTX3090 MSI Gaming X Trio, 32GB Corsair Vengeance Pro RGB RAM@3600, Corsair MP600 1TB NVME System Drive, 10 TB Storage, W10 Pro 64, Custom Hard Tubing Watercooling Loop
I think i found a bug. Either in skyrim or in the weather recognition.
It seems that weather, wich is iniciated by external modules like Climates of Tamriel or expanded snow systems (or what ever) is load order dependand.
That means if i want to call for example a snowstorm with the console from CoT with the ID 047E31 , i wont work becasue the actual id is 09047E31. The 09 inidcates as we all know the actual load position, in this case position 9. As a result the weather recognition in ENB wont know the weatherID "047E31" in the weatherlist.ini. As a sollution I suggest that the ENB Weather recognition ignores the first 2 digits of the weather ID's so it recognises external weather's brougth in by mods properly.
It is an issue with certain formID´s. Depending on Modlist and mod version the first three digits change for some strange reason.
I had 020 for CoT 2.1 and after upgrading to 3.1 I currently have 070.
However as a fix I guess it would be possible to just have an option at the start that specifies these three digits, and it is these are then applied to all values.
Otherwise there is nothing to do but a good old manual replacement.
If that is the case then it will make it really hard to distribute presets based on this version. Most people are never going to understand how to find the digits, and then manually replace them all afterwards. If it can only go manual then this version is going to be somewhat "pro" since only dedicated preset makers and a few others are going to use it.
Oh not so fast, indeed there need to be only 2 digits ignored becausue there are also longer weather id's with 6 digits like the skyrim fogs: 0010a7a7
So far i know leading 0 are ignored anyhow so it should not conflict with 5 digit weather id's
Damn, on a second thought that's true. The vanilla weather ids with five digits (12f89 and so on) are more of a deviation than a norm, actually, and the first two digits denote the load order id.
Urrr! I'm so much tired from development of temporal antialiasing, the bugs with low precision of restored 3d space killing all the time. At first, any operations with matrices produce camera shacking artifact when i third person. After workaround i got another problem with low precision, no shacking this time, but when moving or rotating camera, difference between positions of restored current and previous frames is huge, about 3 distance units in 5-10 meters from camera and error linearly increase with distance, so the mountains on horizon have very huge errors. Okay, this fixed by inverse factor of distance to camera, but now another precision issue appeared, partially pixels on edges of objects are marked as movable areas, because distance between positions of current and previous frame too big in computation just because of precision errors in shifted objects and in taa shader. I can't ignore this, because it looks like trails of semitransparent dots and small lines while moving or flickering dots or lines on edges while standing. I'll try to think about another stupid workarounds, may be by reading nearest pixels and if most of them passed, then i'll ignore failed pixels, but it produce another artifacts instead of existing. If this trick will not work, guess temporal antialiasing will be never done or when another ideas came to mind, i can't depend from single effect and develop it entire day, each day.
