Just starting to experiment with functions. I have no problem with the maths, and the concept of type conversions.
What I can't figure out is the flow. Did my due diligence on the function threads, no luck.
I have a PFS displacing a terrain. It's a good terrain but too spikey. I would like to level them out above a certain altitude.
At this point I'm not even sure if a function is what I want. Perhaps this is a straightforward blend between two shaders (my PFS and a flattish terrain) based on an altitude constraint?
Attached file is attempt to do this, but it ain't working! It doesn't really do what I want anyway because I don't want to layer a flat area onto the peaks so much as replace them. Further work with the merge shader isn't working either. :(
...later...
I finally got the merge shader to work because it has a simple altitude mapper that would allow me to use a flat elevated surface to slice off the peaks. This is not good enough though. I need to find an approach that smoothly flattens most of the (large) peaks, regardless of altitude. The surface layer shader seems to have the altitude/slope tools I need but I don't know how to make that work...
I added a clamp scalar to the power fractal. I also used a strata and outcrops shader before the compute terrain. Finally I changed the vertical displacement into normal displacement on the surface shader.
If you changed the normal displacement to lateral displacement, and added a compute normal before in surface shader it would enhance the flattening. The compute normal is plugged into the surface shaders input. The compute terrain is plugged into the compute normal.
thanks for the reply njeneb, although I'm having problems with it ???
I opened your example.
-I can't see how the clamped scalar works as an input. Is it passed in as some kind of rule or something?
-I disconnect the clamped scalar and I see no difference.
-Although the strata shader is perhaps a good next step for my PFS, I don't see how it accomplishes the task of cutting down the peaks and besides, forces a particular morph on my entire terrain.
I'm still very confused about functions too. I don't know how to integrate them with shaders. Functions seem to be always passing a kind of value. How do I connect them to shaders that can carry multiple kinds of information at once without the function stripping out everything but the type of data it generates?
Let me be more clear: the examples I find always generate data from scratch using the position data, but I would like to interrogate an established shader and either change it directly or generate a new shader that is the result of my applying the function to the shader results.
Clamp scalar- It limits the next 'item' in the structure. So I used min 0 and max 400. It's supposed to limit the output of the following shader/function to fall between these numbers. I'm probably wrong. Many of the function do not seem to work the way I think they should.
I use the strata shader to make mesa structures. This link goes to one of my landscapes in which I used this.
http://forums.planetside.co.uk/index.php?topic=7145.0
I'm not good with functions, actually I don't understand them. Volker's posts are probably the most relevant for using them. Sorry if I can't be of more help. I have to go to work, and I usually have some time to think about things. I may have something tomorrow.
EDIT: Height fields are easier to control than power fractals. The second input below the 1000 1000
sets the size of the terrain.
The main problem for me would be to clamp displacement data. I have no idea how to do it.
Else it would be possible to use the colour information of the PF and plug it into a seperate displacement shader.
I think the easiest way for you would be, to reduce the Spike Limit in your terrain node significantly. Try a value of 0.9 for a start.
This keeps the overall shape of the terrain, but smoothes most of the spikes.
Volker
I'll try out the despiking on my project, but I'm now distracted by figuring out how to work the functions.
I'm trying to modify existing displacement data and the closest I can come is in the example, although it doesn't work right. I think you can see what I'm trying to do with nodes.
-extract the elevation data, then use it as displacement data elsewhere (or do math on it first..)
-my example has two PF shaders, unrelated.
-the result acts more like some kind of unh, no math name for it. When the input node displacement is zero, then the displacement shader function input has NO effect. When the input node displacement contains non-zero amplitude, then the function input data is added, but its scale seems to be synced with the input node data. ??? ??? ??? ??? ???
14 hours on Terragen today, one step gained. (and that was about 8 hours ago)
So, am I completely missing something here?
First thing is ... you need the 'Compute terrain' before getting altitude data.
Second, the 'Get altitude' node has an input, but as far as I know, it is ignored.
The Get-functions:
If you have an image, and we call the width 'W' and the height 'H' and the upper left corner of your image has the position of W=0 and H=0 ... now think of a ray, that is poked vertically into the landscape-image ... this ray will meet the terrain or atmosphere or whatsoever.
If the ray meets the terrain, the Get-functions give you the information about this intersection ...
You get the altitude, the slope, the normal, the position and so on. This information can be used for functions as an input.
Before I will be able to provide a solution, I would like to know what you were trying to achive, exactly - as I did not get the point ;)
Okay, you have the base terrain, and you want to modify it with the second terrain ... to add displacement (the higher the more or less)? The displacement shader in your project has an amplitude of 0 ???
Give me a hint ;)
Do you only want to make mesa structures?
If so then I have a fairly easy way of doing it using highly contrasted powerfractals connected to a displacement shader.
I used it in this image:
http://forums.planetside.co.uk/index.php?topic=7092.msg75580#msg75580 (http://forums.planetside.co.uk/index.php?topic=7092.msg75580#msg75580)
I can post the base of this setup.
Cheers,
Martin
This problem started out as a quest to chop the peaks off of my mountains. I did not see an obvious way to do it except via my experience with programming and math, so I thought the most straightforward way was to read the displacement data, modify it, then stuff it back into a NEW shader with all the same settings as the first shader, EXCEPT I would use my modified displacement data to define the displacement function, rather than slather it on the top of another layer, which seems to be the normal operation in TG.
At this point I don't care about the mesas that much. I encountered a problem that I want to learn how to solve on my own using approaches I'm familiar with, if possible. My brain sees a programming environment and is trying to learn how the rules work. I'm not so good at memorizing solutions, and tomorrow I will just encounter another task with no recipe in my book.
oh yeah, Volker's description of the Get Functions. That is exactly how I recognize how they work. One question that stumps me though, if the input port is ignored: since I'm building up my terrain using a series of displacements, then where in that series does my Get Altitude work? After the final Compute Terrain? What if I want to query a terrain value from earlier in my build-up? It would be natural to assume that is what the input port is for.
Then there is the question of how altitude is represented. Is it a scalar? If I want to use it as a function input in a displacement shader, will the values translate directly to height (with the multiplier set to 1 of course), or do I need to find a way to scale it down to fit within a 0-1 range, ie like a luminosity. Normally in a programmable environment such as this there are clear definitions, but in this case there is so much polymorphism (type casting) going on that it's impossible to determine anything without very hard trial and error.
Okay ...
first of all duplicate your base terrain node ... edit the Copy like this:
In the colour tab turn the High colour black, turn the Low colour white. Be sure that both colours are enabled.
Uncheck the clamp-colours at the bottom and lower the Roughness to values of about 0 to 0.2.
We are going to use this Copy as blending shader for height, therfore there is no much need for details and displacement. So turn off the displacements in the displacement tab.
You can also raise the Smallest Scale in the Scale tab to reduce the octaves and calculation time. Smallest scale and roughness go hand in hand. With a roughness of 0 the smallest scale is ignored.
Now tho the main tweak. Take the output of Copy and drag a connection to the Blending shader input of the base terrain and activate at the very bottom of the Base terrains 'Blend by shader'.
This will smooth down the tops of your terrain. Adjust the Low Colour of the Copy and the colour contrast to your needs ;)
Volker
Volker, could this same technique be applied to an Alpine? It doesn't have the colour inputs, so my first guess is no, but perhaps you have some cunning manipulation up your sleeve?
TU
can you still post your base mesa setup, i have my textures etc for mesa, but am still having trouble getting a decent shape
folder
Hi domdib,
I would use a workaround:
Because heightfield render faster than procedurals ... and the alpine is a very slow procedural, I export the area of interest as a heightfield. The original terrain is most often obsolete after that, but can be kept active for the background.
With the same technique you can export the terrain as OpenExr. I have not tried to blend anything with an Exr-image, if it is not possible you can convert it to a BMP, Jpeg or whatsoever before applying as a blendshader.
So you need to place heightfield to the area of interest, place an orthographic camera above this area with the FOV adjusted to the heightfield's dimension and use this camera for an image shader.
Another way ...
For either terrain you could use the merge shader.
Make that copy of the terrain node, adjust the Copy's settings to your needs and set the Merge shader's Choose by altitude to 'Cut'.
Volker
Volker, thank you for that workaround - I've been wrestling with an Alpine for a while now, and I can see how many options this opens up.
Having had a shot at trying this Volker, I confess I'm not clear on your instructions. So I set up an orthographic over the point of interest, and then what? How does an "image shader" come out of this? DO I need to render from here? If so, do I need to switch atmosphere off? Does the sun have to be at the same heading as the ortho??
I try to give you 1:1 instructions ... as I skipped 8) 8) 8) a few steps for a good setup:
1. Get you PoV
2. Last shader should be an image map shader with a bright coloured bitmap (i.e. pure Pink)
3. keep the image map to camera projection and use your render camera (the whole field of view (FOV) turns pinkish ... good ;D )
4. Create a new camera turn it 90° down and place it over your area of interest with use 'Orthographic'
5. plug the orthographic camera into your render node and change the image width and height to i.e. 800 / 800.
6. Move the orthographic camera around and adjust its width until you get the most of the pinkish area into the view.
7. Write down the width of the ortho-camera and its position, these will be the values of your new heightfield.
8. Plug your render camera back into the render node and delete that ugly image map shader of Step 2
9. Create a heightfield shader and add a 'Heightfield generate' to its 'Heightfield'-input
10. Disable the 'Flatten surface first' in the heightfield shader (I am not sure!?!?!)
11. Disable the 'Fractal detail' in the heightfield shader
13. In the Heightfield generate do the following:
13.a. The size in metres is the width of the ortho camera
13.b. The numbers top if these are the resolution of the heightfield use i.e. 4096 and 4096
13.c. I do not know if this is necessary, but I always set the 'Feature scale' to 0 ... same with the variation in the Tweak-tab
13.d. in the 'Use shader' tab ... plug in your terrain .... insert the location of that ortho-camera
13.e. I am not sure, but I would set the Position to center.
13.f. Press the generate now button
13.g. After the build process do a right click on the Heightfield generate-node and do a 'Save file as ...'
13.h. Save both Ter and Exr ... keep an eye on the file-extensions.
14. Delete the heightfield-generate and add a heightfield-load, load the Ter file of 13.h.
15. You might need to set the position of the heightfield in the heightfieldshader.
16. Into the blending shader of the heightfield plug in a new imagemap shader, use camera projection and the ortho camera.
17. Load the .Exr-image (or converted to BMP, etc.)
18. I hope that I did not forget anything ;)
Volker
Very comprehensive - thanks!
Will give it a shot. I've also tried the option of plugging the Terrain node into the Shader input of a Heightfield Generate, as suggested by Oshyan here: http://forums.planetside.co.uk/index.php?topic=7223.msg78184#msg78184
but unfortunately, the TER file this produces has a few holes, and I don't think there's any easy way to fix that. Unable to replicate the problem - seems TER files are fine produced in this way.
This could be useful in the TG2 wiki. Eh?
Quote from: Volker Harun on September 16, 2009, 11:46:06 AM
I try to give you 1:1 instructions ... as I skipped 8) 8) 8) a few steps for a good setup:
1. Get you PoV
2. Last shader should be an image map shader with a bright coloured bitmap (i.e. pure Pink)
3. keep the image map to camera projection and use your render camera (the whole field of view (FOV) turns pinkish ... good ;D )
4. Create a new camera turn it 90° down and place it over your area of interest with use 'Orthographic'
5. plug the orthographic camera into your render node and change the image width and height to i.e. 800 / 800.
6. Move the orthographic camera around and adjust its width until you get the most of the pinkish area into the view.
7. Write down the width of the ortho-camera and its position, these will be the values of your new heightfield.
8. Plug your render camera back into the render node and delete that ugly image map shader of Step 2
9. Create a heightfield shader and add a 'Heightfield generate' to its 'Heightfield'-input
10. Disable the 'Flatten surface first' in the heightfield shader (I am not sure!?!?!)
11. Disable the 'Fractal detail' in the heightfield shader
13. In the Heightfield generate do the following:
13.a. The size in metres is the width of the ortho camera
13.b. The numbers top if these are the resolution of the heightfield use i.e. 4096 and 4096
13.c. I do not know if this is necessary, but I always set the 'Feature scale' to 0 ... same with the variation in the Tweak-tab
13.d. in the 'Use shader' tab ... plug in your terrain .... insert the location of that ortho-camera
13.e. I am not sure, but I would set the Position to center.
13.f. Press the generate now button
13.g. After the build process do a right click on the Heightfield generate-node and do a 'Save file as ...'
13.h. Save both Ter and Exr ... keep an eye on the file-extensions.
14. Delete the heightfield-generate and add a heightfield-load, load the Ter file of 13.h.
15. You might need to set the position of the heightfield in the heightfieldshader.
16. Into the blending shader of the heightfield plug in a new imagemap shader, use camera projection and the ortho camera.
17. Load the .Exr-image (or converted to BMP, etc.)
18. I hope that I did not forget anything ;)
Volker
These are sad news, Domdib :(
@Calico: Feel free to add it :)
EDIT: I seem to have been mistaken about this problem - I'm unable to replicate it. Sorry for misleading anyone!
shadowphile,
Sorry I didn't get to this earlier. There is a way to do this but I know that the process is not transparent enough.
The basic concept is as follows. You have some terrain which is generated by shaders. Follow that with a Displacement Shader ("Add Terrain" -> Dislacement Shader -> Displacement shader) to perform the modification. The displacement function needs to: 1) get the current altitude (it's in metres or world units); 2) modify it using scalar functions; 3) subtract the original displacement so that the function result can be applied as a straightforward displacement of the original surface without doubling up the original displacement.
Here's a screenshot of a network that simply clamps a powerfractal terrain to a maximum altitude of 200. The constant scalar node has the value 200.
[attachimg=1]
There may be situations where this doesn't work as expected, e.g. if the terrain you want to modify is a displacement along some unusual direction and is therefore not simply generating altitude. In those cases you may need to get creative with the 'get' nodes to retrieve displacement vectors and modify those.
Matt
Matt, I like this solution. It's simple enough for someone with moderate experience to use. I also appreciate that you did not relabel to node functions. 8)
I like to be prooven wrong ... sorry that I mislead you, folks, I was sure that this node-setup would not work.
This is obviously something that I want to make easier and more intuitive. The setup I suggested is pretty simple and allows almost any kind of function-based modification of altitudes, but you have to think along particular lines to come up with the idea in the first place. So my question to anybody reading this is: how would like you like to see the interface work for general modifications of terrains by altitude? It needs to allow general function modifications like the above, in addition to any other easier methods which might be included. While a shader that allows you to perform basic modifications or to draw an altitude profile curve would be great (and may come in future versions), we also need a more intuitive way to utilise function nodes like the setup I showed above, but without the counter-intuitive node setup.
(I hope you don't mind me hijacking your thread, shadowphile. I hope you find the example I posted useful.)
Matt
Quote from: shadowphile on September 13, 2009, 10:49:48 PM
Let me be more clear: the examples I find always generate data from scratch using the position data, but I would like to interrogate an established shader and either change it directly or generate a new shader that is the result of my applying the function to the shader results.
The 'get' functions, such as "Get position in texture" or "Get altitude" query the
current state, which stores information about the surface at the current point in the shading/displacement pipeline. Shaders, such as the Displacement Shader, change these values, so the values depend on what shaders have already been called earlier in the shader pipeline. Functions alone do not change these values - they perform maths operations on whatever values you provide them with, but they need to be plugged into some kind of shader to actually modifiy the surface, cloud, or whatever is being shaded. When you have a network of functions providing information to a Displacement Shader, the 'get' functions retrieve information about the surface being shaded by the Displacement Shader. Basically, information about the surface includes changes that were made by all the other shaders that provide input to the Displacement Shader (in my example they are the Power Fractal Shader and the Heightfield Shader.) Usually, the main 'input' connection of a shader is evaluated before any of the other inputs. If your function network were a RenderMan shader written in the RenderMan shading language, the 'get' functions would be the equivalent of the variables P, Pg etc. or simple relationships between these variables as in the case of "Get altitude", dot(P - Pg, Ng).
I think the problem lies not with the interface but with our lack of knowledge of the program. This is not meant as a criticism but more a simple statement of "fact", well at least as I see it :) You and the developers have a vastly deeper understanding of how the program works from the inside looking outwards. You understand its inner workings. I as an artist see the program from a different perspective.
The solution you posted above is so simple and effective and also one that the best of us couldn't come up with. :( I don't want to change terragen. I like it just the way it is. The interface is unusual, but no more than any other node based graphics program, XSI, Lightwaves shader networks and even the internal node editor in Vue. I'm learning a lot about the concepts behind some of the functions now, Volker and others have been incredibly helpful but still large areas elude me. What the solution? Not really sure, but don't change the interface please, its too useful to have it open ended like this :) Wasn't that one of you "tenets", to allow the user to put pretty much any value, any combination of nodes together? :)
The best I can come up with is keep pushing the Terragen wiki (http://www.planetside.co.uk/wiki/index.php/Terragen_2_Tutorials), keep encouraging the community to share its knowledge and just possibly (if you've gut the time lol) start writing (or adding to the wiki) your "insiders view" of a guide, something that doesn't treat "functions" as a separate subject. :)*
Waffle over :)
Richard
*like you just wrote lol :)
Cheers Richard. This is useful to know.
Matt, thanks for the explanation. It is difficult to understand how the altitude can be used to modify the altitude, without
understanding the order of calculations.
I've used ramp curves for many things (Curve Editors). The ability to add points to a curve and move them would be nice. It could be used for almost anything, from strata, altitude/slope, color, and power fractals. It could be used as an input or blending shader, and adapt to the function/s it's being called for.
No, no. You. It's yours. You get credit. I'm not the Ghost Author; you are. Get the credit, sahib.
Quote from: Volker Harun on September 16, 2009, 02:49:34 PM
@Calico: Feel free to add it :)
I read a lot of tutorials, seen the screenshots :o and they may as well be in ancient Etruscan for all I understand. To truly grasp T2, one needs a fairly comprehensive knowledge of mathmatical functions. Something I shamefully lack. Heck, I have trouble keeping my bank account from tanking...
What Matt has shown is simple and elegant, and I'd sure like to see more of this! Thanks to all who added something here!
bravo Matt! That is the exact kind of information I was looking for and clarifies a lot. Subtracting the altitude from itself to recreate just the displacment, using my example, is something I kept feeling I would need to do but didn't know how. The short of is that there is no way to DIRECTLY specify a terrain, it must always be shaped to act as a DISPLACEMENT from the input terrain.
I can run quite a ways with just this info, thanks for the breakthrough. Its appears others were hungry for this level of understanding as well. :)
Quote from: Matt on September 17, 2009, 09:08:39 PM
This is obviously something that I want to make easier and more intuitive. The setup I suggested is pretty simple and allows almost any kind of function-based modification of altitudes, but you have to think along particular lines to come up with the idea in the first place. So my question to anybody reading this is: how would like you like to see the interface work for general modifications of terrains by altitude? It needs to allow general function modifications like the above, in addition to any other easier methods which might be included. While a shader that allows you to perform basic modifications or to draw an altitude profile curve would be great (and may come in future versions), we also need a more intuitive way to utilise function nodes like the setup I showed above, but without the counter-intuitive node setup.
(I hope you don't mind me hijacking your thread, shadowphile. I hope you find the example I posted useful.)
Matt
Just found this old thread. I agree with njeneb.
A curve graph with maximum and minimum inputs and outputs. Then this can simply be used to manipulate whatever ranges you want whether it's altitude or the fractal output to colour or whatever. It becomes THE most powerful component in TG2. This may not be easy to add to TG2 but it's the ultimate solution. We need to get into the concepts of what we are doing so that it's not about "altitudes" or whatever but about - you change these values and ranges to get this output shape. This way TG2 remains open ended. If we say have something that can sculpt altitude profiles then what if we want to sculpt something else via some sort of curve? It all ends up more confusing rather than understanding the actual basics of the data and how that shapes the forms.
For example, at the moment it is possible to pretty much sculpt the terrain profile fairly accurately but by joining together a mass of maths functions and in particular, the smooth step node. I currently have a big set up like this to sculpt terrain profile but it could all be achieved with a single graph.
Yes, I know a curve graph that can handle everything is probably not a simple addition but thinking along any other lines is pointless.
Hi efflux,
TG2 will definitely have a curve graph in the future.
Regards,
Jo
OK, thanks Jo.
I just read Matt's response on here although it was a while ago. He seemed to be suggesting some kind of shader type thing that might just do terrain profiles which kind of worried me.
Quote from: efflux on February 24, 2012, 05:14:33 PM
OK, thanks Jo.
I just read Matt's response on here although it was a while ago. He seemed to be suggesting some kind of shader type thing that might just do terrain profiles which kind of worried me.
When we implement this we'll start with a function node that applies an editable curve to its input. We're well aware that it's useful for much more than direct manipulation of terrains. There might also be a displacement shader that applies a curve to the displacement or altitude on a surface, but we'd almost certainly give you the function building block first.
Matt