Planetside Software Forums

If there are different classes of signals that connect the nodes together and signals are not to cross class boundaries (i.e. intermixed) when interconnected, it would help if the shape of each "connector" reflected the class it belonged to.  For example, color signals might be represented with a circle.  Displacement might be a down-facing triangle etc.  Then you could just look at the shape of the connector and it would immediately tell you something about it.  As they are, they are just a bunch of triangles staring me in the face without telling me much.  If signals of different classes can be mixed (i.e. there is not a 1-to1 association between compatible connector types) then at least differing shapes can help me decide what I can and can't do as far as interconnecting of nodes is concerned.  Since connectors that are on the top of the node are always inputs and connectors that are on the bottom are always outputs, it doesn't matter that circles (for example) do not point in the direction of data flow.  The shape giving me some information about how the connector can be used is of more use than the direction in which it might appear to be pointing.  Shapes should be simple because they are printed pretty small so that the node editor can pack a lot of information in limited space.  Suggested shapes are:  down-triangle, circle, diamond, square.  I don't have any idea of how many shapes would be needed.  

What do the rest of you think?  

Maybe color coding would work better and the flow direction (arrows) would still be retained?

The last thing we need is more visual clutter.

Quote from: gregsandor on May 05, 2010, 11:36:14 AM
The last thing we need is more visual clutter.

Well, I guess the decision has been made so we can bury this one.

Hi Pablo,

I voted it should stay as is.
Like gregsandor implied it is fine the way it is. More colours, shapes etc. would make it a clutter.

The reason that you come with this suggestion, I think, is that it is not clear what types of data inputs/outputs there are in TG2.
Some time ago I tried to get to you with a more in depth explanation about some of TG2's fundamental ways of working:
http://forums.planetside.co.uk/index.php?topic=9512.msg100715#msg100715 (http://forums.planetside.co.uk/index.php?topic=9512.msg100715#msg100715)

(mis-)Judging(?) from this and others topics - a bit rude/bald way of saying - it seems we people here are not capable enough to explain things properly or you don't spend much time trying to get along with TG2 and try to use it as is. Again, like I said in that topic before: don't get me wrong on this, but the very very best way of getting the hang of TG2 is spent time on the software, more doing/less thinking and post your results in the image sharing and ask for critiques and directed advice how to achieve a certain goal. Step by step.
I simply don't believe that all the things you have mentioned lately are the reasons you can't get started. So again I strongly try to encourage you to experiment etc.
I hope you believe me now :) It's really the best way!
Good luck!

Cheers,
Martin

as it is ! definitely as it is ^^

PabloMack, I'm trying to understand where you are coming from. You seem to want the node network to act as a more complete description of what is going to happen when you render. I think the point Martin is making is that most people approach working with TG2 in an entirely different way - they plug some things together, do a test render at lowish quality, and if the results aren't what they expect, they try something else, or if they really reach a dead end, they ask the community here - which includes everyone from complete noobs, through enthusiastic amateur hobbyists to experienced practitioners, including some people who use it professionally. What is your intended usage, and why do you think your suggestion would help you achieve it?

Quote from: domdib on May 05, 2010, 04:14:00 PM
PabloMack, I'm trying to understand where you are coming from. You seem to want the node network to act as a more complete description of what is going to happen when you render. I think the point Martin is making is that most people approach working with TG2 in an entirely different way - they plug some things together, do a test render at lowish quality, and if the results aren't what they expect, they try something else, or if they really reach a dead end, they ask the community here - which includes everyone from complete noobs, through enthusiastic amateur hobbyists to experienced practitioners, including some people who use it professionally. What is your intended usage, and why do you think your suggestion would help you achieve it?

Yes, more or less. Don't forget that trial and error accounts for all 3D software you use. Never ever you will achieve the desired result at the first time. Even with complete descriptions inside/outside the software. It's always a matter of determination, investment of time and indeed descriptions/documentation. The latter has been discussed endlessly and needless to say a lot of people have proven here that without descriptions/documentation, but with these forums AND determination + investment of time will get the result they're aiming for.
It's just the order of how things usually go. You start, experiment, fail, experiment, succeed or IF fail then ask here, IF succeeded show here, then improve, experiment, fail...then ask here again etc. etc. This is how everybody here has achieved their goals. They start at the beginning, without wanting to change the software, but by wrapping their head and time around the software.

Quote from: domdib on May 05, 2010, 04:14:00 PM
most people approach working with TG2 in an entirely different way - they plug some things together, do a test render at lowish quality, and if the results aren't what they expect, they try something else, or if they really reach a dead end, they ask the community here

simple and realistic point of view. agree with that.

Quote from: domdib on May 05, 2010, 04:14:00 PM
PabloMack, I'm trying to understand where you are coming from.

I come from a world where making "small" improvements to software can happen very quickly and
where the intuition for making judgments on what is "small" and what is "not" is very accute.  
I am a programmer.  Are you familiar with the expression "Bang for the buck"?

Quote from: Tangled-Universe on May 05, 2010, 04:27:57 PM
Don't forget that trial and error accounts for all 3D software you use.

We all had to go through huge amounts of trial and error to get where we are today.  It is a very
inefficient process.  You don't really start to perform effectively until you get to a point where you
understand what you are doing and can formulate how to get to where you want to go before you
start your journey.  It eliminates a lot of back-tracking.  It is sooooooo much better than wandering
around in the dark without a map and a flash light ("torch" for y'all across the pond. In the USA, a
"torch" is what you use to set someone's house ablaze. e.g. "His house was torched").  

Quote from: PabloMack on May 05, 2010, 05:40:29 PM

We all had to go through huge amounts of trial and error to get where we are today.  It is a very
inefficient process.  You don't really start to perform effectively until you get to a point where you
understand what you are doing and can formulate how to get to where you want to go before you
start your journey.  It is sooooooo much better than wandering around in the dark without a map or
a flash light....

....than? What's so much better? Understanding what you are doing? I only know one situation where only "reading" something resulted in complete understanding and control over it: The Matrix ;) I can't believe that's the world you talked about to domdib, which I think you were belittleing to. Anyhow.

Whatever you say Pablo, it all comes to spending time with the software and that's in my eyes what you seriously lack so far.
I can point to several examples proving my point that you're criticising and asking advanced stuff  but with clearly showing to not having looked at the program yet at all.
Others and I have tried to help you before, I even remembered you in this thread about a thorough explanation I wrote FOR YOU, and you seem to completely ignore it and  I'm not sure if I want to invest more time in this. Investing time in TG2 pays though ;)

Quote from: gregsandor on May 05, 2010, 11:36:14 AM
The last thing we need is more visual clutter.

I think the node network could look a little better. There are node networks that looks really nice and clean.
This (http://bp2.blogger.com/_V4SYpI93l98/R-7qhfINcXI/AAAAAAAABFI/fnICpoI1W2w/s1600-h/3dsmax_Particle_flow.jpg) one for example is very simple, jet it looks really nice and makes it a little more fun to work with.

Regards,
Terje

Seriously, I can see both sides of this when I think of other applications I use.  For example, if I'm programming, it take advantage of code folding, syntax highlighting, auto-complete, and many other features that (generally) make the task easier.  If I'm away from Lightwave for a while, I find I have to fumble a bit to get back up-to-speed, so any aids that can help me are welcome.

Sure, if you use TG2 a lot, you remember from session-to-session the little things that beginners have problems with.  That with any complex program.

Maybe the answer is to be able to customize the workspace so you can choose how much "clutter" you want.

Remember the old saying, "One man's treasure is another man's clutter" or something like that!  ;D

You got it.  Exactly my reasoning.  I don't think I could have put it more eloquently.  I am speaking as an engineer and not as an artist (again) but useful information is at least as important as (and maybe more than) aesthetics.  But I am a believer in both. 

Hi,

I have thought a bit about this, as I'm sure the others have to. Speaking in programmer-esque, TG2 has weak typing for the node network, in that most inputs can accept any type and it gets converted to the type the plugin expects. There are conversion rules which I documented for the old documentation but which don't seem to have made it into the new documentation yet.

For function nodes this type will often be included in the name, for example "Add scalar" or "Add colour".

I seem to recall Matt's idea with the node network is that connection types shouldn't matter so you can connect anything to anything, which is fair enough. However I do sometimes think it would be helpful to have node inputs indicated the primary type they're supposed to accept.

There is of course the slightly different issue of what data exactly a plugin is working with. As you say there are some plugins which only work with the displacement or colour parts of the data stream. I'm not so sure about this but in most cases I don't think this would be something to indicate via connectors. It might be helpful if a node was badged with a little icon showing whether it was dealing with colour or displacement, for example.

Regards,

Jo

Hi jo,

Thank you for piping in.  I was starting to feel lonely with no TG staff.  I have a question for you (or several related ones).  With displacement, we are dealing with a scalar.  Correct?  But with colour, we are talking about a 3 or 4-dimensional vector.  So if colour vector outputs are fed into scalar inputs, is the luminance extracted from the source vector to obtain the scalar that will be used to drive the input?  And if colour contains Alpha, what then?  If you are extracting luminance for this purpose, then I presume hue and saturation are thrown away (along with Alpha?).  And if you drive a colour (vector) input with a scalar output then you will either have floating (or defaulting) hue and saturation or you just drive all three RGB signals with the same scalar so you are using a monochrome signal.  Of course there are the active dynamic range compatibility issues (legal or typical end points) to each scale which can be adjusted in math nodes in systems that have them.  Iin my experience, luminance is typically limited to a range of 0 to 1 while displacement may go way beyond 1. 

Of course that gets us back to the root of the problem.  If the documentation was up-to-date and thorough, you wouldn't have to ask many of the questions and wouldn't need the on-screen aids.

I have experience as an Electrical and Software Engineer and some limited time as a Human Factors Engineer, so I probably think more like you, PabloMack.  But it was all in the past, on older, larger, equipment, like P-3 and F-15 fight simulators. 

I would rather pick up a book to get answers.  But if that's not available, I would rather read a pdf document than do Internet/forum searches.  Of course no documentation will answer everything and that's where the power of this forum comes into play.  And new ideas.

I especially agree that we don't want TG2 to lose it's flexibility just to make it easier for beginners to use.  We don't want it to lose performance due to "clutter" or look and feel like a MS Office application.  I think I can say "we" because I haven't seen much evidence to the contrary.

However, there's lots of things that could enhance the new user's experience that wouldn't impact performance/flexibility.  I think it's good to throw it around here with discussion and not simply discount it with "I like it the way it is" without thinking of the user's as a whole. 

The really expert users that post here (not me, by any means) are a minority of the entire TG2 community, but get the most attention, as they should, because they are experts.  But that means the consensus of most forum topics is usually in favor of the experts.

Anyway, fun stuff!

Quote from: PabloMack on May 05, 2010, 10:04:47 PM
Hi jo,

Thank you for piping in.  I was starting to feel lonely with no TG staff.  I have a question for you (or several related ones).  With displacement, we are dealing with a scalar.  Correct?  But with colour, we are talking about a 3 or 4-dimensional vector.  So if colour vector outputs are fed into scalar inputs, is the luminance extracted from the source vector to obtain the scalar that will be used to drive the input?  And if colour contains Alpha, what then?  If you are extracting luminance for this purpose, then I presume hue and saturation are thrown away (along with Alpha?).  And if you drive a colour (vector) input with a scalar output then you will either have floating (or defaulting) hue and saturation or you just drive all three RGB signals with the same scalar so you are using a monochrome signal.  Of course there are the active dynamic range compatibility issues (legal or typical end points) to each scale which can be adjusted in math nodes in systems that have them.  Iin my experience, luminance is typically limited to a range of 0 to 1 while displacement may go way beyond 1. 

There are no difference between a vector and a colour, they are both 3 components data types and the components can take any value.
I you connect the output of a colour node to a  scalar input, you get the scalar: sqrt(red^2 + green^2 + blue^2)
I you apply the "colour to luminance scalar" to a scalar you get weight(red)*scalar + weight(green)*scalar + weight(blue)*scalar

I vote for no change, except it would be nice nodes with no input could suppress the input triangle

I think the main reason there isn't a clear flow of strictly typed data in Terragen is because of the early decision to do much of the work by chaining together shaders which can perform arbitrary modifications on a wide band of data. This is the general case with the shaders, which are the red coloured nodes.

Different shaders do different things and work in different ways. However, there are some basic rules.

Most shaders (the nodes coloured red) are designed to manipulate the current shading state. The shading state contains information about the current point being shaded, including (but not limited to) position (that includes displacement), undisplaced position, texture coordinates, various surface normals. Most shaders execute the shader that's connected to their main "input" input, then perform their own modification of the state. For this reason, in general there is no particular type of data that an input requires. You can therefore think of the main "input" input as being an entire description of a point on a surface or in a volume.

I designed the main flow of shaders to work this way so that each shader can do more than one thing to a surface, not just generate some value.

Other inputs may expect particular types of object, such as a camera, an object (in some cases a specific type of object e.g. a planet), a shader or function. I don't think we can represent all the types we would want to with just a few simple shapes, but I think a clear indication of the expected type would be very useful and is an unfortunate omission in the current system. There are some basic categorisations (e.g. shader/function, object) which we could represent, but they would be coarse categorisations.

The blue function nodes are designed a little differently. With these I wanted there to be a more conventional flow of data consisting of a single value (whether it has 1 or more components) and for each of the nodes to perform only one low level function that we could easily document, and for parameters to be implemented as connections wherever possible, rather than constant values in a parameter window. For these nodes, there are only 3 possible types of data. Scalar, Colour (3 scalars) and Vector (3 scalars). They are not strictly typed, and conversions between these types will happen automatically (according to specific rules we have documented) if a function expects a different type of data from what it is given. By convention, the type of data produced by a function should be the last word in its name, although there are a few exceptions where it was awkward to adhere strictly to this convention.

Oshyan, do we still have that page where Jo and I documented the automatic type conversions done by functions?

We would like to keep the blue function nodes as a haven of transparent behaviour and avoid most of the "black box" issues and confusion surrounding the rest of the shaders, even though for many users they can seem overwhelming. We need to make sure the documentation is finished and online.

Many of the red shader nodes expect functions or "colour shaders". Any shader that modified a surface's diffuse colour can be used as a colour shader, and will also convert automatically to a colour function when connected to a blue function node. Any function node will be converted to a colour shader when connected to a shader that requires a colour shader.

It tends to be the older shaders that are inconsistent about whether they label an input a "shader" or a "function". We should clean some of this up. Generally speaking, though, any shader could generate colour that might be useful as a function.

There are only a few shaders that generate displacement from a function (or colour shader), and if I recall correctly in every case these shaders have an input labeled "displacement function" which expects a scalar function. Colour data gets converted by taking the luminance, and vector data gets converted by taking the magnitude.

I know this only goes part way to answering your questions.

Matt

Yes, we still have the Type Conversion info. It was taken offline incorrectly a bit ago when I was transferring docs to other systems. It will be restored along with some other stuff soon. Apologies for the mistake.

- Oshyan

I vote for no change. Please, leave it as it is, no more visual distractions.

---Dune

I have read everyone's comments and I appreciate their input.  They certainly reflect their author's ways of thinking and work flows.  Special thanks go to the PS staff for their insites and assistance.