My heart goes out to all the TG2 users who feel like they are wandering around in the dark, because they are. Now I understand why so many of you hang out here in the forums because you are in great need of documentation that describes how the software works. I have decades of experience writing technical documentation and I know it takes a temendous amount of work but someone has to do it. In my opinion, if good documentation existed for this product, there would be a lot more people using and buying it. In my experience, artists are not very good in general at describing things. I just went to a local 3D users group meeting in the Houston area and I wanted to pull my hair out listening to this guy trying to describe how software works and he is talking like someone describing the bouquet of wine. I am not asking anyone to walk me through what I want to do. I just want good documentation describing how TG2 works so that I can figure out how to put the pieces together to build something that will generate the images I want. Let me just give a very small example of what needs to be in the documenation. Below is an image of the default planet node in the node view:
[attachimg=#]
It consists of a rectangle with two triangles on top facing down and one triangle on bottom facing down. I have figured out without any documentation that the two triangles on top are inputs to the Planet Node and the one on bottom is an output from the Planet Node. All the documentation says is to connect the nodes together without much explanation of what is happening and why.
In the default scene, if I take the Base Colours Shader output (which is connected to the top triangle on the left) and the Atmosphere 01 shader's output (which is connected to the top triangle on the right) and swap them, the rendered image looks different. Why? There is nothing in the Node Reference that even mentions these two inputs in the Node View and why the left and right one are different. And why is the bottom output triangle of the default planet node not connected to anything? But we still get an image. Why? It would seem that the planet node has to be connected to the input of the render camera but it isn't. Looks like intuition doesn't gain us very much in understanding here. So we must have documentation.
Some information comes in the form of the way nodes are connected in the default scene. And what are these lines between nodes communicating? Should we think of them as scalar elements where the node network is like a collection of expressions that are computed once for each pixel element in the final scene? What should we think of them in terms of their data types with respect to the kind of information they are communicating? Are they different for different node types? Some of their titles imply this but not much more than that is said. And where are all the inputs and outputs of other nodes that are not part of the default render documented as "Left input does this", "middle input does that" etc. The Node Reference really contains little more than a screen shot and a few sentences about what the node is in general. That's it! Anyone will need a lot more than that before they can expect to understand and make use of a software package as powerful as TG2. I, for one, belong to many forums and I am not enough people to just hang out in all of them all the time. We need better and more complete documentation.
I would agree with you there Pablo. Having said that everyone else seems to have worked things out on their own. I'm only using a small laptop so any experimentation takes ages to render and so I'm learning at a very slow pace. Not ideal.
It appears Planetside are working on it though I would have thought there is a market out there for someone to write a book.
First of all I really agree with you about the whole thing on documentation. There's some, but way from complete and/or not detailed enough. If I remember correctly Oshyan recently told you that an overhaul of the documentation is in the making.
You have probably been told by others to just get started, read and walk through the available tutorials, surf the file-sharing sections etc. I guess you've done pretty much of that already, but believe me. They're right.
However, I have been following your posts here from the beginning and one thing I noticed, and I don't want to sound like a dick, is that a lot of questions are things someone would wonder about when they are advanced with the software or either are things which you shouldn't think about too much. Your example of that connecting the atmo-node to the terrain input of the planet gives a different result from the way you're supposed to connect them is to me common sense. When it says "surface shader" it means you should not connect the atmosphere to it.
And yes, you're absolutely right: what kind of information is passed through the nodes? I really can imagine you want to know, I'd too, but I don't mind it too much, because I can often get the result I'd like to achieve.
The reason for that is in alinea 2.
Asking questions is absolutely good and no problem, but with lacking documentation and tons of unsorted info here the one and only best way of learning quickly is getting started and post images ;)
So I'd say get started with your scene, or if you already did then finish it, post it at the image sharing and ask critiques/advice.
Knowing the ins and outs of any piece of software will not guarantee satisfactory/expected results.
Looking forward to see your first work!
Cheers,
Martin
I have just started off using Terragen, so it is very easy for me to agree on that the documentation is sparse. I have learned a lot the last few weeks on how the software works through following tutorials and examining clip files. There are many advantages to this kind of hands on approach and it works quite well with an outstanding user forum such as the Planetside Forums to draw knowledge from.
I do however feel that the lack of documentation slows down the learning process. One 'simple' suggestion would be to make a better description of each node; what does it do, what can be connected to it, and what is it's output in terms of data types. For example: you cannot connect whichever node you please to another, there are restrictions to this probably due to data type definitions in the software. Such fundamental definitions need to be available to the user in order to develop skills more effectively.
Thanks, you guys. Don't get me wrong. This forum is the best bunch of guys I've ever hung out with, really (I brought a six-pack. Where's the 'frig?). Oshyan and cyphyr and everyone else have been so nice and helpful. I wouldn't dare want to mess with a good thing. Oshyan explained that they want to stay away from writing documentation that tell you specifically how to do this or that. As I understand it, Planetside wants documentation to give us an understanding of how the sofware works so we can be more independent in figuring out how to get things done on our own. But it looks like the way everyone is learning how to use the software is to go thru tutorials showing us specifically how to do this or that which seems to me to be the direction Planetside wants to get away from (at least for advanced users). So this brings us back to learning by "specifically how to do this or that". I am getting de-ja-vu all over again. I guess it boils down to the principle that quality (like wine) just takes time. (I want patience and I want it NOW!)
"how to do this or that" is probably a too open-ended path for the planetside documentation. However, as you rightfully say, everyone seems to want to learn that way. Which is why there are so many tutorials around. This is also why Planetside has created the user wiki, where everyone can contribute. Sadly though, not a great many people are growing the wiki. Still it is growing, and will be growing, and is a quite good resource already on "how to do this and that". http://www.planetside.co.uk/wiki/index.php/Main_Page
I don't know if you are aware of the wiki, but there are a lot of nice gems in it, ranging from video tutorials for beginners to some advanced stuff.
Still there is potential (I think) in writing a book on TG2 like in the dummy series. Unfortunately someone would have to pop up that has the writing skill, the time, and the TG2 knowledge to make a good book - which hasn't happened, yet. But there's still hope :)
Frank
I think it is very hard writing a complete book on how things exactly work and what does what, as so many 'procedures' are still to be invented. Things can be accomplished in many ways, sometimes totally unexpected combinations do the trick. And I think that's the fun of TG2. I wouldn't want to know it all from a book (and miss the exchange of ideas, and help in this community). But that's me. I guess a lot of people would want a quick 'how-to' and produce an image. It would benefit the sales of TG2, that's probably right.
---Dune
I did "discover" that the input and output triangles are labelled, for if you hover the cursor over one of them, a little popup identifies it. I think most of this sort of "documentation" has to be discovered by working with the software. The "Your First Scene" document avoids talking about nodes so that it doesn't scare off new users.
As I said in the other thread on doc issues, this is a problem we're painfully aware of and are working to address it. It's a slow process, as anyone who has ever written documentation for a complex piece of software will know. Anyone who has not attempted to document an open-ended node-based application will not quite have an understanding of the full difficulty, even if they've done other complex documentation. This approach presents its own unique, additional challenges.
In any case, some of what you point out *is* already partially or fully documented, e.g. in the in-forum ("archive") docs section. For example the node network connections are covered in the incomplete node ref section of the User Guide:
http://forums.planetside.co.uk/index.php?topic=20
I realize that pointing this out doesn't speak particularly well for the state of the docs, but that's already well understood. I should also acknowledge a difficulty there in that the forum docs may now be mostly overlooked because users are advised to reference the Help page on our main website, where only the 1st part of the User Guide can be found. This is the result of an incomplete move to a new way of providing the docs (as printable PDFs), and I have to take responsibility for not having finished this before. All I can say is it's something I'm actively working on.
The node reference is also incomplete, and actually the version that is available right now is much more incomplete than internal versions have been for some time due to a rather serious oversight. Again I have to apologize for this. The state of things with the docs is something I'm very unhappy about, and would like to resolve immediately. Unfortunately everything takes time, and there are many other things going on at the same time which make progress even slower.
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.
For the time being I hope you'll be able to find the information you need and we will do our best to answer your questions. When the docs are transferred to the wiki, I hope you'll consider contributing some of what you've learned.
I suggest starting a new thread for any remaining application questions you have, not related to the state of the docs.
- Oshyan
I agree with Oshyan. I've been having an awful time writing a tutorial for the canyons tgd files I posted. My gibberish makes sense to me, but my knowledge of the program is largely intuition. Explaining why and how something works is a real chore.
I would surely buy books with a title like that:
"Terragen 2: Basic to Advanced technics" or
"TG 2: Tame the Functions and Make Them do What You Want"!!!!!! ;D
Or whatever Luc would put in a book about TG 2!!!!!
Ghehe, that would be a one-page book then ;D lol
A couple of guys here, me also, have once been approached by a publisher about writing a TG2 book.
We never heard of him anymore actually.
He probably became aware that it is not as easy and straight-forward to write a good book for TG2.
Probably for reasons Oshyan already mentioned here.
I certainly would like to help with documentation, but I'm not sure if I have the writing skills (english is ok, but not that good) or that much understanding of the software to be sure about everything I will write down is really correct.
Martin, you're usually very concise in your descriptions and demonstrations, I think you're exactly the type of user that would greatly benefit the documentation sections of TG.
And there are a few native English speakers here whom I feel sure would be happy to correct any perceived infelicities of expression ;)
I am so ready for complete documentation. It sucks that this has been an afterthought. And I don't see why getting result-specific in the documentation can ever be perceived as a bad thing. 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.
That said, there are a few really good tutorials on Terragen made by the advanced users which really help. It seems to me that the user-based community has spoken, and that in lieu of having fully completed documentation by the devs, they're willing to take up the reigns and provide tutorials on the web.
Terragen is such a massively complex piece of software, that I don't see how it would be possible to write a book on all of the nodes and how they function. Given that those nodes change function from month to month and that each node can produce completely different results based on their implementation into an overall node network, it seems like even if we had documentation differentiating what all the different nodes do, it would still be incomplete without a vast array of user generated tutorials describing what's going on under the hood.
How many people have bought this software with the hopes of just being able to generate a snowy mountain, an early morning fog over a lake, or a desert canyon? There are plenty of standardized looks that need to be achieved as starting points for experimentation which have to be recreated each time someone delves into the software. 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.
Sorry if this comes off as harsh, I don't mean it to be rude, but this is ridiculous. Planetside, either hire more staff to help with what is a seemingly overwhelming task, or prioritize what needs to be done better. We're probably going to be waiting a while for the next big thing to be released again anyways right? Documentation for what is already here should be priority.
You do know that this is a very small comapany right..?
Perhaps too small? Considering the number of users/customers and considering the importance of this program in the terrain rendering field, perhaps it might be an idea to get more people involved in developing it. It's such a good program that there must be some willing investors out there.
Just a thought - not a criticism.
I've been tracking this company for a long time. I understand its small, but considering the user base it has and that its now been tracked being used on blockbusters such as Gi-Joe, it's not an unreasonable request to provide documentation, or even suggest they get on the ball and hire some more people. It's not our fault their small, and if they are maybe they shouldn't be.
It seems to me that since the resource allocation towards documentation on the part of PS is not likely to change dramatically, the Wiki approach lends itself best. Utilize the user base to expand and enhance the documentation, create examples and document findings. What I'd like to see is context-sensitive help pointing to specific Wiki webpages (so that you can click on a help link in a node for example). Basic node information could be followed by further-reaching help, more in depth discussion of available parameters, and there could even be links to specific threads on the PS forum. Of course, there are challenges to keep this collection of material up-to-date and somewhat organized, but you could again enlist the help of users - fulfilling sort of a moderator function common across discussion boards and the like.
While I find the forum indispensable, with its growth it is becoming harder to recall specific discussions and find the info you know has been posted at some point in time, despite all efforts to categorize and merge. This is only going to get worse I am afraid.
We have here a sort of catch-22 situation. PS knows that new-hires (even considering that money is not a problem) are going to have to get up to speed. This puts more strain on those who know how the software works. I, for one, would be delighted to write a book on TG. But I am a relative beginner so I need information from PS to bring me up to speed. I need documentation. See the dilemma? Knowledge necessarily has to trickle from the designers/implementors down to those who write documentation. And the best way to do that is for them to write documentation for internal use in combination with some sort of internal education program. This all takes time away from development. But when you are chasing a changling, it makes it all the much more difficult. Anyone care to elaborate on how much TG2 has diverged from original TGC? This might give us a guide on how much TG is changing thru time.
Quote from: PabloMack on April 21, 2010, 05:52:10 PM
We have here a sort of catch-22 situation. PS knows that new-hires (even considering that money is not a problem) are going to have to get up to speed. This puts more strain on those who know how the software works. I, for one, would be delighted to write a book on TG. But I am a relative beginner so I need information from PS to bring me up to speed. I need documentation. See the dilemma? Knowledge necessarily has to trickle from the designers/implementors down to those who write documentation. And the best way to do that is for them to write documentation for internal use in combination with some sort of internal education program. This all takes time away from development. But when you are chasing a changling, it makes it all the much more difficult. Anyone care to elaborate on how much TG2 has diverged from original TGC? This might give us a guide on how much TG is changing thru time.
This sounds a bit as circular reasoning to me.
Needing documentation to be able to write a book. You're absolutely right, but to a certain maximum extent I'd say.
If it would only be because of documentation then everyone could write a book about anything, without needing any experience with the subject.
In 3D software packages like these a good book distinguishes itself from a regular book by mainly the experience of the author with the software-package and how well he's able to transfer his knowledge to the reader. The latter is dependant on the author's writing skills.
As said before the documentation is being worked on and all the information available can be found here in these forums.
So far I find the majority of your questions very advanced and way beyond the scope of a "relative beginner" as you describe yourself.
I'd say start at the beginning.
I tried to motivate you before a couple of days earlier that the best way to learn TG2 is to spend time here reading the tutorials, going through file sharing and for example reading NWDA contest entries, since these contain a lot of tips about anything.
In the meantime you could actually start using TG2, render images, post these here, explain what you tried to make and what you still want to achieve.
Ask for help and lots of people will try to, including me.
This is the best advice I can give you.
This may sound harsh, but isn't meant to.
It's best to skinny-dip first into TG2 :)
Cheers,
Martin
The problem of documentation has been going on for so long now that most people seem to have accepted that discovering how the system works is part of the fun of owning the software. This and the 12 month wait for the final(ish) version to be released the other year, have been part of the Terragen experience for me. As I have said before, anyone who bought Terragen should have factored in the delays and the lack of documentation to their purchase decision. I don't get angry because I enjoy what I can do and learn from the people who know what they're doing and are happy to pass it on in this forum.
However, you can't get away from the fact that documentation was promised as part of the package and it has not been delivered. This is frustrating even for me but it must be so much worse for people trying to earn a living.
Whilst the loyalty and knowledge of the user base is impressive it should not be used by the company as a free source of the documentation that should be part of the package.
Quote from: Tangled-Universe on April 21, 2010, 06:54:38 PM
This may sound harsh, but isn't meant to.
It's best to skinny-dip first into TG2 :)
Cheers, Martin
It doesn't sound harsh at all. Thank you for being so kind. Right now my TG2 machine is tied up doing a LW render for a paid project. I estimate that it will take about 9 days total and I have about 5 days of progress. Besides that, I have two TG2 renders going on (same machine) put on low priority. One is an HD high quality still and the other is a low-res low-quality animation to see what TG2 can produce. It will probably be a week before all programs have finished. But then I have to start the next LW paid project. So in the meanwhile, I am trying to study TG2 without using the software. I can't afford to crash either program so I am reading what I can with docs that are available. I am looking forward to doing some of these tutorials you talked about.
A lot of what the program does is described in the release notes for each version, posted here in the forum.
guys, I think the point is well taken. I believe this particular thread has already had its impact in bringing documentation a little bit further up the priority list. Everyone agrees, including PS, that the situation around documentation must improve soon, and not next year. But still give it some time to progress, it's nothing one can complete over night.
As some of you have already considered in their posts, besides the 2 programmers, there is only Oshyan for support, documentation, PR, forum management and whatnot. I guess what I'm saying is that personally I am positive that it will come, and has to progress soon, but some patience is still needed.
In the meantime, it's not that there are *no* learning resources, in fact there are quite a lot out there. Just scattered, but not unfindable (is that even a word? ;) )
Cheers,
Frank
We're a small company by choice. We've made the conscious decision not to become answerable to investors who - in general - only have a profit motive. That has limited our ability to grow of course, but it's a worthwhile trade-off for us. We are growing organically (1 new employee every 3 years on average so far, I think ;D), and plan to continue doing so. We also charge a lot less for our product than many other companies would, and we offer a free version. These kinds of policies probably wouldn't be very popular with stockholders.
I certainly regret the lack of documentation, but it definitely wasn't an "afterthought". In fact I spent quite a lot of time prior to the release on creating what we have so far and simply haven't had much time to do any more since. I should note here that what is currently publicly available is actually not totally current due to some recently discovered oversights. In any case I have started to invest more time recently in docs and I think the move to a wiki and my increased focus should yield much improved results soon. Until then we can only ask you to be patient.
Live links to documentation are planned, once we have sensibly named online documentation links (e.g. node-name derived, rather than "page1.html").
It's not as if we plan to "use" the community as a sweat shop to write documentation for us. We're aiming for collaboration, which is a great part of our existing community and the helpful spirit that the forums here present. We'll do what we do best, describe the way the program works. Users will do what they do best, describe how they did a particular thing, or add information about what a specific range of settings might do, etc, etc. It's win-win. And anyone who doesn't want to contribute doesn't have to. If nobody wants to contribute, we'll put all the information we can in there and that will be that. Better a "living" documentation than a static, printed book if you ask me.
Anyway, I think the subject is well talked out. We're workin' on it! ;D
- Oshyan
There are generally enough changes between versions, so that detailed docs would require a large effort to re-write the docs. Maybe a bit more detail on the new and changed features would be better.
Oshyan, I want to thank you for, as always, being forthright and up front with everybody here. You rock! That said, I fully acknowledge PS's right to stay small and avoid the corporate swamp out there, but if a new staffing member is being brought on every 3 years, then may I suggest thinking about hiring some of the Terragen vets around here to come in for a few weeks to a month and knock some of this stuff out? A hodgepodge of questions and answers on the forums is only going to make things more spread out in terms of finding "documentation". If you guys at PS need help writing docs because your small, then please consider hiring on seasonal workers at a lower cost and getting this rolling. Not to mention, if it worked well, maybe you could do this once a year, pick something really dev-worthy to go after and knock a new feature out with a small group of coders over the period of a month or two instead of years at a time.
Hiring people short-term would work well for documentation (if they were already very familiar with TG2 of course), and perhaps a few *very* isolated features, but generally speaking just getting into a new app's code base (or the changes year-to-year if you only work a couple months a year) would take enough time that it's pretty impractical to try to do a "seasonal work" type of thing for coding. But again for docs it's not a bad approach. It's something we've considered in the past and will continue to keep in mind.
For now we have a plan for taking the next step and we'll see where that leads. If progress is not rapid enough, we may indeed have to hire someone on contract to help out.
- Oshyan
Its a fantastic program and I must say, In these times especially, the perfect example of how a company should be run.
Althogh the lack of documentation is well documented shall we get on and produce some images. I struggle with some elements of TG2 but in a years time I feel sure I won't.
Quote from: Oshyan on April 22, 2010, 03:14:06 AM
We're a small company by choice. We've made the conscious decision not to become answerable to investors who - in general - only have a profit motive. That has limited our ability to grow of course, but it's a worthwhile trade-off for us. We are growing organically (1 new employee every 3 years on average so far, I think ;D), and plan to continue doing so. We also charge a lot less for our product than many other companies would, and we offer a free version. These kinds of policies probably wouldn't be very popular with stockholders.
-snipped
- Oshyan
That's fair enough Oshyan. However, that decision also means that development on Terragen is glacially slow. I bought TG2 Deep Animation approx 2 yrs ago because I was led to believe (from text on the website) that there was an SDK in the offing. After all this time there is still no SDK available.
I'd rather see more effort going into speeding up development than into documentation.
- Tim
Frankly I'm surprised a software company can survive with such glacial progress. One employee every three years? The landscape (no pun intended :) is always moving in the high-tech world with 3 and 6 month release cycles.
If I were Planetside, I might be worried that at some point competition will arise. With CGI become more sophisticated and prevalent ever day, it's only a matter of time before the lack of an easy/professional/documented landscape development package creates a demand, then some entity like Blender will decide to tackle special landscape-generation tools. They will accomplish it in months, probably with just one programmer doing the core routines because the entire user interface API is done and works spiffy.
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. Even with a bunch of tedious re-renders after every (unintuitive) tweak, I find it appalling that I still can't identify what is in a line between nodes! The content seems to be a willy-nilly glob that the following input gets what it expects, or converts something else if not. Standard data typing and identification should be MANDATORY for the inputs and outputs of the nodes, or it's just an organic collection of various functions that happen to make interesting pictures when combined in patterns that others tell us will work. Tool-tips would be great place to insert this info, so that those who don't like manuals can still learn on the fly. In fact, that would be necessary, since the contents of the output can change depending on the input and the input will interpret the input-data differently depending on what is available, gasp!
I think part of the issue is that the program is based on a shader language, a specialized construction approach that seems to build in layers, which makes sense at first, but not for general purpose design of landscapes, especially when doing extreme displacements. I am constantly trying to un-learn my programming and design experience to get out of my box.
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.
The only reason I keep struggling with the program is the core routines are awesome! (and I made an investment :)
Planetside concentrates on providing a very stable program. It's one of the strong features of the program. It's possible to crash it, but overall it handles practically any combination of shaders and functions. Very few other programs can claim this.
Terragen 2 is powerful enough to compete with all the other programs of its type. The learning curve is steep; things do make sense in a short time. After a month of use, most can grasp how to expand on the simpler methods of landscape creation.
Quote from: shadowphile on April 22, 2010, 05:21:01 PM
I think part of the issue is that the program is based on a shader language, a specialized construction approach that seems to build in layers, which makes sense at first, but not for general purpose design of landscapes, especially when doing extreme displacements. I am constantly trying to un-learn my programming and design experience to get out of my box.
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.
The only reason I keep struggling with the program is the core routines are awesome! (and I made an investment :)
Hi Shadowpile,
sorry to read you are having so many troubles with TG2, both with understanding how it works and render (speed) satisfaction. From your previous posts in other threads I would reckon you do understand it quite well by now, though. Still you're struggling, as you say, but I think you're just impatient with yourself. Terragen 2 wouldn't be what it is today, with all its capabilities and flexibility, if it were trying to make things simple on the expense of this flexibility. With that flexibility comes complexity, it's inevitable. And for getting that complexity under control, you need to have some patience. Combined with taking the freedom to come and ask questions, instead of piling up frustration, will make that path easier and more enjoyable.
What could help you understand it a little better is to think of the network of a stack, that begins at the top and goes downward into the planet node eventually. Every node on the way done adds something to what you have started with. Just get these things in order and you will not loose control over your network. If you look at it this way, you don't have to worry much about type casting. Inputs will pass on everything from above. If a node has additional inputs, you just have to know what this input expects: color or displacement, or a number. In most cases.
As for render time, here's another brutal truth: you have to have at least a quad core intel, but really better an i7, to not let TG2 slow down your creativity. 1.5 years ago I purchased one of the first i7 systems. BEFORE that time, I loved TG2, but frankly I was doing less and less with it, with my AMD X2. Render times were so unacceptable for a creative mind, that there was a lot of frustration coming up on my part. A new, fast render system changes that situation dramatically and I found myself shelling out new and more complex renders every other day. The truth is you can't have long term fun without fast hardware. Except maybe Njeneb with his otherworldly patience and single core P4, but there are exceptions for everything, aren't there? ;)
Cheers,
Frank
Quote from: FrankB on April 22, 2010, 06:10:48 PM
As for render time, here's another brutal truth: you have to have at least a quad core intel, but really better an i7, to not let TG2 slow down your creativity. 1.5 years ago I purchased one of the first i7 systems. BEFORE that time, I loved TG2, but frankly I was doing less and less with it, with my AMD X2. Render times were so unacceptable for a creative mind, that there was a lot of frustration coming up on my part. A new, fast render system changes that situation dramatically and I found myself shelling out new and more complex renders every other day. The truth is you can't have long term fun without fast hardware. Except maybe Njeneb with his otherworldly patience and single core P4, but there are exceptions for everything, aren't there? ;)
Cheers,
Frank
I can speak for the render time frustration. I have an old system, a Pentium 4 HT. It still handles many things well, but it takes a couple of days, or more to do a large render. Because of how more complex node set ups take more calculations, I tend to keep things simple. It is not helping me learn more, but I can do some very nice pictures IMHO.
Also, not every tgd file works out. I have many that I have abandoned in favor of a fresh start. With every set up, I try to improve or use something new. Hence the abandoned setups.
Shadowfile makes some very good points.
QuoteFrankly I'm surprised a software company can survive with such glacial progress. One employee every three years? The landscape (no pun intended is always moving in the high-tech world with 3 and 6 month release cycles.
If I were Planetside, I might be worried that at some point competition will arise. With CGI become more sophisticated and prevalent ever day, it's only a matter of time before the lack of an easy/professional/documented landscape development package creates a demand, then some entity like Blender will decide to tackle special landscape-generation tools. They will accomplish it in months, probably with just one programmer doing the core routines because the entire user interface API is done and works spiffy.
As much as I love Blender (and I LOVE it), I would hate to think that a program of this magnitude could be in any way shape or form matched for terrain generation capabilities or procedural rendering capabilities; however, Planetside, you need to realize that this could happen. If an open source community gets driven to expand specifically in this way, you might have some new competition on the block that can boast that its not only good, but free.
QuoteAnd 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.
This has been my entire point all along. Documentation is not something that can be thrown around willy nilly. If you have a user base as large as this one and they're expected to pay high dollar / euro / pound for said software, then I'm not saying it has to be easy, but it better be documented well or you will quickly lose trust and faith from your users. Its like buying an expensive camera and upon opening the box finding a quickly scrambled note explaining that better manuals are on the way, but that the following bullet pointed list will have to do for now. Upon unpacking the rest of the box you are left with a complex camera with multiple parts and no way to know how to use this incredible piece of equipment you just invested so much money in.
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.
All that said, I know this changes nothing right now, and promises have been made to get working on the docs and get the ball rolling, but we've heard that before and not just about the docs. We've heard the same thing about timely release dates for software updates and new releases. I hope this can be a wake up call to PS to begin to rethink their seemingly firm policy on a select few employees and to start investing some more of our dollars not only in going to bigger and better places with the software, but improving what's already there and at least getting us up to speed to where we should be before we start thinking about trying to compete with other pieces of software in terms of features.
I guess my concern would be "will the documentation ever catch up to the software?"
I may be the only user here who is on a dial-up Internet connection, so my struggles with online documentation and searching the forums for answers probably don't mean much to anyone here, but that's my problem. However, I also use Lightwave a lot, and they provide nice documentation in pdf format that is (as far as I can tell) up-to-date with the current software release. And Lightwave is a fairly large package and has a very active forum.
Yes, Newtek is a bigger company than PS, but still it's relatively small in the 3D modeling world. Probably Silo is a better compare with TG, since they are small and have a very slow release record (not sure about the documentation since I haven't kept up with that software.)
I'm not looking for a "how to do something in TG", but how each function works and the "whys and wheres" of the connections. For example, I start with the TG2 default scene and look at the nodes. I add a lake and I see "Lake 01" pop up in the Water node. Fine, but I also see a little output triangle which intuition says "I've got to connect that to something or it won't work."
On the other hand, I see Terrain and Atmosphere blocks feeding "Planet 01", which makes sense. But Water and Lighting blocks seem "self-contained". I know they effect the planet, so why isn't there a physical connection?
I think the biggest frustration is that the developers know all these answers, but don't have time to document them. But they also have to deal with "how things work" as they develop. Knowing the answers are "there" is probably what causes the frustrations seen in this thread. But TG2 is still my favorite software, so they are definitely doing a lot of things right, in my opinion. :)
Quote from: FrankB on April 22, 2010, 06:10:48 PM
As for render time, here's another brutal truth: you have to have at least a quad core intel, but really better an i7, to not let TG2 slow down your creativity. 1.5 years ago I purchased one of the first i7 systems. BEFORE that time, I loved TG2, but frankly I was doing less and less with it, with my AMD X2. Render times were so unacceptable for a creative mind, that there was a lot of frustration coming up on my part. A new, fast render system changes that situation dramatically and I found myself shelling out new and more complex renders every other day. The truth is you can't have long term fun without fast hardware. Except maybe Njeneb with his otherworldly patience and single core P4, but there are exceptions for everything, aren't there? ;)
Which AMD X2 were you using? I have an AMD Turion X2 (1.79 GHz /w 1.87 GB RAM) in my current laptop (on which I am writing this text). Adobe After Effects is somewhat lethargic on this system but my new cruncher (Red Dragon) has an AMD Phenom II 955 (3.2 GHz /w 8GB RAM). My older workstation has a 2.4 GHz Intel P4 single core (maxed out at 2GB DDR1?) which the Red Dragon is replacing. I did my own video NLE render benchmark to compare speed between the two systems and the P4 reported that it was only 5% complete when the Red Dragon finished with the render. I didn't want to wait the estimated 2 hours for the P4 to complete its job so I hit cancel. Of course, video rendering is more I/O intensive than something like TG2 which is more compute intensive. I also did my own computation benchmark and each Phenom II core was only about 5% faster than the P4 (after adjusting for the difference in clock speeds). The lesson I learned was that AMD's hyper-transport really is dramatically faster than Intel's counter-part for I/O. This is in large part, due to the fact that the dedicated I/O channel Intel processors have to the graphics card (including the i7) leaves little bandwidth for other things. But I do a lot of video editing so this works for me. But I will have to consider the i7 if I decide to add render farm nodes some day.
actually, I don't exactly remember which AMD X2 it was, but it was one of the first that came out. So very, very old, and f**** slow. Well, back then it was cool, TG Classic was quick, but when I got my hands on TG2 alpha in (2005?) it was a nightmare. TG2 is an application for HW of the year 2009 and beyond. Like modern 3D games are made for today's computers, you have to have a new and powerful modern system for TG2. I mean, we all know it "runs" on older HW, but to stay with the anology: would you want to play a game with 5 fps? Probably not :)
As for what's the right choice of CPU for TG2, the benchmark site tells you everything in plain truth. An i7 is what you need.
Cheers,
Frank
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.
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.
Lots of people can tell me how to make something work, but I really need somebody who can tell me why something (that seems like it should) DOESN'T work.
(even in college I noticed a split amongst students: those who learned by copying and those who learned conceptually. I was often frustrated by TAs or profs that couldn't or wouldn't explain WHY MY THINKING WAS BAD. Without that, I'm just doomed to keep applying the same bad thought process unless I get lucky.)
Quote from: shadowphile on April 23, 2010, 08:06:26 PM
(even in college I noticed a split amongst students: those who learned by copying and those who learned conceptually.
Let me guess, the first group dropped out and became artists and the second group stayed in science or went into engineering. There are many people, even professors in technical fields, who don't understand what they are teaching. It is very frustrating to students who want to know how things work.
If you asked me, I would say that a colour input or output should be broken into its three or four channels (HSL , HSLA, RGB or RGBA). You must follow where those specific signals go before you can really understand what is happening. And then you need to know what the node's "black box" is doing with it. And it must also be understood what the active ranges are for all channels ($00 thru $FF vs. 0.0 thru 1.0 etc.). In a really flexible node system you could hook colour channel so and so to displacement channel thus and thus and it should work. And if you get strange behaviour, you should be able to trace the signals and do the calculations by hand to find out where you went wrong. Then you could insert a node that re-scales the signal to make it have the range you want if that is what it takes. As a programmer, I would probably prefer a node system that uses a list of assignment statements rather than a messy graphical node system as is standard practice. If you try to assign the same input with conflicting expressions, the software would check and flag the confilct as an error. This is how it should be. But if you hook a 3-channel output to a 1-channel input in a graphical node system, what it going on? Does the input just accept the luminance or what? And if it is not permitted, why does the node editor let me do it just to give me an undefined result? This is how it should not be. So ideally, colour inputs and outputs should have four channels, not one, and even a choice of RGBA vs. HSLA. You should be able to hook the Blue output to the Red input and get any effect you want if you are willing to live with the visual consequences. There would be more lines running every which way in a graphical node system, but at least you can see what you are doing. You could provide a bus output that will hook all four channels to the bus input of another node. But then you are still left with the question "How does the software handle mis-matched channels (or does it)?"
Quote from: shadowphile on April 23, 2010, 08:06:26 PM
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?
After thinking about it some more, I must rescind some of what I wrote two posts ago. I think that many of the lines connecting nodes represent light (correct me if I'm wrong) and some of the nodes represent objects acting on the light. In such case, there is no Alpha channel to light because Alpha is a property of an object (or part of the object's surface) that acts on the light. And for realism, you would only connect a Blue light output into a Blue light input because light doesn't suddenly become another color unless it interacts with something that makes it change (i.e. an object/node). So I now think that node interconnects may never need to be broken up into channels. After all, we all want realism in our renders, correct? If someone really wanted to alter a light channel, he/she should have some sort of math node to pass the signal thru and do the adjustment inside the node. So if someones connects a light output to an inappropriate input on another node, the software should probably report an error and disallow the attempted change to the node network.
Quote from: PabloMack on April 24, 2010, 08:45:18 AM
After thinking about it some more, I must rescind some of what I wrote two posts ago. I think that many of the lines connecting nodes represent light (correct me if I'm wrong) and some of the nodes represent objects acting on the light. In such case, there is no Alpha channel to light because Alpha is a property of an object (or part of the object's surface) that acts on the light. And for realism, you would only connect a Blue light output into a Blue light input because light doesn't suddenly become another color unless it interacts with something that makes it change (i.e. an object/node). So I now think that node interconnects may never need to be broken up into channels. After all, we all want realism in our renders, correct? If someone really wanted to alter a light channel, he/she should have some sort of math node to pass the signal thru and do the adjustment inside the node. So if someones connects a light output to an inappropriate input on another node, the software should probably report an error an disallow the attempted change to the node network.
Well, actually your previous thoughts were close to how it works I think.
The reason I think not light is represented is because the light has no output to connect to the input of a surfacelayer/powerfractal/whatever
I'll basically try to tell my understanding how TG2 works, hold your breath ;) :
Terrain -> Shaders -> Planet
+
Atmosphere -> Clouds -> Planet
= Planet + (water +) Lighting
(water is an "object" and not a shader, that's why it isn't connect to the planet)
So:
In the terrain tab you set up the fractal flavours with which you want to create your landscape.
The fractal is generated inside the node and can either generate displacement(scalars) or colours. Depending on how you configure it. Here's roughly how:
Displacement: if you leave colours unchecked the internal fractal will not create colour, which you for example could use for texturing (in the shader tab).
the fractal is generated using the scale-definitions and the displacement parameters in the displacement tab. The colour settings in the colour tab do not affect the profile of the fractal. Only the scales and displacement settings do. Just try for yourself: start new file, and add a powefractal terrain. Go to the terrain fractal and adjust any of the colour-parameters. No effect.
If you want to have the colour-settings affect the displacements, then feed the powerfractal-output to the shader-input of a displacement shader. This shader allows for colour-based adjustments inside the powerfractal. You can control the displacement with the displacement shader.
The powerfractal probably generates scalars to build up the fractal's displacement and the displacement-shader converts the scalars to colours and that's why you can do colour-based adjustments of the powerfractal.
So basically the node which is being fed determines what happens with the data.
Therefore the breakup-shader, blendshader and colour-input of a surface-layer are programmed to use colour-data.
The displacement-input of a surface layer works similar to a displacement-shader.
The layer-child accepts both data-inputs, since you wouldn't want to discriminate between those two for the logica reason that you can do that with the shader you choose to use as a child.
When I use these principles it is also fairly easy to understand how you can use powerfractals for colour.
To go a bit further:
When you have generated the displacements in the terrain tab the you compute terrain. Why?
- Compute terrain computes the normals and texture coordinates of the geometry generated by the shaders above it.
The resolution of the computation is determined by the patch size.
Compute terrain allows for restriction to slopes (needs computed normals to determine vectors) and height (texture coordinates).
- Compute normal computes the normals of the displacements, so as mentioned this only allows for slope-restriction.
This can be useful if you want to do vertical/lateral displacements, since displacing in these directions demand a "known" normal to function correctly.
- Tex coords from XYZ computes the texture coordoinates/height-information, so allows for height-restriction.
The terrain and shader groups are a guideline for building the scene, that's why you basically generate and compute terrain in the terrain tab and use the computed normals + texture coordinates to texture the terrain in the shaders tab.
Once the terrain and textures are produced it is being fed into the planet-shader.
The planet-shader also has an atmosphere shader for the atmosphere and clouds.
These two are combined with the lighting-settings and generate the final outcome of the scene.
Sorry for the bit messy "quick" (took me half an hour though lol) write-down of how I see TG2 works and so far it works fine and logical to me.
Hope some of this helps.
Cheers,
Martin
See , it is so easy !
Sorry Martin , couldn't resist ;D Thanks for the explanation .
Quote from: Tangled-Universe on April 24, 2010, 04:13:23 AM
Quote from: shadowphile on April 23, 2010, 08:06:26 PM
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.
Hi Shadowphile,
Quote from: shadowphile on April 23, 2010, 08:06:26 PM
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.
Quote
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
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!)
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
Quote from: shadowphile on April 25, 2010, 06:37:35 PM
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
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
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.
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.
MATT: gradient limiting makes more sense, thanks!
And the further conversation about lake level vs Y position addresses my question in another thread, coincidently!
QuoteOshyan
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.
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
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.
Quote from: njeneb on May 24, 2010, 08:25:05 AM
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 (http://www.geekatplay.com/tutorials.php).
Bye!!!
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.
Quote from: jritchie777 on May 24, 2010, 01:41:08 AM
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.
Quote from: dandelO on May 24, 2010, 07:04:10 PM
Quote from: jritchie777 on May 24, 2010, 01:41:08 AM
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.
Only problem when the program crashes due to not liking some of the values I've put in, then my creativity becomes a guessing game...
Quote from: jritchie777 on May 24, 2010, 07:46:09 PM
Quote from: dandelO on May 24, 2010, 07:04:10 PM
Quote from: jritchie777 on May 24, 2010, 01:41:08 AM
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.
Only problem when the program crashes due to not liking some of the values I've put in, then my creativity becomes a guessing game...
My general rule of thumb is if I don't know what it does, add/subtract the current value divided by 10. See how much it affects it, and then modify again depending on how much more i feel i need.
Example, the default value is 1000. So 1000/10 = 100. So I pick a value between 900-1100. Then change depending on that.
One exception is values between 0-1. These often in TG2 will represent a % value of 0-100% (with 1 being 100%). So if its a 0, a 1, or any decimal between I'll try out other decimal values or switching the 1 to a 0 or a 0 to a 1 first. Then depending on how that worked out move on to bigger values.
I am more of a hobbyist so it doesn't much matter for me.
But every time i see such topics i remember what my friend said years ago .
( I hope i didn't wrote this before :) )
I think this idiom is in many languages " By trial and error " !
My friend asked me something about a program. He had to meet a deadline for work .
I said " You can try ".
He said " I have time for trying , but not for error! .
Aye, I do see your point, Jritchie777, it isn't ideal at all.
I don't think I've ever crashed TG myself because of any extreme inputs, though. And I really do use some ridiculous settings sometimes. What parameters do you find these problems mostly occurring?
I could imagine some really extreme settings that might cause crashes, if you were to input, say, 1,000,000,000m as a displacement multiplier on a near-to-camera terrain then, yes, the renderer would most likely crash the program due to impossibility of rendering such extremes, if the 3D preview doesn't crash it beforehand, that is. I couldn't really see anyone using such extreme settings as this, though.
In another thread yesterday, as an example on extreme inputs, Seth wrote a post on using, I think it was a value of 10,000 for transparency, on a water shader applied to a sphere. The transparency slider's limits here are '1', this doesn't mean you can't input higher.
I've experimented on this myself since then, and it appears that if you raise transparency above '1'(the logical maximum) then, sure, it isn't physically correct but, Terragen will do as you tell it, most of the time. This results in a physically impossible calculation, of course, how can you possibly go beyond 100%('1') in the real world? But, TG doesn't really discriminate in this way, it'll take that value and do the mathematical sum of your inputs, in this case, some new way to create luminosity that will cast off from the given surface onto surrounding elements.
'10,000% Pffffft! No problem. What else have you got?' Says Terragen.
Neuspadrin has some good advice there, too. ^^
Increments of the value in a given field's defaults are the way I usually experiment. It's extremely difficult to see the difference between cloud internal scattering values of, say, '0.25' and '0.3'. Try changing things logically, maybe from 0.25 to 1. This will let you see better what this setting is actually doing.
I often use internal scattering of 5+, I've went even further, of course. I think my volumetric fire file in the sharing forum might use about '8' in this field, I'm not sure now.
Regardless of the exact number I used, a value of '5' here is 10 times that particular slider's limit...
A lot of applications will not let you increase such settings, embrace it! ;)
EDIT: In fact, the actual value used here is '10' so, it's 20 times the 'maximum'. http://forums.planetside.co.uk/index.php?topic=9039.0
I find that the area that gives me the most trouble for crashing is using negative values for manipulation of terrain. Either into the power fractal, or one of the other displacement shaders. I start getting interesting results until I touch one - then bam, T2 crash...
I can't help my obsession with negatively displaced terrain.
JR
I am going to have to try the negative displacement you mention. I am curious what is going on. It could be the negative displacement is forcing a division error of some kind (divide by zero?)
The b*tch with settings like "fake internal scattering" is that the outcome of the setting heavily depends on:
the lighting of your scene, sun's strength e.g.
chosen cloud color
chosen scatter color
chosen density
chosen edge sharpness to a lesser extent
chosen light propagation and propagation mix
and to even make it worse, also the fake ambient settings affect how changes to the fake internal scattering setting look...
All in all, with or without documentation, it is really a matter of experience on how to use them in your advantage.
Given that you might have all these settings well documented, you still need to find out yourself how the settings are balanced and how to balance them for every scene you're working on. These kinds of things can NOT be documented.
Martin
Not to argue a clear point, Martin, but you just did document this.
Someday, it would be great, if people like Martin and whoever <make a list here> could get together to write chapters on their various strengths to enhance the basics to the place of understanding you're talking about here.
Has anyone else found crashing on negative displacement? I've been getting memory errors causing crashes, but chalked it up to the large masks and populations I've been using. I do have some negative deisplacements on my terrain, but all less than 1 meter in depth.
It seems to work for me. Sorry...
I remember, in a certain couple of updates, that negative displacement in PF's was broken for a time. It worked, then didn't, now, it does again. Apparently, there shouldn't be any problem with negative displacement values in a fractal any more.
For now we have a plan for taking the next step and we'll see where that leads. If progress is not rapid enough, we may indeed have to hire someone on contract to help out.
- Oshyan
(April)
Sorry to nag but how's it coming?
It works fine now. The only problem I've had lately is out of memory errors due to my use of dozens of 8192x maps :) at the same time.
Quote from: dandelO on May 27, 2010, 10:13:23 AM
I remember, in a certain couple of updates, that negative displacement in PF's was broken for a time. It worked, then didn't, now, it does again. Apparently, there shouldn't be any problem with negative displacement values in a fractal any more.
Try using two color images. Power fractals can be merged in to provide variation to the coverage.
Quote from: njeneb on August 15, 2010, 07:47:55 PM
Try using two color images. Power fractals can be merged in to provide variation to the coverage.
I saved a lot of memory I think by combining some of them into RGB images, using one map for each channel then splitting them with color to scalar nodes. Works fine, though I haven't seriously tested it to see if it actually saves memory, or if the other changes I made are responsible for the improvements.
Terragen doesn't just need documentation, it needs video tutorials and recourses.
Who the hell reads huge pdf pages on how to create something, when a few simple youtube videos show it without confusion and wondering if you misinterpretated something.
That's what really bothers me about Terragen. It's one of the few 3D programs I've come across that doesn't have proper video tutorials. I learnt Zbrush and 3dsmax in only a few months, purely by video tuts and training dvd's. But learning Terragen is desperately combing google, this forum and hundreds of unclear documentation pages.
The only reason I chose Terragen over Vue was that I came across those basic tutorials, which got me started, but after that you're pretty much screwed :)
For zbrush or 3dsmax you can find video tutorials about every function on youtube, and limitless free recourses like base meshes etc. Try the same for Terragen...
Great program, but difficult to get started.
Quote from: uggi on August 20, 2010, 12:07:30 PM
Learning Terragen is desperately combing google, this forum and hundreds of unclear documentation pages.
The only reason I chose Terragen over Vue was that I came across those basic tutorials, which got me started, but after that you're pretty much screwed :)
For zbrush or 3dsmax you can find video tutorials about every function on youtube, and limitless free recourses like base meshes etc. Try the same for Terragen...
Great program, but difficult to get started.
You want video tuts, make them. I'm busy making terrain models. If you have a question or two about a practical problem in TG, I will (as well as the other users here) be happy to help. It took every one of us no little effort to learn how to work with TG, and we'll help. but generally if you demand spoonfeeding you'll go hungry.
Go to the files section of this forum and download a sample project and mess around with it, then try to customize it. When you break it, use the search function and figure out why, and then if you can't figure it out, post a question. In that order.
Many of the video tutorials for e.g. 3DS Max, Zbrush, etc. come from the community, which in the case of both those apps is much larger than TG's at present. We do have plans to make some video tutorials ourselves, but the most interesting, complex, and in-depth stuff usually comes from other users or vendors (e.g. GeekAtPlay, etc.). As TG and the community grows, the chances of more material like this being published increase. I think it's really just a matter of time and scale.
- Oshyan
In order to learn TG2, I'm experimenting with individual parts, one at a time, to see how everything works.
Since it is challenging to learn the program, I decided to write brief blog posts about my journey. Keep in mind, I'm a student not a master.
http://terragen2.wordpress.com/
The content of the blog will be guided by my own interests and projects. If anyone wants to contribute let me know.
Hope it helps someone.
Please will someone at Planetside give some idea when some basic documentation will be provided. The sort of thing I mean is a node reference that isn't just a set of pictures of all the node screens but also tells me what to put in each field. (Even better if it tells me what the effect of me altering the field will be but let's start small and work up.)
Reading this forum, as I have for years now, you see poster after poster asking simple questions which are generally answered for the first few times but eventually the good people of the forum get fed up of the same questions and say search the forum for yourself. I see people posting once or twice and then never appearing again. I can't believe that they all know all they need to know and I suspect that most of these are lost potential customers.
This current system is like an old fashioned adventure game where you pick up bits of advice and knowledge like lamps and pieces of gold to enable you to go on to the next level of ability.
My fear is that I may grow old or even die before I understand the system and that the people who have, through this forum, helped me so far might also get tired of the fact that not only have they paid for the application but are also operating as extremely cheap support staff for it.
From Planetside's point of view there are many examples of applications (and computers) that have been far better than the rest of the market but have failed because the developers were far to busy with the next technical developments to properly finish the original application. You must be losing customers through this problem.
Nobody is under any illusion about documentation being fun to do but it is as much a part of a good application as the exciting technical bits are. It is not an optional extra for a professional application which I am sure is what you consider Terragen to be.
There's so much possible, that it's hard to write a comprehensive tutorial. There will always be hidden ways to do something, and for me that's a lot of fun, and something to keep me sharp. You can't teach someone to paint a Rembrandt by writing a thorough tutorial, if that's a fair comparison. But I see your point about Planetside losing people who do not have the tenacity to dive into the matter. I also think the basic tutorials/documentation give a good starting point to get decent landscapes.
There should be one (or two) people who gather all that's available in the tutorials and forum(s) and combine it into the total 'bible of TG2', but that would take quite some effort (or payment). And still, not all effects to be had can be described precisely, as there are too many variables.
There will ALWAYS be better ways to use tools that are intended to support creative endeavorer.
If you take something as straightforward as C++, there are tons of books out there on the subject and yet blogs and forums thrive discussing things that go beyond the basics.
We are missing "the book" on TG2, but it will ever only cover the fundamentals of how the tool works and what can be done with it. There will always be discussion among experts and learners about new things that can be done or better ways to do things.
The best answer I can give you is that we'll have a much better node reference by the end of the year, if not sooner. It will be wiki-based, we will provide the major base for it, with significantly more detail than is currently available. Users will also be able to augment with additional info they discover, or techniques they use. Additional "how to" documentation will follow; we are thinking of a potentially equal split between written and video, though we will continue to focus on the basics, as trying to show techniques for creating every natural phenomenon under the sun is simply not practical.
- Oshyan