Good day everyone, I had a question regarding the AP Sky and clouds pack. Is there a way to get the clouds to move across the sky, similar to dynamic clouds. I vaguely remember there was a pack from Armstrong Powerhouse were the clouds would move across the sky. I recall the dynamic clouds setting has to be off. The current AP clouds look even better but they are static
That's stated in the manual. This is an interesting topic. I'm currently experimenting with making my own sky. As much as I like AP sky, I wanted to have an alternative that works with all default and route specific weather patterns, so I don't have to edit scenarios. I also wanted to learn a bit more how things are working exactly, and for me immersion mainly comes through good lighting, not textures. Also, I needed a sky that works in southern regions with high standing sun at noon (AP sky causes way too long shadows at noon on Cajon for example - switch to 3D weather to see how it must look like (3D weather / Dynamic Clouds renders the sun at the exact position based on scenario date and route latitude, whereas AP/ToD can only define four different days representing each season). The ToD sky is a dome, with three layers that can display cloud images. The weather pattern determines the transparency of these layers, they are called Wispy, Thick and Storm layers. AP uses a "hacked" skydome that splits the Wispy layer into three bands of clouds that circulate around the player. Now for my testing, I have applied the AP TimeOfDay definitions and all the colours to the Kuju\RailSimulatorCore sky. It didn't look right, I wasn't getting the blue upper sky that AP has though I used the same colour values. The sky itself is made up of two colours you can choose (for eight different times of a day), Upper And Lower sky. A gradient value determines at which height the colour transition takes places. A clear blue sky is usually brighter, almost white at the horizon and gets darker, deeper blue the more you look up. The gradients AP used didn't match. I found they are depending on the radius of the skydome model itself, and after a lot of testing I found dividing all these values by three gave me the exact AP colours in the default sky. The AP skydome is three times bigger (probably to support the high res cloud textures - this might be the reason for some glitches found in certain circumstances (huge shadows appearing out of nowhere). Now back on topic. The TS ToD system has a drawback. If the wrong wind direction and speed is chosen, the according hemisphere will tilt in the wrong direction, exposing the skydome background. As the fair cloud wispy layer only rotates horizontally around the player, it is not affected (but will move into a weird position if the other layers rotate.) This is what happens when wind moves the layers into the wrong direction, I have not yet fully explored why that happens, and if the route origin coordinates have anything to do with it too. Official Steam store screenshot, "Rascal and Cottonwood". Here you see the effect, and why AP does not rotate the layers using wind. The bug is caused here because DTG did only rework the RailSimulatorCore and RailSimulator (ELAP) sky - the RailsimulatorUS update was never finished (there's experimental skydomes in the RSC\CajonPass folder but they were never used. Also some US locos don't have dynamic light casting headlights, only textures). So the core weather blueprints "1. Clear", "2. Cloudy", etc. were all updated but now incompatible with the old pre-TSX US skydome (TSX=rain effects and dynamic lights/real lightsources), that was introduced with RailWorks 3 - now hidden as "DynamicLights" in the settings menu.
... continued. The core sky lets you rotate all layers, in this example you see the clouds moving over you head, actually two layers (the "Thick" cloud layer and a, by weather pattern definiton, semi-transparent "storm" layer) moving in different directions. What still puzzles me is that you can only specify one wind direction, so I'm not sure based on what information the second layer rotates. Weather: Core, "14. Overcast Showers" on Core skydome using AP colours, looking straight up
Another demo. The default DTG sky, Academy TimeOfDay, weather core "2. Cloudy". The cumulus layer just moves along the horizon (same as AP Fair cloud), it seems it is only affected by WindSpeed, direction fixed - always clockwise (to be verified). The other layer is moving according to speed AND direction set, so that's that mystery solved. Of course, the images AP uses are not meant to be moving over your head, which would lead to strange distortion / unrealistic effect. Note that the sky colours for the "dusk" section are too dark for the sun still up (and its white glare colour also looks unrealistic at evening). (The ToD sky colours and ambient light are independent from the sun (You could have black sky during day and white at night), and must be carefully composed to match the sun's position. That's why the AP pack is worth the money for the colour defs alone. Which is 4 seasons x 8 times of day (BreakOfDawn, Dawn, Morning, Noon, EarlyEvening, Dusk, Night, Midnight) x 10 colour defs per time of day (UpperSkyColour, LowerSkyColour, SunGlareColour, SunLightColour, CloudColour, MoonLightColour, BackFillColour, UplightColour, AmbientColour, FogColour) = a palette of 320 hand-picked colours!) Before I was aware of this, I thought "why is the cab of the GP38 on N-Line so bright?", only to find out it's not the engine but the TimeOfDay Ambient Colour value that's very high on the N-Line ToD blueprints - on the original Bristol Exeter it's even set to full 1/1/1 values, leading to overexposed textures. That's why DTG introduced the "Ambient/Contrast/Sunlight" sliders in the options, to be able to adjust these colour intensities on the fly. And a second completely different system which is more based on realtime calculations than on preset colours and sun azimuths - SilverLining aka DynamicClouds / 3D weather (only this offers realistic midnight sun on northern routes like OldVern 's Sulitjelma or the Narvik route. The TimeOfDay sun path is a circle thats fixed at East/West and can be tilted by specifying the azimuth, but cannot simulate the real path of the sun, which has sunrise moving to NE and sunset to NW in northern summer - and if you're far enough in the north, see the sun in the North at midnight ) Technically speaking, the ascending/descending nodes are fixed in TimeOfDay, and dynamic in DynamicClouds.
I know it's off topic, but just a demonstration what 3D weather can do (and TimeOfDay/AP cannot) I've created a new route, at 72°N, above the polar circle, thrown in some core assets quickly. Some location in Norway Three images at 10PM, midnight and 3AM. Facing north. Kinda cozy place
Finally, my AP-coloured RailSimulatorCore sky, adapted to US daylight times and azimuths, which handles all non-AP weather patterns. Additionally removed the blue fog from "2. Cloudy" core weather. Took me three days until everything looked well. That sky is roughly applying to regions between 30 and 40° north, I'm using it for the chinese routes too. By just changing the sun and moon azimuths from negative to positive, I'm using that sky for southern hemisphere routes like the South African ones and NZ Midland Line.
I'd much rather take everything the AP weather offers than lose all of that just for date specific sunrise/sunset times of the 3D weather...!
Interesting topic indeed, I always liked the dynamic 3d clouds, especially in mountainous routes but they fell out of favour.
Yes, whilst being real clouds you can drive through, they still do not look as real as a photograph. Even TSW's clouds look a bit artificial.
You can use both, that's the good thing I don't know of any other sim that offers two environments to choose from. I'm praising the advantages of both here. If you set a scenario to use "3D 2. Cloudy", it will use Silverlining when DynamicClouds are enabled, and "AP Fair Cloud" when disabled (as AP copies its FairClouds weather to Kuju\RailSimulatorCore\Weather\RW_Cloudy.bin, which is the fallback weather when DynClouds are disabled) Like I said, it's an OCD thing and became apparent when driving on far northern routes where I wanted to see those white nights, and I wanted AP weather on Cajon, but with that high standing and short-shadow casting desert noon sun Adapted AP sky colours for Cajon Pass (and mid/southern US routes). High sun. Desert feel
"Like I said, it's an OCD thing and became apparent when driving on far northern routes where I wanted to see those white nights, and I wanted AP weather on Cajon, but with that high standing and short-shadow casting desert noon sun" Is this not possible just by amending the AP ToD sunrise/sunset and azimuths? Bypassing 3D weather altogether?
That's what I did for the US AP sky. Edited the azimuths, sunset and sunrise based on San Francisco and adjusted all TimeOfDay times (BreakOfDawn etc.). But you can't have polar days for northern routes, as the sun must set in TimeOfDay. This is only possible with 3D weather. I have actually contacted AP to release an official "southern" pack. Current AP sky is based on 51° degrees N (London), if they released a 35°N pack we'd basically have all routes covered. There's only two "tropical" routes that I've made special blueprints for, that's Miami and Livonia sub, where there's almost no seasonal differences in daylight (That's why Livonia uses "TimeOfDay\Default.bin" for all seasons....) Current Ap sky is also ok for routes near the US/Canadian border, like Stevens, Marias, HiLine, CMP, Yellowhead, etc) Legacy CP looking so much better... it's all about lighting
Of course! And yes, that's another annoying part of the old ToD in that the sun always has to rise exactly east and set exactly west.
Initially there was only one season, that's why RailSimulatorCore\Default.bin is still there. Still nice to see what is possible with the ToD system.
Hi Spikee1975, just to clarify, to get the correct sunrise and sunset times and the correct angles and to use the AP weather enhancements, you need to use a 3d weather pattern, and dynamic clouds disabled, is that correct? Just getting a little confused, and want to use the enhanced AP weather and the dynamic time of day.
The thing with moving clouds on a sky dome, as opposed to the silverlining is that in real life, because of perspective, the clouds near you seem to move at a different speed than clouds far away. So my preference is to pretend it’s not a particularly windy day. It’s a game after all, so you have to accept a level of make believe.
Much of the stuff I tried to figure out myself is actually explained here - hidden in the "TS2012 New Features" section of the dev docs Quoting: SkyDome The skydome is set up as per documentation but with support for a few new layers. The hierarchy is now: 1_0000_skyhack 1_0000_cloud_storm 1_0000_cloud_wispy 1_0000_cloud_thick 1_0000_cloudband_1 1_0000_cloudband_2 1_0000_cloudband_3 1_0000_stars The new layers here are ‘cloudband_1’, ‘cloudband_2’, ‘cloudband_3’ and ‘stars’. The background sky dome hemisphere (skyhack) uses TrainSkyDome.fx Three Cloud layers (cloud_storm, cloud_wispy, cloud_thick) uses BlendATexDiff Stars layer (stars) uses Stars.fx 3 new cloud bands (cloudband_1, cloudband_2, cloudband_3) uses BlendATexDiff For the three new cloud bands, cloudband_1 is drawn first, cloudband_2 is drawn second, then finally, cloudband_3 is drawn. Previous we could not represent Cumulus clouds in the skydome, as the original 3 layers rotated about all axis. These three new cloud bands only rotate around the Y axis allowing the clouds to always appear on the horizon. The speed at which these three new bands rotate is linked to the wind speed set-up in the blueprint. The stars layer is a simple sphere with generic star map applied. The shader supports transparency, so therefore the alpha channel of the stars texture should predominantly be black with white pixels representing the stars.
Spikee1975 Great work on the skyboxes, and some very interesting insights as well. Are you planning on releasing some of your patches, not just limited to this topic? I could probably reverse engineer them from the messages on this thread but it would be very convenient for myself and others to have them ready to use? Just the TOD files to implement in routes manually would be very useful for me.
I'll post an excel sheet later (I won't distribute the files as they contain payware, the 320 colours palette from AP). One with values to put in the ToD files for US-adaption of APSWEP, and another one if you want to use the Core sky like I do which is compatible with all non-AP weather blueprints. (Incompatibility comes through the AP skydome being three times bigger than DTG's, resulting in too fast moving clouds.)
