Planetside Software Forums

General => Image Sharing => Topic started by: TheBadger on July 17, 2011, 01:51:59 PM

Title: A valley crowned
Post by: TheBadger on July 17, 2011, 01:51:59 PM
Not sure what the problem with this one is, but it does not seem real to me.
Title: Re: A valley crowned
Post by: freelancah on July 17, 2011, 02:27:26 PM
Looking good already! I would probably bump the contrast, decrease the brightness and change the clouds.. Currently the clouds look a bit unreal to me. Possibly consider some vegetation?
Title: Re: A valley crowned
Post by: TheBadger on July 18, 2011, 12:42:00 AM
clouds don't look real? Hell, that was the only part I thought was good. :-[
Title: Re: A valley crowned
Post by: Draigr on July 18, 2011, 04:06:21 AM
The clouds look a bit more like potato mash, then clouds, to be honest. They're cool, but the details aren't really there.

The mountains need far more variation in colour and are currently giving me strong 'CG' vibes.

Additionally vegetation would help a lot.
Title: Re: A valley crowned
Post by: TheBadger on July 18, 2011, 03:53:30 PM
a little better.
Title: Re: A valley crowned
Post by: efflux on August 04, 2011, 11:13:19 AM
Good POV. Clouds need work but another thing is the water. It's unlikely that the small lake would have waves like that. Waves are always a giveaway of scale.
Title: Re: A valley crowned
Post by: TheBadger on August 04, 2011, 08:26:45 PM
Thanks guys. I have been trying to work on this one. Unfortunately this project represents the hight of my TG2 powers for now. I did add a ton of plants, and they do make the image a lot better. Before I render again I would like to fix the other things you all mentioned, but I need help.

Ill save the clouds for last, because clouds are kind of their own special torture for me. But as for the mountains and lake, perhaps its an easy fix?

Quotemountains need far more variation in colour and are currently giving me strong 'CG' vibes
I agree. Can you talk me through a simple method of improving it?

QuoteIt's unlikely that the small lake would have waves like that. Waves are always a giveaway of scale.
This is the first water I'v used, its just default settings. The image is part of an animation Im planing as part of a larger project, wherein the camera will move very close to the waters surface, so I think to avoid problems the lake should be very calm. How can I calm the waters?

Thanks guys.
Title: Re: A valley crowned
Post by: Henry Blewer on August 04, 2011, 10:31:07 PM
The water waves can be calmed down by changing the roughness from 0.2 to 0.002. This makes the water very still. It's great for reflections.

Clouds are not that hard, but then they can be quite impossible. ::) I stick with the default clouds using a billows noise. The edge sharpness can be increased to make the 'puffiness' more apparent. I am still learning the function tab in the cloud controls. I just add a power fractal to the density input. The power fractal scale works ok for me using about 1/3 of the cloud scale. The lead in scale controls how tight, or the spacing of the power fractal looks. That probably is not too clear. Try 1000, then try 100 and then 10. You'll see what I mean.

Color variation. I think of what environments might exist. Dark green for pine areas, mixed with light browns and tans for their trunks. Lighter greens for deciduous trees with whitish trunks. Low saturated yellows and light greens for grass areas. The rocks can be what ever colors you like. I use reds or grays mostly.
Title: Re: A valley crowned
Post by: TheBadger on August 05, 2011, 12:17:44 AM
Thanks njeneb, thats very helpful ;D

But on the issue of color variation in my mountains, I get that there should be more variation. But the question is how? What I mean is, I used a high color and a low color, how do you add more, without changing the terrain? I will guess the answer is add a color shader and blend that with a distribution shader, correct? If so, do I have to make sure that I put the new color fractal shader on top of the original terrain shader, and below everything else? Or does it not matter because I am using a distribution shader?

You cant see it in this image, but on the ground there are now grasses and dirt and flowers and trees and so on. I want to fix the issues your helping with before I render again. :)
Title: Re: A valley crowned
Post by: Dune on August 05, 2011, 03:00:19 AM
You can stack PF's for color, but after the first one with high and low color, just use one color (high or low). And uncheck displacement if you put this stack into the child input (if you don't want too much displacement, that is). Either PF can be blended by whatever you like (distribution, painted, distance shader, or another pF). You could also stack surface shaders (with a color), each blended by a PF. In the latter case you can decrease the amount of color as well as the distribution.
Title: Re: A valley crowned
Post by: Henry Blewer on August 05, 2011, 03:09:47 AM
Dune is correct. I use distribution shaders all the time. I have found that the altitude settings interfere with displacement nodes in the Terrain node area. I don't know why. The slope settings work fine.

One of the great features of using Surface layers is the Effects tab. Favoring rises for stone and favoring depressions for the plant coverage works well. If you only need color, move the intersection shift to 0.1. I rarely use the low color unless I am using a power fractal as a mask.
Title: Re: A valley crowned
Post by: Tangled-Universe on August 05, 2011, 04:07:37 AM
Quote from: njeneb on August 05, 2011, 03:09:47 AM
Dune is correct. I use distribution shaders all the time. I have found that the altitude settings interfere with displacement nodes in the Terrain node area. I don't know why. The slope settings work fine.

I hope this gives you some insight on how this stuff works more or less.

What's your usual workflow? Do you perform all displacements before compute terrain or also some after?
Compute terrain builds/updates the normals + texture coordinates. Normals for slope, texture coordinates for altitude.
These coordinates are slightly smoothed internally to allow for intersect underlying for instance, so the smoothing already can cause slight discrepancies, but I think only at small scale you may notice this. More on this later.

Surface Layers use "position in texture/terrain" (texture coordinates) for altitude.
The reason for this is that colour and displacement will be based on the same altitude constraints and displacements will not use the final displaced position and can only be based on the texture/terrain coordinates. This would allow the surface layer and displacement to be aligned.

Likely you're also displacing after the compute terrain which creates discrepancies when you use a surface layer for altitude restrictions as this only uses the texture coordinates provided by the preceding compute terrain. For accuracy the terrain would need te be recalculated again by a compute terrain and you would need to add your surface layer after that last compute terrain.

If you're not displacing after the compute terrain then you could have a too large patch size of the compute terrain, because the patch size provides a "resolution" for the calculation of coordinates (and also has this slight smoothing).
Lowering patch size may increase accuray, but would increase rendertimes.
If you use a distribution shader then instead and set altitude key to final position (the position at the end of the shader network) then you circumvent this issue as the final altitude key is calculated separately for this shader. I don't know how costly it is to use this.

Distribution shaders use position in texture as well, but also allows for "final position" which are the final displaced coordinates.
This would allow you to use an altitude setting according to the altitude coordinates at the end of your shader network.
These don't necessarily need to align with the displacements and is the reason why you often think a distribution shader works better.

Basically over larger areas the altitude key in a surface layer are correct, but dependant on compute terrain patch size.
At smaller scale the altitude key in a surface layer may not provide enough accuracy and distribution shaders might help because they recalculate Y at a different point.
However, if you stick at the "usual" workflow you wouldn't need this quickly except when you're working far from the origin or with waterbodies, because then "Y" and altitude can differ because of planet curvature.
So if you ever have troubles aligning altitude settings with your water level then use a distribution shader (as blendshader).

Cheers,
Martin
Title: Re: A valley crowned
Post by: TheBadger on August 05, 2011, 04:19:25 PM
QuoteWhat's your usual workflow?

Martin, to tell you the truth I follow John's (schmeerlap) "BenMcDuff" each time. Using the order of actions he lays out. I start with a good idea of what I want, and change his method as I go in whatever way I need, but I always do it in the order of things in his tut. His lesson became methodology. But I very much would like to move to the next level!!!

Thank you all! ;D I am reading what you wrote carefully, and trying to be a good student. Will show the improvements soon.
Title: Re: A valley crowned
Post by: TheBadger on September 11, 2011, 08:13:38 PM
Have made many changes using info from this thread and several others I asked questions in. I am about half way done now, still have a few things I want to do yet. After the still is finished I'll start animating.

CC welcome
Title: Re: A valley crowned
Post by: jbest on September 11, 2011, 08:56:22 PM
Now this looks great.
Title: Re: A valley crowned
Post by: Pentagular Dark on September 12, 2011, 01:48:13 AM
I agree almost completely! Btw I hope one of those changes is adding grass and dirt around the trees.
Title: Re: A valley crowned
Post by: TheBadger on September 12, 2011, 10:53:37 PM
Thanks fellas,

Im glad its starting to impress. If you or anyone has ideas on how to improve i'm all ears.
Title: Re: A valley crowned
Post by: FrankB on September 13, 2011, 07:07:14 AM
I've just read TU's detailed comment and thought I could explain a part of this is simpler terms, although it simplifies a few things.

Let's assume you do all your displacements before the compute terrain node. When you add a population to sit on the ground, TG2 will just "ask" the compute terrain node at which altitude the terrain is at any given position. The compute terrain node knows this, because it's part of what it does: computing the altitude of the terrain for any given point on the planet. So it tells the populator to put tree instance 123 at 51 meter altitude, for example.

Now, let's assume there is one additional displacement after the compute terrain. Now your populator still asks the compute terrain node at which altitude to put the instances of the population. The compute terrain node will answer with the same coordinates like in the previous example, except that now these coordinates are wrong. Applying displacements after the compute terrain node essentially means you hide them from the compute terrain node. It won't know about them.

The way for you to fix this is to either move the additional displacement also before the compute terrain node, or add a second compute terrain node after your additional displacment. Be warned though, each additional compute terrain node doubles the render time. Pretty much.

Once you have understood the above, next thing you need to learn is about the patch size setting in the compute terrain node. You can think about the compute terrain node to have a practical mind. It doesn't compute the altitude and slope for every infinitely small point on the planet. It would never finish! So what it does is that at default settings it computes altitude and slope for every 20 meter only. If the populator for example wants to place an instance of a tree right in the middle of four known points (that are all 20 meters apart), the compute terrain note replies to the populator with an "educated guess" - based on the values around the known points - how high and steep this point in the middle probably is. So if in this 20m square, there is an unexpected dent or peak, the tree will be placed above or below the "real" ground.

Now, in most cases the 20m grid is sufficient enough. If you find it's not working for you, just decrease the patch size to say 10m or 5m. In practice I found that yes it's slower but not that much in many cases. It's worth trying.

Lastly, as a rule of thumb: displacements that are *much* smaller than the patch size are ok to happen after the compute terrain node. Every little 2cm fake stone is a displacement, but in most cases when the patch size is 20m, it doesn't matter if you place them after the compute terrain.

Regards,
Frank
Title: Re: A valley crowned
Post by: TheBadger on September 15, 2011, 03:58:38 AM
Thanks frank.

But what do you think of your trees being to dark in this image? The spruce I mean.
Title: Re: A valley crowned
Post by: FrankB on September 15, 2011, 01:22:50 PM
Quote from: TheBadger on September 15, 2011, 03:58:38 AM
Thanks frank.

But what do you think of your trees being to dark in this image? The spruce I mean.


errr, I have replied to your pm? Check your pm's I'd say ;)
Title: Re: A valley crowned
Post by: TheBadger on September 16, 2011, 02:06:54 AM
Thanks frank! ;D Got it.

No, if you don't think there to dark, then Im not going to mess with it. I think Ill just work on getting some sun light to certain places. Really, I just needed some input I guess. You get to looking at something to long and it starts to not make sense anymore, like saying a single word over and over again. Im sure everyone here knows what I mean.

see ya
Title: Re: A valley crowned
Post by: :) on September 20, 2011, 08:29:12 PM
upper clouds getting overexposed some. I think put back in rays but at 1/3 start amount (first picture)
Title: Re: A valley crowned
Post by: TheBadger on September 21, 2011, 05:15:40 AM
Quote from: TheOne on September 20, 2011, 08:29:12 PM
upper clouds getting overexposed some. I think put back in rays but at 1/3 start amount (first picture)

Спасибо. I like the first one better too. But I could not get a good exposure for the back ground mountain :'( and fill lights killed the rays, although, I don't really know how to use fill lights.