[REL] Nordschleife3 v3.00

Tosch said:
I believe the track at full details is near the vram limit of a 2GB gfx card. When you alt-tab to firefox, Windows has to free up some GPU memory for the browser (around 200MB, depends on the website) and you loose this memory for textures in VRAM. If you go back to rFactor, the game engine has to read the missing textures from (slow) system gpu memory (you may notice the difference between physical GPU memory and by directx reported memory in the video settings). When this happens I see stutter and a decrease in fps.

Check the green VRAM bar on the top left of the screen (if you press 2x Ctrl + f). If it's more than half way down you run partially on system GPU memory and should reduce texture details.
Click to expand...

Nice explanation, thank you.
I will check out the VRAM bar next time I load up Nords. :)

Oh btw, forgot to mention:
The FPS decrease and stuttering I get when alt-tabbing back from another program is worst on the GP part of the track.
As soon as I leave the modern layout and go unto the old, it gets better.
I'm guessing because the recently added GP track isn't fully optimized yet?
 
mianiak said:
Tosch, it would be really good if you would also do the GP circuit and the DTM layouts to include it in your package. I haven't had time to get back into it and fix all the stuff that needs fixing and you have basically gone and fixed it all anyway. So if you wish, feel free to do so.
Click to expand...

Thanks mianiak, it's good it know we are allowed to do that if we have the time. Cheers.

@Tosch, looking good :).

DJC
 
I noticed relatively heavy flickering on the rear of the Apex Modding Mercedes SLS GT3, which I didnt have on other tracks. Several other drivers reported the same issue. I tried diffrent opponent detail levels, but no change.

Any ideas?
 
Freddy3792 said:
I noticed relatively heavy flickering on the rear of the Apex Modding Mercedes SLS GT3, which I didnt have on other tracks. Several other drivers reported the same issue. I tried diffrent opponent detail levels, but no change.

Any ideas?
Click to expand...

http://en.wikipedia.org/wiki/Z-fighting

Z-fighting is a phenomenon in 3D rendering that occurs when two or more primitives have similar values in the z-buffer. It is particularly prevalent with coplanar polygons, where two faces occupy essentially the same space, with neither in front.
Click to expand...

Car modders should avoid these "coplanar polygons", but I see them all the time and not only in modded content.
 
Found some sick hdr settings. :cool:

-Brightness of the sky is ok
-Whitepoint settings work for sky and track at the same time
-Good saturation and contrast
-No overexposure in cockpit view
-Sun occlusion works for the first time since 2012 like it should (almost no shadows when the sun is hidden by clouds).

My question to ISI. Who had the questionable idea to run the automated profile with light intensity 40 times stronger than needed?



Edit:
@DJC
Did you notice the reduced reflection on the "space boxes"? ;)
 
Tosch said:
Found some sick hdr settings. :cool:

-Brightness of the sky is ok
-Whitepoint settings work for sky and track at the same time
-Good saturation and contrast
-No overexposure in cockpit view
-Sun occlusion works for the first time since 2012 like it should (almost no shadows when the sun is hidden by clouds).

My question to ISI. Who had the questionable idea to run the automated profile with light intensity 40 times stronger than needed?



Edit:
@DJC
Did you notice the reduced reflection on the "space boxes"? ;)
Click to expand...

Yes, this looks terrific. Is it just for Nords or would it work as a general setting? And can you share it? Preferably with ISI so they can use it, but failing that, the rest of us can spend hours installing it in every individual track.
 
Wow, I can't wait to see it in motion, sounds real good. Are there really no major drawback to the profile? Night time racing look ok?
 
Tosch said:
Found some sick hdr settings. :cool:

-Brightness of the sky is ok
-Whitepoint settings work for sky and track at the same time
-Good saturation and contrast
-No overexposure in cockpit view
-Sun occlusion works for the first time since 2012 like it should (almost no shadows when the sun is hidden by clouds).

My question to ISI. Who had the questionable idea to run the automated profile with light intensity 40 times stronger than needed?



Edit:
@DJC
Did you notice the reduced reflection on the "space boxes"? ;)
Click to expand...


OMG, looks fantastic. Can't wait ;)
 
@Tosch You really should send every single value, screenshot etc to the devs. To Luc and Pierre. It could be for the mutual benefit and OUR benefit in the process! :D
 
Jesus! Tosch...everytime I think it can't get better, You guys pull a rabbit out of the hat.
This update process reminds me of years as a young Porsche/Audi technician.
Every year, I kept thinking the 911 was going to be discontinued....every year it got better.
I fully expected the development to stop years ago and it's still going...even now some 28 years after I stopped fixing the cars on a full-time basis.
 
Ronnie said:
@Tosch You really should send every single value, screenshot etc to the devs. To Luc and Pierre. It could be for the mutual benefit and OUR benefit in the process! :D
Click to expand...

We know the HDR pipeline and HDPs like our own pockets but now we're focusing on automation because static HDPs are tuned to work just on the specific set of data hosted in the .gdb file, infact they're now considered a legacy feature. There are not magic values nor IRL values as HDR it's just a image processing pipeline working on dynamics. You can play with HDPs for years and getting hundreds of amazing profiles but no one will works for all tracks and all cars, so the automation (which is still an open Task for us) it's the only way to go if we want the game looking the same, in terms of colors and lights, between all combos.

Not saying our automation will process the image as the Tosch one because functions are pure math and they can't be changed per track, but for sure that's what we want to find the balance and get rid of the HDP creation loop.
 
Tuttle said:
We know the HDR pipeline and HDPs like our own pockets but now we're focusing on automation because static HDPs are tuned to work just on the specific set of data hosted in the .gdb file, infact they're now considered a legacy feature. There are not magic values nor IRL values as HDR it's just a image processing pipeline working on dynamics. You can play with HDPs for years and getting hundreds of amazing profiles but no one will works for all tracks and all cars, so the automation (which is still an open Task for us) it's the only way to go if we want the game looking the same, in terms of colors and lights, between all combos.

Not saying our automation will process the image as the Tosch one because functions are pure math and they can't be changed per track, but for sure that's what we want to find the balance and get rid of the HDP creation loop.
Click to expand...

This is great. And the latest version is better (best yet). But you must hurry to get to a state where it can be locked down and then tracks updated as necessary. Otherwise we will just have a different set of abandoned third-party tracks with mismatching/ugly lighting off into the future. Modders are not willing to re-do their tracks every time a global/core adjustment is made. At least half the tracks we have are already abandoned/orphaned. And few have properly done lighting. There are only one or Tosch's out there and your solution correctly recognizes this, but we need it to not come too late.
 
Marc Collins said:
...Otherwise we will just have a different set of abandoned third-party tracks with mismatching/ugly lighting off into the future. Modders are not willing to re-do their tracks every time a global/core adjustment is made. At least half the tracks we have are already abandoned/orphaned. And few have properly done lighting. There are only one or Tosch's out there and your solution correctly recognizes this, but we need it to not come too late.
Click to expand...

That's kinda myth. As you see Tosch is changing day by day the Nordshliefe HDP profile without redoing the entire 2D asset to match a new profile. We're also working our own tracks using actual automation, just following the albedo rule, and we can easily move between different HDR values without screwing up everything. If, and when, artists are getting overdo texture reactions or crazy colors, it's mostly because they're producing diffuse maps with wrong color palette (aka full reds, full greens, full whites, high luma, super contrasts etc) and/or pushing too much with HDPs values. Working with Albedo maps instead standard diffuse means removing sunlight from it, reducing the overall exposure down to at least 1 stop and avoiding too aggressive contrasts. The albedo map will be then compensated by the HDR+tonemapper, since you're working with balanced values.

Paradox of this myth is HDPs profiles are introducing LOADs of variables between textures, colors, contrasts, white point ranges, gamma, sky palette etc... and this means the artist may go nuts in finding the balance. Automation is going to solve this mess.

Just use albedo maps instead standard LDR diffuse maps, and let those maps working inside a balanced HDR automation.

I of course agree with you about to lock the feature when finished. :)
 
You must log in or register to reply here.
Back
Top