I have the free versions of Terragen 0.9 and Terragen 2 (please don't think I'm cheap), and recently I somehow managed to figure out enough of the latter to actually make a few images. I'm quite fascinated with Terragen 2's abilities and capacity for realism, but I'm afraid the program is highly counterintuitive and I have a few questions I thought maybe someone could clear up for me. Okay, so maybe it's a lot of questions. It's not my fault I'm a noob!
- Generally I prefer to render my images overnight, because nighttime is usually the longest block of time during which I don't use my computer. This timespan is normally about 9 to 10 hours long. I hope you didn't just eat, because my computer's processor is an Intel Celeron which says it runs at 1300 megahertz, and it has 256 megabytes of real RAM and about 1024 megabytes of page file space split evenly among two separate hard drives. It is running Windows XP Professional, and background processes include Windows Live Messenger, Steam and possibly a few others. Is there any way I can calculate a fairly accurate measurement of the time it will take to render a particular image? What kinds of settings would you suggest to achieve the maximum quality while minimizing the wear on my hard drives, without going over 10 hours?
- I tried importing a heightfield made in World Machine. After a while I even figured out how to get rid of part of the heightfield forming a square depression in my ground. However, I still have a problem. Sometimes when I open the TGD file, the preview and render will refuse to show the heightfield at all. So far it appears that this is inconsistent, that is to say it can change despite absolutely no changes to either the TGD file or the heightfield file (including filename and directory). Is there anything I can do to make sure that the program consistently reads and displays the heightfield properly?
- My first couple landscapes turned out okay, however I recently tried setting a lateral displacement on my terrain and the result looked rather odd (both in the preview and when rendered). Is there some trick to making overhanging cliffs that actually LOOK like overhanging cliffs and not like buggy computer graphics? The lateral displacement menu option said 'requires computed normal'. Does that mean I have to put the displacement shader after a compute terrain shader and then put another compute terran shader after that before I get to the surface layers? Is a displacement shader even the right thing to use at all?
- I heard somewhere that someone was implying that with the free version, I am limited to no more than three object populations. Is this correct? If so, is the limit on populations, or only object files (that is to say, can I have four populations of the same TGO or OBJ file)? I have not tested this yet.
- I downloaded the free Xfrog plants from their website. I read that the fifteen objects in this set are composed of three species of plants, three ages of each species. Each tree object is marked with a, m or y and each flower object is marked with 01, 02 or 03. Which plant ages do a, m, y, 01, 02 and 03 correspond to?
- I've tried importing two of my own OBJ files which I made in Art of Illusion. The first one worked perfectly (or at least as perfectly as could be expected). The second one, however, contains a number of 'spikes' sticking off the model which were not present in the AOI file (Art of Illusion's native format). These exist whether or not I choose to subdivide smooth surfaces during the export process, and no matter what quality setting I put for the population. Is this a problem with the way Art of Illusion exports OBJ files, or a problem with the way Terragen 2 imports them? If the latter, is there anything I can do to correct it?
- Another OBJ problem: The first OBJ file I made to try in Terragen 2 had two images to go with its associated MTL file. After I updated to the newest version of Art of Illusion, the program would no longer make any images for the MTL file for my new object. I took a look at the two MTL files and reverse engineered the image syntax in order to make an image for one of the textures on my new object, which worked. However, the texture appears far too small when rendered in Terragen 2. Is there any way for me to scale up the texture in Terragen 2 or in the MTL file itself so that it appears the proper size when rendered? Would scaling the object itself down help at all, and if so, if I scaled other objects (like trees) down to match the new scale, would THEIR textures get messed up in any way?
- Is it possible to make waterfalls in Terragen 2, without using objects? If so, is it possible to do it EASILY? If so, how is it done?
Sorry for being such a pathetic, worthless noob. I may not have much time, so don't be surprised if I can't post responses to any answers I get. Also, don't be surprised if I come up with more questions in the future. Thanks in advance!
welcome ! you're in the right place for getting answers !
though not from me cuz' i'm still a noob like you !
hope you'll find good teachers in here soon ! (no doubt you will) :)
1. Depends on the image. Images with High detail settings (in both node settings and rendering settings) will lead to some long render times.
2. Could you go into more detail on whats happening? It could be any number of things.
3. There are some good tutorials on this, I'll see if I can find them. If not one of the other members will not doubt give you a link.
4. I'm pretty sure it 3 populations total, no matter the obj or tgo, not sure if this effects items that are not part of a population.
5. not a clue, never used them.
6. hmm could be a problem with displacement, maybe there is a space in the map thats not matching up?
7. are they in the Image file node? if so you can just use the scale, if not you could try adding a transform node that could work.
8. Probably but it would most likely need to involve functions.
(in response to Will's post)
1. So far, my node networks have been rather simple. I understand that higher settings can dramatically increase the render times (most especially volumetric clouds). I'm wondering if anyone here can give me a good idea of how to fine-tune my render time and quality so that I don't go over and end up being unable to use my computer for an hour or two (or ten) in the morning.
2. There isn't really any more detail to add. Sometimes when I open the file, the heightfield simply isn't there on my terrain. The white wireframe box that normally goes around the heightfield is also missing. I'm not using any fractal terrain, the heightfield is the only thing affecting the terrain displacement. The colored surface layers still show up normally, and everything else including sky, water and (I believe) object instances also show up normally in both the preview and the final render. It's only the heightfield that vanishes, and so far I haven't found any way of predicting whether it will vanish or not each time I open the TGD file.
4. So you mean I might be able to have lots of individual objects? Hmm...that's nice, except if I recall correctly I tried putting just one individual object in a file, as a test, and it didn't work...
6. How do you mean, a 'space in the map'? I've heard it implied that you can do stuff to objects within the program itself, but I'm not doing that, I merely inserted the population and changed only the population characteristics (including the object scale and quality).
7. What image file node? And if I don't have one, what do you mean by adding a transform node?
8. Okay then. I haven't used functions that much yet. The program is so very counterintuitive, nothing seems to work the way I expect it to work so unlike with Terragen 0.9 I really have to start from the ground up...and it's a long way up...
Looking forward to any more answers!
Quote from: green_meklar on September 16, 2007, 09:59:56 PM
1. So far, my node networks have been rather simple. I understand that higher settings can dramatically increase the render times (most especially volumetric clouds). I'm wondering if anyone here can give me a good idea of how to fine-tune my render time and quality so that I don't go over and end up being unable to use my computer for an hour or two (or ten) in the morning.
Each scene you will create will have factors that may increase or decrease your render times accordingly. Even the position and orientation of your camera will affect the length of render times. In my experiance there really are five values that have the largest effect on rendertimes: Detail, Antialiasing, GI Detail, GI Quality, and the Quality settings within your Atmosphere and Cloud nodes. Other than the obvious "Lower values will mean shorter rendering times" there isn't too much else to say.
Quote from: green_meklar on September 16, 2007, 09:59:56 PM
8. Okay then. I haven't used functions that much yet. The program is so very counterintuitive, nothing seems to work the way I expect it to work so unlike with Terragen 0.9 I really have to start from the ground up...and it's a long way up...
Node based systems are very intuitive to those who have used them before, lot's of software use node based systems nowadays. I personally have to disagree with the statement that TG2 is counterintuitive. Having worked with many node based programs, I have to say that TG2 uses many standard concepts of a node based system that make it really easy to get into. Within a few minutes of my first time in TG2, I was getting displaced terrains with clouds and rendering them fine.
Those of you who have not used a node based system will probably say that TG2 is counterintuitive, but then again, everyone has mentioned this the first time they use a node based system in any software. Sure TG2 needs a few UI optimisations, but I wouldn't say it's counterintuitive...maybe you can give us some specific issues for us to help you with?
Nobody has yet congratulated this person on managing to run XP Pro on a Celeron with only 256 mb RAM.. :o ...Hats off to you !!
Rgds
Chris
good point
Point 1: a testrender of the same resolution at 0.2 quality will last with 0.9 quaitly ~20x longer, at quality 1 ~25x longer.
Point 2: I've heard of it ... and I think it is on the todo list ... reloading the heightfield should help, but.
Point 3: You will not need lateral displacements when using the displacements on high slopes (slope-tab in the surface shader) On slopes you use along normal. Take care that the displacement fractal is not too noisy!
Volker
QuoteNode based systems are very intuitive to those who have used them before, lot's of software use node based systems nowadays. I personally have to disagree with the statement that TG2 is counterintuitive. Having worked with many node based programs, I have to say that TG2 uses many standard concepts of a node based system that make it really easy to get into. Within a few minutes of my first time in TG2, I was getting displaced terrains with clouds and rendering them fine.
It's not the node-based system that's counterintuitive. I have used both World Machine and Art of Illusion before Terragen 2 and they both use node systems as well. What I find counterintuitive is the names of everything in the program. For example, the word 'shader', which you'd intuitively think would be simply an array of values in two or three dimensions, turns out to cover a wide variety of quite different nodes that do everything from creating cloud fractals to coloring terrain. And that's not all: 'Bluesky exp height' doesn't say what 'exp' means, 'catmull-rom interpolation' could hardly get less informative and 'sample jitter', 'buoyancy from variation' and 'light propogation mix' might just as well be 'x', 'y' and 'z' to the layperson. 'Lead-in scale'- why didn't they just say 'largest scale' the way they said 'smallest scale'? And as for 'unclamped multifractal', it literally sounds like technical jargon deliberately exaggerated for comedic effect, and it almost comes as a surprise that the program is dead serious about it.
QuoteNobody has yet congratulated this person on managing to run XP Pro on a Celeron with only 256 mb RAM.. 8O ...Hats off to you !!
Not my doing, I got this computer third-hand and haven't made any major changes to its operating system, hardware or drivers.
QuotePoint 1: a testrender of the same resolution at 0.2 quality will last with 0.9 quaitly ~20x longer, at quality 1 ~25x longer.
Okay, so you say 0.9 quality will take approximately 20 times as long as 0.2 quality...but are you saying that 1 quality takes 25 times longer than 0.2 quality, or 25 times longer than 0.9 quality (500 times as long as 0.2 quality)?
QuotePoint 2: I've heard of it ... and I think it is on the todo list ... reloading the heightfield should help, but.
How would I 'reload the heightfield'?
QuotePoint 3: You will not need lateral displacements when using the displacements on high slopes (slope-tab in the surface shader) On slopes you use along normal. Take care that the displacement fractal is not too noisy!
Okay, thanks, I'll keep that in mind. It's possible I may have had the displacement fractal too rough, I'll see what happens if I make it smoother and use 'along normal'.
Hi and welcome to the forum :)
I know what your saying with TG being counter intuitive although I would also say that in order to achieve some of the things this program dose they have had to make some fairly radical departures from the normal way of doing things. Don't fret about it though all will become clear in time. As others have said, keeping your render settings down is vital to getting anything actual rendered in a reasonable time frame. This will depend on your desired finished result. At present I don't even think of rendering to print. An A4 sized image at 300 dpi would come in at something like 3000 x 2000 pixels wide and would take an interminably long time to render! I render to a decent screen resolution, max really would be 1200 x 800 but in your case you might want to think about dropping that down lower, maybe to the size of your screen. The things that will impact on render time apart from output size are the render quality, something between 0.5 and 0.8 are good for finals (nobody renders at 1.0 !!). The Anti Aliasing setting can go from 0 - 9, a setting of 3 - 6 will generally suffice (lower is faster, higher is better). GI Relative Detail & GI Sample Quality can GREATLY increase your render times, disable these (setting 0) or leave them both on 1. The other main component to increased render times is the quality settings in your Atmosphere and cloud settings. Low settings can b e noisy, high settings will be smoother. Try between 64 and 128 for clouds and only go higher if you really have to. You don't need ray tracing active unless the terrain is casting shadows onto the clouds.
I don't have much experience with imported hight fields but you may want to see if you can export the height field as a .ter and then re-import that.
SCALE SCALE SCALE
Understanding this is the most important step to getting the results you want. The default measurement in Terragen is meters. You'll notice that the Heightfield generate node is set to 10,000 meters (10Km). Fractals have lead in scale and smallest scale also in meters. Volker Harun posted an excellent tutorial on getting textures to the right scale http://forums.planetside.co.uk/index.php?topic=2287.0 (http://forums.planetside.co.uk/index.php?topic=2287.0) Take a close look at this as it may help you with your overhangs. When a value is not represented in meters it is generally a percentage expressed as a value between 0 & 1 (or over or bellow) These are effectively multiplying the input value bay their amount.
It dose all take a bit of getting used to but your in the right place to get all your answers.
I wouldn't try making a waterfall in TG, rather export some data from TG and use another app more suited t partical simulations.
If you have problems with imported objects, firstly check that they use no procedural textures made in the original app and then convert them through the free Poseray app.
Your limited in the free version to three object populations. This means that you can have as many copies of your three selected objects as your three object populations can handle.
Good luck and be sure to post some examples of your work
Richard
The quality time is: (1x1)/(0.2x0.2)=25
Reloading the heightfield: Just reopen the heightfield-file.
QuoteAt present I don't even think of rendering to print. An A4 sized image at 300 dpi would come in at something like 3000 x 2000 pixels wide and would take an interminably long time to render! I render to a decent screen resolution, max really would be 1200 x 800 but in your case you might want to think about dropping that down lower, maybe to the size of your screen.
No, I'm not doing anything for printing. No way my computer would be up for that, it would probably overflow its virtual memory and spend all night writing and reading the hard drive without going anywhere. :\
My screen is set to 1024X768, but so far I've been doing my final renders at 640X480 (and preview renders at about 300X225 or thereabouts).
QuoteGI Relative Detail & GI Sample Quality can GREATLY increase your render times, disable these (setting 0) or leave them both on 1.
I understand that 'GI' stands for '
global
illumination', which I've seen implied is when you bounce light around a few times rather than tracing just a single light ray for each point. What kinds of quality differences would I see between 1 and 2 and how would that differ from the quality differences between 0 and 1?
QuoteThe other main component to increased render times is the quality settings in your Atmosphere and cloud settings. Low settings can b e noisy, high settings will be smoother. Try between 64 and 128 for clouds and only go higher if you really have to.
Actually, so far I've been staying well under 64 for cloud quality. I managed to get both some acceptably good (although still subrealistic) clouds as well as some really crappy clouds, so I'm thinking that the density fractal settings are probably quite important in the final cloud realism. One thing I was wondering, how do cloud quality and atmosphere quality interact? If you set one really high and the other really low, how does that compare in terms of image quality and render time to setting them both to medium? Since they seem to be one of the main things that affects render time, it might be very useful to know.
QuoteI don't have much experience with imported hight fields but you may want to see if you can export the height field as a .ter and then re-import that.
It already is a TER file to begin with, I saved it as a TER file from World Machine.
QuoteIf you have problems with imported objects, firstly check that they use no procedural textures made in the original app and then convert them through the free Poseray app.
I'm not sure what you mean by 'using procedural textures in the original application'. I tried exporting the object both with procedural textures and with uniform textures and it didn't create any image files either way. The MTL file doesn't seem to refer to the application or any kind of procedural textures either.
QuoteGood luck and be sure to post some examples of your work
I may when I have something that isn't totally embarrassing. So far I haven't made anything that can stand beside the stuff I've seen from people here. Of course my computer might not even be capable of making such images within my time constraints, and my best images will probably be the ones that can look good while remaining computationally simple (i.e., rocky mesas with no plants or water and only a few clouds).
QuoteReloading the heightfield: Just reopen the heightfield-file.
Actually, I did manage to get it to refresh and load into the scene after it failed to load on opening. I went into the original heightfield node and unchecked then rechecked the 'read from file' checkbox and the heightfield popped into existence. :D
Okay, really hate to double post, but there's something else I'm going to need cleared up. It has come to my attention that I really, really do not understand how these shader things work. At times I find myself questioning the idea that they even DO work, although for the time being I'll blame myself before I blame the program designers.
When inserting a population of objects, I keep running into these same problems over and over again with the shaders. The population node has only one input port which I think is called 'terrain shader'. Yet the population node is actually USING two shaders, one for 'sit on terrain' and the other for 'use density shader'. It seems that sometimes if I save the file, exit the program and come back in, the population node will have magically spawned an extra input port. This is inexplicable enough in itself, but there's more. The shaders simply don't do what they say they're doing. As an example, just now I tried limiting the maximum altitude of the tree shader to 250 with a fuzzy zone of 100, and the program neatly sprinkled trees above a certain altitude. And even that's not all. At other times, the population will be placed on a level plane and as a result end up floating in the air over low terrain while intersecting high terrain. If I recall correctly, in one instance, placing and deleting a connection between the compute terrain shader and the population shader would toggle the population between one, existing on a flat plane with proper fractal density, and two, existing on top of the terrain uniformly (i.e., ignoring the fractal density). Given all these mysterious and counterintuitive activities by the nodes, I'm frankly surprised I ever got a population working in the past at all. Just what the (I'm not sure what this place's policy on swear words is) heck is going on here? How does one go about making the population exist in the desired and expected manner?
Well, Mr. or Mrs. Green_Meklar.
This is a point that confused many.
When going for a population, do the following:
- Create the atmospheres and ground surfaces (the last is more important)
- Create your population and place the cursor in the first field of 'Area Centre', move your mouse then to the preview window, approx. where the middle of your population should be.
- Enter the values for X and Z into the 'Area centre' using the 'Tab'-key to switch, leave (!) the Y value 0 or your population will float or drown
- Create a distribution shader to your like.
- Do a 'Populate now' and Preview the instances. Adjust the length a and b for width and depth of the area of interest.
- Finetuning: If you made displacements in the surface shaders, you might want TG2 to consider these. Default in the 'Terrain Tab' is the 'Compute Terrain' (sit on terrain enabled). This means, that any displacements after the 'Compute terrain' node will not be considered. Safest would be to assign the last of your surface shaders instead. The one just before the 'Planet 01' node.
Render and have fun ,-)
And feel free to ask anytime.
Volker
1. there is an option to go inside your nodes (if you already dint knew, right click --> Internal Network
2. are you using a surface shader to limit the population or distribution shader....when you add distribution shader it doesnt turn on by itself even though you have specified what to use as blending shader (in this case distribution shader) you have to click on the checkbox that is beside the blending option....
Admittedly some of Terragens workings do get a little getting used to but once you do understand them they're fairly predictable and simple to operate. Populations ssues do seem to occur after extreme displacements but in almost all cases problems come from bad wiring. The deliverance between the 'Sit on Terrain' and 'Use Density Shader' is as follows. The objects have to sit on something and the 'sit on terrain' chooses that surface, generally the Compute Terrain node but you could use another node such as the last node in your shader tree. The 'Use Density Shader' defines the distribution across the terrain so if you plugged in a checkerboard image then you objects would be distributed in a checker board fashion. If your using a "Surface Layer" as your distribution be aware that if your pretty much anywhere other than the "top" of the planet make sure "Use y for altitude" is un-checked in your altitude settings.
Attached is a very simple set up showing a working population. You'll need to re-specify your own objects.
Hope this all helps
Richard
Quote from: green_meklar on September 23, 2007, 04:44:07 PM
The population node has only one input port which I think is called 'terrain shader'. Yet the population node is actually USING two shaders, one for 'sit on terrain' and the other for 'use density shader'. It seems that sometimes if I save the file, exit the program and come back in, the population node will have magically spawned an extra input port.
This issue is something that I agree needs to be cleared up. When you create your initial population, there appears to be only one type of input connection. To make the other input connections (Like Density) appear you must do the following:
* Create a shader, any colour shader will do.
* Go to the population node attributes, next to the Density field path then click on the button that has the 3 "..." to the right of the path field.
* Manually assign the shader you created earlier.
* With the population node still selected, click on the button next to the edit field of the name of the node called "Edit the Internal network of this node"
* Go back the the main node level (Up one level)
Now you will see the second input. I hope this is clear for you.
QuoteWell, Mr. or Mrs. Green_Meklar.
Male, unmarried and, if you don't mind nitpicking, all lowercase. :P
QuoteWhen going for a population, do the following:
[stuff]
1. Yes, I'm aware that the terrain needs to be ready before a population can sit on it.
2 and 3. Actually, I managed to figure out this trick on my own. I usually just use rough values rather than your tab system, but I most certainly make use of the pointer coordinates displayed below the preview when positioning the population.
4 and 5. This is one of the sticky parts. Like I say, I got a case just before I posted replay 12 in which a maximum altitude set on the density shader resulted in the trees going above a certain altitude.
6. Hmm...this is something I should definitely keep in mind for the future. For the time being, though, my problems don't involve displacement after the compute terrain node.
Quote1. there is an option to go inside your nodes (if you already dint knew, right click --> Internal Network
Um...I'll take a look at that.
*goes and takes a look at it*
Interesting, but I'm not sure if it's a good way for me to understand the working of the shaders better. Most of the time when I do it, it doesn't show anything at all, although my population does show one...um...subnode?
Quote2. are you using a surface shader to limit the population or distribution shader....when you add distribution shader it doesnt turn on by itself even though you have specified what to use as blending shader (in this case distribution shader) you have to click on the checkbox that is beside the blending option...
How would I tell the difference? The population has a checkbox where it says 'use density shader', that's checked, beside it is a text input field which says 'tree layer' (the name of the shader with the maximum altitude set), and below the text input field is another checkbox that says 'invert density shader', which is not checked. The tree layer is connected with a white line to the compute terrain node at its input port, and the population itself is connected to the compute terrain node at its terrain shader port and to the tree layer at its density shader port. Is that the way it's supposed to be?
EDIT: Whoops, forgot about the second page for a moment.
QuotePopulations ssues do seem to occur after extreme displacements
'Extreme' meaning...?
QuoteThe objects have to sit on something and the 'sit on terrain' chooses that surface, generally the Compute Terrain node but you could use another node such as the last node in your shader tree. The 'Use Density Shader' defines the distribution across the terrain so if you plugged in a checkerboard image then you objects would be distributed in a checker board fashion.
This is what I had assumed so far. However it doesn't always appear to work that way for me. For one thing, creating or deleting a connection between the compute terrain node and the density shader node changes the way the population works.
QuoteIf your using a "Surface Layer" as your distribution be aware that if your pretty much anywhere other than the "top" of the planet make sure "Use y for altitude" is un-checked in your altitude settings.
Okay, I'll have to go make sure of that.
QuoteThis issue is something that I agree needs to be cleared up.
[fix method follows]
Oh, so there is in fact a bug associated with it and not just me messing stuff up? That's reassuring, especially considering you said how to get around it. Still, does your fix method theoretically change the way the population works, or only the way the nodes are represented on the screen? Is it necessary to use the fix before doing certain things in order to make the population work correctly?
Quote from: green_meklar on September 23, 2007, 10:19:57 PM
Oh, so there is in fact a bug associated with it and not just me messing stuff up? That's reassuring, especially considering you said how to get around it. Still, does your fix method theoretically change the way the population works, or only the way the nodes are represented on the screen? Is it necessary to use the fix before doing certain things in order to make the population work correctly?
This does not change the population in any way, just how it's displayed. It will still react normally to any node you have input into the population.
QuoteThis does not change the population in any way, just how it's displayed. It will still react normally to any node you have input into the population.
Okay then, thanks!
By the way, cyphyr, I'm wondering about what you said about sit on terrain and making sure it works properly. I noticed after my last post that I had some trees in one image floating just slightly off the surface of the ground. If I set the population center down a few meters, will the population take both 'sit on terrain' and that into account and move the trees downwards, or will it have no effect? If the latter, what should be done to make sure the trees sit either directly on or very slightly under the terrain and not slightly above it? Your post seemed to relate to this kind of thing.
HI G_M
If you want to change the position of objects relative to your population then move the reference object a small amount, this movement will then be translated right across the entire population. By the way what I meant by extreme displacements applies to situations where you have overhangs and suchlike. Effectively the populations are distributed in the x and z axis and moved upwards in the y axis; therefore you cant have a population overlapping on itself.
Richard
QuoteIf you want to change the position of objects relative to your population then move the reference object a small amount, this movement will then be translated right across the entire population.
I'm not sure what you mean by 'the reference object'.
However, I did try two small test renders of my scene, one with the population coordinates at y=0 and the other with it at y=-5, and from what I could see in the relatively rough render I could get in a short amount of time, it appeared to work. I'll run a large, high-quality render tonight with y=-2 to see if I can get a proper final image with trees that don't appear to be hovering.
QuoteBy the way what I meant by extreme displacements applies to situations where you have overhangs and suchlike. Effectively the populations are distributed in the x and z axis and moved upwards in the y axis; therefore you cant have a population overlapping on itself.
I see. In such a case, would the objects be distributed on top of the overhang or on the terran underneath it? Would it be possible to make two populations which would get instances onto both areas by changing the population coordinates, or can it only be done, say, by telling them to sit on a terrain designed to match one level of the overhang but not the other? Not that I'm planning to do anything this complex anytime soon, but I just want to make sure I understand what you're saying.
It seems like you're getting a lot of good input already so I'll let you guys hash through things unless more help is needed. But I did want to mention that if you're using a Surface Layer for your distribution, unless that layer's color is pure white it will not act as a pure distribution function for the population. A better approach usually is to use a Distribution Shader as this doesn't have the same color issue - it just puts out a basic grayscale mask based on the distribution settings in the node.
- Oshyan
btw, I did a final render of that world with the population at an altitude of -2 and the trees now look like they're standing on the ground properly. The scene still doesn't look entirely realistic, but it's one of my best yet (and also the biggest).
I still have an issue that I haven't been able to resolve, though: That of the scaling on object textures. I looked at the internal networks but I can't find any 'texture scale' or anything along those lines. Does anyone know how to do this properly?
By default imported objects are setup to respect UV maps that are setup in other applications. These will define scale, placement, etc. The Default Shader that is used to load images in these setups does not have an explicit Scale setting. If you want to control scale manually within TG2 replace the Default Shader with an Image Map Shader, plug it into the same Multi-shader input, and load the same image, then use the Size controls there.
- Oshyan
Okay, I'll try that.
I tried that, and it didn't work out very well. First the mapping was set to 'through camera' which was highly unrealistic. When I set it to 'use object UV', the part of the object covered by the texture turned black. How does one go about making the texture mapping respect the alignment of the object faces while still allowing the texture to be scaled?
This is not really something you can do within TG2. TG2 is not intended to be a modeling or model adjustment application. You should adjust the UVs (and thus the scale of the texture) in another application that is better suited to 3D modeling and texturing.
- Oshyan
So do you think if I increased the texture scale in Art of Illusion and then reexported the file, I could make it work properly?
Also, some other things I've been wondering. First, it seems that when rotating the camera in the preview (alt+left mouse button), the camera rotates around a point external to itself. Is there a reason for this, and can it be turned off somehow? Also, if I zoom too far away from the default planet, everything starts disappearing into blackness, with the atmospheric halo usually being the last to go. Is there a way to fix this?
What about the UV's on the terrain made by Terragen?
Quote from: sjefen on October 05, 2007, 11:42:31 AM
What about the UV's on the terrain made by Terragen?
What do you mean?
- Oshyan
Okay, I don't know what this forum's policy on necromancy versus spamming is. Every forum seems to have their own code of conduct, so I guess I just have to hope that posting in this thread a month after the last post is considered the proper procedure as opposed to making a new one. Or that if it isn't, you guys don't get angry at me. Or at least not any more angry than I deserve. Which is probably pretty angry. I can post a new thread if you like, so if that's required by your forum customs, feel free to say so.
There are two things that are really starting to bug me. The first is the thing with the camera at long distances that I already mentioned, which basically prevents me from rendering the default planet anywhere higher than low orbit. I would like to be able to do a planet from an appreciable distance, but it looks like if I want to do that I'd have to make a new planet and move it away, which I would prefer not doing because it adds complication and I haven't even tried it yet to see if it works anyway.
The second thing (which I haven't mentioned previously) is functions. From what I've seen here, most of the decent artists swear by functions. But go figure, every single time I've tried to use functions to alter the terrain, the result has always been the same: The terrain ends up totally flat. It doesn't seem to matter what function I use, where I put it in the network leading up to the planet's terrain input, or what parameters it has. Whenever I plug a shader into a function, it invariably comes out flat. I haven't tried them on other things like water or clouds yet, but if I can't do it on terrain, there's not much point anyway. Can anyone explain what I'm doing wrong? Or is it just one of those things that will always remain a mystery to me due to my limited talent and mental ability?
First point.
There does seem to be some strangeness when you zoom out the camera to large distances (outside of the black sphere). Does that black sphere's normals interfere when the renderer attempts to work out what it needs to draw? Even at a quality of 1, the planet appears like it has black parts.
Second point.
Without any examples it's hard to give you any answers. Generally it seems that you are not using them correctly. If you are new to functions, I highly recommend opening up some of the setups that people have posted here, and experiment with changing various values and nodes one at a time. By understanding the results that these setups give, you can deduct what results happen when you change a value here and there.
Do a search on nvseal. He has done exactly what you say you can't do, though he is doing it better than any of us. So that means you'll need practice.
This brings us to the second thing - there have been quite a few threads that do nothing but talk about making functions work. Get involved when these take place, go through the threads that have TGCs with functions, practice what you read people talking about functions (ask more questions) and
especially do what you can to do some tutorials on functions. There have been some created just for that and you'll find them under the Terragen 2 Documentation thread.
Practice what you learn and you'll discover possibilities you don't know.
To start a function, begin with a Get Position. Build from there by adding this to the Input of some Noise Function node and then add a Constant (try Scalar) to the Scale of the Noise Function node. Now connect the conclusion of this to the Function input of the Displacement Shader. Take the output of the Displacement Shader and run it through a Compute Terrain. Take the output of the Compute Terrain and go to the input of the Base Colours or another Surface Layer. All this, of course, goes into the Planet Surface Shader input. Practice. Practice. Practice.
Quote from: green_meklar on November 05, 2007, 09:34:45 PM
...which basically prevents me from rendering the default planet anywhere higher than low orbit.
The second thing (which I haven't mentioned previously) is functions.
Quote from: green_meklar on November 05, 2007, 09:34:45 PM
There are two things that are really starting to bug me. The first is the thing with the camera at long distances that I already mentioned, which basically prevents me from rendering the default planet anywhere higher than low orbit. I would like to be able to do a planet from an appreciable distance, but it looks like if I want to do that I'd have to make a new planet and move it away, which I would prefer not doing because it adds complication and I haven't even tried it yet to see if it works anyway.
The black sphere is the project's background. It's listed at the bottom in the Objects group. It's default radius is -2e+008. Change it to -2e+010 and you should have enough room. This render is from 4.46308e+008, 1.75682e+009, -7.43829e+008, camera FOV 6.75°
I completely forgot about the background object. Yeah, BigBen has it right.
QuoteThere does seem to be some strangeness when you zoom out the camera to large distances (outside of the black sphere). Does that black sphere's normals interfere when the renderer attempts to work out what it needs to draw? Even at a quality of 1, the planet appears like it has black parts.
Um...as far as I know, the renderer suffers from exactly the same problems as the preview. I
think I did a test for that, and the same thing happened. I just got black space where the planet was supposed to be.
QuoteDo a search on nvseal. He has done exactly what you say you can't do, though he is doing it better than any of us.
If he's doing it better than anyone else, then that's probably a very bad place to start. You know, sort of like learning physics from Stephen Hawking or mathematics from Kurt Godel. It won't do me much good being told that a five-step scaled vector rotation tree has to be plugged into five Turing-symmetrical voronoi displacement networks merged using a universal slope scalar smoothing node with a ceiling variation value of the derivitave of pi squared and a reverse offset shear input from a cylindrically mapped radial altitude converter indirectly blended with a disabled atmospheric shader that utilizes a memory bug in the program's built-in limitations on negative 64-bit floating point variables if I don't understand
why.QuoteThis brings us to the second thing - there have been quite a few threads that do nothing but talk about making functions work. Get involved when these take place
So far I've seen lots of threads praising the power of functions and the elite people who make wonderful honeycomb and melted plastic landscapes out of them, but I don't recall seeing any that were saying anything useful for me. It seems like every last person here started out at the 'functions work, now you just need to figure out how to make something cool out of them' level the first time they opened the program, which is one step ahead of the 'functions either make everything flat or produce infinite displacements that mess up the preview and turn the terrain into an array of giant needles' level that I'm at right now.
QuoteTo start a function, begin with a Get Position.
Is that something you always have to do?
QuoteBuild from there by adding this to the Input of some Noise Function node
Oookay... The strange thing is, whenever I change even one aspect of your setup, the terrain has a tendency to either go completely flat, or do something really weird like develop extremely long spikes that stick up into the air. It messes up most particularly when I try to plug a power fractal shader in, which is something I've seen in screenshots on these forums and which seems to work fine for other people. I'm afraid your setup, while functional (no pun intended), doesn't really give me any understanding of how these things work. You know, sort of like little kids knowing that 99+1 is 100 just because they've heard it, without knowing why that's the case. Examples are all very well...but only if they're demonstrating a principle I can understand, not just for the sake of their own existence. I hate to sound so helpless, but it's just not that easy to learn by practice when 97% of the things I try fail in exactly the same uninformative manner. I think it would do me a lot more good just to know what it is that is done by the program when one attaches the functions and the shaders together. Even if it involves advanced mathematics, at this point I think I'd prefer that to figuring it out by...by...
experimentation alone. *shudders*
Quoteand then add a Constant (try Scalar) to the Scale of the Noise Function node.
So I take it that simply typing in numbers in the fields where it says stuff like 'min' or 'scale' is totally ineffective?
QuoteThe black sphere is the project's background. It's listed at the bottom in the Objects group. It's default radius is -2e+008. Change it to -2e+010 and you should have enough room.
Okay, I tried that... Now at least the render is showing the planet properly from a distance, however the preview is still running into problems. That is to say, it only shows the atmospheric halo and not the part of the planet with solid ground. If you haven't seen this 'atmospheric halo' effect before, I can always get a screenshot. Wait, never mind. I don't think there's anything left in this program you haven't seen before.
green_meklar - Go to this URL http://forums.planetside.co.uk/index.php?topic=1266.0 and start here. This is a very simple use of functions and if you don't understand what everyone is talking about go to the bottom of this page to find the TGD that might help you by offering you the opportunity to play around with it.
The preview has limitations due to its detail level. This is just inherent to how the detail levels work. If it doesn't look right, I'd suggest just doing a quick render. Time-wise it isn't particularly slower and you can control the detail levels more explicitly.
- Oshyan
Quote from: green_meklar on November 06, 2007, 12:14:46 PM
...Quoteand then add a Constant (try Scalar) to the Scale of the Noise Function node.
So I take it that simply typing in numbers in the fields where it says stuff like 'min' or 'scale' is totally ineffective?
Correct. You need to connect numbers to function inputs via a Constant (scalar, colour or vector) node.
Quotegreen_meklar - Go to this URL http://forums.planetside.co.uk/index.php?topic=1266.0 and start here.
Wow...if anything, that thread just underlines how much the functions are beyond me. You said to start with just get position and not plug anything into that and go straight to add noise, yet in that thread ProjectX (who I'm definitely going to get mixed up with an online acquaintance named Project_Xii) says you have to plug a power fractal into the get altitude and then put a Y to scalar right after that before you start doing anything. Knowing about certain setups that work without knowing why they work is looking more useless by the minute. I'm aware that I seem to be annoying you all pretty badly with my blatant ignorance and inferiority...but surely
someone must know
how the functions work. Or is it something that can be understood, but not explained?
QuoteThe preview has limitations due to its detail level. This is just inherent to how the detail levels work. If it doesn't look right, I'd suggest just doing a quick render. Time-wise it isn't particularly slower and you can control the detail levels more explicitly.
So in other words there isn't really any way to fix it in the preview? That's kind of annoying, but I guess I can live with it. Normally I don't like to do quick previews just to adjust something like the camera, because of my slow computer speed. Instead I'll probably end up having to keep track of the planet's location just by using the atmospheric halo.
Use of the function nodes depends *heavily* on a decent baseline understanding of math and especially how mathematical functions translate into 3D space and use in 3D graphics. Previous experience with a shader language like Renderman or Maya's shader node system can help a lot. If you don't intuitively understand mathematics translated into 3D space then it's going to be a struggle for you the whole way.
I think you may be operating under the mistaken assumption that using function nodes is somehow necessary to achieve the best quality scenes, and that's not at all true. In fact the vast majority of people posting images here do *not* use functions. There are maybe 5 people here that are really producing good stuff in the function nodes - Efflux, Volker, ProjectX, and a few others - the rest are all using more conventional (and easy to understand) approaches.
So unless you're seeing something being done in functions that you really want to be able to do in your own scenes, I would just not bother trying to deal with them. For people to whom their use comes naturally they are great, but I just don't think it's worth struggling to learn them when there are many other useful techniques that are easier to understand and use.
- Oshyan
Just to back up Oshyan, the same goes for me too. I hardly ever use functions to get what I want. Also I agree, that if you do not know anything about math in 3D graphics, then trying to understand functions in TG2 from an entry point would be like trying to learn a foreign language by picking up a random novel and attempting to read it. You need to know the 'alphabet' of math in 3D graphics to understand what functions do. I would suggest any beginners book to math for 3D graphics, there's plenty out there.
QuotePrevious experience with a shader language like Renderman or Maya's shader node system can help a lot.
Haven't got Maya. Haven't got Renderman, whatever the hell that is. But I have used Art of Illusion, and I think it has similar stuff...although maybe it looks more similar than it is, especially judging from the fact that it's so much easier to use.
QuoteI think you may be operating under the mistaken assumption that using function nodes is somehow necessary to achieve the best quality scenes
That depends what kind of scene you want! Power fractals and all can look really nice, but they still don't give you the kind of control required to tweak the terrain precisely the way you want it. I learned this the hard way.
QuoteSo unless you're seeing something being done in functions that you really want to be able to do in your own scenes
I am. But if what you say is true, it's probably not worth it. I'm used to being a permanent, incurable noob anyway, so it's something I know I can take. At least for a while.
QuoteFor people to whom their use comes naturally they are great
Nothing comes naturally for me.
green_meklar,
I can awnser you first question: RenderMan is a Renderer from Pixar and has been used in many films information about it can be found here https://renderman.pixar.com/ and also this list of films made using it on Wikipedia http://en.wikipedia.org/wiki/List_of_films_made_involving_PhotoRealistic_RenderMan
Can I just add that no one said that learning TG2 was going to be quick or easy and come to think of it painless, but at the end of the day ask the questions you have when you get stuck and there are plenty of people here who can help you solve them, that is what this community is for.
I remember when a few years ago I started to take what I was doing with Terragen more seriously rather than some thing to play with while waiting for a file to download form the Internet I my self had questions about how to make more open terrain in version 0.9.43 and was simply told to move the camera zoom slider and sure enough the kind of terrain I was looking for.
Over time I asked more questions, they where answered and I began posting first on Renderosity and then on Ashundar and I paid attention to the comments on the images I posted so that those lesions could incorporated into future work, these people some of them are members here know who they are: I hope in time you will learn TG2.
In the mean time have a better one.
Regards to you.
Cyber-Angel :)
I used to thick of functions as "The scary blue boxes", sorry I don't remember who first referred to them as that. I am now becoming a real Function Junkie, not as advanced as some but learning all the time and the more I learn the more I use them.
As you say you are I was getting nowhere looking at the clips and tgds that had been posted until I found and worked through a series of four function tutorials in the Terragen 2 Documentation / User-contributed Tutorials section.
These are:
A function only Landscape : Part One - A Pyramid
http://forums.planetside.co.uk/index.php?topic=1166
A function only Landscape : Part Two - Linear Dunes
http://forums.planetside.co.uk/index.php?topic=1167
A function only Landscape : Part Three - A Detour into Perlin's Noise
http://forums.planetside.co.uk/index.php?topic=1168
A function only Landscape : Part Four - Putting it all together
http://forums.planetside.co.uk/index.php?topic=1169
I will admit that I had a fair idea about the math but these tutorials showed me how to set up functions in TG2.