Quote from: james adamson on February 20, 2020, 07:56:10 PMHi all. Once again I very much appreciate the time and effort put into helping me with this cloud setup I am trying to achieve. I would have no chance on my own. Right.. this is a long one. Martin I have tackled your setup first and I have quite a few questions so apologies for the length of this post.
I am going to explain it as I understand it if at all.
1. So the blue nodes going up to the sin node are essentially extracting a vector and creating data to create the terrain and the cloud offset function in this example?
2. The sin function is just there to build a terrain as a visual aid and to show cloud following terrain as it also feeds into the altitude offset.(to be replaced with what in a real world scene?)
3. When I have my final terrain where would the blue nodes leading up to sin go in my network. (Power fractal does not have a function input.)
4. What is the displacement to scalar doing it is not plugged in. Is that a stand in for what a heightfield generator would create and does it do the same job as a heightfield generator foregoing the image creation stage but increasing computing overheads ?
5. The rectangular cloud simple shader? Is that just a stand in node to be replaced with some other more complex density function?
6. Aaaaand finally, the depth modulation constant. Why is that at 0.08? Is that just an arbitrary number to be adjusted to taste in a final scene?
Right, onto the other version.
Thanks again.
James.
Hi James,
I'll try to explain a few things, but you're a few steps ahead of me as I'm still working on a simple real user case example without sin stuff.
The sin stuff is just there to create a simple terrain shape that can be easily interpreted.
Using some basic math and logic you can create a terrain with absolute values for altitudes which take all the guessing away and forces one to fully understand the function operations.
The take away message from that project file is really in the note shaders for the cloud layer.
The formulas and logic is what you need to understand and for that it's sufficient to believe me when I say that the terrain you see has a certain altitude span and that we work from there.
I understand you'd like to understand it, but it's not the aim of the file.
Perhaps by explaining this approach in the project file I also drew attention to this aspect of the scene, but I did not intend to.
I chose to do so nonetheless, because there's no better way than explaining something when it's stripped from all other variables with unpredictable outcome.
For instance, displacing a fractal with 2000 does not necessarily result in a terrain ranging from -2000 to +2000 meters, but I actually don't want to talk about this because it might only cause more confusion.
I'll try to answer your questions as briefly as possible.
1) Yes
2) Consequently to the answer for #1, yes.
3) The sin stuff is just to create a super super simple terrain with absolute certainty of the altitudes so that we can fully test and understand the cloud function inputs.
4) Yes that's correct. With the sin stuff you know that you create something with a certain range of values. A displacement shader to scalar converts the input terrain to the range of values of that terrain, but those values are not truly known by the user, since it's a fractal. You can predict it, but it's more 'rule of thumb' than absolute. More about this in a future file.
5) Correct. The terrain is a sinus shaped ribbon so that I can create a cross-section view. A cloud layer has a circular bounding box so to make sure it's also a ribbon you can simply use a simple shape shader in the shape of a ribbon and use that as density function for the cloud.
6) That explanation is in the note shader. You can double-click on the note shader's name and a box will open containing the explanations.
This should also help with the sinus stuff.
