Planetside Software Forums

General => Terragen Discussion => Topic started by: Dune on September 24, 2010, 09:04:37 AM

Title: procedural population variation
Post by: Dune on September 24, 2010, 09:04:37 AM
Instead of hijacking Frank's topic: http://forums.planetside.co.uk/index.php?topic=10752.0 (http://forums.planetside.co.uk/index.php?topic=10752.0), here's a new post with my latest improvement on procedural population variation. Made a mix of several functional noises.

This has all sorts of interesting side effects; I'm now rendering an image where I attached this tgc to the opacity function of the object's leaves. Very nice effect... autumn!

I too would like to know your workflow in this Volker, as it seems you get the same with a PF.

---Dune
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 09:08:53 AM
Thanks, Dune.
Volker, a quote from Frank's post...

Quote from: Volker Harun on September 24, 2010, 07:31:12 AM
Okay,

both attached renders are with TGOs.
The colourful is with the above shown Powerfractal.
The reddish and black Bots are rendered with a Get position node inside the Parts-shader.

!!??!!!

I think, that I need one of those objects you used for your tests, as with mine everything is just the way, I expect it.

Volker

You have the 'get' inside the actual parts shader? I experience many trace-ray errors and black render outputs doing this, as Frank said, aswell. ???
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 09:11:45 AM
Ulco, using the 'get pos in tex' should make it work with a fractal, I'm almost sure.
I remember a while ago, I could not get a power fractal to bend with a warp shader when I just used a 'get position'...
Title: Re: procedural population variation
Post by: Dune on September 24, 2010, 09:12:42 AM
I'll try that...
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 09:13:32 AM
Me too, playing just now...
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 09:25:14 AM
Okay, as I am not allowed to post this trafficBot object, I'll build a new object and will post the whole scene as TGD.

It might render fine on my machine, as I am using a Mac!?!

@Dune ... for those who might follow us in a few years ... can you put the link to FrankB's thread into your first post as reference!?!

thx
Volker
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 09:26:25 AM
It really looks to be as simple as this, after all;

[attachimg=#]

A 'get position in texture', input to a default fractal that is set at the top-level affects only the leaves.
God-damn! One extra node is all it has ever taken to make a fractal work for this! Bang head repeatedly off of wall! :D

It seems to be still applied to object-space, not world-space this way, sorry. Getting my hopes up prematurely there! ^^ ;)  :-[
Title: Re: procedural population variation
Post by: Dune on September 24, 2010, 10:59:20 AM
I couldn't get it to work either. A stack and mix of functional perlins works quite well, IMO, until someone finds the ultimate solution. I did another test and used the color function input of the default shader(s) to stick the tgc in. That works as well for variation without added color.
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 11:15:09 AM
You can get the scene-file with object over here: http://www.rx-optimal.de/TG2/MiniBotScene.rar

Which objects do you use?
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 11:19:07 AM
Same here. It appears Volker has it working with fractals on page 4 of Frank's image post. I can't see where the 'get' node is, though. Apparently inside the parts shader but I can't see where. It must be contained inside another node in there because, what I'm finding is, when the 'get' node and functions are inside another container node(whilst in the parts shader), there are no traceray errors. Take the functions out of the container node, however, and place them straight into the parts shader on their own, kaboom!
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 11:23:00 AM
I'm using a fantastic tree model that I made for simple testing purposes...

[attachimg=#]

.obj

:D
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 11:33:16 AM
Quote from: dandelO on September 24, 2010, 11:19:07 AM
I can't see where the 'get' node is, though. Apparently inside the parts shader but I can't see where. It must be contained inside another node ...

In that scene I did not use any Get node ... :)
Title: Re: procedural population variation
Post by: Hetzen on September 24, 2010, 11:40:28 AM
Just trying your scene, and it doesn't seem to work...

Hrmm.

I'm getting bucket errors.
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 11:44:44 AM
I am going to try the scene on my windows machine ... with Mac, everything is fine.
Title: Re: procedural population variation
Post by: Hetzen on September 24, 2010, 11:46:29 AM
I'm Windows based, so this maybe the problem, and hopefully an upcoming solution, because this would be awesome to get to work.
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 11:46:49 AM
QuoteThe reddish and black Bots are rendered with a Get position node inside the Parts-shader.

How did you achieve that, Volker?
I can make it work if the 'get' node is contained within another node in the parts shader but not if it is just directly inside it.

EDIT:
Ah, I just read above, I guess it's down to the Mac/Windows thing, then.

Hetzen: Try placing all the functions inside another container node, like a colour adjust shader. I think it should work...
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 11:54:45 AM
Checked ... On my WinSys the render does not work ... this is stupid ...
Well, maybe we can get TG2 soon for iPad and Steve Jobbs is buying Planetside ,-) ;) :) ;)
Title: Re: procedural population variation
Post by: Hetzen on September 24, 2010, 11:57:07 AM
Well, just deleting the left hand blues, and placing the right hand side PFs in a colour adjust shader seems to be doing a GI pass. So far so good.
Title: Re: procedural population variation
Post by: Hetzen on September 24, 2010, 12:03:10 PM
I think that works Martin. I'm stopping this render and try it on some teapots. As you do.
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 12:13:10 PM
It does, pop the left hand nodes in a colour adjust, then assign the square scalar to the input of the colour adjust shader. That then goes to the colour function fine.

Disabling the other unused nodes won't work, you'll have to delete them or, place them inside their own container. I think a group node should work like the colour adjust shader, it's a good node to use as a container, though, as it only has one input.
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 12:14:54 PM
I am sitting here eagerly awaiting the first images ,-) ... I stopped working on my WinSys, as it alway shuts down after 10 minutes due to overheating. :(
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 12:16:11 PM
I reduced the render size for quickness but just making a new container does the trick.

*Edit: Using a group node works just fine as well. It seems you just can't have the functions on the same level of network as the desired shader you're inputting to.
Title: Re: procedural population variation
Post by: Hetzen on September 24, 2010, 12:19:06 PM
Hrm. The red PFs on the right hand side do not work. I'll try the blues now.
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 12:20:09 PM
Wahey! The famous teapot! :)
Title: Re: procedural population variation
Post by: Hetzen on September 24, 2010, 12:23:19 PM
Oh Yeah. It's not a test without a teapot.

The Blues are working, without RayTrace errors  :) . Shame about the PFs not. ???
Title: Re: procedural population variation
Post by: j meyer on September 24, 2010, 12:46:22 PM
Very interesting!
Has anybody tried with RTO unchecked? Just as a test to see if it's
related to the other PF problems with objects.
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 12:49:08 PM
Aye, bummer.

I can still get some degree of fractal variation by setting the variation functions as colour function of a surface layer then, using a power fractal blend shader on that. The main function still works correctly, supplying the world-space variation but, the fractal is still only applied to the object-space. It works but it isn't quite 'there', yet...
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 12:50:04 PM
@jmeyer ... interesting idea ...
@all ... what happens when combining the Reds and the Blues with an Add-Colour or Multiply-Colour?
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 12:52:49 PM
Good thinking, J Meyer. It's still the same, though. The fractals are still only applied per-object, not per-population. :(
Title: Re: procedural population variation
Post by: FrankB on September 24, 2010, 02:12:52 PM
Quote from: dandelO on September 24, 2010, 11:23:00 AM
I'm using a fantastic tree model that I made for simple testing purposes...

[attachimg=#]

.obj

:D

pure eye candy, Martin :D
Title: Re: procedural population variation
Post by: FrankB on September 24, 2010, 02:22:00 PM
can someone please just post a version of a tgd you're having success with? I kinda lost you when you all were talking about separating blue nodes form red... sounds like the matrix ;)

Besides, I would have bet a considerable amount against that "mac vs win" is the reason for it working with Volker and not me :D
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 02:58:00 PM
This is the simple version, Frank. Just import the clip, one node, place it in the parts shader and then into the colour function of the 'part' you want to vary.

You'll want to get a little busy in its network, there's only a simple 10m perlin inside it for now. Ulco has the right idea for now, just make different scaled perlin stacks and merge them.

The only reason we have been getting traceray errors is because the get functions were on the same level as the parts shader, pop them inside a separate container node and it works fine.
Title: Re: procedural population variation
Post by: Volker Harun on September 24, 2010, 03:02:01 PM
What comes into my mind ... a year ago I was playing with a couple of objects, that were not shade-able.
It was not a matter of the objects, it was a matter of the single faces of the object.

When applying a green and red texture to a 'Part' of the object, there was no shading on the space origin of the Part, it was that the space origin was reset on each single face.

So when you use a shader like Dandelo's fantastic wood on the object you ought to see the patterns or just a brownish mixture. Last would be a broken object.
Title: Re: procedural population variation
Post by: dandelO on September 24, 2010, 03:15:03 PM
I haven't actually tried the wood on many imported objects yet, I mean, I have but just laid across the whole object, not its parts. It does hold its pattern when applied to whole objects, I'll experiment with different grains on different 'parts' soon, should work fine and rotating the object will also rotate the grain so, that's not a problem, I'll have a play later on, making dinner...
Title: Re: procedural population variation
Post by: Dune on September 25, 2010, 03:06:53 AM
QuoteThe only reason we have been getting traceray errors is because the get functions were on the same level as the parts shader, pop them inside a separate container node and it works fine.
Why would you do that, I'm getting confused here? If you have the functions anywhere on your workspace it works, no need to put them into a parts shader.

The main problem is to get PF's to stick to the world level, like the functional perlins with their 'get'. A 'get' into a PF doesn't work. A simple shape shader, for instance, has its coordinates baked in, so you can vary a pop by using that as well. Limited use of course, but the baking of coordinates would do the trick. I've also tried feeding some fractals into a surface shader or distribution shader attached to the compute terrain and then into the default shader of the object, but that doesn't bake the coordinates either.
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 04:13:14 AM
It really may be object related ... so we should go for one common OBJ to test with, else we get with the same setups different results!
For me it really does not matter where the 'Get position' node hangs around ... the result is always the same ... regarding to an object.

The images I made yet, proof, that there is no baking for objects ... else the image over here:
(http://forums.planetside.co.uk/index.php?action=dlattach;topic=813.0;attach=26920;image) (http://forums.planetside.co.uk/index.php?topic=813.msg111193#msg111193)
This image has a new OBJ populated which is not affected by the same functions used with those Bots ... if those functions would have worked, the ToonCars would be turning blue to black ...

Cheers,
Volker
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 04:57:02 AM
Ulco: have you tried taking all your functions directly into the parts shader and rendering?(without the function nodes being inside another container). You're right, there is no real need to put them directly inside a parts shader but it makes sense to do so, since that is where you'll find the shaders that you want to vary the colour of...
Do you use a Windows or Mac?
If the functions are on the same level as the 'object part' on a Windows computer, there are lots and lots of traceray errors and a failed render. It's very weird. Boxing them up inside any other node stops that from happening.

Volker: Nightmare! I wonder, why it works for one and not the other? This is a pain.
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 05:00:19 AM
Doing a render now with the PF enabled instead of the Get position and it works ... with this OBJ.
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 05:36:29 AM
Oh, FFS! I give up!

Actually, I don't. ;) I'm test rendering a working functional method on different objects at the moment... :D
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 10:00:59 AM
And here is a mixture ... one Part has the PF fed in, and another part has the 'Get position' function ...

... and both show up correctly ....

this is funny ;)
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 10:13:33 AM
Volker, can you try this with a larger scaled fractal? I suspect that the large variations are functional but the smaller patches are the fractal, is this right?
I was able to achieve similar results and thought that I had proper population-space fractal variation but actually, I then raised the fractal scales to be larger than each model and it soon became apparent that the fractal variations were still only in object-space.

If I'm wrong about this with your example, well done! You've cracked it! :)
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 10:26:11 AM
I understand what you mean ...
to control this, I just have to turn off the rotation within the pop ... this way even the small grey and white patterns should be different for our goal.
Title: Re: procedural population variation
Post by: j meyer on September 25, 2010, 10:45:07 AM
Did some more tests yesterday night and noticed that even an unconnected
blue node (like perlin noise or a multiply,not a get though) inside the parts
shader gave ray trace errors.Could someone confirm,please.

The only globally visible effect from a PF i got by using a group with functions inside
connected to a surface layer that's between the default shader and the gray
one and has a PF as a break up shader (coverage 0.5 break up 1).
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 10:57:51 AM
Confirmed, J Meyer, I have been getting the same results.
Dune got it that very way as well, with the breakup of a surface layer, it seems to work great that way in his example, it still  involves adding surface layer to each object-part shader you want to affect, though.
I'm trying to make a simple plug-in-able variation shader that will just feed the colour function already present in the default shader.

I've got a functional based one, which I'm testing a basic pattern over lots of different objects to see if it holds up over all of them. Working so far on all the objects I've tested.
Here's a few cheap examples with only the basic variation enabled. I'll re-enable the finer detail variations and upload the clip in a while...

* The last one is an older object and still has a multi shader, it still works.
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 11:08:43 AM
Here we have what I was talking about two posts above.

By the way, the Perlin's scale was for the low_PoV-Render: 30; for the image a few posts up 10. This image's scale is 60.
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 11:51:26 AM
Ahhh, so multiplying by a fractal will keep the world space setting from the get node. Very good.
Where is that square scalar going to?

Instead of abs and square nodes I'm using a smooth step between -1 and 1, I don't like the perlin transitions with abs/square, to drastic. They're really minimized with a smooth step scalar.

This thread is great, so many possibilities! :)
Title: Re: procedural population variation
Post by: j meyer on September 25, 2010, 12:44:19 PM
dandelO - thanks for confirming.
               Haven't looked at Ulcos file from the beginning of this thread,but
               compared to his set up posted in the other thread i have just
               a single PF as break up not his array of nodes and it seems to
               give a different result.Maybe i'll post an example later,got to get it from
               another machine.
               "...it still  involves adding surface layer to each object-part shader you
                want to affect, though." Ain't that necessary with the color function
                input,too?  ???
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 01:27:15 PM
Well, when you load an object, it comes with a default shader attached. Even if an image is specified for that texture, you can still use the colour function input of that default shader to specify how much of that image/colour is applied to the object part, and where it will be applied.
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 02:28:11 PM
Quote from: dandelO on September 25, 2010, 11:51:26 AM
Ahhh, so multiplying by a fractal will keep the world space setting from the get node.

No it doesn't. Not by my tests I'm afraid.
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 04:00:08 PM
The first question I'd like to answer:
Quote from: dandelO on September 25, 2010, 11:51:26 AM
Where is that square scalar going to?
As you can see, there are two Pops ... the square scalar goes to the Part's input of the first Pop ... which is just the same you got with the file on page 1 of this thread. It worked there without even have plugged the PF into the other Part of the only active Pop ... before the both Pops got the same function to run ...

Quote from: dandelO on September 25, 2010, 11:51:26 AM
Ahhh, so multiplying by a fractal will keep the world space setting from the get node. Very good.
2 years ago I would say: 'YES' but I am not sure anymore ... it would be a great help for us knowing what the difference of the 'Get position' and the 'Get Position in Geometry' is. The last is clear ... it does not care about any textures or displacements and is not scalable. The first one is not scalable either, but acknowledges displacements after a 'Compute terrain', doesn't it (<--- this is an honest question) ... and this is a wink to Matt, Oshyan, Jo ... ;)
Quote from: dandelO on September 25, 2010, 11:51:26 AM
Instead of abs and square nodes I'm using a smooth step between -1 and 1, I don't like the perlin transitions with abs/square, to drastic. They're really minimized with a smooth step scalar.
This is quite a good idea ... good ... ehmmm .. in means of GOOD!!!!! ;)
Quote from: dandelO on September 25, 2010, 11:51:26 AM
This thread is great, so many possibilities! :)
I feel a bit alien here, as I have more working possibilities with the Mac - while I do not know if mine is the correct version at all ;)

Cheers,
Volker
Title: Re: procedural population variation
Post by: j meyer on September 25, 2010, 04:49:16 PM
dandelO - that's what i wanted to do with the fractal break up: mixing the image
              and a color,but i'm not sure anymore.(see below)

all - meanwhile i've played with Dunes tgc and by comparing and mixing it with
     my approach i found a) the results are pretty similar and b) i was wrong
     thinking the PF had an effect(a 'normal' effect that is) as break up shader,
     actually it's just brightening up the masking/blending a bit.When i tried it
     yesterday i started with another noise flavour and when i changed it i got
     a huge difference and so i mislead my self,i guess.Sorry.
     But on the other hand it seems strange that with perlin noise the coverage
     of the surface layer is working (the green is visible) and when it is set to
     ridges just the original color (orange) is visible.
     For the sake of completeness i attach my result from yesterday.
     [attachthumb=#]

PS:Hey Volker,it's not that often one can see mac-users in that situation these days. ;)
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 05:08:46 PM
Hey jmeyer ...

... right ,-)

About the PF ... it may matter having one or two colours enabled ... having one changes from transparency to visibility, having two may overwrite the above colour, scalar information.
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 05:52:44 PM
I thought it was a good one too yesterday, then realised the fractals were still only working around each object when I raised the scales or something. We need a way to simply force a fractal over the desired space, there has to be a way, I've even tried an invisible connection from 'compute' terrain, which feeds the planet, to the fractal but still, only per-instance coverage. All instances take their coverage from different points in the fractal(the point in world-space of which they sit, I'd bet), otherwise they would be textured the same in each instance. They aren't, though.

Here's what I've been playing with then, a simple combo. It only uses 2 perlins; large scale/small scale. I started out with 4 but it's just to keep it simpler for now. The good thing about the container node is that, it serves as an added contrast control for the function. [attachimg=#]
I just go into the parts shader, open the clip there and plug into the default shader colour function from there because, I figure, this would be a good type of thing to enclose inside objects you'd likely want to colour vary easily, vegetation models for example. If you loaded the model in a population, you'd be able to enable population variation in one or two clicks for that object.

I'd like to know more of the functions, to be able to make the perlins more pretty but this is all good practice. :P
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 06:34:53 PM
I don't know if I'm using the 'smooth step' scalars in their most correct context, I'm not great with maths functions but according to the node description, this should make a smooth curve, from values 0>1, I'm finding I need negative numbers to achieve the kind of smooth curve I'd like. But, whatever, it's working for creating a nice smooth blending option, if a bit harsh in the images.
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 06:54:07 PM
Hi Martin.

The smooth step scaler makes a black and white ramp from an input with a base constant to a ceiling constant.

In other words

If I had an input of something that gave me a value of minus infinity to positive infinity, like Get Altitude, I can create a greyscale ramp from say 1000m to 5000m, where everything below 1000m is black, and everything above 5000m is white, and everything in between is a value of grey.

If you want to put a curve on that ramp of grey, then you need to have a look at Bias and Gain functions.

http://www.planetside.co.uk/docs/tg2/noderef/window_1_13_1.html?MenuState=fABEAAQABAAAAQEABAAAAABAQAEAEAEAAAQABEEAEAQdVVVVXdVVVBAEAAAAEAAAAAAAAAAAAAA

http://www.planetside.co.uk/docs/tg2/noderef/window_1_13_4.html?MenuState=fABEAAQABAAAAQEABAAAAABAQAEAEAcVVVVABEEAEAQdVVVVXdVVVBAEAAAAEAAAAAAAAAAAAAA

Those two links show you the curves you can apply.

*** Edit. I thought the output of the smooth step was linear, it seems it isn't. I now realise why some of my stuff doesn't work how I expect it. Any chance of a linear step scaler Matt?
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 07:00:22 PM
Mind you, there is nothing stopping you using that ramp to drive more functions, like Sine waves or other trig equations, of which I'm sure Volker can explain more about. Could even be the scale of a Perlin noise, or multiplying another chain of nodes from 0 to 1, ie blending.
Title: Re: procedural population variation
Post by: jo on September 25, 2010, 07:06:18 PM
Hi Hetzen,

The smooth step does make a smooth curve, not a linear ramp:

http://www.planetside.co.uk/docs/tg2/noderef/window_1_16_2.html?MenuState=fABEAAQABAAAAQEABAAAAABAQAEAEAcVVVVABcFAEAQdVVVVXdVVVBAEAAAAEAAAAAAAAAAAAAA

The advantage of using the gain or bias functions is that you have some control over the shape of the curve, however you only a smoothly transitioning curve with the gain function with gain values greater than 0.5 (IIRC!!). In all other cases, for both gain and bias, you will get discontinuities (i.e. sharp edges) at the start and/or end of the curve.

Regards,

Jo
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 07:08:48 PM
Quote from: Hetzen on September 25, 2010, 07:00:22 PM
Mind you, there is nothing stopping you using that ramp to drive more functions, like Sine waves or other trig equations, of which I'm sure Volker can explain more about. Could even be the scale of a Perlin noise, or multiplying another chain of nodes from 0 to 1, ie blending.
I use the smooth step after trigging with sines and/or cosines ... not before, yet ... but it is interesting ,-)

But first, about the Perlin noise which is basically a random driven Sine ... so somebody might think about distorting the 'Get Position' with a Sine ... well, one step further, with a low scale Perlin ... just a guess, but I'll give it a try ...

thanks to the inspiration you just gave me in the posts above :) ;) ;) :)

Edit: Thanks Jo for your fast response
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 07:10:16 PM
Quote from: jo on September 25, 2010, 07:06:18 PM
Hi Hetzen,

The smooth step does make a smooth curve, not a linear ramp:

http://www.planetside.co.uk/docs/tg2/noderef/window_1_16_2.html?MenuState=fABEAAQABAAAAQEABAAAAABAQAEAEAcVVVVABcFAEAQdVVVVXdVVVBAEAAAAEAAAAAAAAAAAAAA

The advantage of using the gain or bias functions is that you have some control over the shape of the curve, however you only a smoothly transitioning curve with the gain function with gain values greater than 0.5 (IIRC!!). In all other cases, for both gain and bias, you will get discontinuities (i.e. sharp edges) at the start and/or end of the curve.

Regards,

Jo

hi Jo

Ha ha, I was just editing my post after re-looking at the reference site. Could you tell me how to make the smooth step linear? I've been working on a set of functions that make crashing waves on any shorline, and I've been heavily relying on Smooth Steps, under the miss assumption that the output was linear. This makes things a lot clearer on why I'm not getting things to happen when I wanted them.

Many thanks

Jon
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 07:22:31 PM
Actually, and sorry for taking this thread off topic a little, the solution for a linear step is the top right hand corner of this node network. So I've kind of answered my own question. LOL. Any chance of putting this into a single node form Jo?

http://forums.planetside.co.uk/index.php?action=dlattach;topic=10582.0;attach=26288;image
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 07:27:18 PM
Quote from: Hetzen on September 25, 2010, 07:10:16 PMCould you tell me how to make the smooth step linear?
Hi Jon,
my first thought is to use a conditional node and the Mod scalar.
You use first the Mod scalar to get the ramp(s) from 0 to 1. Then you can use the conditional scalar ... wait ... maybe it is easier this way ...
You want a range from 500 to 800 so you do a clamp of this range. After this you use a subtract scalar, where the value of 500 is subtracted. The result of this gets a mod scalar of 300 (Difference of 500 and 800 might be more convenient)
Quote from: dandelO on September 25, 2010, 05:52:44 PM
I'd like to know more of the functions, to be able to make the perlins more pretty but this is all good practice. :P
See the attached screenshot
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 07:29:38 PM
Well, Jon, ...
you were faster and better .... I have not thought of the Divide scalar at the end ... :)
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 07:32:16 PM
We seem to be skinning the same cat at the same time with different sheers. Lol
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 07:51:58 PM
I just figured it was a good way to make a perlin more fluid. Sorry for causing a ruckuss! :D
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 07:56:21 PM
Nothing of the sort. I've just had a major face palm moment on a project I've been working on for ages. ;D

So thanks.
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 07:58:01 PM
Quote from: Hetzen on September 25, 2010, 07:32:16 PM
We seem to be skinning the same cat at the same time with different sheers. Lol

Some poor guys are simply picking up that poor cat's pieces behind you. ;)
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 08:03:45 PM
Thing is, anyone who uses this program pretty much blind, is a pioneer, and as Volker said in another thread, we should all learn off each other.
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 08:04:24 PM
Quote from: dandelO on September 25, 2010, 07:51:58 PM
I just figured it was a good way to make a perlin more fluid. Sorry for causing a ruckuss! :D
Well, as I do not quite understand the term ruckuss, I post the next Screenshot ... even if not necessary ;)
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 08:09:28 PM
Quote from: Hetzen on September 25, 2010, 08:03:45 PM
Thing is, anyone who uses this program pretty much blind, is a pioneer, and as Volker said in another thread, we should all learn off each other.
When Efflux and me were digging deeper into those functions, at least me did not really knew what he did.
When I look at one of those old scene files ... I wonder how they worked .. I try solve the knots in the node network ... find nodes that are disconnected, delete them, and the image does not render anymore ...
That was really a fluid perlin work ... with ups and downs ... and I kept any step of progress in the scene files ;) LOL ;) Just to have it handy.

But one thing for sure, I learned how to play with this stuff ... there is a german term which means literally: Playing is better than studying ;)

And even if we are going a bit off topic here, I think it is really an advantage for all of us to follow this thread and to play, discover and learn.

Cheeeers :)
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 08:18:45 PM
Did any of you has ever tried the 'Get position in texture' ... because this is the most global Get-node imho.
Title: Re: procedural population variation
Post by: dandelO on September 25, 2010, 08:19:03 PM
Quote from: Volker Harun on September 25, 2010, 08:04:24 PM

Well, as I do not quite understand the term ruckuss, I post the next Screenshot ... even if not necessary ;)
I'd have just stuck a warp shader in there and been done with it, Volker! ;)

Great stuff, all of this!
Title: Re: procedural population variation
Post by: Hetzen on September 25, 2010, 08:20:26 PM
I agree completely Volker. This thread is a gem at the moment. But I do think it should be kept back on topic for future reference.

I'd like to suggest we start another on function noise patterns. I've got one you might like to have a look at.
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 08:22:58 PM
Quote from: dandelO on September 25, 2010, 08:19:03 PM
]I'd have just stuck a warp shader in there and been done with it, Volker! ;)
A Warpy :)
One of those mysteries I have not understood ... it works ... but I do not know why and where to activate the displacement and so on ...

End off OffTopic
Title: Re: procedural population variation
Post by: Volker Harun on September 25, 2010, 08:25:29 PM
Quote from: Hetzen on September 25, 2010, 08:20:26 PM
I agree completely Volker. This thread is a gem at the moment. But I do think it should be kept back on topic for future reference.

I'd like to suggest we start another on function noise patterns. I've got one you might like to have a look at.
As long as you find a good topic for the thread I might join ... (there is some french Merlot making me type nonsense) :D
Title: Re: procedural population variation
Post by: Dune on September 27, 2010, 02:40:50 AM
Back to basics. Volker's perlin 3D setup is a nice way to get a bit smoother variation and not the harsh gradients when you use just one perlin 3D. That's why I've stacked a couple and played with the mergers, and an adjust color. But it's hard to get a nice 'real' fractal variation, and for such we would indeed need a 'fixer' such as the simple shape shader, where basic coordinates can be given to a node which accepts a stack of PF's, which at that point are set at this reference. Maybe that's not to hard for Matt, Jo, or Oshyan to implement (?).

If normal PF's work globally on a Mac perhaps these gentlemen also know what is the difference between the Mac and Win version?

QuoteBut on the other hand it seems strange that with perlin noise the coverage
     of the surface layer is working (the green is visible) and when it is set to
     ridges just the original color (orange) is visible.

@ jmeyer: how can you set a perlin 3D to ridges? I presume you used a red PF instead, and then the global reference doesn't work anymore and you'd get the normal color for your objects.

@ Martin: Why would you put your tgc (which I'm about to have a look at) inside the object? If you put it on the global workspace it is easier to address it, e.g. draw a line to a test surface color input and see what it does on ground.

If you attach the tgc to a surface layer between the default and simple shader, you can add whatever color you want, or even luminosity or displacement. If you attach it to the color input of the default you'd only get variation of the basic color.

I used to use a camera and image map shader tp project color variation onto a pop, but as I now found out (and it's obvious actually) it will color the leaves of a tree in a line downward. For grass that's no problem but for trees it is not always very nice. So now I prefer this method, if only we could get a more PF like variation....

Long story so far, but now for a render I did yesterday with my stack (the first tgc)

---Dune
Title: Re: procedural population variation
Post by: Volker Harun on September 27, 2010, 03:50:37 AM
This is a nice render :) The Pops look very good.

For the Perlin ... here is an idea that might help ... http://forums.planetside.co.uk/index.php?topic=10826.msg111379#msg111379

For the colouring ... I think two Mix colour would be perfect to make the scene ultra realistic. One large scale and one small scale. Use the Transformshader to scale the one or both inputs of the Mix colour.

Cheers,
Volker
Title: Re: procedural population variation
Post by: Dune on September 27, 2010, 05:41:36 AM
already found it!
QuoteAh! So this would perhaps be perfect to use as 'global variation node set' for pops. Looks nice and PF like, especially if its appearance can be 'seeded'. Thanks Volker. I'll check it out.
Title: Re: procedural population variation
Post by: dandelO on September 27, 2010, 05:43:13 AM
Ulco: I'd put the shaders inside the object because it's the object I'd want to apply colour variations to, over the population space.
I don't need to plug this into a surface layer, I use the shader preview in new window every time I'm working on a shader set. I open the uppermost shader preview in a window of its own and anything downwards from this shader that is edited is translated to that final shader preview. It's also easily zoomed in and out to lots of different distances/scales so my camera never actually needs to move to check this.

I suppose everyone has their own methods and practises when designing things. :)
Title: Re: procedural population variation
Post by: Dune on September 27, 2010, 09:49:47 AM
@ Martin: Ah, but 'shader preview in a new window' is something totally unfamiliar with me. Never do that. You're right; everybody his/her own ways.

@ Volker; I tried your 'stone' nodes, replaced the get position in texture/geometry by a get position (or it wouldn't work), but the PF that you included is still only working on object level (in my WIN version at least), although blended by the global perlin. So I'll stick to a combination of perlin and voronoi. The smooth step is excellent, although I changed the -1 to -0.5 to get a little more spunk.

One thing I don't understand yet is how to achieve another distribution of the perlin 3D. When I stick a PF into its .. (arse, I wanted to say) seed, and hit random, nothing changes. Even applying a redirect or transform shader anywhere in the line of nodes doesn't change the pattern.  ???  Does anyone have the solution for a nice button to simply change the pattern?

---Dune

Ah! I hit the 1000 posts level  :D
Title: Re: procedural population variation
Post by: j meyer on September 27, 2010, 11:34:35 AM
Dune - You're right i used a PF.I did several tests with PFs earlier in regard
           to coloring non-uved objects and found that a surface layer between
           the parts shader and the surface input of the object still accepts a
           PF as blending shader.And i wanted to test if it works on the next
           level (between the default shader and the gray one),too.And i was
           refering to an effect i noticed.
           Just tried to find out what works and what not.Since RTO was introduced
           there seems to be something wrong with PFs and objects and i think the
           more we find out,the easier it's for Panetside to solve these problems,
           hopefully.
           Sorry for any confusion.
Title: Re: procedural population variation
Post by: dandelO on September 27, 2010, 11:55:56 AM
Quote from: Dune on September 27, 2010, 09:49:47 AM
I changed the -1 to -0.5 to get a little more spunk.
I'll have to try that one on my birthday! :D (I'm not sure that'll translate very well to anyone but us nasty Brits!)

And it gets better yet!
Quote from: Dune on September 27, 2010, 09:49:47 AM
When I stick a PF into its ..

Brilliant post, Ulco! :D
Title: Re: procedural population variation
Post by: Volker Harun on September 27, 2010, 12:01:47 PM
Well, a perlin's seed is not used to broken stuff ... you ought to try something more smooth. Integer numbers are just fine to use ;)

The smooth step wasn't my fault there, by the way ...
Title: Re: procedural population variation
Post by: jo on September 27, 2010, 09:46:17 PM
Hi Dune,

Quote from: Dune on September 27, 2010, 02:40:50 AM
Back to basics. Volker's perlin 3D setup is a nice way to get a bit smoother variation and not the harsh gradients when you use just one perlin 3D. That's why I've stacked a couple and played with the mergers, and an adjust color. But it's hard to get a nice 'real' fractal variation, and for such we would indeed need a 'fixer' such as the simple shape shader, where basic coordinates can be given to a node which accepts a stack of PF's, which at that point are set at this reference. Maybe that's not to hard for Matt, Jo, or Oshyan to implement (?).

Basically you're after a multifractal version of the Perlin 3D node?

QuoteIf normal PF's work globally on a Mac perhaps these gentlemen also know what is the difference between the Mac and Win version?

There shouldn't be any difference between how this works on the Mac and PC. It's all the same code. If it were working differently it would be a bizarre sort of a bug. My first inclination would be to suggest Volker is doing something differently than you think he is.

Quote@ jmeyer: how can you set a perlin 3D to ridges? I presume you used a red PF instead, and then the global reference doesn't work anymore and you'd get the normal color for your objects.

I know this isn't quite what you're saying, but if you weren't aware you can make a ridged or billows version of the Perlin 3D noise by modifying the output. Looking at the power fractal code it seems that the "billows" mode comes from using an Abs function and the "ridged" mode looks like it's Abs followed by a Complement. The mixed modes aren't achievable with the Perlin 3D node. Anyway, I'm sure you guys had figured this out already :-). I've attached a screenshot showing normal Perlin 3D, ridged Perlin 3D and billows Perlin 3D.

Regards,

Jo
Title: Re: procedural population variation
Post by: Dune on September 28, 2010, 03:35:06 AM
@ Martin:
QuoteI'll have to try that one on my birthday!
You're going to have a treat on your birthday then?   ::) ::) (I was referring to the first of the 'freedictionary' translation, actually). Didn't even know the second, as I'm not a Brit.

@ Jo: Thanks for your input. And yes, a multifractal (more varied) 'seedable' perlin 3D node which can be stuck to a global perspective as it now is with the get function would be fantastic. Perhaps Volker is doing something different, but I haven't figured out what...

Volker??? Or did I misinterpret your findings?
Title: Re: procedural population variation
Post by: Volker Harun on September 28, 2010, 06:32:58 AM
Quote from: Dune on September 28, 2010, 03:35:06 AM
Volker??? Or did I misinterpret your findings?

I don't know, I always used the same setup as on the first page of this thread: http://forums.planetside.co.uk/index.php?topic=10810.msg111137#msg111137
Sometimes with different objects, sometimes only the blue part on several parts of an object, sometimes the PF-part only, sometimes a mixture ...

dandelO's render needed a bypass, but it worked: http://forums.planetside.co.uk/index.php?topic=10810.msg111151#msg111151

I think, as long as the result is effective, you have the solution.

,-) Volker
Title: Re: procedural population variation
Post by: FrankB on September 28, 2010, 07:15:00 AM
it may not be worth opening an image thread for this. I just refined my color variations somewhat. I still use two mixed perlins to provide the variation pattern for 2 default shaders with color functions. It's a method that I think works well.
Of course, ideally we would be able simple choose whether an in-object color function relates to object- or world-scale.

Here's another doodle. I kinda liked the outcome. Secondly, gentlemen, you are looking at 12.5 million gras clump instances :)
Other stats are GI 1/1, detail 0.3, AA4. I've run it through a color filter in post to light it up somewhat. Rendered 17 minutes, a lot of that was population time.

Cheers,
Frank


Title: Re: procedural population variation
Post by: Volker Harun on September 28, 2010, 07:27:41 AM
You have mastered the grass clumps .... I really like the mood of this render!
Title: Re: procedural population variation
Post by: domdib on September 28, 2010, 07:54:14 AM
I agree with Volker. The distance from the grass clumps is just right, so they produce an extremely convincing texture (aided by the excellent lighting). And the colour variation is beautifully subtle. If you worked a bit on the soil texture, and made sure none of the trees looked as if they were partially buried, this would be a winner.
Title: Re: procedural population variation
Post by: FrankB on September 28, 2010, 10:45:26 AM
a second one for the same scene, different perspective and lower. nothing special, just for completeness... I guess. :)
Title: Re: procedural population variation
Post by: Walli on September 28, 2010, 02:19:45 PM
very nice Frank, the color variations really add a lot!
Title: Re: procedural population variation
Post by: otakar on September 28, 2010, 07:26:48 PM
Brilliant. Now, if you could tie the grass color to the normal vector's affinity to a specific cardinal direction, you could make north facing slopes appear greener than those exposed south facing ones :)
Title: Re: procedural population variation
Post by: Hetzen on September 28, 2010, 07:53:25 PM
You might find this set of shaders useful then...

http://forums.planetside.co.uk/index.php?topic=8853.0

:)
Title: Re: procedural population variation
Post by: Dune on September 29, 2010, 03:02:00 AM
I second Otakar. But
QuoteYou might find this set of shaders useful then...
Unfortunately, these formulas are unfinished business, but maybe a mathematical wizzkid will arise and venture into this...
Title: Re: procedural population variation
Post by: Hetzen on September 29, 2010, 06:38:13 AM
The only thing missing is the y orientation on the "green to scaler", which isn't needed for creating a north facing mask. Set the direction heading to 0, then use the output from "Clamp 0" as your blending mask.
Title: Re: procedural population variation
Post by: otakar on September 29, 2010, 12:22:06 PM
Hetzen, thanks for the link. I'll have to study this as the thread only confuses me. ???
Title: Re: procedural population variation
Post by: Dune on September 30, 2010, 02:26:02 AM
The stack of perlins works well, and offers several possibilities, like snow on trees etc. Here's another test I did yesterday (not the snow one) with only 2 trees.

The only problem I encountered is the 'line' due to the displacement intersection and clouds (?) bug.
Title: Re: procedural population variation
Post by: Volker Harun on September 30, 2010, 11:03:13 AM
Line??? Which line? ... Or do you mean that road in the distance that you made on purpose??? :)
Does the line vanish if you turn off the clouds?
Title: Re: procedural population variation
Post by: FrankB on September 30, 2010, 11:08:42 AM
Quote from: Dune on September 30, 2010, 02:26:02 AM
The stack of perlins works well, and offers several possibilities, like snow on trees etc. Here's another test I did yesterday (not the snow one) with only 2 trees.

The only problem I encountered is the 'line' due to the displacement intersection and clouds (?) bug.

Ulco, I know this line. It comes from intersect underlying in combination with a fuzzy zone. Turn it off and you will see.

Cheers,
Frank
Title: Re: procedural population variation
Post by: Dune on October 01, 2010, 02:47:24 AM
Thanks guys. I set the fuzzy zone to 0 now. See what happens. I'm now rendering another one, where I made a gradient with 2 distribution shaders + the 3D perlins to partially cover some pines with snow. So, playing along happily...
Title: Re: procedural population variation
Post by: Floating.Point on February 04, 2011, 07:24:31 AM
Okay this was a great thread
(so great in fact that I don't even feel like I need to apologize for resurrecting it  ;D)

All this is fairly full on for me (and perhaps/surely others)

Here is what i have done so far...
(Using a Grassclump population as my example)

1. Grabbed DandelO's clip from this post: http://forums.planetside.co.uk/index.php?topic=10810.msg111255#msg111255
Plugged it into the color function of the parts shader of the Grassclump

2. Grabbed & used Volker's beautiful fractal from this post: http://forums.planetside.co.uk/index.php?topic=10826.msg111379#msg111379

3. played with the Color Adjustments to get a nice smooth variation...

But all this seems to do is darken/lighten the green of my grass... how do I get the amazing differences in color...
like in Dunes post here: http://forums.planetside.co.uk/index.php?topic=10810.msg111374#msg111374

Would it be possible for a quick idiots guide to population variation ?
I don't think a full blown tutorial would be needed, just a bit of hand holding as to how to use the information accumulated within this thread (and its sibling threads)

Cheers!

-FP

Edit: Attached my little example project
Title: Re: procedural population variation
Post by: dandelO on February 04, 2011, 08:50:21 AM
You could set the colour function of the object-part shader to 'white' and then use different colours from each perlin function that feeds into it. That should distribute each colour used over the populated parts.

Haven't time to have a look as it's my eldest's birthday, maybe tomorrow I'll have a play with TG again.
Title: Re: procedural population variation
Post by: Volker Harun on February 04, 2011, 09:06:17 AM
Agree with the above ...

The attached image might give you a clue :)
Title: Re: procedural population variation
Post by: Floating.Point on February 04, 2011, 09:46:47 AM
Thanks DandelO and Volker,

Can you explain to me the reason for the Multiply Colour Function, and what is feeding into its input 2?

Many thanks

-FP
Title: Re: procedural population variation
Post by: Volker Harun on February 04, 2011, 02:03:52 PM
The merge shader is for getting different shades of green and brownish colours.

The multiply colour is for getting darker and lighter areas (those tiny spots). The right input is fed with the other perlin function which is in the internal network of your colour variation shader.
Title: Re: procedural population variation
Post by: Floating.Point on February 12, 2011, 12:18:48 AM
Okay Thanks for this!!
Champion!