Idea: Terragen Visual Reference Sheets

[Dune]

He said he didn't have even the slightest clue how to use it, and uninstalled it.

If a new user reads just a little more and follows one or two tutorials or checks the wiki, even the very first beginner can make quite decent landscapes. But perhaps there should be a version of a basic landscape included with TG, with a string of notes included in the node area, so a beginner can understand what each node (series) does at first glance.

[Tangled-Universe]

Yep correct.
I think this has been discussed quite some time ago already in the testers-group.
Some alpha testers like me and Luc Bianco offered to donate complete scenes with documentation, but the offer remained unanswered by PS.

However, this is still something I'm willing to do, but for the best effect this needs to be supported and guided by PS and not by us.
It's best to  include these in the installer and in TG2 (for instance, click 'file' and then choose 'demo files/examples' upon the user can choose a scene and it will load without any problems).
If people still need to dig through these forums for the example files then you already miss a large amount of the target audience.

Anybody here using World Machine? I remember how happy I was when I found out it came with a dozen of example files and it really helped me.

Anyway, this is a bit deviating for the original discussion, but I still found it relevant to explain.

[Kadri]

I made a thread about this too i do not know how much years ago, Martin .
I simply can not understand why Planetside does not make this.
Documentation is hard, coding something new is hard , but using content that others are willing to give free?

This would maybe bring more new users to TG2 then a documentation about purple(!) nodes .

[PCook]

Very little of anything worth doing in life comes with no effort. My friend quit Terragen too soon, not because of lacking documentation, but because he was intimidated by an interface that simply sat there waiting for him to tweak dozens of settings he knew nothing about. PlanetSide dismisses this new-user-is-lost problem with Terragen-is-intended-for-the-VFX-market who are suppose to know this stuff, yet will gladely give anyone a free copy and even take a license fee.

But even if Terragen came packaged with tuts and examples and demos (an excellent start), Brave New Users are still faced with the challenge of breaking away from donated and canned projects to continue their own independant ventures in landscape visualization. For the ones who make it to that break-away point, they have not enough documentation to carry them. As such, learning Terragen becomes a badge of honor reserved for the courageous (or the employee of a VFX studio). So, to the several valid points that were made in the last three posts; this is NOT a PlanetSide problem because PlanetSide has decided that its target market is the VFX industry that presummably already has a grasp on 3D design fundamentals. In fact, this lack of documentation problem doesn't have an owner because everyone, including the community, has some reason why it's someone's else's responsibility. Even throughout this thread, people kept suggesting that I make a bunch of TRVS's to get it started, to *prove* the concept. But that's simply deferring the problem to me. This passing-the-buck may very well be the reason that most Terragen documentation discussions have failed. But in my opinion, TVRS's are a type of documentation that many can contribute to because they don't require in depth technical knowledge. TVRS may be the only thing that can be done where buck passing doesn't work.

My orginal thinking was the Terragen Visual Reference Sheets (TVRS's) were a way to provide simplified help without the over-the-head technical speak. Fast to look up. Easy to make. TRVS's are NOT the solution, just part of a solution. Would a TVRS library have saved my friend? I don't think so because he didn't have that drive to digitally create imaginary landscapes. But they sure would come in handy for all those Brave New Users who stick with it, only to encounter a new stopping point when they try to wean themselves off other people's donated projects. Point is, ANY documentation, however its defined or however it's constructed or whoever makes it will help save Brave New Users, who will then go on to help save other Brave New Users. Terragen needs lots and lots of people who can use it, not just who would like to use it, else it will remain largely undocumented.

-Pat

[Oshyan]

Sorry for not providing a Planetside response sooner everyone. I'm speaking essentially from my perspective here, so though I am a part of Planetside, this shouldn't be considered an "official response" or statement of policy. Hopefully that does not diminish its value.

Overall I think Pat's idea is a good one. In fact it has been suggested and even demonstrated before (as noted earlier in this thread). This sort of thing has always seemed like a potentially valuable part of the documentation to me, but it is quite laborious to create when doing it manually. Even using the built-in animation capability, which *does* make it easier, still misses parts of the problem because it does not note the settings used for a particular image, nor combine them all into a reference sheet, so while it saves some work, much still remains to create even a single "TVRS". Solving those problems makes the project much more feasible, and Neon's application goes a good ways toward doing that.

Terragen is a kind of language. Nodes are words and the network is the grammar. If you don't do things in the right order then it doesn't make much sense.
Your TVRS would be the spelling of those words, but wouldn't cover the whole story.
My suggestion wouldn't also, except for showing the complete spelled out words.
The language you will need to learn by practice and lurking these forums.

This is a very insightful way of looking at it Martin. But what I find interesting is I think this actually upholds the value of Pat's suggestion rather than undermining it. Just as in learning a new language, you must know the alphabet and pronunciation to learn to speak it! Knowing those things alone does not let you speak it, yet it is an integral part of the learning process. The "TVRS" idea is a potentially useful part of complete documentation.

So here's what I propose: there exists a program that can do this sort of thing fairly easily (Neon's app), and I have spare render time I can dedicate to it. I'm willing to spend a bit of time setting up parameter runs for this and output a bunch of tests and put them into the Planetside wiki. I think they would actually make most sense as either a part of the Node Reference, or linked directly from a given node reference entry. That way those who learn best from reading about a setting can do so, and those that learn best from viewing examples can also do so, and you don't need to go to 2 different places to find closely related content about the same settings. So that's where I'd put them.

I'm willing to do say 50-100 settings from 5-10 nodes. Once that was done, it would be critical to get feedback from the community. There are literally 1000s of parameters, so completing this job could be quite demanding and we want to be sure this is actually a useful thing to have and worth the time investment. Once we have a solid breadth of examples for key nodes, I think that will be easier to judge. We could start a poll thread on it, for example.

For now what I need from the community are suggestions on what nodes to do this with first. Like I said, I only want to do 5-10 nodes and 50-100 settings *total*. I would start a poll, but with 100+ nodes in TG, it's not possible to include them all for vote. But I will create a new topic so this one can remain for further discussion, and so it gets some attention as a newer thread. Just note your picks for TVRS, top 5 or 10 at most, in response to the thread here:

http://www.planetside.co.uk/forums/index.php?topic=15090

- Oshyan

[Tangled-Universe]

I see your point Oshyan.
The part you quoted from me is of course a simplification of what I think that is important to know and understand about TG2.
You can read more on that in your own TVR topic.

It's nice to see every set of parameters for every node being visualized, but it's as equally important, if not more, to know how to use it.
This is a bit like the chicken and the egg situation I realize.
If I would refer this to my "language example" then it would mean that you would know a lot of words because of the TVR's, but not knowing their meaning and where to put it in the network and what to expect.

Therefore in the other topic I briefly explained my vision on how to 'teach' or document the TG2 language and it's most important nodes.

Richard is right for instance in his remark that it's nice to know what the strata steepness setting does, but that the compute terrain node affects this as well.
It's essential to know the TG2 language to make the best use of TVR's.

[Oshyan]

Unfortunately your doc feedback would have been better here Martin. But no matter.

It still sounds like you are not arguing against "TVRS", but rather for more documentation in general, which has never been in question and frankly isn't really worth debating further in my view. The reason I am taking up the TVRS charge is because I find the work manageable. I have spare compute resources and can setup a series of renders for my system to do without me. The existence of an application that assembles the resulting images into usable "TVRS" format completes the package.

This means I can potentially make a reasonably positive impact in the documentation area with less time/effort than writing and explaining a bunch of stuff. It does *not* mean I don't think things should be explained, just that this is easier, faster, and more manageable than other approaches, in my view. This is part of why I want to test it, though. It may turn out to be just as laborious in the end, and then it really would come down to a matter of what it is better to put time into - visual reference, or textual explanation. Currently the priority is put on visual reference because of the potentially higher ratio of time input to benefit, and the results of this initial test will influence future work (Node Reference work is ongoing regardless).

Regarding the effect of Compute Terrain on Strata Steepness, there is absolutely no way to ever document all the potential effects of various nodes on others. Setting the bar for docs that high is, in my opinion, not very useful; it just makes the job more overwhelming and less appealing. It makes most sense to me to explain the effects that Compute Terrain *can* have in shaders down the line, and let that stand for all future work. It's a very important thing to keep in mind for all surface shaders, really.

- Oshyan

[Tangled-Universe]

Regarding the effect of Compute Terrain on Strata Steepness, there is absolutely no way to ever document all the potential effects of various nodes on others. Setting the bar for docs that high is, in my opinion, not very useful; it just makes the job more overwhelming and less appealing. It makes most sense to me to explain the effects that Compute Terrain *can* have in shaders down the line, and let that stand for all future work. It's a very important thing to keep in mind for all surface shaders, really.

- Oshyan

I think this is really exemplary of how you often misunderstand what I'm saying It must be the way I'm saying things I think?
I didn't mention, nor mean, to document how strata steepness can be affected by compute terrain settings. Did I?

It was an example to explain the necessity of understanding what changes to or a compute terrain in general can imply to following shaders downstream in the network.
That's the language part we're talking about here.
People need to know that. I can really predict/foresee this will give problems in general.
So yes, your seconds thoughts is the correct one.

Without proper context and framing the TVR's will be less valuable and so will be the reward for the huge amount of time you're planning to put into it.
It's only a concern or prediction I'm trying to share with you with my best intentions

And yes, you may consider this as deviating the discussion to general documentation and yes I do know why you want to avoid that, especially with me perhaps.
I just think you can't say A and C, without saying B.
You're going to make us a big cake and I'm only trying to suggest you to put some icing on it

[Oshyan]

My intention in doing this is to see exactly how much time it does take. I know how much time writing text documentation takes - a lot. My hope this project will give more "bang for the buck". We will see.

As to the cake, well, would you rather have the cake with no frosting, or no cake and no frosting? I say the cake can be frosted later. It's an iterative process is my point and I think it's simply defeatist and pessimistic to continually point out that doing one part of documentation does not solve the entire documentation issue. I think doing A and C without B is *fine*, provided you eventually get to B. A is valuable, C is valuable, on their own. B is also valuable on its own. Together they are more than the sum of their parts. But that doesn't diminish their independent value, nor the value of spending time on *any* of them.

I am simply trying to maximize the results of time input here, on the assumption that creating these visual references will be easier and faster than writing docs. Perhaps it won't be. And in any case, doing this project does not remove the need or intention to finish the rest in text. But it's a potentially valuable additional piece that I hope will add less work than its comparative beneficial impact will be. It remains to be seen if that's the case.

- Oshyan

[Tangled-Universe]

Thanks Oshyan Don't worry. I think you let history cloud your judgement on what I'm trying to say here. I mentioned this twice today which under normal circumstances one wouldn't consider "continuously". But never mind it's ok.

I'm rather realistic than pessimistic or a defeatist (that was really weak and disappointing to hear, sorry ).
I shared my vision of how I would set up a learning path and you replyed with your vision and the way you will prioritise it.
In fact you agreed between the lines, only in a different order/priority (You need to do this in steps as you pointed out.) and I understand and accept your reasoning that doing TVR's first is more effective time-wise and labour-wise. I can see that.

That's really fine and more than enough, believe me.
Just please continue with this

[Oshyan]

Sound good. I'll do my best.

- Oshyan

[yossam]

Oshyan,

If you could use some help with render time I would be glad to help.

[Oshyan]

Thanks Yossam. I suspect render time won't be the primary bottleneck, but we'll see... This is as much a learning endeavor as anything.

- Oshyan