I'm sorry if this has already been covered but I keep coming back to this and I just cant see how the "Cloud Fractal Shader v3.01" relates to the cloud output (in this case "Cumulus layer 01"). Clouds are generated where there is no white and are not generated where there is ... sometimes ... in each case.
In the screen grab below there are two View Windows (thanks for those PS, very useful) opened up at the same scale and height with the camera in the same place etc. One shows the final cloud positions (the upper right window) and the other shows the seed fractal used to generate it (the lower right window). The are very different although there are similarities (centre top left blob matches very well) but other areas are completely non-matching. I can only assume that there must be some invisible data within the seed fractal that adds and subtracts from the final output or that there is more going on within the Cloud layer than meets the eye.
Nothing else matches TG's clouds particularly the cumulus clouds but it is such a difficult process to get a desired result. Any light that can be shed on how the cloud density shader is interpreted would be great because it certainly bares very little relation to whats on the screen:)
Thanks
Richard
Then I'll move my response as well ;D
I also run into these kind of problems often.
Distance shaders and/or blendshaders working unpredictably for example.
In your case, what is the setting for cloud coverage adjust in the cloud-node self?
Martin
Quote from: Tangled-Universe on August 18, 2008, 08:33:41 AM
I also run into these kind of problems often.
Distance shaders and/or blendshaders working unpredictably for example.
In your case, what is the setting for cloud coverage adjust in the cloud-node self?
Martin
Hi Martin
I just moved my answer and your quote over from image sharing as I posted in the wrong place and you answered so fast :)
Yes there is an internal logic behind all this that eludes me and I keep running into it. In the above example the coverage adjust is left at
1 in both the cloud layer and the density seed.
Richard
Quote from: cyphyr on August 18, 2008, 08:41:47 AM
Quote from: Tangled-Universe on August 18, 2008, 08:33:41 AM
I also run into these kind of problems often.
Distance shaders and/or blendshaders working unpredictably for example.
In your case, what is the setting for cloud coverage adjust in the cloud-node self?
Martin
Hi Martin
I just moved my answer and your quote over from image sharing as I posted in the wrong place and you answered so fast :)
Yes there is an internal logic behind all this that eludes me and I keep running into it. In the above example the coverage adjust is left at 1 in both the cloud layer and the density seed.
Richard
If you lower the coverage adjust in the cloud-node self the problem might be gone.
I also had this once when the distance shader wasn't working. You can consider this setting as a sort of "override" for the coverage setting from the cloud fractal shader.
Martin
Thanks, that went in the right direction but they are still not really relating to whats on the screen. I did a very rough test with an greyscale image map shader instead if the density fractal and that works exactly as expected. There is cloud where there is white,there is not where there is black and grey areas are relatively less cloudy. Therefore I deduce that the density fractal is not working on a simple boolian (is, is not) basis.
Richard
...and I'm seeing weird stuff with the Distance Shader.
From Oshyans last answer in the Cloud Overhangs thread he said
QuoteI'm fairly certain the cloud function accepts 3D, volumetric information, but how it treats it can mess with explicit shapes if you don't turn off all the tweaks (flatter base, etc.). I've seem pyramids done with clouds, and an inverted pyramid would be an overhang basically, so I do think it's possible.
..and when coupled with...
QuoteI was always under the impression that the density fractal sent a 3D perlin noise to the cloud shader, and then some of the tweaks such as Base wispiness and Invert profile would modify how the cloud interpreted the noise.
By old_blaggard in the The Elusive Billowing Clouds thread
I'm assuming the Density Fractal shader noise has to somehow progress over Y, probably through noise phasing (ie animating through Y not time). If this is the case, then having a 2D representation of the Density Fractal output, will only show one frame of that phasing. Couple that with what ever else is going on to round off top and bottom fall-off on the white to give a cloud a 'rounded shape' through Y, then I'm not really surprised that the Density Fractal isn't showing the full plan view of a cloud shape.
I've also discovered, that if a I want a specific shape for a formation of clouds, by blending in an Image Map shader into the Density Fractal, does allow me to form the X/Z shape quite accurately, but you do have to bump up the Density Fractal coverage to fill in your mask, ie with fewer gaps. What would be good for me to know, is how I could possibly warp the height of Y with a larger scale of fractal to take out a lot of the uniformity seen from low orbit.
http://forums.planetside.co.uk/index.php?topic=4680.msg48866#msg48866
Quote from: calico on August 18, 2008, 09:55:12 AM
...and I'm seeing weird stuff with the Distance Shader.
Out of curiosity and a desire to learn, why are you using a distance shader?
I don't have problems with the distance shader very often. It can be a little anti-intuitive but I find that generally once I have my views set up properly I can get it working ok.
For using the distance shader this is my work flow.
1. Add the distance shader
2. Add a new camera (generally I name it node ... (since its got sod all to do with being a camera really ;D)
3. Double click on the relevant cloud layer or surface shader and click in the little square blue button next to the nodes name to open up a new View Window.
4. Open the Blend Shader (or Distance Shader if its the only shader being used in blend mode) and click on its square blue button.
5. Pause the main 3d preview window
6. In all open View Windows zoom out to a useful height (8km or 16km seems a good place to start)
7. now I can move the "node camera" about and set useful min and max distances.
I'm fairly confident that the distance shader returns values of between 0 and 1 where 0 is black and 1 is white (maybe its the reverse) and can be used in a very similar manner to a normal alpha map.
I'm also becoming "fairly" confident (well not actually, bit of a guess really) that the fractal shaders produce values below and above black and white (0 and 1) which are not (can not?) displayed on the screen. This would be similar to the way HDR images (.exr etc) work in that there is much more pixel value information available than is shown on a computer screen. This would account for clouds appearing where there was no evidence of any relevant seed source since (for example) a value of -1 blended via an other value of -1 will give a final result of 1 (not -2) so an area of fractal coverage that is shown as dark (ie no information visible) in fact dose contain negative data which when blended with more negative data (a blend shader with similar negative dark areas) will produce a positive (ie white-ish).
basically
-1 blend -1 = 1 not -2 or -1
or
-2 blend -2 = 4 not -4 or -2 or 0
(i know the math is technically wrong but I hope you get my point)
I know the above is a bit waffleish but since I don't really know whats going on here its the best I can come up with.
Richard
Ok, so you are using the Distance Shader as a type of focal plane, ie distance cutoff on where clouds are made? To reduce processing/render time/scene requirements?
yep or to isolate a particular part of a shader be it cloud density or displacement or texture.
Richard
Ta. Pretty obvious really ::)
Thanks Richard. But, here's something practically confusing for me about the Distance Shader, which seems to defy logic -
Two Distance Shaders
The first Distance Shader goes into the Density Shader as a Blender for the First Cloud.
The second Distance Shader goes into the Density Shader as a Blender for the Second Cloud.
First and Second Clouds are nearly identical, even to the Seed of the Density Shaders. The only major difference is that the First Cloud is higher than the Second Cloud by about 1500M.
First Shader:
Near (Black) = 0
Far (White) = 3000
Second Shader:
Near (White) = 1900
Far (Black) = 5400
In order to isolate these clouds, I assumed that this combination would eliminate anything in the foreground and anything behind the section of cloud I want, which would leave the cloud approximately between 1900 and 3000. Instead, what works is to reverse the First Shader so it's like this -
Near (White) = 0
Far (Black) = 3000
Why?
My brain is not up to par today ???
Could you post a screeny or the tgd please.
Richard
Although remember that the distance shader in default mode is SPHERICAL with its centre at your camera. Therefore the higher clouds will be laterally closer to your viewpoint than the lower camera. This is one reason to use a separate camera for each distance shader. Try this for each distance shader and move their source cameras up to the height of the clouds.
rICHARD
Thanks for taking the time. I'm in no hurry. What I have is working, but doesn't seem logical and I've been working on this for weeks. ;D
The highlighted cloud shader is the First Shader. The other...yes, it's the Second Shader. LOL Sorry. My brain is working on a few things, too.
Well for a start you'll need to plug in your distance shader to some sort of camera, render cam or otherwise.
Richard
Well, it's working, though. I have successfully isolated the cloud.
I'll try it with a camera to see if it then works logically.
Back to the original question in the thread: I've done some experiments to confirm what I originally thought. Hetzen is basically correct: the cloud shader is fed a bit of 3D noise from the cloud fractal. The cloud shader give a complete image of the shape of the clouds. The density shader only lets you see one plane - specifically, the X-Z plane with Y=0. This is true for all shaders - when you have no displacement applied, you will always see what the shader looks like at Y=0. You can confirm this by using a transform shader to subtract the cloud altitude from the density shader's Y position, and you will get the shader looking more similar to your actual cloud distribution.
@ob - Title says Cloud Confusion. This is a Cloud Confusion - the Distance Shader doesn't seem to work as prescribed.
Cheers OB, this is finally starting to make sense.
I can now use the transform shader to sensibly preview cloud formations. Brilliant ! :D ;D
Attached is a low octave cloud structure (just for simplicity) and screen cap.
The top window in the input seed density fractal. As you can see there is mismatch!
The window below is the final cloud output, and on the right is the density fractal transformed -2000 (the altitude of the cloud layer).
As you can see although the match is not perfect its good enough for jazz :) nice...
Thanks
Richard
ps gona go back and cross out my wild ideas ::)
Interesting discussion. You might consider this a bug in that the "shader preview" for the cloud noise seed is not showing what will actually be produced, however (and unfortunately) in a technical sense it is correct as the cloud noise seed (and any other noise function) can only ever show one point in the 2D noise plane, and the shaders that depend on it later in the chain may sample elsewhere in the shader. Since you can connect 1 shader to multiple other shaders, there would be no way for the shader to determine how to offset its preview display, thus using 0 for altitude (Y) makes sense. It's one of those counterintuitive things that actually makes sense in the long run, and is sadly very difficult to communicate clearly.
I'll have a think on whether there's any better way to handle this. Having a preview for the cloud shader itself and having that open while tweaking the density fractal would help I think.
As for the Distance Shader, as far as I know it's still working as it should. It would be best to post a separate thread about those problems though.
- Oshyan