Weird Real Road graphical bug (no chicane tested) As on Sunday I did many tests at Limerock, I found a strange behaviour of realroad aspect. If you run a practice session with a rubbered track at 10 AM you'll see the rubber along the racing line everywhere but in the main straight and at the braking zone of turn 1 near the bridge (makes finding the braking point difficult, that is why I noticed). Change the hour of the practice to 2 PM and you'll see the rubber along all the racing line, including the main straight and the braking zone of turn 1 near the bridge. It happens with automated HDR and legacy profiles. It si so weird, that I did many tests to confirm it was correct (erased realroad saved, and created a new one). I can reproduce it at will. I think it has some relation with the angle of sun in the main straight, I don't know if it is the only track affected. Cheers.
AFAIK there was an option like this implemented for modders some builds ago, and someone actually posted about it in this thread or another, can't seem to find it back anymore though. Somebody know what I mean and how it works?
It' not a matter of auto exposure. It depends on how you setup your camera (focus, exposure time, aperture, white point).
Yes, set-up properly or not. Most onboard cameras, unless it's for a major broadcast network, don't have professional camera people managing them. They have racers doing it, most of whom wouldn't know what they were doing. Let's try a race sometime where the racers do the videography and the camera operators race the cars and see the result! I would like my rF2 default car set-ups to be configured by racers and my HDR set-ups to be configured by photographers.
A camera has a fixed dynamic range (diference between lower light and brighter it can record for a given level of noise). As there is no additional lighting in the cockpit (the light present in the cockpit is the light entering through the windows and the wind shield), if the camera points to the track and the auto exposure works mainly according to the lighting of the track, the brighter the outside scene, the darker is the dashboard and vice versa. But human vision has a much higher dynamic range than cameras, and is able to see very bright scenes and at the same time compensate for very low levels of light. So what we should see in cockpit is not what would record a camera due to the higher dynamic range of our vision. But what is sure is that at a given moment, the track should look the same (if seated at the same height) in a white cockpit, in a black one, or in an open cockpit. The lighter the track is, more lighting should be added to the interior of the car to bring the dynamic range of the whole scene, in the limits of the range of values our screen can show. What doesn't work is averaging the whole scene interior and exterior as is done now by HDR. If you feel I am wrong, I welcome your explanations. Cheers.
At the end of the day, our eyes don't work like a camera's exposure so it's all moot. I've said this in a past thread, put an alpha mask around the cockpit, and then adjust the display for the outside view only. Then, any light sources can boost the cockpit and/or the outside view, just as long as the cockpit and outside scene brightness aren't being used together to determine the overall/balanced brightness. I'm sure it's as simple as that EDIT: I posted this before lgel's post.
I will happily accept the seniority of your post. So at least we are two thinking the same, how to implement that it is probably not so easy (in fact both lightings should evolve in relation). Cheers.
HDR is post-processing algorithm which doesn't take any stance on cockpits or alpha masks, it only takes color information of each pixel as input and calculates a transformed image as output. So I don't think these post-processing effects can easily be implemented on part of image only. Perhaps someone more into computer graphics could give better explanation. The profile of Tosch is anyhow excellent, there is no visible overexposure in cockpit. Also night-time looks reasonable, so based on this, automated HDR should be able to achieve better results if ISI tweaked their parameters.
