Poll: Suggestion for improving Node Editor- Connector Shapes

[PabloMack]

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?  

[jaf]

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

[gregsandor]

The last thing we need is more visual clutter.

[jaf]

The last thing we need is more visual clutter.

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

[Tangled-Universe]

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

(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

[Seth]

as it is ! definitely as it is ^^

[domdib]

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?

[Tangled-Universe]

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.

[Seth]

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.

[PabloMack]

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"?

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").  

[Tangled-Universe]

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

[sjefen]

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 one for example is very simple, jet it looks really nice and makes it a little more fun to work with.

Regards,
Terje

[jaf]

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!  

[PabloMack]

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. 

[jo]

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