Everything becomes pitch black ..
As I said before never mind I'll stay with the default. You've done more than enough for all of us here.
PS: Just to clarify: the main GraphicsConfiguration.xml is the default one from Frontier.
Just disabling the prototype lighting balances still results in things being too bright, especially bloom, and doesn't remove the tinting that's applied to everything by the main star. Some of the changes I mentioned mitigate this...but they are still a work in progress and are a mess.
Try removing GlareCompensation and setting ExposureType to 0.
Alternatively, I can give you my personal config and override files if you want to see what it looks like on your setup, then you can move the changes I've put in the main config into the override.
Edit: I'll probably get around to collating and consolidating my settings soon and will double check what's actually doing what when I move it to the override.
Edit: I'll probably get around to collating and consolidating my settings soon and will double check what's actually doing what when I move it to the override.
The subtle differences I was seeing in brightness with the prototype lighting balances disabled are down to both my bloom and galaxy map settings (the brightness of the milky way is determined largely by three parameters in that section and the skybox itself is a lightsource).
None of my other HDRNode nor HDRNode reference settings appear to have been influencing anything, or are so subtle I cannot tell what they are doing. I'm pretty sure I was trying to find a way to disable the new tone mapping, without totally destroying the gamma curve of the game, but wasn't making much progress in that regard.
Setting UseCompute to 0 is a performance tweak that improves my frame rate frame rate by about 3% in GPU limited scenarios, with no change to IQ. However, UseCompute 0 also requires ExposureType 0 to avoid the black screen you were seeing.
None of this stuff has any impact on my custom shadow settings and the extra frustums still need to be added to the GraphicsConfiguration.xml proper, not the override, to work.
Edit: Might need to check some of the settings I just discarded again...some of these ice rings are much brighter than I remember.
Alright, there is definitely a difference between the HDRNode settings I was using and simply turning off the the ProtoTypeLightBalance and UseCompute settings.
Both of the following images are using the same override file for bloom and the like, but with different HDRNode and HDRNode_Reference settings in the main graphics config.
First image is only PrototypeLightBalanceEnabled=0, UseCompute=0, and ExposureType=0:
Second image is with my additional changes:
So now that I've confirmed that they are definitely doing something, I need to figure out what is doing what and if it can all be moved to the override. I'm doubtful of the latter as I am actually adding entries in some places rather than just overriding them.
but now I've got to study your 2 new posts.
1stly the UseCompute 0 does require ExposureType 0 to avoid the blackness BUT not the one in the HDRnode, rather the one in the HDRnode_Reference.
2ly I can double confirm the HDRNode & HDRNode_Reference settings do produce a change:
These are with the following values in the override:
Now luminosity is much more controlled and within acceptable limits.
Of course you are one step further with your percentile adjustments
But you are the Master and I am the student here
As you said we need to figure out what does what and particularly what is the difference between HDRNode and HDRNode_Reference values. One probably has a higher hierarchy vs the other.. One thing is for sure the override does work but probably not for additional values that are not present in the main graphicsconfiguration.xml. Further testing is needed.
As you said we need to figure out what does what and particularly what is the difference between HDRNode and HDRNode_Reference values. One probably has a higher hierarchy vs the other.
I believe the HDRNode_Reference was, at one point, just that. However wither 3.3 they started to include entries in HDRNode_Reference that were not in HDRNode.
Both must be parsed, and the plain HDRNode probably overrules HDRNode_Reference, but I haven't really investigated it with any detail.
That's what I thought initially but the fact that ExposureType 0 does not parse when placed in HDRNode is confusing / contradicting..
Anyway I'll be away from home and from my ED PCs for a couple of days so I'll catch up hopefully sometime towards the end of next week.
On a somewhat related note what do you think about the new nvidia's filters presented by good old OA in YT?
Personally if it wasn't for GeForce Experience I'd be more than happy to give them a try (when I return next week) but I simply detest this app (but it might have changed for the better since I last used it a couple of years ago..) - I only install the driver.
On a somewhat related note what do you think about the new nvidia's filters presented by good old OA in YT?
Personally if it wasn't for GeForce Experience I'd be more than happy to give them a try (when I return next week) but I simply detest this app (but it might have changed for the better since I last used it a couple of years ago..) - I only install the driver.
I normally avoid 3rd party filters, both for the sake of reducing complexity and because there is a lot that can be done in the game settings themselves. I don't like GFE either and typically don't install it.
However, NVIDIA has integrated their sharpen filter into the core driver control panel, and I've been having some success with it.
Hmm it doesn't appear to have an observable effect for me - at least not in real time. Does it require to close and relaunch the app? (Yes I have selected the elitedangerous64.exe as the custom application and not the edlaunch..).
You are right - it doesn't show any visible differences in screenshots no matter if they are bmps or pngs or jpgs..
BUT in game it is clearly noticeable. I uninstalled reshade btw so that I can tell the differences with an unbiased perspective.
Anyway I am off to bed cause I'll miss my flight for sure.. see ya next week.
This will be the biggest update to my shadow frustums in a while. I recently acquired some white paint for my CMDR's Mamba which makes a lot of near-surface geometry visible as shadow acne. Had to make a few hard choices between keeping peter panning to an absolute minimum, or eliminating as much shadow acne as practical and ensuring that transitions between shadow cascades were as seamless as possible...I went with the latter. This involved tweaking many of the depth slope biases and offsets again, generally upwards. I've also increased some of the frustum end distances slightly, to push out shadows, as far as good quality can be maintained, with my current number of frustums.
Though this is a move in the opposite direction of my last few significant updates, I believe it's an overall better balance and I was still able to keep the frequency of peter panning (detached/floating) shadows acceptably low (and significantly reduced from default).
As usual, this should be pasted over whichever shadow detail setting you wish to replace in your GraphicsConfiguration.xml. As these changes add at least two frustums above and beyond those that exist in any of the default profiles, placing this in the override file will not work correctly...there is no Frustum6, Frustum7, or Frustum8 to override, even on ultra.
Optionally, one can download the config file I've attached to this post, rename the file to remove everything after ".xml" and paste it over the game's copy. Reverting the file to stock is as easy as having the launcher verify game files. Note that the attached file replaces the game's LOW detail shadows with mine, to make comparisons with the default higher quality settings easier.
The image encoding/file format is not the issue. Evidently the point from which the frame is grabbed is before the filter is applied, at least with any software I've used to grab images. It's possible NVIDIA's GFE or Ansel could capture the effect, but I have no intention of installing GFE.
Also, I played around with the lighting and tone mapping a bit more. I tested a much older tone map I pulled out of a back up dating back to 1.3 and compared it with both a linear map (ToneMapType=0) and the current defaults. In the end I left it at the default tone map, but pulled the Percentiles entry (if it did anything it was too subtle to be clear, even when comparing screenshots), and turned down GlareCompensation further, to 0.75.
Here is my complete GraphicsConfigurationOverride.xml, so you can see everything I've adjusted to my personal tastes (both for IQ and performance):
Testing approach and surface shadows at low illumination levels with the light source at a low angle, current settings (this scene is very dark and some Chromium based browsers may make it even darker, I recommend viewing at 4k in a Firefox based browser):
And this image of a white Mamba illustrates some of the opposing variables I'm fighting against:
Mamba has a bunch of geometry that, ideally, should not be casting shadows at all. I can't do anything about the geometry itself, but it does provide a useful reference for my changes. See that shadow around the seams of the panels at the nose of the ship? Ideally, bias should be large enough to hide that. However, if bias gets any higher you'd start to see detachment/floating/peter panning of the shadows on the small vertical stabilizer/wing fence right next to it, at the rocks on the ground, and from the utilities that are casting shadows on the hull. The shadow of the small hardpoint cover, which being flush with the surface, which shouldn't exist, would also look even stranger as it would be further detached from the geometry casting it. Regardless, current settings are passable in most scenarios, and are much better than the unmodified ultra shadows.
The wanton destruction of a petty criminal, too poor to afford a 10CR paint touch up, for two containers of Filament Composites is an Atrocity against Mankind.
..
