4 Easy Cloud - Prepass

Started by WAS, November 04, 2018, 10:12:15 AM

Previous topic - Next topic

WAS

Should this prepass really be blank 4 hours in? I got tired of fighting with v3 customs and just threw in some easy cloud layer types and so far middle of the night, (ehh morning, it's 7:12...) 4:13:00 in and it's blank still. 5 v3 clouds only took about an hour to prepass for me. Calculations? Collision of preset base alts? I'd imagine their preset alts would have been all tested together? Not sure if I should cancel.

There is a lot of surface reflection but no Ray tracing.

Oshyan

Literally impossible to say without looking at the scene file. Knowing you're on low-end hardware and, especially, with limited memory, and that you've said in the past you don't think swapping to disk is something that must be avoided at all costs, I'm honestly not that surprised. Especially with lots of cloud layers.

And no, the layers have not been designed not to intersect, why would they? In real life the altitude ranges of cloud types overlap. It's not as if they're all meant to be used simultaneously in any given scene, so there's no particular reason to correlate their altitude ranges to each other. Realism is the goal. The mid-level ones are all at the same altitude, and so are the low level ones, just with different depth values.

- Oshyan

WAS

#2
Quote from: Oshyan on November 04, 2018, 09:52:17 PM
Literally impossible to say without looking at the scene file. Knowing you're on low-end hardware and, especially, with limited memory, and that you've said in the past you don't think swapping to disk is something that must be avoided at all costs, I'm honestly not that surprised. Especially with lots of cloud layers.

And no, the layers have not been designed not to intersect, why would they? In real life the altitude ranges of cloud types overlap. It's not as if they're all meant to be used simultaneously in any given scene, so there's no particular reason to correlate their altitude ranges to each other. Realism is the goal. The mid-level ones are all at the same altitude, and so are the low level ones, just with different depth values.

- Oshyan

Well technically cloud-types are very much limited to altitude zones by ambient weather, as it's pressure layering the drives their types. It's wind up-draft currents that augment that, which isn't seen everywhere all the time, and more a "altitude offset" sort of thing. In fact the names and descriptions of these altitude-piercing clouds like Cumulonimbus or Nimbostratus describe this. All the rest stay within their defined altitude regions unless uplifted into the next region, but will very quickly fade or reconfigure. And for, again, a realistic scene, you'd need multiple type of clouds. It's quite rare you'd see one type of cloud in the sky. Even when it's a pretty clear sky with whisps cirrus, you'll usually be able to pickup some cirrocumulus and cirrostratus.

So if realism is the goal, it's a bit contrary.

It doesn't even use 3gb of my 8gb of RAM so SWAP isn't a issue at all. Doing very small preview renders for clouds as a full will take even longer. Usually when working I do a even lower quality preview which don't work the best as quality is so low shapes get noisy and hard to distinguish.

Oshyan

Funny, your illustration largely contradicts your statement, with stratus, stratocumulus, and cumulus all occupying the same base altitude, not to mention the anvil type (again, base altitude), while altocumulus and altostratus also occupy the same altitude range. Etc, etc. Yes, there are separations between *certain* cloud types, which are reflected in our presets, but otherwise they tend to exist in *altitude ranges*.

- Oshyan

WAS

#4
Quote from: Oshyan on November 06, 2018, 12:19:57 AM
Funny, your illustration largely contradicts your statement, with stratus, stratocumulus, and cumulus all occupying the same base altitude, not to mention the anvil type (again, base altitude), while altocumulus and altostratus also occupy the same altitude range. Etc, etc. Yes, there are separations between *certain* cloud types, which are reflected in our presets, but otherwise they tend to exist in *altitude ranges*.

- Oshyan

I don't think you understand at all.... Pressures and Altitude drive particle creation and their configurations, which give us cloud types. What the chart shows, is how altitude clearly defines type-clouds.

And you also misunderstand what's happening when a cloud enters a new "altitude range" (which is what is being discussed.......), they change. Sure as they enter the new region they stay similar, but capture that in high-speed and you'll literally see the effect of them entering a new atmospheric layer and how they radically change to represent the models of that range (lots of videos of that sort of stuff during storms and even here in WA with our convergence zone which creates low and high pressure zones daily). 

And again, clouds only drive into different altitude ranges due to updrafts, (which create vertical growths). This is why clouds with vertical growth are so common close to the planetary surface. That anvil top demonstrates severe low pressure and updrafts created by bad weather, and not a common occurrence. 

You seem to be thinking clouds just convert when passing atmospheric boundaries, but no, they transform.


Oshyan

Please quote above where I said anything about clouds "converting" vs. "transform", etc. I wasn't talking about that *at all*. I think you're radically misunderstanding my point.

Here's what we're trying to do: provide cloud type presets that are reasonably realistic *aesthetic* representations of real-world cloud types with generally realistic altitude ranges. If you look at your diagram and the default altitudes of our Easy Cloud presets, they correspond pretty well. What we are *not* trying to do is have cloud types automatically change based on altitude, or enforce any kind of accuracy or realism, etc. We provide a realistic starting point, it's up to the user to determine if they want to change that from realistic default or not.

- Oshyan

WAS

#6
Quote from: Oshyan on November 06, 2018, 11:27:42 PM
Please quote above where I said anything about clouds "converting" vs. "transform", etc. I wasn't talking about that *at all*. I think you're radically misunderstanding my point.

Here's what we're trying to do: provide cloud type presets that are reasonably realistic *aesthetic* representations of real-world cloud types with generally realistic altitude ranges. If you look at your diagram and the default altitudes of our Easy Cloud presets, they correspond pretty well. What we are *not* trying to do is have cloud types automatically change based on altitude, or enforce any kind of accuracy or realism, etc. We provide a realistic starting point, it's up to the user to determine if they want to change that from realistic default or not.

- Oshyan

Lol, Oshyan, this whole conversation started about collision and how that is "Realistic" when these types driven by altitude will not collide like that. In fact, the updrafts will push up clouds above it creating "seams" before ambient currents ever mix them over periods of time [and transform them]. And we know v3 clouds slow down exponentially when they collide (I believe it was even you that mentioned trying to avoid that for render time due to computation).

So, it's not only not very realistic, but also terrible optimization wise for people learning this software.

I don't know if they collide or not, but you seem to be saying they likely do and that is "realistic" when they're completely different types just fading into each other... IE, completely contrary to realism.

Oshyan

Nope, once again you're miscontruing my intent and what I believe I have clearly explained. The bottom line: we do not do things *for* the user to avoid lack of realism or collisions or whatever. Multiple cloud types occupy the same altitude range because that is realistic, those same cloud types are shown in those same ranges in the illustration you posted. If someone *chooses* to add several different types within the same altitude range, then yes they will overlap. That's their fault, not ours, and we want people to have the *option* to do as much as we can allow them to do within the bounds of technological limitations. Changing the altitude of cloud layers automatically to avoid collision would not only not be realistic, it would not be intuitive.

- Oshyan

WAS

#8
Quote from: Oshyan on November 07, 2018, 01:06:41 AM
Nope, once again you're miscontruing my intent and what I believe I have clearly explained. The bottom line: we do not do things *for* the user to avoid lack of realism or collisions or whatever. Multiple cloud types occupy the same altitude range because that is realistic, those same cloud types are shown in those same ranges in the illustration you posted. If someone *chooses* to add several different types within the same altitude range, then yes they will overlap. That's their fault, not ours, and we want people to have the *option* to do as much as we can allow them to do within the bounds of technological limitations. Changing the altitude of cloud layers automatically to avoid collision would not only not be realistic, it would not be intuitive.

- Oshyan

I'm not talking about adding multiple types/seeds to the same altitude but utilizing the High, Medium, and Low easy cloud, or generic presets, one of each for a basic atmospheric setup (preferably easy cloud since it can give the best out-of-box shapes). I'm not talking about a mess of clouds and those same-zone clouds, but whether adding those three presets for each altitude range by default would slow down TG because the alts cause collision between the v3.

Again, they don't collide in real life, they float within their regions UNLESS an external force drives them into another atmospheric range. The pressures that literally form the particles and configure them change from atmospheric layer to another. And even than they don't just mesh together it's like fluid dynamics with oils. They resist each other until they're transformed and mixed. This is also why, ironically, fluid dynamics is used to study clouds.

Even with clouds of the same altitude you can see division between froms colliding because of these same dynamics at a small scale between cloud types, but that's some serious work to recreate.

My only concern is users like myself unaware of why a scene is so slow, because of collision of clouds. This should really be noted that heavy cloud types fused together create huge slowdowns, and you can create a relatively similar look, with a lot less render time subtracting noises so there is some collision but not to a great internal extent.

But as for realism, clipping altitude ranged clouds is silly, Oshyan, simple as that, it's not realistic in any sense unless you're going to simulate the fluid dynamics. Lol best to have that ever so slight offset that no one is going to really notice but will save literally greatly on render times when slapping in "Easy Clouds" for diff alts.

Oshyan

Decided to test your assertions. I added 1 cloud layer in each altitude range using the Easy Cloud presets in the default scene, High Level: Cirrocumulus, Mid-level: Alticumulus Castellanus, and Low-level: Cumulus Medium. Then I tilted the camera up to get a mostly-sky view. First render was 4m36s. Then I increased the base altitude of the top 2 layers, ensuring there was no overlap. Render time was 4m45s. Slower than with them closer/potentially overlapping.

Re-tested with Cirrocumulus, Altostratocumulus Large, and Stratocumulus, and then again with Cirrucumulus, Altocumulus Castellanus, and Cumulus Large. Similar results in all cases, i.e. render time is basically the same for default altitudes vs. enforced greater spacing. In fact it tends to be slightly *longer* for enforced spacing, though I don't think this has anything to do with the overlap issue, more likely to just be more cloud visible since the thicker clouds get put at higher altitude. So yeah, I don't see a problem here.

Which suggests there is a problem in the file you're using and encountering slowdown in. Possibly it's due to overlap (which can but does not always cause a lot of slowdown), possibly it's due to other settings. We'd have to look at the TGD to be sure. And in any case the defaults are fine.

- Oshyan

pokoy

I have a scene where a distant cloud layer causes excessive render time increase. Good to know overlapping clouds may cause this, I've been scratching my head over this for a while now...

WAS

#11
Quote from: Oshyan on November 07, 2018, 02:38:58 AM
Decided to test your assertions. I added 1 cloud layer in each altitude range using the Easy Cloud presets in the default scene, High Level: Cirrocumulus, Mid-level: Alticumulus Castellanus, and Low-level: Cumulus Medium. Then I tilted the camera up to get a mostly-sky view. First render was 4m36s. Then I increased the base altitude of the top 2 layers, ensuring there was no overlap. Render time was 4m45s. Slower than with them closer/potentially overlapping.

Re-tested with Cirrocumulus, Altostratocumulus Large, and Stratocumulus, and then again with Cirrucumulus, Altocumulus Castellanus, and Cumulus Large. Similar results in all cases, i.e. render time is basically the same for default altitudes vs. enforced greater spacing. In fact it tends to be slightly *longer* for enforced spacing, though I don't think this has anything to do with the overlap issue, more likely to just be more cloud visible since the thicker clouds get put at higher altitude. So yeah, I don't see a problem here.

Which suggests there is a problem in the file you're using and encountering slowdown in. Possibly it's due to overlap (which can but does not always cause a lot of slowdown), possibly it's due to other settings. We'd have to look at the TGD to be sure. And in any case the defaults are fine.

- Oshyan

This assertion contradicts many conversations on V3 clouds and collision where slowdowns were tracked to dense v3 clouds mixing because of their calculated lighting model rather than simple fake scattering ignoring other clouds.

I mean I can take a v3 ball, and overlap with with another v3 ball and have exponentially greater render times.

What you are establishing is lighting model interacts in render time via altitude alone (which makes sense, different angles, shadows, etc), you weren't at a median of the cloud setups ensuring clipping, were you (if any?)?  I'll have to test.


Matt

#12
1. The more layers of Easy Cloud or Cloud Layer V3 you have in the scene, the longer it will take to render. This might have a more pronounced effect in the pre-pass.

2. This can be mitigated by the "Cloud GI max ray depth" parameter in GI Settings, which should be kept to 1 or 2 if you're experiencing slow renders.

3. When layers of these cloud types get close to each other, this tends to increase render times even more.

4. Overlapping cloud layers are worse than non-overlapping layers.

5. If you add multiple cloud layers (even from different presets), they might overlap. However, if you only choose one "high altitude" preset, one "mid-level" preset and one "low altitude" preset, they won't overlap *except* if the lower cloud is the "Cumulus, Large" preset.

6. In general, when cloud renders become slow, try lower values for "millions of voxels" on each cloud layer.
Just because milk is white doesn't mean that clouds are made of milk.

WAS

#13
Quote from: Matt on November 07, 2018, 04:26:39 PM
1. The more layers of Easy Cloud or Cloud Layer V3 you have in the scene, the longer it will take to render. This might have a more pronounced effect in the pre-pass.

2. This can be mitigated by the "Cloud GI max ray depth" parameter in GI Settings, which should be kept to 1 or 2 if you're experiencing slow renders.

3. When layers of these cloud types get close to each other, this tends to increase render times even more.

4. Overlapping cloud layers are worse than non-overlapping layers.

5. If you add multiple cloud layers (even from different presets), they might overlap. However, if you only choose one "high altitude" preset, one "mid-level" preset and one "low altitude" preset, they won't overlap *except* if the lower cloud is the "Cumulus, Large" preset.

6. In general, when cloud renders become slow, try lower values for "millions of voxels" on each cloud layer.

Thanks Matt. This is what I assumed the scenario was from the get go. Also you narrowed down my specific issue with the "Cumulus, Large", which I also raised density on so I probably had more exaggerated clipping than in a default scenario.

It's good to know the clouds all should be working fine at their altitudes, just in my case having opted to use the "Cumulus, Large" coupled with higher coverage and density. I understand that the Cumulus has a lot of extra bits to create those nice Cumulus tops, so that "Growth" probably pushes their maximum up?