Sun "glare" and star fade

[Scorch]

Hey fellow Orbinauts

I used to post in here quite a bit. I've been busy doing some work in the space industry since leaving active duty...a welcome distraction! Anyway, I recently participated in the Human Exploration Research Analog (HERA) mission at the Johnson Space Center. Essentially, it is a month long mission where we simulate a mission to an asteroid inside a two level "spacecraft" with dedicated mission control, emergency procedures, and simulated windows.

This brings me to my idea/question. The software we used to simulate EVA's at the asteroid was run on linux as far as I know, and the graphics were pretty darn convincing. As a regular Orbiter user, one thing really stuck out to me...and that is that when the sun would be in our field of view, the star pattern would fade out. The software essentially simulated the pupilary reaction that prevented the stars from being visible while the sun was in the field of view. As soon as we would rotate the sun out of the windshield, the stars would fade back in.

Does anyone know if this type of thing is possible in Orbiter? I love the program the way it is, but I've been thinking about that aspect of our mission ever since. Any thoughts?

-Dan

 

[SolarLiner]

Does anyone know if this type of thing is possible in Orbiter? I love the program the way it is, but I've been thinking about that aspect of our mission ever since. Any thoughts?

"Hacking" this in would require a few lines of code: check whether if the sun is in frame, disable star rendering if it is.

But the proper way to do it would be with exposure simulation - and that requires full HDR workflow. I've been trying to add it to D3D9 but that proved rather hard as Orbiter evolved with the "classical" rendering techniques, and there is no good way to provide satisfactory backwards compatibility.

 

[n72.75]

Wasn't there a version of this in 2006 before the patch?

 

[Thorsten]

But the proper way to do it would be with exposure simulation

I don't think you need HDR for that.

Imagine you have an external function which has access to sun position and view axis vectors. You compute a dot product and know whether you're looking into the sun (you can clamp output to [0:1].

The result of that dot product (which you can pass to a non-linear filter if so desired) you pass to an asymmetric rate limit filter which goes to 1 very quickly (in a few seconds) but goes to zero very slowly (over the course of 10 minutes) - that's the eye response to light.

The output of that function you pass as a uniform to the star renderer and use (1-value) as factor for the star alpha.

Voila - you won't see stars if you look into the sun once, and it'll take a few minutes looking elsewhere till they re-appear.

(You can refine the rate limit filter by considering ambient light level as well).

In my view HDR is a brute-force solution to things which you can often solve faster by some cleverness...

 

[jangofett287]

In my view HDR is a brute-force solution to things which you can often solve faster by some cleverness...

The perceived/physical intensity thing is a computing time/memory trade-off. Storing light as perceived intensity requires more computationally expensive maths in the shader to combine light sources correctly but you can store the result in SDR framebuffers without losing accuracy. Storing light as physical intensity makes the maths simpler, but requires HDR framebuffers which have double the memory footprint of an equivalent SDR buffer. I'm willing to bet there's a reason all the modern game engines I can think of went with HDR.

 

[Thorsten]

The perceived/physical intensity thing is a computing time/memory trade-off.

That's a complicated one, because rendering to buffer and then doing additional pass(es) over the buffers incurs extra cost and may require to bounce data between CPU and GPU or between regular memory and GPU memory - which is relatively expensive in itself.

In my comparison tests, a single-pass forward pipeline beats the crap out of a deferred one.

I'm willing to bet there's a reason all the modern game engines I can think of went with HDR.

Don't under-estimate the tendency of coders working under a budget to drift to standard solutions to get things done quickly. Also, you may render to texture buffers anyway for other reasons, so while the cost of introducing a buffer to do HDR is generally higher than doing the math in the shader, that may change if you have the buffer anyway.

 

[SolarLiner]

I don't think you need HDR for that.

Imagine you have an external function which has access to sun position and view axis vectors. You compute a dot product and know whether you're looking into the sun (you can clamp output to [0:1].

The result of that dot product (which you can pass to a non-linear filter if so desired) you pass to an asymmetric rate limit filter which goes to 1 very quickly (in a few seconds) but goes to zero very slowly (over the course of 10 minutes) - that's the eye response to light.

The output of that function you pass as a uniform to the star renderer and use (1-value) as factor for the star alpha.

Voila - you won't see stars if you look into the sun once, and it'll take a few minutes looking elsewhere till they re-appear.

That is a better thought way of my "hacking" version - but the idea is the same.

But with HDR, exposure effects are not set up on a per-object basis (you should not see the stars when looking at the Earth on its bright side, nor on the moon, despite what moon landing hoaxers say), but light intensity is measured and exposure is changed accordingly. Besides, it is I believe the last major step before a truly immersive experience playing Orbiter. (It's not only about the physics, right?)

 

[Thorsten]

But with HDR, exposure effects are not set up on a per-object basis (you should not see the stars when looking at the Earth on its bright side, nor on the moon, despite what moon landing hoaxers say), but light intensity is measured and exposure is changed accordingly.

It all depends on the sophistication of your lighting scheme I guess. You can get a credible scheme for light scattered from the atmosphere in a forward renderer if you invest work - and once you have it you can factor it into your exposure filter - and you can mess up the same problem in a deferred renderer with a HDR scheme.

At the end of the day, all real-time 3d is the art of fake and illusion HDR is a particular method to structure a computation - nothing more, nothing less. It's not reality by any means.

It's not only about the physics, right?

There's a measure of art in modeling perception, but personally I'm not a fan of video game aesthetics (motion blur, lense flare, bloom, that kind of thing...) which is often mistaken for 'more immersive'.

Though, there's no arguing about taste.

 

[SolarLiner]

There's a measure of art in modeling perception, but personally I'm not a fan of video game aesthetics (motion blur, lense flare, bloom, that kind of thing...) which is often mistaken for 'more immersive'.

Though, there's no arguing about taste.

If you're going for photo-realism, then motion blur, bloom (and maybe lens flare*) are not art as much as they are tools to improve immersion. When you're going for the full camera simulation, you have to implement those effects. But are they overdone? Most certainly, most of the time.
Also, HDR isn't just one way to get a satisfying render - it is the way to get physically correct renders. All modern game (and game engines) implement HDR rendering because photo-realism is the trend and HDR is known to produce physically correct results.

Now with Orbiter we get a special deal: it is more turned towards physically correct and less towards art in itself: everything is done "by the (mathematical) rules", nothing is left to the artistic mind. Add-ons respect real life or fictional (in case of add-ons inspired from tv series and films) specifications - and I believe that the graphical rendering should reflect that as well.

* The Lens Flare case is specal: naturally the eye doesn't produce them, but camera do, and it evolved into such a nice way to show over-bright parts that it is used everywhere. They are supposed to be non-intrusive and sparse, and can be easily overdone too - I tried to make them bright but not too overpowering, in my implementation in the experimental builds of D3D9, and only in external views.

 

[Thorsten]

Also, HDR isn't just one way to get a satisfying render - it is the way to get physically correct renders. All modern game (and game engines) implement HDR rendering because photo-realism is the trend and HDR is known to produce physically correct results.

Coming from a theoretical physics background, I know a lot about light scattering in physics, and I assure you that no real-time 3d rendering technique is even halfway physically correct - it's always the art of illusion (not that developers of the latest games advertize this much...)

And HDR really has nothing to do at all with physics (which really doesn't know texture buffers and rendering passes...) - it's a technique to structure a computation. Also, the reason why you would want to use HDR is perception, which only has to do with physics in so far as fundamentally everything has to do with physics, but it has nothing to do with solving the light scattering problem for the scene itself.

Anyway - I'm not interested in continuing this discussion - I've linked my material on what HDR is mathematically, use it or discard it at your leisure, I couldn't care less.

 

[Urwumpe]

All modern game (and game engines) implement HDR rendering because photo-realism is the trend and HDR is known to produce physically correct results.

As physically correct as paintings of Salvador Dali: Its surrealism. HDR does not produce physically correct results, but pictures that feel more than they are. Yes, HDR looks impressive. But it is not "physically correct". As if a typical GPU could produce this. Even "Photon mapping" isn't resulting in physically correct pictures, even though it is really very close.