Hi all,

has this been proposed? People have their own color codings they like to use, both in SOPs and especially in VOPs. This would of course be a preference, but it would make big node networks more readable with less effort.

In a perfect world it would be user-definable, and you could download color sets like you can for the general UI..

+1

Over on OdForce:
http://forums.odforce.net/topic/12280-colour-codes/ [forums.odforce.net]

Ohh, and it's not even that old, DOhh.

Yes, I know, using it for quite a while now, but out of box support would be really nice

edit: and assumed eetu did too and was talking about SideFx implementation

Please submit an RFE. Also add your list of colours, preferably as an additional text document if you go so far as to list each node and it's color.

As well, you are only limited by the RGB colours. The color swatch is just that, a swatch.

To test stuff out, you can edit each node's Tool script by adding something like:

node.setColor(hou.Color())

or more general from the python shell:
hou.node(“/obj/sphere_object1/sphere1”).setColor(hou.Color())

You can put down a Toon Character to see some color node options at the Object level.

+1

I also think SESI should do this because it would help establish a more common node coloring guideline for people to follow instead of everyone making their own.

They already did it with Bind and Parameter VOPs.

pusat
+I also think SESI should do this because it would help establish a more common node coloring guideline for people to follow instead of everyone making their own.

As long as we can turn it off too.

Nuke has an autocolor checkbox that beginners leave on, whilst seasoned users turn off and colour important nodes only. Helps to read a complex node tree.

MartybNz

pusat
+I also think SESI should do this because it would help establish a more common node coloring guideline for people to follow instead of everyone making their own.

As long as we can turn it off too.

Nuke has an autocolor checkbox that beginners leave on, whilst seasoned users turn off and colour important nodes only. Helps to read a complex node tree.

For sure, I don't know if Nuke colors every node type but I meant just a few certain ones like File, DOP IO, Null, Parameter, Bind, etc which wouldn't be disruptive IMO.

This is the pref tab in nuke. Looking at it explains it all. Fully optional to turn off or on and assigning nodes to colors by simply typing their name next to the color into the string.

Cheers,

Andy

Thanks for posting the screenshot. It looks great. +1 to have it in Hou

RFE submitted ID=61133

jeff
RFE submitted ID=61133

Thank you Jeff

jeff
RFE submitted ID=61133

Great!

I think it would be nice to have some discussion on the principles people have when coloring nodes. It would of course be good to be able to configure the color coding, but on the other hand it would be great if people used the same rules..

I do not use the colors that extensively myself. More in VOPs than elsewhere.
My main principles are:
- one color for incoming data (import points)
- one color for outgoing data (export points)
- one color for all sorts of subnets (eg. subnets and vopsops in SOPs, for loops and if-then blocks in VOPs)
- one color for the “most important” nodes with the main adjustable parameters. This of course can't be included in the rules.

That's it, mostly.

Also, especially if I'm recreating something from a paper or somesuch, I color (and name with a null) important midway points in the network that match a named stage in the reference.

I think the auto-colored nodes should use low saturated colors by default.

So you can still use signal colors for specific and very important nodes to find them at a first glance.

BTW, coloring the wires could be handy, too.

I am really up for this… every time I see a network from someone else the different colour scheme makes everything crazy…

jordibares
I am really up for this… every time I see a network from someone else the different colour scheme makes everything crazy…

+1 to eetu and jordi. A good standard goes a long way. Otherwise everyone has their own personal definition which is not very helpful. As eetu outlined, it's not even an overwhelming amount of nodes, but a handful.