With so many wonderful nice Skydome textures made by Claus Visby Overgaard, it made me wonder something... Why not use them in different seasons without changing out ORTS content?
Instead can Routes have there own environment/season content folders where if present in the selected routes OpenRails subfolder seasons ORTS overrides using the routes .png files instead of ORTS content folder? Would be helpful for those that like updating to next experimental updates without all the copy pasting an just a click of changing seasons when not using MSTS Environments.
ORTS Skydome & Custom Seasons
#3
Posted 29 October 2017 - 06:32 AM
Yes, a great idea. Different routes, different times of year, different weather conditions, even different times of day may look better with differing skydomes. Maybe even a method to transition among skydomes during an activity would be nice? If you think about it, a lot of the new "optional" skydomes are really a way of modifying the appearance of the sky to replicate differing weather conditions that the "standard" skydome just can't render very well.
#4
Posted 29 October 2017 - 11:14 AM
What it sounds like you guys are asking for is to have the Activity files specify the skydome. IMO that's where it should have been from KUJU on Day 1 and if not then Day 1 from Open Rails. You know.,.. OBVIOUS.
IMO a large portion of OR options should be Activity based.
IMO a large portion of OR options should be Activity based.
#5
Posted 29 October 2017 - 12:49 PM
I think the best long-term solution would be a global dynamic skydome based on time of day (which implies adjusting for the time of year based on lat/long) and volumetric clouds based on weather coupled to ground textures based on the four seasons. FSX does this with 140 32 x 32 pixel sky bitmaps which change out as appropriate. Then you just don't have to worry about it. The sky just behaves like a sky should. Think of how the Earth works, not how a background on a model train layout works. The "model train" mindset that has plagued MSTS and its derivatives since day one is probably becoming its biggest long-term drawback, in my opinion.
I could see the route-based idea as a workable interim solution, though, because just creating the necessary graphics for the other approach would take some serious time. Unless there's a way we can have the sim dynamically blend images together? We could probably get by on a relatively small set of images then.
I could see the route-based idea as a workable interim solution, though, because just creating the necessary graphics for the other approach would take some serious time. Unless there's a way we can have the sim dynamically blend images together? We could probably get by on a relatively small set of images then.
#6
Posted 29 October 2017 - 02:17 PM
Yes, a lot of what goes on should be activity-based. As for the weather part, it absolutely should. Weather data should include more of just how it looks, too. I've long advocated having wind speed and direction, outside ambient temperature, etc. to be part of any weather module. Then other things in the sim (for example, engine coolant temperature) could then be influenced by the weather condition. Compared to rendering visual stuff, the calculations needed for temperature, for example, would use little processor time.
#7
Posted 29 October 2017 - 02:24 PM
ATW, on 28 October 2017 - 08:13 PM, said:
Instead can Routes have there own environment/season content folders where if present in the selected routes OpenRails subfolder seasons ORTS overrides using the routes .png files instead of ORTS content folder? Would be helpful for those that like updating to next experimental updates without all the copy pasting an just a click of changing seasons when not using MSTS Environments.
But .. MSTS has support for different sky for each season. Sky is defined in env file and each season can have it's own .env file.
#8
Posted 29 October 2017 - 04:20 PM
Perhaps just a series of .env files can be made for activities (or better yet, as common sets) with different weather characteristics that could transition to eachother at times set in the .act file?
#9
Posted 29 October 2017 - 06:58 PM
I don't think some of you guys have any idea of how many different appearances of clouds there are... IMO there is no way a project like OR should waste its time trying to do World-of-Clouds. Leave it to the route builder to pick something that approximates "looks kinda right" and hope the OR team gets around to moving Skydome.png out of it's status as The One Solution into a route specific skydome, or a route-seasonal skydome, which would be better, or route-seasonal-activity skydome for the ideal. Tie starting time of day, sun illumination, current precipitation, current ground appearance, and cloud density to the activity as well and IMO we'd have all the bases covered.
#10
Posted 29 October 2017 - 08:20 PM
Oh, I do, hence why I said it would definitely be a long-term idea. That said, I must confess that I forgot how well OR handles the sky for a bit - the atmosphere, sun, and moon, that is. It's superior to the FSX system of frame-by-frame texture sequences in every way. The only complaint, now that I think of it, is that the sun seems to go retrograde at times. While I do think that 3D clouds a la FSX would be the ultimate solution for clouds, for now, the activity-based variable skydome solution is probably perfectly adequate.