'One For All' - Surface Shader Setup

Started by Volker Harun, July 19, 2007, 08:09:25 AM

Previous topic - Next topic

rcallicotte

The only basic question (with more detailed questions to likely follow) is - how did you come up with your numbers in your PFs?  Were these calculated from an understanding of some basic grasp of graphic arts or is this from an understanding of procedural graphics?  I see no pattern I can follow to learn from what you've done, but perhaps I'm looking too intricately into what you've created.


Quote from: Volker Harun on July 19, 2007, 04:30:44 PM
Calico,
I will go into detail soon - but now it is the time for my wife ,-)
Volker
So this is Disney World.  Can we live here?

Volker Harun

Hi Calico,
I might be wrong, but this is how I approach PFs (Powerfractals):
I get an overview of the object's size I want to texture (terrain, spheres, leaves).
This size will be my lead in scale (approx.).
The smallest scale is just how fine will the texture be in detail.

The feature scale for me is something that needs further explanation:
Make a feature scale the same size as the lead in. With Colour Roughness turned to 0 you will get some shallow, clean fractal.
Make a feature scale half the size of the lead in. With Colour Roughness turned to 0 you will get twice the noise. (Lead in is the maximum size of the noise, Feature scale is the distance between two noise patterns - or think basically of 100m sized hills [lead in] every 50m [feature scale]).

The colour roughness is giving this pattern the amount of variation that is sometimes needed. I reduce the roughness for blending shaders or for displacements. I push the roughness for surface patterns.
Colour Contrast just is the 'steepness' between lowest and highest colour and thus rather a fine tuning - or essential for getting smooth blend shaders.




So first I made a large scale fractal with contrasting colours and some medium roughness. Scale is from 3 to 100m, repeated every 19m. Just like large stone-like features.

The second one has a scale from 19 to 76, repeated after 17m (I just love multiples of 19,17,13 and so on). Less colour contrast but immense roughness. The detail comes from the blending shader at the edges. Like plaques sitting on the first PF.

The third one is even smaller. Interesting is the negative colour offset in the blending shader. Due to the low contrast there is no white but heaps of black holes. Instead I could have typed in high-colour 0.75 and low-colour -0.25 - and this what the clamp colour is useful for.

The choice of the colours themselves was just try and taste ,-)

I hope this helped, feel free to ask and/or correct me.
Volker

rcallicotte

Oh my God.  I haven't even read all of this yet and my mouth is dropping open.  So...yeah!  Thanks for explaining.

Back to the drawing board...with this new information.


:o
So this is Disney World.  Can we live here?

Volker Harun

Quote from: mr-miley on July 20, 2007, 05:56:30 AM
Firstly... Volker, many thanks for sharing, both are superb  :) Secondly, I must be missing something, cause I think that the trees render is superb. I don't think that it looks "a bit dull", I think its spot on for realism. Unless you live on a deset Island or somewhere really hot, natural colours aren't always that bright and vibrant. I'm in the UK (and I'm sure that this goes for most of europe and a lot of the States too) and if I look out of my office window at the landscape that is more than a few hundred metres away it all looks a bit muted and dull (dull probably isn't the correct word to use, but I cant find my theasarus (bugger, can't spell it either  :) )) I'd say the colouring and contrast of the whole scene is incredibly realistic. Hats off to you Volker... if only I wore a hat  >:(

Hi, I agree to most points. The dull, tainted shadows are often a matter of haze. On summer days the high contrasting is visible - but you must watch, as the brain is used to washed out greens and has to be persuaded ,-) I was quite surprised the last weeks when I wanted to get a good visible reference of what I was remembering(!)

bigben

Hi Volker

Iwork on a few computers and ocasionally I have version problems between them which can be almost as troublesome as losing files, so there have been times I've been glad that I've posted files here as well  ;)

Thanks for your files and also the explanation above. It was very helpful.

As for tree quality... as you've found, increasing the render quality of the tree populations does make a significant difference for trees close to the camera.  Unfortunately they also require more RAM to render. To get around this issue I use duplicate versions of a population with different render qualities, using a distance shader to separate them. If you use the same distribution shader for each population the trees will not move during an animation.

Attached a basic clip example.  I actually use 3 populations for trees, with a billboard object as the most distant population. The middle distance shader is then created by combining the near and far distance shaders.  I have some tests planned to try and figure out at what distances the various render qualities are indistinguishable yet... somewhere on my list of things to do  ;)

Volker Harun

BigBen, this is a very good idea.
Well, heard about it years ago, when seeing a documentation about LucasArt, but forgot until your post. Thanks for the clip .
Volker

AndyWelder

Maybe this helps in moving the 'Main Sun' around and keeping the cluster of suns intact.
A spread-sheet were you can fill in the new position of the 'Main Sun' and the new position of the other suns is automatically calculated.
You can then copy the values manually into the 'Heading' and 'Elevation' fields.
If I only knew how to get those values into the "SUNS" clip file.... A clip file is that an XML file?
"Ik rotzooi maar wat aan" Karel Appel

Volker Harun

That spreadsheet is a good way! - The clip is an XML that can be edited with any texteditor.
This would be a good post for the Soft-shadow-thread in the discussion-board ,-)

Volker

bigben

TGDs and TGCs are also tab delimited, so you could easily set up something in Excel to save as text.  I'd put all of the suns into a group first so that they're easier to select and delete before inserting the new clip.

Volker Harun

Hi Bigben,
I reduced the render quality for the populations to medium quality. Imagelink

Matt

#25
Quote from: bigben on July 20, 2007, 08:17:51 PM
As for tree quality... as you've found, increasing the render quality of the tree populations does make a significant difference for trees close to the camera.  Unfortunately they also require more RAM to render.

I didn't realise this was the case. Theoretically the populator quality setting shouldn't have any significant impact on RAM usage, only render time.

Quote
To get around this issue I use duplicate versions of a population with different render qualities, using a distance shader to separate them. If you use the same distribution shader for each population the trees will not move during an animation.

The quality setting is primarily a means of reducing detail in the distance to increase render speed, and the reduction in detail is progressive. If you find it better to use lower quality settings for distant trees then perhaps I need to think about changing this progression.

The level of detail is also controlled by the master detail level in the renderer.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

bigben

Quote from: Volker Harun on July 22, 2007, 06:24:07 AM
Hi Bigben,
I reduced the render quality for the populations to medium quality. Imagelink

At this distance increasing the quality would probably be only very subtle. Once the trees get to about 1/3 to half of the image height the extra detail becomes more noticeable.
Quote from: Matt on July 22, 2007, 10:39:10 AM
Quote from: bigben on July 20, 2007, 08:17:51 PM
As for tree quality... as you've found, increasing the render quality of the tree populations does make a significant difference for trees close to the camera.  Unfortunately they also require more RAM to render.

I didn't realise this was the case. Theoretically the populator quality setting shouldn't have any significant impact on RAM usage, only render time.

Quote
To get around this issue I use duplicate versions of a population with different render qualities, using a distance shader to separate them. If you use the same distribution shader for each population the trees will not move during an animation.

The quality setting is primarily a means of reducing detail in the distance to increase render speed, and the reduction in detail is progressive. If you find it better to use lower quality settings for distant trees then perhaps I need to think about changing this progression.

The level of detail is also controlled by the master detail level in the renderer.

Matt


Firstly.. I will have to verify the following statement, but from watching the TGDCLI output, the RAM usage climbed steadily while the populator was doing its thing.  I'm assuming that lower detail = fewer triangles overall = less RAM.  My leaves also used extra TG surfaces to enhance the bitmap textures so that may have been the cause of the extra RAM usage and noticeable quality differences. (early sample node network attached)...

But as I said I'd have to verify this.

rcallicotte

Not to interrupt this discussion, but I want to illustrate what I have learned from Volker's TGD from this thread.  I took your work, Volker, and reproduced something of my own.  I changed some elements, but I have left many of the numbers the same until I understand this better.  So, it's a work in progress.  If anyone wants to use the TGD, you'll need an image texture for the fake stones.

So this is Disney World.  Can we live here?

Mavcat

About the RAM thing, I found out the same thing. When i used the standard terragen grass in different qualities my RAM used on the lowest quality was around 250.000-450.000 kb while populating, with higher quality it easily could get around 1 gigabyte