Elvas Tower: What abour fog and mist in OR? - Elvas Tower

Jump to content

  • 6 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

What abour fog and mist in OR? Rate Topic: -----

#1 User is offline   BB25187 

  • Fireman
  • Group: Status: Active Member
  • Posts: 138
  • Joined: 09-December 12
  • Gender:Male
  • Simulator:OpenRails MSTS
  • Country:

Posted 12 January 2014 - 06:06 AM

Hi all,

I would like to open a discussion about the fog in OpenRails.
When adjusting fog effect with MAJ+ or MAJ-, we get something like that:

http://imagizer.imageshack.us/v2/800x600q90/819/3qz0.jpg

http://imagizer.imageshack.us/v2/800x600q90/854/suu8.jpg

http://imagizer.imageshack.us/v2/800x600q90/23/pahv.jpg

http://imagizer.imageshack.us/v2/800x600q90/199/vyft.jpg

http://imagizer.imageshack.us/v2/800x600q90/21/h29p.jpg

This is not bad, but we can notice that:
- Whatever the tuning, the foreground remains perfectly clear. Even when the fog is at the maximum level, the first 30 to 40 meters in front of the camera are totally clear.
- In the opposite, the fog effect in the background is very dense and uniform. This becomes true even for a relatively low level of the fog effect.
- As a corollary of the two observations above, the transition between the clear part in the foreground and the "dense" part in the background is very abrupt compared to what happens most of the time in the reality.
It is impossible to render a light mist for instance. The fog effects in MSTS didn't expose this type of drawbacks.

Alltogether, I am wondering if the fog in OR could not be improved. This would help to create more realistic and varied environments. The images below have been made with the OMSI bus simulator and illustrate my point. The fog/haze effect looks much smoother.

http://imagizer.imageshack.us/v2/800x600q90/690/urgs.jpg

http://imagizer.imageshack.us/v2/800x600q90/541/vqii.jpg

http://imagizer.imageshack.us/v2/800x600q90/600/1fc5.jpg

http://imagizer.imageshack.us/v2/800x600q90/43/qgqr.jpg

http://imagizer.imageshack.us/v2/800x600q90/842/8jah.jpg

http://imagizer.imageshack.us/v2/800x600q90/46/9g69.jpg

I made quick attempts in OR code. I am not fully satisfied and the implementation is probably not the best possible one, but this also illustrates my point and can be used to open the discussion:

http://imagizer.imageshack.us/v2/800x600q90/819/at83.jpg

http://imagizer.imageshack.us/v2/800x600q90/202/mjwh.jpg

http://imagizer.imageshack.us/v2/800x600q90/713/fxie.jpg

http://imagizer.imageshack.us/v2/800x600q90/4/yfrd.jpg

Regards

#2 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,862
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:ORTS / MSTS
  • Country:

Posted 12 January 2014 - 06:18 AM

Whatever you changed, BB25187, it looks good. I think, these changes could well be used generically. Only, in the last picture, is that already showing maximum fog density? If so, whitouts would now be even harder to simulate...

Cheers, Markus

#3 User is offline   PA1930 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 782
  • Joined: 16-December 12
  • Gender:Male
  • Simulator:-
  • Country:

Posted 12 January 2014 - 07:13 AM

I'd love those changes on the fog as well! Also that's some interesting modification you made on OR just to illustrate your sugestion. It would be awesome if those changes could make into the OR code at some point. :) I agree that although the fog looks rather nice currently on OR, I'd prefer it to be exacly like you explain. :rotfl:

#4 User is online   railguy 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 651
  • Joined: 10-October 10
  • Gender:Male
  • Location:Kansas
  • Simulator:Open Rails
  • Country:

Posted 12 January 2014 - 07:25 AM

I agree with the suggested improvements. My main criticism of the fog in OR is that it just really doesn't look right at night. It turns things black rather than a dark greyish hue.

On the subject of skies, I know the team is working on the stars to eliminate the "blotchiness" currently rendered in them. Hopefully, as part of that, the diameters will also be reduced. The current stars are just "too big." I live in a place with an outstanding view of the stars--one of the best in the world, I would think. The stars don't look that big, even with my excellent view. Also, while it is nice in OR to have a star view like I see frequently in reality, most places don't have that kind of clear view. It would be nice to have an option to "dim down" the stars (and moon and sun) without doing it by increasing the cloud cover.

Finally, the clouds in OR move too fast--that is another parameter that should be made adjustable.

All that said, I say a heartfelt thanks to the OR crew for making OR skies and weather much more "user-friendly" and player controlled. Seeing the continual great work from the OR team, I know that "better weather" is in the offing for OR.

#5 User is offline   edwardk 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,350
  • Joined: 11-December 09
  • Gender:Male
  • Location:Chula Vista, CA
  • Simulator:MSTS
  • Country:

Posted 13 January 2014 - 10:55 AM

I realized that the "fogCoeff" under the snow category in "Weather.cs" was initially set too high for my taste so I adjusted the value down just enough. OR will eventually be totally different from MSTS, but I have to wonder if it would be beneficial if we followed MSTS's use of the env file.

Edward K.

#6 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 13 January 2014 - 12:59 PM

View Postrailguy, on 12 January 2014 - 07:25 AM, said:


On the subject of skies, I know the team is working on the stars to eliminate the "blotchiness" currently rendered in them. Hopefully, as part of that, the diameters will also be reduced. The current stars are just "too big." I live in a place with an outstanding view of the stars--one of the best in the world, I would think. The stars don't look that big, even with my excellent view. Also, while it is nice in OR to have a star view like I see frequently in reality, most places don't have that kind of clear view. It would be nice to have an option to "dim down" the stars (and moon and sun) without doing it by increasing the cloud cover.



The problem OR faces here is that stars as seen from earth are essentially mathematicaly VERY small pinpoints of light and the apparent variation in size as seen is caused by the atmosphere and imperfections in the eye.

A second point is all star maps printed (and even astronomical programs) show progressively brighter stars as being larger so its very likely that any readily availible star map that OR can use will have all objects of various sizes. What is required for OR is a star map of around at least 4096x4096 with all stars being single pixels of varying brightness and colour. Various large nebula and aour own galaxies core being displayed as variations in the back ground brightness and colour.

With such an images comes the problem of what projection will it be required to be in so the stars as they appear in the sim will be in the correct place.

I find the current system really annoying and if I drive at night I make sure its cloudy. I have toyed with the idea of improving it, I may have to do more on this I think.
I do have a computor catalog of all heavenly objects, it would not be a chronicly difficult project to write a program to plot the points on to a projection to suite OR............ Hmmmmmmmmmmmmmmmm, I will give this further thought when the weather cools down (currently in Victoria we are facing at least 5 days of temperature in the 39 to 44 degrees celsius, 102 to 111 farenhiet, AND they are forecasting showers later in the week at these temperatures............. NOT fun at all).

Lindsay

#7 User is offline   rdamurphy 

  • Open Rails Developer
  • Group: Private - Open Rails Developer
  • Posts: 1,199
  • Joined: 04-May 06
  • Gender:Male
  • Location:Thornton, CO
  • Simulator:MSTS - OR
  • Country:

Posted 13 January 2014 - 11:39 PM

I'm working on the .env file connections now... Not much to actually see, though. Water textures will be tiled soon, with parameters taken from the .env files, but it is going to take a while to connect the whole thing together with the MSTS files.

Robert

#8 User is offline   BB25187 

  • Fireman
  • Group: Status: Active Member
  • Posts: 138
  • Joined: 09-December 12
  • Gender:Male
  • Simulator:OpenRails MSTS
  • Country:

Posted 17 January 2014 - 11:58 AM

Hi all,

Thanks for your feedback. Great to hear about the connection with MSTS environment files.
I kept testing different fog expressions. And I think that I found a compromise which suits me. I also better understood the impact of the formula on the visual perception.
The large picture below depicts the effect of different algebric expressions used to simulate fog, as well as their effects in game. Each set of curves represent how the "opacity" varies with the distance, for different values of the fog coefficient. From the left to the right:

- Original OR code:
Out.LightDir_Fog.w = saturate(length(Out.Position.xyz) * Fog.a - 1);
The fog is modeled by a pure linear function of the product of the fog coefficient by the distance. An offset is subtracted to this value, and then a saturation is applied. The saturation imposes that the resulting value is within the range [0, 1]. We notice that the opacity in the foreground is always nul value. This is caused by the offset. This explains why we never have fog in the foreground. Furthermore with such a formula, the opacity increases between two distances, the second of which (the "end distance") is twice the first one (the "start distance"). The higher the fog coefficient, the steeper the transition. This explains why fog looks like a "wall" in so many cases.

- Test 1:
Out.LightDir_Fog.w = saturate(length(Out.Position.xyz) * Fog.a);
To have fog in the foreground, the offset must be removed. The formula is slightly modified. The fog is then also present in the foreground. The "wall effect" is still observed.

- Test 2:
Out.LightDir_Fog.w = saturate ( ( log10 ( length(Out.Position.xyz) + 10.0 ) - 1.0 ) * Fog.a * 30.0 );
To reduce the wall effect, I first attempted to use a smoother curve based on a logartihm. The result is slightly smoother, but the wall effect is not totally fixed. Furthermore, the saturation creates a discontinuity in the curvature which is perceived by the eye. And the formula is too complex to be elegant!

- Test 3:
Out.LightDir_Fog.w = (2.0/(1.0+exp(length(Out.Position.xyz)*Fog.a*(-2.0))))-1.0;
It suddenly came to my mind that sigmoid curves could fit the need. Those curves varies in a smooth way between two constant values. They are based on exponential functions. The "wall effect" is dramatically reduced. As a saturation isn't needed, the curvature remains continuous, and the eyes are happy. The fog is also present in the foreground when fog coefficient is high. And by the way, I realized soon after that this curve is very close to the one known in the litterature and used in many graphic engines to model... the exponential fog!
The only drawback of the expressions used for Test 2 and Test 3 is the possible impact on performance. The one in Test 3 saves one call to the saturate function, but it costs a call to the exponential function, one division and two multiplications. I did not yet measure the impact on FPS, just because I make use of the "VerticalSync" option, and thus my FPS never exceeds 60. With this setting, the FPS was not modified by this change and remained close to 60. So, at least on my PC it works fine, but this may not be the case on any other machines.
It is also necessary to verify if this fog works fine with distant mountains too.

http://imageshack.com/a/img690/355/b6a7.jpg

I can provide SVN patches if the developpers are interrested (but only one line of code has to be modified in SceneryShader.fx).
Regards

#9 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 17 January 2014 - 01:33 PM

Thanks for making such investigations and tests!

View PostBB25187, on 17 January 2014 - 11:58 AM, said:

- Original OR code:
Out.LightDir_Fog.w = saturate(length(Out.Position.xyz) * Fog.a - 1);
The fog is modeled by a pure linear function of the product of the fog coefficient by the distance. An offset is subtracted to this value, and then a saturation is applied. The saturation imposes that the resulting value is within the range [0, 1]. We notice that the opacity in the foreground is always nul value. This is caused by the offset. This explains why we never have fog in the foreground. Furthermore with such a formula, the opacity increases between two distances, the second of which (the "end distance") is twice the first one (the "start distance"). The higher the fog coefficient, the steeper the transition. This explains why fog looks like a "wall" in so many cases.


I just want to explain what was going on here originally, for context: the 'fog' calculation and its existence was simply to hide the "pop up" of scenery in the distance. It was decided (quite possibly before my time) that we didn't want that to adversely cloud the scenery close by. Due to technical limitations in Shader Model 2, the function used had to be very simple, so we went with a linear 'fade' from 50% of viewing distance to 100% of viewing distance.

Now, the adjustments for rain and snow conditions, and more recently the completely variable control of fog, have obviously shown up that this basic function is not actually designed to be fog at all.

So on to the new proposals: I can't actually remember which of linear, logarithmic or exponential fog is supposed to look better (your text suggests exponential and I'm happy to go with you on that) but I would like to suggest we attempt a hybrid of the old and new. What I would like is for fog to operate according to the best of the new functions up to ~90% of viewing distance, and then linearly go to 100% fog at 100% viewing distance. The fog between 0% and 90% should not depend on viewing distance, only the weather conditions/fog settings.

Given the reasoning behind the old code, I hope my suggestion is logical; I would like good, realistic fog for as much of viewing distance as is reasonable (90%) but still wish to obscure the scenery "pop up".

Feel free to provide any code patches as attachments ("Create Patch" in TortoiseSVN works), but I'm happy to copy/write the code giving due credit too.

#10 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 17 January 2014 - 04:31 PM

Keeping the means of "Closing the door" right before max view distance is a good idea James.

That does leave a bit of an open question tho and that relates to managing the max view distance value... Just one value for everything, just one for each route, just one for each activity? My own preferences would be, short term, to let end users (or route developers) record as many decisions as practical as route defaults, perhaps in the *.trk file, and later on when the new activity editor & files are being done allow for an optional override to be recorded somewhere in there.

Should weather conditions and/or time of day alter the fog density or the view distance? Beats me.

  • 6 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users