Severe need for documentation

[shadowphile]

Does that make sense?  I've attached a simple example clip.

The reason why this file doesn't work is because your "mountains distro" powerfractal appears in the node-network but its settings are not described/stored in the .tgd-file.
The "mountains displ" is described/stored in the .tgd-file and therefore works as expected.

How did you create this file? Did you edit it manually in a text-editor?

nope, although what you see is the result of editing.   That may have introduced an artifact and rebuilding it from scratch might remove the problem.

[Matt]

Hi Shadowphile,

Just for the record: programming languages, either graphical or textual, exist to allow the user to roll their needs, and are probably the best examples of powerful and flexible = complexity.  I have no problem with complexity, I live it in fact.
But you won't find one of those that doesn't have very precise documentation on each and every function and what the inputs and outputs expect, and how the data itself flows.

That's a valid criticism of our current documentation, which I hope we can do something about.

For example, in another thread I started a while back, it was clearly explained to me that the blend-by-shader input only uses color, and yet when I turn on displacement in the shader feeding the blend-by-shader input, the whole image disappears.
Who is in charge here, the input or data connected to the input?  Wouldn't an input that only uses color ignore everything else?  Without having read the 'valleys' thread (very short), I eventually figured out I had to turn off displacement, EVEN THOUGH I wanted to use the displacement data from the same blending shader.  Sometimes one wants both displacement AND color data to be synchronized from the same source.
Does that make sense?  I've attached a simple example clip.

Shader connections that are named "blend shader" or "blend by shader" should only use colour information and nothing else. In the example you posted, it seems like the particular displacement settings you chose have raised a bug which I wasn't aware of. Setting displacement spike limit to 0 it is preventing the shader from generating colour for some reason. You can make it work correctly by giving spike limit some non-zero positive value.

Matt

[shadowphile]

yah, I noticed that a zero spike-limit causes blank renders.  My current mental model for the spike-limit operation is that of a low-pass filter: scales below the spike limit size (smaller) have a stronger roll-off in amplitude than otherwise.   It might be a band-pass, with subdued amplitude only at particular scales?

Anyway, I figured that a zero spike limit just blocked all since frequency = 0 means everything.

Just to show I can make positive posts too, I love the lake/water render.  My canyon-locked lake renders just look SO great!  I have to keep a simple constant shader proxy on my lake objects during dev because water-render is so slow, but it really makes those final renders awesome. (the ripples and water-depth effects for terrain just under the water surface are unsurpassed!)

[cyphyr]

During dev I almost always use a copy of the planet object with a water shader attached. I do this because the water plane can give slightly confusing feedback when it is away from 0,0,00. This gives me a water level at 0m automatically at all positions on the planet. If then I find that I can sub a water plane at final render time to speed things up then I will but this is not always the case. Just my working practice and I'm sure there are other solutions.

Richard

[Matt]

yah, I noticed that a zero spike-limit causes blank renders.  My current mental model for the spike-limit operation is that of a low-pass filter: scales below the spike limit size (smaller) have a stronger roll-off in amplitude than otherwise.   It might be a band-pass, with subdued amplitude only at particular scales?

Not exactly. Its units are not a size or a wavelength. It is basically a gradient limit, even though it can't actually operate on the gradient point per point. It puts a damper on how steep the Perlin noise features can get, because without this damping you can end up with very steep/spikey features caused by high roughness, high displacement, or high variation parameters. You might want to set high roughness values to drive an overall trend towards steeper, rougher terrain at small scales, but still need to stop the roughness getting out of hand in some places due to amplitude variations.

Matt

[Matt]

Richard, you shouldn't need to do that. If you enter 0 in the water level parameter for the Lake object, it will be at 0 altitude. If you move the lake horizontally, you will find that the water level changes because the same Y position is not the same altitude as you move away from the origin, but after you have chosen the position of your lake all you need to do is re-enter whatever altitude you want into the water level parameter.

I had to decide whether to force the altitude to remain the same when you move a lake horizontally (thus changing your Y value), or keep the Y value the same when you move along X or Z (thus resulting in a different altitude calculation). It does the latter. To lock the altitude, it would have to detect when you're only dragging along X or Z, because you want it to change altitude if you drag the object along the Y axis. Getting clever with the object manipulators (in our code) leads down a tricky path - it's better to keep it simple and allow you to drag in X, Y and Z however you want. It shouldn't be a problem to adjust water level after you have decided on a rough position for the lake.

Matt

[Tangled-Universe]

Thanks for clearing this up a bit Matt.
So to get it even more clear (for me then): which of the two altitudes in the water-object is the altitude you use in your scene when the distance is far from the origin? These values differ more over distance from the origin and I'm always confused which value represents the value I have to use.

[Matt]

Water level = altitude.

Altitude is rarely the same as Y.

If you read a Y coordinate in the 3D Preview, then use that value as the Y coordinate in your water. If you are matching an altitude constraint, then you need to use Water Level.

[shadowphile]

MATT: gradient limiting makes more sense, thanks!

And the further conversation about lake level vs Y position addresses my question in another thread, coincidently!

[fxsculpt]

Oshyan
Our current goal is to publish all the information we have so far written, and then allow the community to help us improve and maintain it. We realized this was necessary due to the ever-changing nature of the application, such that docs that were written a year or even 6 months ago, may not now be entirely accurate, or certainly cannot be comprehensive as new features are added.

acolyte
people buy Terragen to produce images or animations that are specific to nature. Pretty sure no one's going to be doing any character animation with it soon. Sure it's a nice idea to keep things in general terms so that people reading the docs aren't locked into only creating one type of mountain, but come on. I would gladly trade a solidly worded tutorial (with pictures) that walked me step by step on how to create a specific scene for any of the incomplete and vague documentation floating around any day of the week. ....

A step towards resolution for this can be found in the NWDA packs which are available (at additional cost); however, if Planetside is going to ask someone to pay more than a couple of hundred dollars for a piece of software that is supposed to be specialized for generating realistic nature scenes, then if they're not going to have presets, then the very least they can do is get proper documentation out to door. And this documentation needs to be what the community wants and is looking for and not what Planetside thinks is best.

Not to beat a dead horse, I know the devs have already responded here, but users who buy a piece of software should not be expected to play this kind of guessing game when it comes to using the basic functionality of the software. If I choose, I should be able to never engage in the forums and still have the opportunity to know as much as I want about how the program I bought works to produce what it promised to produce. I deserve at least that much as someone who actually paid for the software and didn't pirate it.

shadowphile
My other huge and blinding headache has to do with lack of information about node connections.  I'm not a pre-rolled solution kind of guy: I think of what I want to do and how it is built up and how I can use the nodes to build that up.   A frustrating session the other night reminded me of why I can't stay focused for very long with TG: nothing is intuitive.

And BTW, I'm not one of those for whom trying things out is part of the fun.  That's an experiment, or me playing detective.  I bought TG to build terrains/skies as an artist or designer.  If it was more intuitive or faster (the 3D preview isn't much different than the main render, speed-wise) then I might enjoy exploring more.  Bad settings -> bad (longish) renders -> lose interest.

I agree strongly with what was said here.

Terragen produces some of the best CG images I have ever seen hands down. This makes it so attractive for artists like myself to use. That said I have also found myself needing to drop the product on my productions simply because I cant figure out how some of these great artist on the forums get the results they do. We the users need much better docs and a page of video tutorials ( see what 3dCoat has done with a very small team for their video docs ).

After creating CGI for 12 years (on large productions also) I have not been able to get an image out of terragen2 that matches my specific design intent(Cliff walls, overhangs, Cloud patters, Sunsets, Vegetation layouts etc... ). I have seen a select few on this forum seem to have absolute master control of this tool. So I truly believe it CAN do it but without docs I need a few more years or months of tweaking with the software to get what I need out of it.

PS I understand how hard it can be to get docs out. I started a company and developed a major modeling tool you all know and then sold it to a big monster company you all know. Docs were difficult but lucky one of my partners was a great writer. Its hard but there are examples of smaller teams than yours pulling this off and I know once you guys get some good docs and especially video tutorials of how to create these beautiful images the software can produce, your sales will greatly improve which you can then reinvest in building features faster.

Still your software outputs results that are really inspirational and that is difficult for a software to do. The tool is VERY stable in my months of hard testing also a credit to your teams skills. If there is anything I can do to help you guys let me know by PM. I hope I did not offend anyone here. I love the TG2 but need some docs & videos, with audio to get the specific results I know the tool is capable of.

[jritchie777]

I too feel a bit cheated without thorough documentation.  What are the limits on the input fields???

And yes I have made my way around and ask questions and experiment - BUT, I could be spending a lot more time experimenting and creating if I were not trying to figure the program out as well.  As a programmer for over 20 years I know it is hard to do docs - I did them for all the software I had to write and face it every other piece of software I have bought comes with documentation except for Terragen.

Don't get me wrong the forum is great and T2 is a wonderful program, but we could be spending more time trading creative ideas instead of trading instructions on how to do something...

JR

[Henry Blewer]

I'm going to make some people mad. I kind of enjoy the fact that there is such little documentation. The program has been so much more enjoyable experimenting with it. I have crashed it more than once trying some odd functions ( I do not understand many of them).

Blender also suffers from little official documentation. As Terragen 2's user base expands, I am sure someone will publish a book on the basics of T2 at the very least.

[latego]

Blender also suffers from little official documentation.

It more than compensate with a huge number of video tutorials. TG2 needs video tutorials, full stop. For an example, see what is available for Vue at http://www.geekatplay.com/tutorials.php.

Bye!!!

[jritchie777]

Let's not forget that Blender is open source - T2 and Terragen Classic were not, they had to be paid for...  I for one would like to crash T2 less by knowing what value ranges I can put into fields.

[dandelO]

What are the limits on the input fields???

JR

Well, there's the thing. There are no limits for most of the input fields. You have pretty much complete and unrestricted control of your creativity.

For me, it was more learning the terminologies used and labels inside each node that frustrated me when I started out with TG2. Like, what's a 'horizon shift' and, how does it relate to a default '0.5'? I also thought, for example, for a very long time, that 'Haze exp' height' meant expiration height, I've since learned that exp' stands for exponential.
This is a very complexed piece of software and it's sad to say that there are not many informative documents to accompany it but, as the staff have said, they cannot teach us all how to do maths.

Still, I'm with Njeneb on this one, really. I like that freedom of exploration and experimenting with ridiculous parameters and settings, you don't get that from reading a user guide explaining to the letter what each setting does, or can do. But I never read the instructions for things until I'm stumped.
Terragen was like those old games 'Myst' and 'Riven'. You were just given this absurd set of windows to a world, with next to no instructions whatsoever. That was fine for the free technology previews, for example.
I understand that people really need to know and understand what they're buying, though. Not everyone can trawl forums and expect to be satisfied with a rabbit-hole of posts on obscure and, sometimes, apparently random settings.

All that said, a nice, fully documented manual would be fantastic.