Just casual reading of the Planetside forum will reveal a lot of requests for Terragen documentation. In those discussions over the last several years it's clear that the staff of Planetside is very aware of the need for documentation and has been addressing that need with a wiki-based node reference. While a node reference is a good place to start, I'm finding it difficult to translate text descriptions of settings into practical application when working in Terragen. I'm sure I'm not alone in this particular challenge.
The demands of a business require that priorities be established which, in the case of Planetside, is clearly to create powerful software for terrains, which it is doing remarkably well. But that priority, and limited staff, leaves documentation (and I'm sure many other projects Planetside would like to do) on a lower priority, but nonetheless important. While we (myself included) have been pressuring Planetside to give us more documentation, there may be something the Terragen community can do to help.
I've constructed a settings reference example to illustrate a way to publish visually oriented Terragen reference material quickly. For discussion purposes, I'll call it "Terragen Visual Reference Sheets" (TVRS). I've simply taken screenshots of low resolution renders along with the applicable settings window, and show them side-by-side to allow a quick visual comparison. I chose lower, middle and higher settings to illustrate the effect of the setting. Note that I didn't take a minimum, mid or maximum setting – rather just enough to show the effect of the setting. This provides a visual of how a setting affects the image. Such TVRS's could be placed in a wiki to be indexed by the upper left title and the descriptive text. My example TVRS image is below, which is not intended to be technically accurate, just as example of a TVRS.
A couple benefits come to mind of this type of visual reference:
a) Persons from the community can easily make these, even with the non-commercial version of Terragen 2 because the render size is low. In this case I used Image Width=450, Image Height=300, Detail=.85, AA=3. These are well within the TG2 non-commercial version's rendering capabilities (and they render more quickly). I don't feel the preview image would work for TVRS's.
b) Other than Terragen itself, no special software is needed. I used Photoshop, but there are many alternatives including such low power apps as Window's Paint. In most cases, a TVRS author could have a zero monetary investment.
c) Provides a very fast visual, good for when an author just wants to know the affect of a settings with minimum technical description and much less experimentation in a real Terragen project.
d) This approach isolates the setting from relationships with other settings to aid understanding what the specific setting does.
e) Since the intention is not to create a specific landscape image, TVRSs need only focus on a specific setting and do not need to be tutorials. In fact, the actual TVRS image can be anything that illustrates the target setting's effect.
f) When a future Terragen release affects published TVRS's, only those TVRS's need be revised/republished.
This is clearly a project for the Terragen community on the whole, since there are potentially hundreds of such TVRS's. One person would take months or years to produce a usable TVRS collection. What I'm thinking is that a wiki be constructed (or Planetside makes its wiki available) where persons could publish their own visual reference sheets into the wiki assuming that a TVRS didn't already exist for that setting. Anyone could tackle any VRS they chose, whenever they like. The *original* author would get attribution on the TVRS page.
A couple key success factors of this project are; a) isolate as much as possible - avoid setting relationships as much as possible, b) keep technical text to a minimum to not slow down publishing new TVRS's – detailed text can come later. Keep the TVRS's highly visual to help them make it to the wiki quickly with minimum author pain. A consistent structure will also be important so that the reader doesn't encounter variations of the TVRS layouts. In summary; keep TVRS's very specific, highly visual, consistent in layout, easy to make, fast to publish and even fun to create.
Anyway, that's the idea for all to consider and comment on.
-Pat
[attachimg=1]
Sort of like the user editable wiki already available that mostly gathers dust... http://planetside.co.uk/wiki (http://planetside.co.uk/wiki)
The problem is the same as it always is each time these threads are created. Coming up with a plan is great but pretty much everyone would rather be building their own scenes instead of building documentation. Maybe if you started it off and did up 50-100 or so others may jump in?
Ryan, you referenced the official Planetside wiki. Is that wiki gathering dust?
As I'm sure you yourself have discovered, creating content yourself is the slow way to success. The exception would be when you have the time, ability and motivation to create large enough amount of content to attract a good number of people to the website. Else what happens is that people stop returning to the site because they lost confidence that there will be new content for them to review and consider. Point is, with this project, a single person can't get there fast enough to get regular traffic that uses the content. When traffic is not there, contributions slow or cease because it's not worth the effort for a small traffic volume.
A single-person project suffers from a couple of handicaps. First, the project becomes "owned" making it seem off limits to others. It becomes proprietary. Second, a single person is not likely to get enough content in place fast enough to get the project out of first gear, and indeed may actually slow the project down considerably. Contributors are more likely to wait until the single person gets his work done, which chews up valuable time to establish the resource. In short, a commitment from those 50-100 people you mentioned need to come before the content is created, else the result will likely be a Terragen resource with sparse content not seemingly worth spending the time to contribute to.
Projects die in their idea stage because the support is not there, not because the idea doesn't have merit. But putting the burden of proof on the person with the idea doesn't make the project any more viable. If the Terragen community wants this, the community will make it happen. Else it dies along with the other ideas and hundreds or thousands of Terragen users get to keep experimenting with Terragen settings until a nice image appears.
-Pat
Gathering dust only in the User Contributed sections. Jo and Oshyan update the official parts as often as they are able. You were asking for a community driven wiki, well feel free to log in to the wiki and edit to your hearts content. One clarification on the previous message - I did not mean 50-100 people would jump in and help, but perhaps if you, personally, created 50-100 "Terragen Visual Reference Sheets" then perhaps others might step up eventually as well.
I'm not knocking your ideas at all, they would be great. However the reality of the situation is that these sorts of threads are created quite regularly and I've yet to see one move any further.
Quotethen perhaps others might step up eventually as well
"perhaps", "might" and "eventually" are some fairly uncertain words. But as I explained, this needs to be a community project, not my project.
Quotethe reality of the situation is that these sorts of threads are created quite regularly and I've yet to see one move any further
And this one may also suffer that same fate. But wouldn't it be better if we spent our time discussing how it could be done rather than predicting it won't be done? If the idea is any good, let's not kill it with history.
-Pat
I think Pat makes a lot of valid points - they are well thought out and he has the gift of explaining them clearly and concisely. My viewpoint differs in this regard: if the documentation is to be created, then one person will need to own that mission to ensure it gets done properly. The reality is that the Planetside folks should be doing this and, as far as it is possible, I think they've tried. But let's face it: documenting a process is boring and painstaking. Who wants to do that when they could be satisfying their creative yearnings? Most of the folks on these boards are artists, and artists follow their passions. Unfortunatly, artists also have a reputation for being, well ... let's call it "a little bit undisciplined." They will spend countless hours trying to make a beautifull image, but will always have trouble finding the time and focus to document how they went about making that image. I honestly belive that the only way this documentation effort will ever come to fruition is if one person takes it upon themselves to own this effort and treat this as a project - with themselves as the project manager - and actively strive to pull other in people in to contribute their knowledge and ideas. To be clear about this: the project manager doesn't do the technical work. The project manager solicits input from other people (on these boards) for their creative input, and then puts that input into a document that can be reference and expanded upon. But - and this is a big 'but' - the Planetside folks should really be approaching someone in these boards to take on that tasks. Ultimatly, PLanetside should be overseeing this effort.
But that's just my opinion...
- Cam
If I recall correctly, someone created a small application for rendering out the same scene while selectively varying specific settings values. The scenes were output automatically and tiled together into a finished image grid (with what setting was changed as text below the image) so that the user could inspect the differences visually.
I always thought this was a great way to get a feel for the effect settings changes. And, if done across a range of parameters could allow a visual understanding of what controls do.
Unfortunately, I have no idea who this was, or how long ago! (I just spent 15 minutes searching and looking through old threads and came up empty - but I remember a grid of clouds with settings differences between them).
I only bring this up because, if this application could be found (or re-created ... there are programmers on the boards here and TGD files are just XML, and TGD can render from the command line.) then perhaps a group of users could be persuaded to supply some CPU cycles to help render out some of these images and that way a large visual library could be created and uploaded to the wiki relatively quickly.
Some coordination would be needed ... so that people didn't waste time rendering the same settings.
Just a random bit of brain storming.
~Micheal
I wholeheartedly agree with you Cam that the project must be managed. But I don't believe that one person should be developing the content because, as I reasoned, it will take much too long to have a useable reference. As with many projects that involve many people, a leader will emerge. But, it's too soon to decide management. Is the project even viable amongst the community?
You make a good point Cam, that many Terragen users are artists. But I think what we need confidence that there will be those who will contribute to reference material, including the artists amongst us. The idea is invite such people, give them guidance, and let them contribute into a system that is well defined. And, those that do make a TVRS enjoy a structured learning of at least that setting they chose to do a TVRS on – nothing like taking a close look at that setting to better understand it yourself.
I think it's also important to remember that this particular contribution requires the lowest amount of time to prepare, and doesn't require deep technical knowledge. A tutorial requires considerable investment of time. A book is a huge time investment. But a TVRS could be made by even those who don't have a deep knowledge of the setting because they can visually see how the setting affects the image, which is all that is really required for a TVRS. Once the TVRS is posted, others can provide or expand upon the technical explanation in text. As such, even hobbyist Terragenians can get reference materials into the system whereas, as it is now, one needs to be fairly skilled at Terragen to publish help material.
As for Planetside needing to do this, I also agree with you Cam. But, the Planetside forum has been lit up for at least 3 years with discussions of documentation needs, with some resorting to criticism of Planetside. But Planetside has made its decision how to handle documentation which has been clearly stated at various times in the forum. It doesn't appear to me that Planetside is going to take on such a project as this, nor does it appear it has the resources to do even if it wanted to. So, it seems to me that either the community is going to do this, or it's not going to get done.
-Pat
Excellent points Micheal! A fellow by the name of Ryan Grobins from Australia did something similar:
http://www.motionmagnetic.com/a_terragen2/atmosphere_examples/atmosphere_examples.html (http://www.motionmagnetic.com/a_terragen2/atmosphere_examples/atmosphere_examples.html)
It's curious that his website at http://www.motionmagnetic.com/index.html# (http://www.motionmagnetic.com/index.html#) doesn't seem to link to the examples page at the link above, which I obtained from a Google search using the keywords "terragen settings".
And you are right Micheal, the TGD is in XML format. So it would be feasible to write software that "parses" the XML of a TGD to ferret out the setting that was changed. Thinking out loud, a user would make a setting, save the project, execute a command of the app to capture the XML of the TGD, then make a setting change, save the project, execute another command to capture the XML of the TGD, then repeat. The app would then examine what XML element was changed and isolate that one setting with its values. With the changed XML element identified, the app would then run the Terragen from the command line to produce a render of each of the three setting values. The app would then capture the TG screens and get them into a format ready for the wiki submission, and possibly even automatically upload the screen captures. That could work!
The user would still need to prepare a scene that was intended for the simplest possible demonstration of the target setting. And the user would still need to make the setting adjustment within a range that was meaningful, because the minimum and the maximum settings will not always be practical for illustrating the effect of a setting. And, you don't want to show a large complicated scene because the setting effect is not likely to be visually evident in a big scene. And the contributor still needs to know if a setting needs a TVRS or not. So, the human hand will still be needed, although the business of capturing the content for the wiki could be automated to some degree.
Even though an app could be developed to do the above, I wonder if its value would be all that significant given that the human still needs to be involved to setup a simplified scene that would focus on the scene element that the setting would affect. And, such an app would need to be distributed and supported. It would be possible for the entire TGD to be uploaded to a website for analysis, or in this case three incrementally saved TGD's each with the changed setting. Someone from Planetside might want to comment on whether uploading TGD's like that would be a licensing issue.
Excellent contribution to the discussion Micheal!
-Pat
Found it!
This is the tool I was thinking of:
http://www.planetside.co.uk/forums/index.php?topic=12721.0
The thread is only a year old. I was hoping to use it sometime, but never heard anything else on it. Most of the examples are in the atmosphere/clouds realm, but he does have one changing the blend on a stones shader ... I'm hoping you could do blends of most any property.
The author (neon22) is still active here, but it's been about a month since he posted.
Just came up with this:
http://neon.wireframe.biz/node/38
Looks like you need a number of other tools installed to use it.
~Micheal
Also, I got bored and spent a couple hours writing a simple program to allow a user to inspect a TGD, select a value and specify starting and ending values, along with a step count over which to modify the value.
It's working pretty well and outputs TGDs ... but no command line rendering. Also, it's not got much in the way of smarts. It will allow you to modify any value that can be converted to a number, but doesn't know if it should be limited to a particular range, or if the value is really a Boolean.
Still, kinda useful and I might play with it a bit more.
Hopefully, though, Neon22's is in working order and allows you to blend any value you want ... it looked pretty feature rich.
~Micheal
Good detective work Micheal!
I looked over neon22's Batch_TG2 and it seems very capable. It's an automated batch rendering app targeted at creating multiple renders from a range of a particular setting which would be useful in animations and panoramas, and possibly even creating HDRI's. The app is written in Python and requires several other third-party software apps to also be installed. However, it is something I'll try out for its intended purpose.
I can see how Batch_TG2 might be pressed into service to create TVRS's (Terragen Visual Reference Sheets), but the app is way overkill for TVRS's. And, one needs some technical knowledge to install it along with it supporting software. So, I wonder how many people would actually press it into use for rendering out educational content. It also doesn't work with the non-commercial version of TG2 because it requires the command-line capability - we don't want to marginalize the non-commercial TG users. There seems to be fairly significant barriers when it comes to using the tool for TVRS's.
But the introduction of Batch_TG2 to this discussion does raise a very important question. Would people be more likley to create TVRS's if they had a tool that automated the process? And, what would that tool look like?
-Pat
Speak of the devil and he comes !! :o haha
TGD_Batch has been rewritten a number of times and a year ago I migrated it to QT based UI, using pyside (a python wrapper of Qt).
I haven't updated it for the changes from 2.4.X - specifically for animation - which it did quite well. So it might not work so well with the latest tgd files. I'll get to it when I finish my current project. Sorry in advance...
Proper thread is here: http://forums.planetside.co.uk/index.php?topic=12769
You could animate a number of frames, each of which rendered a tile, which it would then stitch back together seamlessly.
It also makes panoramas. in a similar way. Yes, even animated panoramas.
But at the time imagemagick did not have openexr support built in so it could not stitch open EXR tiles back together so an HDRI pano could not be made automatically. Maybe this year imagemagick has openEXR support compiled in ?
I haven't tried it with the 2.4.X yet - but I did make a fix for hetzen using win7_64 bit. So it does run.
Its a simple procedure to load and get it working. My instructions are long and drawn out but the steps are few and simple.
Its all been modularised to support remote rendering and I started a Django website but lost focus a year ago to make a coomunity supported remote render mechanism to use spare CPU sycles on anyone's machine who cared to help out. Maybe I'll get back to it... I guess we're getting more users.
as for its suitablity to make TVRS's - looks like its well suited to it actually. Maybe you should try using it (on an older tgd file).
Cheers...
Thanks for joinging this discussion neon22. As a software developer myself, I can appreciate the amount of time you must have spent developing your application, and I'm sure it has served you well in your own Terragen work.
Given that there may be a tool to create TVRS's, my question to everyone following this thread is this:
Would Terragen users be more likley to create TVRS's if they had a tool that automated the process?
-Pat
I'd rather see these sorts of things within the Wiki tbh. Its a good idea and will certainly help flesh out the documentation.
I agree with Jon (Hetzen).
For instance, your example showing hard layer steepness could perfectly be submitted to the strata and outcrops shader's wiki.
However, even better would be one image covering all settings of the shader. I made it quite a while ago and it should be somewhere here, but I haven't found it yet.
QuoteI'd rather see these sorts of things within the Wiki tbh. Its a good idea and will certainly help flesh out the documentation.
Hetzen; The TVRS's
are intended for a wiki. The idea is to create a reference where Terragen users can quickly lookup (in an online wiki) what the visual affect a particular setting would be.
TVRS's wouldn't be documentation par sa, in the sense that text would be secondary. Rather it would be a visual reference that is a) easy to create and post and b) fast to locate and use. TVRS's capitalize on visual recognition of change in the sample image.
-Pat
Quoteyour example showing hard layer steepness could perfectly be submitted to the strata and outcrops shader's wiki
Under normal circumstances, that would be a good point. However, I think we want to avoid trying to combine with Planetside's wiki work, mainly because we need to be sensitive to the fact that the Planetside staff can't spend as much time on documentation given only three people and other priorities (at this time). If we were jamming in images into the current wiki, it would force the Planetside staff to have to moderate the wiki changes and I'm sure they would feel the pain. But more important is that the TVRS wiki would need to be unfettered by text, allowing many TVRS to get posted. However, Planetside would most surely reference one of more TVRS's or even copy them into their documentation. But they need to do that work as they are able.
Quoteeven better would be one image covering all settings of the shader
Also a good point. But the TVRS's each need to be simple - highly focused on one setting. However, your suggestion would be implemented by creating a number of TVRS's as a set that is related to a particular shader.
-Pat
Taking your TVRS idea and just rendering a simple strata node with steepness (as in your original image).
The default output looks like this:
Seems like it could be good for this purpose...? Just a name change to the file would be good.
Thanks neon22 for running the test. Yes, your app could work for TVRS. A couple barriers seem to exist, please correct me if I'm wrong.
First, the installation of the various components is beyond most (you really should consider making an installation package). Second is that it's much more than needed for TVRS - will the user get lost in it's capabilities? Third, from a previous post you indicated that it may not work with the most current TG version - will a user need to install an older TG version?
You didn't build it for TRVS's, obviously. But I wonder if those persons willing to install your app and its supporting software will do so just for TVRS work. It just seems to me to be more technical than necessary for creating TVRS, which really should be simple and fast to make, else we'll not have many people making them.
-Pat
Quote from: PCook on August 31, 2012, 10:01:30 PM
Your app could work for TVRS. A couple barriers seem to exist:
First, the installation of the various components is beyond most (you really should consider making an installation package).
I'd like to, and I see there is something called cx-freeze which might help me package it. But seriously its four steps. I didn't think it would be that hard. I guess the test was that it was too hard, or the app just isn't that useful so the barrier was too high for people to be bothered. All good information :)
QuoteSecond is that it's much more than needed for TVRS - will the user get lost in it's capabilities?
Well its basically designed to do exactly what you propose for TVRS.
I.e. pick a a shader node, a parameter to vary, its range and how many steps.
(OK you can also choose to vary two or three params at the same time.)
It also allows you to tile if your image is really big (less of an issue these days but there wasn't a 64 bit TG2 version when I wrote it - and its still useful for load balancing if you have several machines.)
And it does panoramas with one button. Seemed like a useful thing to add...
The creeping elegance part would be trying to get to remote rendering on a network - but its not enabled at this point anyway.
QuoteThird, from a previous post you indicated that it may not work with the most current TG version - will a user need to install an older TG version?
Actually I used it today with current TG2 so it works fine but not if your tgd has animation in it. Then you lose :(
So I need to fix that - and add the 6 new nodes and the new parameters scattered through.
As a side Note - as at 2.3 there were 74 animatable nodes with 885 args.
Cheers...
Quote from: PCook on August 31, 2012, 10:53:55 AM
Quoteyour example showing hard layer steepness could perfectly be submitted to the strata and outcrops shader's wiki
Under normal circumstances, that would be a good point. However, I think we want to avoid trying to combine with Planetside's wiki work, mainly because we need to be sensitive to the fact that the Planetside staff can't spend as much time on documentation given only three people and other priorities (at this time). If we were jamming in images into the current wiki, it would force the Planetside staff to have to moderate the wiki changes and I'm sure they would feel the pain. But more important is that the TVRS wiki would need to be unfettered by text, allowing many TVRS to get posted. However, Planetside would most surely reference one of more TVRS's or even copy them into their documentation. But they need to do that work as they are able.
Quoteeven better would be one image covering all settings of the shader
Also a good point. But the TVRS's each need to be simple - highly focused on one setting. However, your suggestion would be implemented by creating a number of TVRS's as a set that is related to a particular shader.
-Pat
As far as I know Planetside encourages us users to update the wiki with references, examples or any kind of useful information.
I guess you're worried by the quality, but that's only a matter of using the right methods to determine what certain settings in a node actually do and also make a systematic report of them.
Your concern about quality, if it is, isn't very valid since you want to make these TVRS's anyway. As it seems the information at the moment isn't sufficient enough anyway so I don't see any reason not to append it with extra information. As I just said it is encouraged by Planetside.
I have the feeling you like your TVRS idea so much + automating it potentially that you may eventually miss your goal or get passed it.
Why shouldn't a TVRS contain just one image containing all the settings?
Just look at this image, it isn't covering the whole story about the strata and outcrops shader, but with 1 or 2 extra ugly drawings I could easily explain hard layer depth, hard layer spacing and the tilt settings all in 1 big image;
http://www.planetside.co.uk/forums/index.php?topic=8415.0
It's not that hard to cover most of the story in one or up to a handful of images.
The way you propose it now I'm afraid it will end up with a enormous pile of images and information and I'm not sure if the message/information will really be absorped anymore then?
Especially inter-related settings are impossible to be dealt with using the approach you're proposing. The pile of images will only get larger and things will get confusing pretty quickly and easily.
I'd recommend using the least amount of images possible, explaining individual settings and only mention if one setting can effect the other.
It's up to the user then to apply that basic knowledge and refine it further through experimentation and experience.
I guess that's how it works with everything else too besides TG2.
Cheers,
Martin
Yes - interestingly my TGD_batch program does not produce useful results for a complex node like the strata node.
The interrelationships between the parameters is not at all evident when trying to make, say, a triaxial blend between steepness, altitude, numoctaves.
The only way to work out what is going on is to experiment with all the params manually, or to find some doc like the excellent link in Tangled's post about how the node actually works.
This is one reason why I seldom use the Blend aspects of TGD_batch anymore even though it makes nice pictures :)
(but panos are super useful IMHO :-))
QuoteAs far as I know Planetside encourages us users to update the wiki with references, examples or any kind of useful information.
No argument there. But my thinking was to avoid trying to follow PlanetSide's wiki content so that the TVRS's could be populated without being throttled by another's content. However, PlanetSide would be welcome to use any TVRS they choose to augment their content. Keep in mind also that PlanetSide must moderate wiki content, so PlanetSide would need to buy into this TVRS idea if it wanted to use such material. But TVRS's are not intended to augment PlanetSide content, although they could.
QuoteI guess you're worried by the quality
Quality is not the objective. The TVRS concept is intended to produce quick references to visually demonstrate isolated setting values. Quality is secondary to usefullness. However, if by "quality" you mean "accuracy", then yes, accuracy is essential.
QuoteI have the feeling you like your TVRS idea so much + automating it potentially that you may eventually miss your goal or get passed it.
I don't fully understand your point Martin. However, reading your statment literally; First, I don't "like" my TVRS idea as much as it was intended as a starting point for discussion. If the community doesn't like the idea, it will not likley support the project which will likely result in one person hammering out a bunch of these that will simply go unused. As for automation, that would be wonderful. But how to do that without asking people to become software technical experts is the question?
QuoteJust look at this image, it isn't covering the whole story about the strata and outcrops shader, but with 1 or 2 extra ugly drawings I could easily explain hard layer depth, hard layer spacing and the tilt settings all in 1 big image;
Good point. But the idea of the TVRS's is to *not* attempt to cover the whole story, rather to isolate to a specific setting in each TVRS to show what that setting does. As such TVRS's become a fast wiki-based lookup of just a specific setting. TVRS are not intended, as I envison them, to be tutorials or node references - just setting referece points isolated to one setting, and not relationships of multiple settings. Then, using a wiki format, the user can look up the TVRS that concerns that one setting of interest to the user at that moment. TVRS's are, then, a fast reference *during the workflow*, not to study Terragen.
QuoteThe way you propose it now I'm afraid it will end up with a enormous pile of images...
Not if each TVRS is focused on just one setting. The original idea was for each TVRS to show the affect of a particular setting in a lower, middle and higher setting, just enough to visually show the *affect* of the settings. In that sense, each TVRS is 3 images at most, stitched together to show the 3 selected setting levels.
QuoteI'd recommend using the least amount of images possible, explaining individual settings and only mention if one setting can effect the other. It's up to the user then to apply that basic knowledge and refine it further through experimentation and experience.
Agreed. Avoid relationships of settings. Avoid in-depth text explanations. Just give the user a fast visual as to what that setting looks like visually. This simplicity of TVRS's also allow TVRS to be constructed much faster, even by people who do not have indepth knowledge of the setting, thus more TVRS contributions, thus more value in a TVRS library.
QuoteI guess that's how it works with everything else too besides TG2.
Also agree. When we can reduce a thing to it's simpliest element, we can better understand it. Then, we can more easily merge that knowledge into the big picture.
Thanks for your points Martin. My question to the community is this: is this thread moving us closer to validating the TVRS idea?
-Pat
Great idea but I fear it simply won't work as you expect.
Terragen is an integrated system in that what each node does, and what each setting within each node effects, is governed by where that node is placed within the larger structure of the nodal tree. For example the steepness setting you're illustration your idea with is itself modulated by the patch size of the preceding "compute terrain", amongst many other settings.
I started a discussion a while ago about a "Terragen modus operandi" (http://www.planetside.co.uk/forums/index.php?topic=13776.msg135361#msg135361) in which I was trying to bring forward an idea of a wider overview of how Terragen works. Some approved of the idea and some did not, but the general response has always been that if your idea is good enough and you get the ball rolling people will jump on board. However as has been mentioned most Terragen artists are busy making their latest master work and have little time for community projects.
Cheers
Richard
Hi Pat,
With "like" I was referring to your enthusiasm and that it possibly may blind you from some disadvantages.
So keep up the enthusiasm :) Seemingly, from your reply, you're not suffering from tunnel-vision so eventually my concern seems invalid.
To answer your final question; I'm not sure.
To me it seems you're the only one with a clear idea on what you want and how it should be done, because I'm not getting it (yet).
For instance, you agree with me that the least amount of images must be used to cover explanations, yet you want to make a series of 3 images for every individual setting.
In my eyes these 2 don't go along really well together?
So at the moment I'm not seeing a real advantage of your TVRS over my suggestion to just support the wiki articles with some visual explanation by one to a handful of images in total.
I think it's really a personal matter of how people like their information presented. Clearly, I like it condensed as much as possible into the least number of images.
However, I can understand why you'd like to have every setting explained separately and I see some situations it will be better than my suggestion.
Maybe you can try make 1 or 2 and see how it works out for you but also see how people think of it? See if they think it is a really useful way of explaining stuff?
In a way I'm not very suitable for judging this I'm afraid when it comes to the red nodes.
Maybe I'm not the best person to discuss this with as pretty much anything would work for me since I have enough background.
Except for about a handful things they don't have many secrets for me anymore, so consequently I probably understand it much quicker than less experienced people.
However, for blue node logic (which I lack) I consider myself suitable as a reviewer on how useful information is. If you can make me understand blue nodes then you did a fine job :)
Cheers,
Martin
Quote from: cyphyr on September 03, 2012, 02:07:23 PM
Great idea but I fear it simply won't work as you expect.
Terragen is an integrated system in that what each node does, and what each setting within each node effects, is governed by where that node is placed within the larger structure of the nodal tree. For example the steepness setting you're illustration your idea with is itself modulated by the patch size of the preceding "compute terrain", amongst many other settings.
I started a discussion a while ago about a "Terragen modus operandi" (http://www.planetside.co.uk/forums/index.php?topic=13776.msg135361#msg135361) in which I was trying to bring forward an idea of a wider overview of how Terragen works. Some approved of the idea and some did not, but the general response has always been that if your idea is good enough and you get the ball rolling people will jump on board. However as has been mentioned most Terragen artists are busy making their latest master work and have little time for community projects.
Cheers
Richard
Yes, exactly my concern I epxressed a few posts ago.
I see the usefulness in some situations, but I think it's mostly because of above mentioned reasons why I also don't think it will work as expected.
However, he's also right that that if an idea is good and people are convinced then they will likely hop on and help out.
So I'm still happy to see us proven wrong.
I hope you understand that we do support your idea (very much!) since we all paid for this and still have to do with incomplete documentation, but Richard (I think) and I are trying to make you aware of the difficulties and scope of the task.
Imagine the difficulty and scope when considering PS couldn't do it themselves ;)
The open ended nature Richard mentioned is debit to this and that's why his modus operandi discussion is such a good one.
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.
The best tip I can give you is using the search function and use the "search by user" field and look what Matt and other experienced guys have to say.
Talking is fine , no problem!
But talking if this works or not is not so much meaningful.
Make it ! Talk about how to make it better.
I like reading what all you write here and it is of course not up to me to say what you should write or not.
Threads like this come and go but nothing much does change.
The problem TG2 faces is that the user base is not so high that user generated content is high too.
Basically some people have to make this.
I wanted to make a tutorial about using texture maps in TG2 but making a tutorial is harder then i thought.
And i was already kinda aware of this :) Although it is very easy considering other aspects of TG2 .
I will make it anyhow hopefully.
And if the user base would be high we would get professional made books tutorials etc. too anyway.
If you guys make a tool that is easy to use for such tutorials it could rise the probability that users use it for tutorials.
Not sure if this comes out as pessimistic .This is not my intend.
Make it , use it! If it has problems they could be fixed , changed .
If we only argue if this or that will be useful , i can see already another thread from 1-2 years latter linking here !
I agree with Kadri. I have seen I don't know how many threads about improving the documention, but nothing ever comes of it. I don't know if it's apathy on the part of the members or something else. I understand that Planetside has more than enough to do already. I for one will be glad to donate render time to this project or any other that will improve the ease of use for the users, current and future. I think that the user base would grow if the software were a little easier for beginners to understand. I have friends that are interested in the software from seeing what pics are posted here, but they are scared too death that they will not understand how to use it without getting frustrated.
Again count me in, for whatever use that I can be.
QuoteI for one will be glad to donate render time to this project or any other that will improve the ease of use for the users, current and future
Ahh, sweet progress. It's such a downer to focus on what can't be done or why a thing shouldn't be done. yossam brings hope.
QuoteI think that the user base would grow if the software were a little easier for beginners to understand.
Good observation. If beginners can get started easier, it's likley they will be helpful to others sooner, if at all. A good start get's a person's confidence up to help get through the tough times.
Quotethey are scared too death that they will not understand how to use it without getting frustrated
Just last night a friend told me that he had downloaded Terragen after seeing it on my PC two weeks ago and a couple images I managed to create. He said he didn't have even the slightest clue how to use it, and uninstalled it. What a shame because he was interested in Terragen. People can't keep getting scared off like this.
Do we have any other supporters (or dissenters) of TVRS's?
-Pat
QuoteHe 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.
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.
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?
:o
This would maybe bring more new users to TG2 then a documentation about purple(!) nodes .
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
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.
Quote from: Tangled-Universe on September 03, 2012, 02:19:28 PM
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
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.
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
Quote from: Oshyan on September 16, 2012, 04:55:08 PM
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 :)
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
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 ;)
Sound good. I'll do my best.
- Oshyan
Oshyan,
If you could use some help with render time I would be glad to help.
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