I wonder what Truesky does to make their volumetric clouds perform quite nicely. Anyways good job and keep up the good work, looking forward to weather updates.
Weather is actually my current focus, I’ve been testing the material function that applies snow/wetness following the corresponding precipitation. (No particles in yet.)
Still tweaking the snow shader, a more updated iteration than the first gif in a testing stage:
Also, I just received word that 4.13 is due right around the end of August/beginning of September. I had planned on submitting my finished build of Orbit around August 7th, hoping to pass it through the quality assurance process and have it on the market around the beginning of September. With the new engine version coming right around the same time, I’m considering waiting to submit Orbit until the newest engine version comes out, putting it on the market closer to the middle/end of September, but I wanted to get some input from anyone interested to see if there’s a demand for it to be on 4.12. Let me know your thoughts, and thanks again for all your feedback and support.
Make sure its 4.13 compatible and release it like you were going to, or do you need the actual 4.13 to make it compatible?
It’ll likely be 4.13 compatible as it is, you’d just create the example project in 4.12 and migrate the Orbit folder to a 4.13 project until I updated it for 4.13. That part I’m not too concerned with, the main thing I’m thinking of is the possibility of Epic’s native volumetric lighting/fog iteration being implemented in 4.13, if theirs performs better than mine (which I have absolutely no doubt that it will) I’ll want to migrate the control parameters over to it and remove my implementation from Orbit. I just don’t know for sure if it’s even going to be in the engine, what all features it’s going to have if it is, how it’ll perform, etc, and so getting all that squared away immediately after releasing the 4.12 version would be a bit of a scramble, and in addition swapping out the volumetric lighting/fog effects immediately after release may come off as inconsistent or misrepresentative of the product, and I want to avoid situations like that, I definitely want to approach this as professionally as possible.
I’m not saying either situation is impossible, I’m just wanting to make sure I act on the best interest of the system and the people who want to use it.
I am fine with 4.13 
Idk if its possible, but maybe you should add a poll
I’ve created a poll here. Something I forgot to mention in my other post but is included on the poll, landscape tessellation may be iterated on for better performance in 4.13 as well according to some speculation, this system would benefit greatly from that as the snow shader utilizes tesselation on static objects currently, and can be used on landscape as well, but at a heavy performance hit. (I’ve been exploring landscape WPO + parallax occlusion mapping as a substitute in the meantime.) I’ll also update the OP with a link to the poll.
Hey @ -
Got a few questions -
- Does Orbit work well with extremely large maps that use the World Composition toolset?
- Would it be possible to sync the current weather state over a network via a manager class?
Hi there HeadClot 
Orbit works well with very large maps, I’ve tested some rather large landscapes very recently with my focus shifting towards weather effects on materials (including terrain) using material functions, and it performed at the same pace and quality as it did with smaller maps. Parameters are exposed to allow you to control the scale of each individual piece of the system, (dynamic stratus clouds, backdrop clouds, starsheet, sky coloration sphere, moon and sun) so you should be very easily able to scale the system up to whatever world size you like.
I’m not super familiar with networking, so I’ll try to answer this to the best of my abilities: I’m building the framework for the runtime stuff as soon as I finish the visual construction of this system. The plan is to allow for the user to select from weather patterns or create their own, and then have the user set the probability of each weather pattern being called. When a particular weather pattern (likely to be identified via an enum stored in array) is called at runtime, it’ll fire into a struct that will contain the necessary variable values to form that visual weather pattern.
So yes, as I’m typing this out it’s clicking (at least in my mind) that a manager class could store the same enum array > struct layout, and then fire out the struct information to the clients (if that’s the right word, the players, I guess) which would be awaiting that data anyway to display the proper weather values synchronously.
Snow is coming along nicely:
That looks really nice.
I’m excited for this package, actually as far as I can tell, extremely clear and an advanced. I’m looking forward to it.
Fanstastic job on snow, i like how separated is its buildup. As to previous reply above i would add +1 if you implement straight forward multiplayer for it, just something simple that would synch the weather across all clients (does not need to be identical at all, just that the weather states are following each other).
Maybe as a part of constructive opinion from Ultra dynamic sky, to make night look good you should make system to use as little as skylight in nighttime as possible, which should turn night properly dark. I havent seen any of your screens of nightime yet, but that is main missing link on Uds.
Thanks!
While the goal is to have initial set up be as simple and quick as possible, there is a plethora of options available for customization of all portions of this system, and as such I’ll be including documentation with the release.
Thanks for your interest and support!
Thank you!
I’ll certainly do my best with implementing multiplayer support, I’ll have to do some research first.
As for the skylight portion, I’ve got you covered there, I’ve set up skylight parameters for overall intensity, as well as night-time darkness, so you can tweak how light or dark you want your nights to be without having to edit any curves or recapture your skylight.
Cheers!
Alright, poll results suggest the general consensus is that release for Orbit should be put off until 4.13 is released, pending confirmation of system-friendly engine features being implemented by then. I’ll be tentatively saying that this system will be released around mid-September. Thanks everyone who voted!
My wife and I took some vacation time last week, so I stepped away from development stuff as well. Came back late last night and worked on some rain stuff, still lots of work to be done but the groundwork is there.
Please tell me your making it so rain and weather doesnt go through walls or roofs of buildings so there is a smooth transition to the outside and its not raining in your house?
Definitely! Depending on performance, I may end up applying a physics check to each rain drop, which will result in the raindrop sprites being killed upon collision with an obstructing actor. If performance doesn’t allow that, I’ll use a trace-technique instead.
As for wetness, the effect is actually applied per-material using a material function, so keeping things from getting wet under cover simply requires that materials under cover not utilize the material function that applies wetness/snow.
Still working on ground splashes, not quite ready to show off, but rain drop collisions work.
