Realism under extreme conditions

Lately the discussion came up what would happen in close distance to stars. I think this is a very interesting topic, because getting close to stars might cause a lot of trouble the engine might not be able to handle.

However, it would be great if there was an elegant and realistic way to get around these issues.

The current issues close to stars would be on the one hand the amount of light they produce. If I understood it correctly, the amount of light would blow even the HDR abilities of the engine. Is that correct?

1 Like

what do you mean by blow? we already have close to stars pictures where all is black and only star white. is it blow or how it used to be without any filters?

Cheap and dirty solution could be to give cockpits (and only cockpits?) a dimming mechanism for unplayably bright circumstances.

1 Like

Nah… you have to calculate with actual values. If these values have an overflow (or you have floating-point values which loose detail precision at extreme values) you cannot calculate any image at all.

So 100% contrast past a certain point? It would look pretty unique at least.

Sorry, I can’t parse that lingo… Why can’t you switch to a different calculation, when past some arbitrary threshold? I’m just curious, no big deal if you can’t think of a simple text or image demonstration.

Maybe it could work if you have a global exposure variable which is always applied first to all calculations. However, this can only work if no local-adaption is done in the tone-mapping and if the calculation has been designed for this from the beginning.

Edit: Even a certain amount of local-adaption (within a range) would be possible. But the point about the design of the formulas stays valid.

Instead of having something automatic, why not have it turned on / off?
A realisitc example would be the rear view in your car: you turn the “night view” only when you need it.

Same would apply here: the “instense light” filter should be turned on / off by the user. This way you’re sure not to bother the player if he wants to capture some nice screenshots, whatever the circumstances.

I guess the “automatic” filter can also be good, especially in combat situation and if your opponent tries to constantly switch you from being in front / back to the bright star. Then again, this “automatic” filter should also be turned on /off at will ^^

I’m not opposed to have the filter only availble in the cockpit view, as long as you have information on your rear, like pursuing opponents.

You still think of it as a filter. That is not what I am talking about… If the formulas are not designed for that, you end up having no data you can show. The luminosity values for every pixel would be the same…

1 Like

Can you not use a trick and drop the luminosity values of the star as you approach it? All the calculations should still work fine like that.

That would be strange. Other light sources would stay the same … just pointing out.
You could lower all. My toughts too, but I don’t understand the concept completely.

Everyone who thinks you can’t filter out sunlight needs to…


Er, if you’re filtering (dimming) light, then you apply the filter while you have the precision. So in some early stage in the pipeline, they currently clamp to between 0 and 10,000 lux (or whatever). Subtract the lower limit, divide by the range, and they have a 0.0-1.0 value that flows through the rest of the pipeline.

Instead of that, say that you’ll clamp between 50,000 and 5,000,000 lux, then subtract the lower limit, divide by the range, and you again have a 0.0-1.0 value. Alter the range that you clamp to and you play with the filter strength (and other stuff). Tint as desired.

A silly example of a filter is to clamp to 5,000,000 and 5,000,001 lux. Everything less than 5,000,000 will be black, and everything more than 5,000,001 will be white. Any pixels with luminosity between those ranges will be comfortably visible.

I think you don’t have to clamp like this because you usually use floating point precision. With floating point you should have some smiliar-to-logarithmic precision.

I would think that you have an offset which you can move around. All luminosities near that offset would work while luminosities far from it won’t.

Take this example with a floating-point var that has 4 digits + sign and you can move the comma by 10 digits:

Max: 9999000.0
Min: -9999000.0

In this case, the precision near max or min is 1000.
Between 1.0 and -1.0 you would have a precision of 0.0001.

The problem now is, if the bright parts of the scene are between 5000000 and 5001000 while the dark parts are between 0 and 1000. You would not be able to calculate that, because you have no more available numbers between 5000000 and 5001000. Even if you offset this as whole, you would get the same issue at a different position.

Clamp and distribute values in the range as you like. I used trivial clamping and distribution to demonstrate the technique. The essential point is to act early in the pipeline while you still have the precision.

yea. and the pipeline needs to be designed for this

I only understood the ‘how’ when you first explained it, but now that you guys have argued it some more, I think I’m starting to see the ‘why’ of the problem. Thanks.

Stars are the largest and brightest objects in the universe…why are we trying to rob them of that title they rightfully deserve?

Id say let them be bright…it only enhances gameplay by creating a natural obstacle. If it aint broke don’t fix it.


I think you skimmed the topic a bit too quickly. The idea is to give pilots the ability to filter light, like sunglasses. All light. Where we gain in seeing the brighter stuff, we lose in seeing the dimmer stuff. Crank the filters up high enough and we can see the details of the star’s surface, but we can’t see anything else.

What’s not needed is a star looking like a 10^2W bulb yet illuminating everything as if it was a 10^26W star. That would qualify as “broke” in my book.

You’re probably right I’m on mobile right now and in between classes.

I’ll read more in depth and probably have a better response later when I get home…