Hi! First, sorry for not being more active on the forum. I am really busy getting some cool Vue stuff ready.

I would like to discuss a interesting technique which permits you to seamlessly blend from a fractal node based to a heightfield based altitude within the same procedural terrain. This is achieved by defining an area at  the center of the terrain that blends from fractal based to greyscale based altitude generation.

 

An  example scene can be downloaded here. (28 MB, because it includes a high resolution heighfield terrain) The scene itself  is kept very simple so its easier to see the principle.
The tutorial below discusses the function of the terrain and requires some basic understanding of the function editor.

 

The reason why I am posting a tutorial here and not elsewhere is simply because this way communication is easier in case you have questions.

---

Load the scene file (it might require Vue 7).

 

 

The terrain you see is a procedural terrain with a size of 200km/200km.

 The mapping mode is set to Object Parametric.

 When you open the function editor you will see this function.

 The parts of the function tree are as follows:

 

1- Fractal function which defines the overall shape of the terrain. Here I used just one node. Of course this could also be a more complex set up.

 

2- Projected Texture Node. This part generates the heightfield. The Contrast/Brightness node below lets you scale and offset (altitude) the heightfield

 

3- This segment defines the area which blends-in the heightfield.

 You can also see that the terrain fractal as well as the area is connected to a Multiply node on top of the function tree. Multiply is set to a value of 50. This will actually scale all features down to a 50th of its size.

 

Since the Projected Texture node cannot be connected to the Multiply node it has to be scaled down separately. So the x/y scale parameters are set to 0.02 (1 by default).

Btw. for this example I used a terrain generated in World Machine 2 with a resolution of 4096/4096. You can load your own terrain, of course.

 

The rightmost branch of the function tree contains a Smooth Map node. It has 4 parameters. The top and bottom parameters should be left at 0.

The parameter "Input range/Upper value" defines the radius of the area where the heighfield appears. It`s set to 22 to make certain you dont have any edges from the greyscale map. But you can experiment with other values.

The parameter "Output range/Lower value" sets the area influence. I set it to 1 to achieve a full blending between the fractal part and the heightfield part.

Well, thats all :-)

 

Just brilliant. Thank you for this function example! :thumbupboth: In my picture I increased the Contrast of the filter node. I never imagined I can place that way a giant Mountain in a infinite landscape. Before I always created a new terrain for my Mountains and placed that in scene. :ohmy:

Mazak

Click on image for lager view!

Excellent work indeed. Thanks for your generosity in sharing it with the community!

That looks impressive, Mazak!

I`m glad you appreciate the function and make use of it :-)

To me the main obstacle when using 2 separate terrains has always been the edges of the heightfield terrain. And even if you manage to get rid of those edges, there is still this sharp transition between the 2 terrains.
By using this function there is no need to hide anything and the transition will always be perfectly smooth.

 

Quote - Excellent work indeed. Thanks for your generosity in sharing it with the community!

You`re welcome, Artur :-)

Excellent!  This will really help with GeoControl terrains.

that's a very nifty idea, I'll have to investigate this - thanks a bunch ! :)

Quote - Excellent!  This will really help with GeoControl terrains.

Glad you like that, Peggy. Im quite confident that this technique opens new horizons when using such terrains. Whats also nice is that if you hang in a Combiner node after the Projection Map node you can add a subtle amount of the fractal noise to the heightfield terrain.

great tutorial, thank you

Quote - that's a very nifty idea, I'll have to investigate this - thanks a bunch ! :)

Your`re welcome, Frank.
The technique is not entirely new. In fact, there is a MetaNode accessible in the filters menu named "Flat Area". It is intended to be used with Infinite Terrains to create a flat area around its center. 

Quote - great tutorial, thank you

You`re welcome :-)

I am happy you find it useful and also that I could give a little bit something back. Have spent hours with your tutorials and they are an excellent resource for all kinds of techniques.
Also, your relaxed way of handling the function editor really helped me to get into it myself.

Wow, thank you for  that!! that will also be awesome for putting volcanoes in landscape! :)

Mmm....

 Yes, eonite...very nice work :-) Big thanks for sharing!

 My pleasure, Silverblade and Chipp :-)

Quote - Wow, thank you for  that!! that will also be awesome for putting volcanoes in landscape! :)

Mmm....

Absolutely....and all that other stuff that works best with greyscale terrains.

... although I hope that one day we won`t need to use greyscale maps anymore. As mentioned elsewhere,  the current Vue terrain editor lags way behind what other softwares, like GeoControl or WorldMachine, are capable of.

But let us not complain as long as there are ways to combine nice greyscale terrains with procedural terrains.
If we care to generate terrains in sufficiently high resolution, and as long as we are aware that for areas very close to the camera a procedural function is needed (to get enough detail), we are on the right track.

Oh- that's so much fun, Thank you for posting it. I havnt done anything sophisticated with the terrain editor, so these are my baby steps, and I'm stumbling a bit:) I wanted to see if I can extend this to having more than one feature. In the attached image I have my revised terrain function, and the resulting render. The basic idea was to replace the 'length' node with a new version. The original length node basically calculates the distance to the terrain's origin (0,0,0). Instead I added a constant vector (pos1) that should define the position of the first feature, and I subtract that from the input position. The rest of this branch remained the same. Then I added a new branch for the second feature. This of course has a different constant position (pos2) to be subtracted from the input position. Well, it sort of works , in the sense that I have now two features, but I had to adjust the parameters in the brightness/contrast node and in the smooth-map node. And even though I played around with it for awhile, I cant make the two features look identical. (the heightfield map is the same).

Also, I seem to have generated a partial moat around the mountain on the left(see arrow. I suspect the numbers I used in the smooth-map node, but I dont know for sure.

Any advice how to get better control on my mountains? ultimately I would like to be able to define
the position, radius and height of each feature, without having to adjust additional parameters on a trial&error basis.

Thanks anyhow - even if I dont get it to work any better, it was quit fun!

Hey, Im glad youre having fun with it :-)

Your approach might work provided you find the right offset value for the 2nd terrain.

I have experimented with multiple terrains as well and found out that for some reason ( I do not have an explanation for this) the offset of the Texture Projection Map node has to be set to a minus value, if you offset the area with a positive value.

There is a recipe which works fine and which lets you have multiple features (which will all look identical if you want)

In short:  you can use the function I posted. Add an Offset node above the Length node.
Lets say you want to offset the area branch with an Y value of 40.
In this case, with a Multiply node value of 50, you need to use an offset value of -0.8 for the Texture Projection Map node.

I will add more info tomorrow or so (It`s late here in Switzerland and I need some sleep).

(just edited my post):"In this case, with a Multiply node value of 50, you need to use an offset value of -0.8 for the Texture Projection Map node."

I probably didnt follow what you meant. If I change anything in the texture map node -origin or image offset- turns the mountain into a valley, without moving it in the x;y direction. If I add a Math node, (Vector operations;offset) I get some reasonable results - as in the image. The offset was (0,0,0)  for one of the mountains and (-14,-14,0) for the second. I cant move it any further apart because I get 'black holes' (there is a beginning of one on the right hand side of the right mountain).  I guess I should go through the math of both the methods I used to understand it better.

(or wait till eonite wakes up:) )

At least you managed to create black holes in Vue ;-) 

Below is a screenshot showing the new function.  I just added some nodes for the additional heightfild. The left side of the function is identical to the previous function tree.

 The framed nodes are the ones I added. As you see the new area is connected to the Multiply node on top which is  set to a value of 50 as in the previous function tree.

You can also see that the "old" branches are connected to the Blender input "0" of the second Blender node.
I also marked the Offset node which offsets the new area.

I set the Y offset value of the Offset node to 40 to make certain that the 2 terrains are completely separate from each other.

 Now this is important: If the y offset value is set to 40 you have to set the Projection Map node`s Y-origin to  -0.8. The logic behind is that because the Multiply node on top of the function is set to 50 you have to divide the values you set in the Offset node by 50, which makes 0.8. But for the Projection Map node`s origin you need to set it to a minus value (for which I have no explanation). Anyway this way it seems to work. Tested it with different values and it always worked as expected.

 And here is the proof. The image is a render of what the function above generates. A hybrid terrain consisting of two heightfield maps at a reasonable distance from each other, embedded in a procedural terrain.

No black holes, just terrain...

My function was exactly the same as yours. The only difference was that I didnt have the '-0.8' in the projected texture map.
I guess I should have gone to sleep too - I understand it better now. I only made changes in the branch that defines the ratio in the blender node, or made changes in the texture map node, but not both together in a correlated manner. Seems so obvious now:)
I can get similar results to yours now -hurray. I'm pretty sure my previous method, defining the position and using the subtract node would work too if I move the texture map at the same time.
I might prefer that because then I could position primitive objects where I want my features to be, read their position in the world browser and enter the numbers in this function. Seems more straightforwards than measuring a distance. Depends on the circumstances of course.

Also, it will look a lot cleaner if I dont  have to define two numbers -one in the multiply and one in the texture map. These numbers are related, and I shouldnt be able to define them independently. I remember now -but I wont in a few days.
But this is a detail, the method works for multiple features - that's so cool!

Also, with regard to the sign  of the value entered in the texture map- it is related to the sign defined in the offset node. If I move the feature in the other direction (-40 instead of 40) I need to reverse the sign in the texture map (from -0.8 to +0.8). Maybe it's what you meant, but I thought I could never use positive numbers at all in the texture map node.
It all makes sense now. Arnt math and the function editor wonderful!

And this is the resulting render with the two (identical) heightfiled features

 Very cool, ArtPearl!

Its great we are discussing this here. Also its refreshing to have others participating in finding good solutions. As you said the function editor is wonderful (and powerful too). It allows you to really dig deep and come up with new or better solutions.

Sounds like you have quite a profound understanding of the function editor. That`s good to know...

Just checked out your positioning method and it works fine too. You`re right, defining a position instead of a distance makes sense.
What I also like about your version is that you do not have to "convert" the value for the texture map node, just change the sign.

Now we can go ahead and add a couple more heightfields :-)

Quote -  
What I also like about your version is that you do not have to "convert" the value for the texture map node, just change the sign.

I have just noticed that we do not have to change the sign when we use the Substract node (I tried with the Add node).
That`s good because now we can extract the Origin parameter of the Texture Map node and connect it to the Constant node (used to offset the area branch). This way we can define the position of both, the area AND the texture node, simply by entering the values we want into the Constant node entry field.

"Its great we are discussing this here. Also its refreshing to have others participating in finding good solutions."

Yes - 2 brains are at least 3 times better than 1 :)
It would have taken me ages(if at all) to figure out my problem of the missing '-0.8' on my own...

"Sounds like you have quite a profound understanding of the function editor. That`s good to know..."

profound...no, I wouldnt go that far, but I do like it.

"Just checked out your positioning method and it works fine too. You`re right, defining a position instead of a distance makes sense.
What I also like about your version is that you do not have to "convert" the value for the texture map node, just change the sign."

Oh you so much faster than me...I didnt get to doing it yet, so its encouraging

"Now we can go ahead and add a couple more heightfields :-)"

I'm trying to sort it out so all the conversions are done automatically and the user only needs to define scale and offset (or position).   Then I'll see if I can make it into a meta-node, I havnt used those yet. But if I/we can do that, than extending it to extra features will only involve adding one meta node(with the associated values) and a blender node. Should be easier for people who arnt that keen on complicated functions

Quote - > Quote -  

What I also like about your version is that you do not have to "convert" the value for the texture map node, just change the sign.

I have just noticed that we do not have to change the sign when we use the Substract node (I tried with the Add node).
That`s good because now we can extract the Origin parameter of the Texture Map node and connect it to the Constant node (used to offset the area branch). This way we can define the position of both, the area AND the texture node, simply by entering the values we want into the Constant node entry field.

crossed posts:)
Isnt it funny - I'm working on your original version and you're working on my version...

I feel a moment of enlightenment(for me) arriving - how do you extract parameters?
And somewhat related - is there a way to examine what values a node actually has (input or output)? some way of displaying the values? When the function gets to be complex it could be a very useful way of checking that everything is actually proceeding correctly.

Sorry - I've got to do some 'real life' things, so If I dont post it isnt that I lost interest

> Quote - > I feel a moment of enlightenment(for me) arriving - how do you extract parameters?

You just have to click one of the flashs.

 

Quote - And somewhat related - is there a way to examine what values a node actually has (input or output)? some way of displaying the values?

Click on the Node Preview icon in the top tool bar of the function editor. Lets you preview the values of the node.

Ah, no, that imports values  - if I click it I get a  new 'tooth' on the node and I can connect some additional input to it. I know how to use that. What I'm wondering is if there is a way to check what the node actually got. For example, if I started with a vector-constant, did a series of operations on it- multiply - invert etc- and then plugged it in to the node as you describe, is there a way to check what is the resulting number that arrived in the node?

Thanks eonite, I looked at the node previews and I dont understand it (yet). It will wait a bit till I can  look at it closer.

OK - I figured it out and sorted it so that now I only have to change the numbers at the top, the scale factor and the three components of the offset vector. In this case (0,-40,0). I changed -40  to 0 and it just moves nicely:)
I know it looks more complicated to decipher, but its easier (and less prone to errors) to use.
I made a start in converting it to a meta node and it works, but It isnt set up nicely for having 'published values' so I'll give it another go, and add the brightness/contrast parameters to the top.
(and also fix the 'position' method similarly)
I'm still excited about it like a kid with a new toy:)

Artpearl, your latest function is just brilliant!  How the heck could you figure that out so rapidly???
This will make things a LOT easier to handle.

Will take me some time to analyse your function and to check it out.

Btw. When creating Metanodes and extracting parameters, make certain that, when publishing parameters, you also use the group option. The resulting Metanode will look much cleaner this way.

Thank you:)
I think the crossing over of lines make it look like its complicated, but if you follow one branch at a time it isnt that hard.
The starting point is just deciding what needs to be done:

1. the fractal terrain and the 'affected area' branch  need to be multiplied by Kscale
2. In the texture map: the scale needs to be multiplied by 1/Kscale;
                                      the origin(Kx,Ky,Kz)  needs a sign change and needs to be multiplied by 1/Kscale.
   So you  just calculate the conversions at the beginning and connect to all the right places:)
   The other parts - Composer turns individual numbers into vectors as expected by the following nodes.

The only place I had problems was that I cant use the 'opposite'  node on a vector, or multiply a vector by a negative number. Bizarre ! I would classify this as a bug or at least a design flaw, but I would need to check a bit more.

I think it should only take me a few minutes to turn it into a meta node, but I dont have time probably till the evening (US mountain time). I did see the group option, you are very right really useful.

 Thanks for the info, ArtPearl!

In the meantime I have analysed your function tree and duplicated it here. Everything works fine.
And I learned a couple of new things by analysing your function, for example I have never used the Invert node before. The thing makes me more aware of the fact that there is math behind it. Your solution is really clever!

The only thing I have changed in your function is that I disconnected the Multiply node above the procedural terrain from the Constant Node. This way the procedural terrain can be scaled independently from the heightfield/area.

Yes the function looks complicated, but once a Meta node is created with the relevant parameters published it all becomes very simple. The picture below shows a possible parameter box of a "Heightfield Integrator" Metanode. The Metanode itself works perfectly.

What a great collab! :-) 

 Forgot to say: When you create a Metanode and you publish parameters all works fine. But if you want to make changes afterwards like renaming it requires you to "un-publish" first...and then unfortunately it may happen that Vue crashes. Happened to me a number of times, so it`s better to check twice before you publish a parameter.

I managed to get it to be a meta node too- yeh! (only a couple of crashes, I think one may have been because I included the input node in the meta node by mistake, still -  shouldnt crash)
I'm not sure about needing a different scaling factor for the  procedural terrain. If we want a different relative scale for the HF terrain we already have the parameters in the brightness/contrast node and the smooth map node.  Why do we need an extra variable? I thought it was important to keep the same scaling for both terrain types.
I must admit I dont yet fully understand the values in the smooth-map node. Where does the '22' come from...
I think I need to test how it works in a real situation, but I rather get my method (defining the position rather than offset ) working first.

Yes- good collaboration, I enjoyed it!

and that's how it works with 3 heightfiled terrains, using the node 3 times, just changed the the x and y values for each -  (0,0,0), (0,-40,0), (-25,-25,0).

Quote - I managed to get it to be a meta node too- yeh! 

That`s good news. Metanodes are a really powerful option in the function editor.
I have also noticed that when you use MetaNodes, even if you can have really complex functions inside, the function itself becomes very stable. Never had crashes because of using Metanodes (although ungrouping Metanodes can be a disaster).

Quote - (only a couple of crashes, I think one may have been because I included the input node in the meta node by mistake, still -  shouldnt crash) 

I had a number of crashes because of un-publishing a parameter, but never because I included an Input node. Btw. in my Metanode version I included the Input node as well.

Quote - I'm not sure about needing a different scaling factor for the  procedural terrain. If we want a different relative scale for the HF terrain we already have the parameters in the brightness/contrast node and the smooth map node.  Why do we need an extra variable? I thought it was important to keep the same scaling for both terrain types.

You mean the Brighness/Contrast node underneath the Texture Projection Map node? This one merely scales and offsets the altitude. But the size of the procedural terrain remains the same.

IMO being able to scale the size of the procedural function separately makes sense.

It`s only important to have a common scaling factor for the heightfield and the blend area.

Quote - I must admit I dont yet fully understand the values in the smooth-map node. Where does the '22' come from... 

t took me some time to understand it either, but now it`s clear to me. Below is a way to learn how it works.

 

To help understand the "area branch",  first create a new procedural terrain. Open the terrain editor.

Make sure you have the Zero Edges option turned off and that the terrain mapping is set to Object Parameteric. Reset the function.

You should now have a completely flat terrain.

 

Open the function editor, which should be empty. Add a Lenght node to the Position Input and connect it to the altitude output. Activate the Function Node Preview from the top tool bar.

It will display what the Length Node actually does. It measures the distance and returns a value (In this case an altitude value, which corresponds to the distance, length or whatever you call it)

At the point of origin the value will be 0 and gradually increases with increasing distance to the origin.

You can see the result directly on the terrain. You should see a reversed cone.

 

Now for the Smooth Map Node: Add this node to the Length node. Allows you to smoothly remap those values. Make certain you still have the Function Node preview window open, so you can directly observe what happens when you change the parameters. Set the parameters like set them for the area branch 0/22/1/0 and you will see a smooth bump. This bump is what drives the blender ratio in our terrain function.

Again you can observe the effect directly on your terrain. There should be a smooth bump of the size of a terrain.

 

Hope this helps clarify things.