Colour codes

[Nerox]

So here is a copy of my OnCreated.py script which I made a few quick changes to to make more robust. You can put this file somewhere in the Houdini script path, most likely in $HOME/houdiniX.Y/scripts/. Right now it provides a few features for setting colors based on types and locations in the Tab menu. All the mappings are set up using straightforward dictionaries and rgb colors.

The first check looks for manager nodes (chopnet, vopnet, popnet) and colors them, in this case green. Next it checks directly against a list of what I call "common" types. Things like nulls, switches, merges, and stuff that appear in many context could go here. The previous two cases will skip immediately to the end and color the node if they are successful. After that it begins a more detailed check.

First it looks into the list of specific node names based on context. This allows you to have an entry for any operator in any context. By default this search mapping is a bit of a soft mapping. It is soft because it is only doing a string search match, as opposed to an identical string match. This allows you to have more general mappings for things such as lights. Many of the lights are an instance of 'hlight', but then you have things like 'gilight' or 'causticlight'. By using a soft type match we can just add an entry for 'light' and it will cover all those. If you don't want that you can easily disable the feature by passing in False to the function that does the comparison.

If the name mapping is unsuccessful then it looks at the option to color by context specific tab menu location. This option gives you the ability to easily color similar nodes the same color. Examples include all nodes that appear in the SOP Import or Manipulate menus, all DOP objects, forces or solvers, or VOP Geometry and Utility nodes.

The final thing it will do is if a node is a generator node and it hasn't found any colors using the previous methods then it will color the node red for example. Generators include things such as Box and Sphere SOPs, Source POPs, Object CHOPS, etc.

Any comments or suggestions are welcome since it's just something I hacked together pretty quickly and always has room for improvement.

Cool :-), this approach is different than the one that I initially had in mind which is more pointed at what a node does in the current network instead of node type. How ever I think this approach might be better to start from. You still have to color some nodes by hand like parameters in VOPs, or adjust colors based on certain networks. I'll try to find some time to edit your script and add the stuff that I have in mind and then I'll post it back so we can all give it a shot :-).

Guess this is my geeky side surfacing, but I can get so excited about simple things like this .

[Nerox]

I finally found some time to continue on the color side of life :-).

I'm pretty sure it's not perfect yet, but I hope that together we can come up with something where every one can settle in. With other words, I encourage every one to participate in the process

I figured it would be good to start defining a convention, I came up with the following global rules according to coloring nodes:

Relations: Purple

Geometry: Green

Null: Black (doesn't add anything)

Merge: Dark gray (doesn't add anything)

Subnetworks: Orange (which contains the same node types as the current level and which you should dive in to)

Solvers: Blue (This is essentially a subnetwork, but you shouldn't dive in)

Managers: White

On purpose I don't use full red colors since I believe they should only be used to bring attention to certain nodes which errors out or what so ever.

To make things work down the line I had to make some concessions, but I really tried to stay as close to the convention as possible.

I've adjusted graham's script, which is based on node types rather than functionality within a certain setup. I suggest this as a good thing, since the point of a node color convention is to make networks more readable, also by someone who didn't build it.

I limited my self to the colors available in the default Houdini node color pallet.

Specific to the Obj Level, referring to the tab menu:

Geometry nodes: Green - 0, 0.4, 0

Subnetworks: Orange - 0.8, 0.6, 0

Lights: Yellow - 1, 0.8, 0

DOP: Blue - 0, 0.2, 1

Bone: Purple - 0.6, 0.4, 1

Specific to the SOP Level, referring to the tab menu:

Primitives: Green - 0, 0.53, 0

Attribute: Light Blue - 0.4, 0.8, 1

Polygon: Light Green - 0.4, 1, 0.4

Material: Pink - 1, 0.4, 0.4

Manipulate: Yellow - 1, 1, 0.4

Volume: Blue - 0, 0.4, 1

Import: Purple - 0.4, 0.2, 0.6

Specific to the VOP Level, referring to the tab menu:

Constant: Light Blue - 0, 0.4, 1

Geometry in/out: Purple - 0.4, 0.2, 0.6

Import Attribute: Purple - 0.4, 0.2, 0.6

Utility: Yellow - 1, 0.8, 0

Math: Pink - 1, 0.4, 0.4

Geometry: Green - 0, 0.53, 0

Specific to the DOP Level, referring to the tab menu:

Geometry: Green - 0, 0.53, 0

Solver: Blue - 0, 0.4, 1

MicrosSolver: Light Blue - 0, 0.6, 1

Force: Brown - 0.6, 0.4, 0.2

Relationships: Purple - 0.4, 0.2, 0.6

Fields: Pink - 1, 0.6, 0.6

ConfigerObject: Light Green - 0.4, 1, 0.4

So again, it's totally open for discussion. Ideally I would like to push it for the beta of H12, hoping people will like it so it can end up in the final product. How ever, I also realize that people might like a little GUI to edit those colors.

Attached you'll find my edit of Graham's sophisticated python script which handles all the coloring. To install it place in $HOME/houdiniX.Y/scripts/, you might need to create the scripts directory ( I seriously don't understand why it isn't created during installation, but that just me ;-) ).

I hope you like it, and let us know what you think.

Cheers!

Nick van Zutphen

OnCreated_V02.zip

[LaidlawFX]

I've been doing this a bunch lately, I need to go ask why, but this code looks soo much more complicated then what I've been doing. I could have forgot something, since I've been above my skill level a lot lately. I've just been putting in my script folder, a folder called sop(or obj, etc..), drop a text file with the node type in with an hscript opcolor like command and it is done. I'll post back, but there seems to be a simpler way to create this and to thusly modify it. I think the only downfall is I currently drop a text file for a node in the script area, like a .idx preset. One script, like the ophide node commands would be preferable so i could list them, in one text file, but a lot simpler code surrounding it. It's not my preference to look at that much code.

I do like the color selection for the nodes, if it were implemented in h12 I would want the control of an on and off feature(probably in preferences), and if it gets buried in the program and is no longer in the scripts directory I would like a menu to modify these default colors. Plus the system would need to work seamlessly with .otls, too.

[Nerox]

I've been doing this a bunch lately, I need to go ask why, but this code looks soo much more complicated then what I've been doing. I could have forgot something, since I've been above my skill level a lot lately. I've just been putting in my script folder, a folder called sop(or obj, etc..), drop a text file with the node type in with an hscript opcolor like command and it is done. I'll post back, but there seems to be a simpler way to create this and to thusly modify it. I think the only downfall is I currently drop a text file for a node in the script area, like a .idx preset. One script, like the ophide node commands would be preferable so i could list them, in one text file, but a lot simpler code surrounding it. It's not my preference to look at that much code.

I do like the color selection for the nodes, if it were implemented in h12 I would want the control of an on and off feature(probably in preferences), and if it gets buried in the program and is no longer in the scripts directory I would like a menu to modify these default colors. Plus the system would need to work seamlessly with .otls, too.

If it would be implemented in H12, than the code needs to be rewritten any way since it probably has to be imbedded in Houdini like you suggested. The current method however works pretty well and I'm very glad Graham took the effort to share his script, since it works for the moment. In that respect I would like to focus on the node colors instead of the method used to color them. If SESI would implement it, they would like to have a style guide which describes how the nodes are supposed to be colored. I hope that we can give the node coloring thing a jumpstart by providing this style guide.

So let's discuss some colors, the question would be: 'Do my suggested colors make sense?'

[graham]

To be honest I'm not sure what the problem with the code is? Ignoring the fact that I wrote it, it just seems to get the job done in a fairly simple and straightforward manner. It's not any more or less complex than that of any other functionality written in any of the toolutils modules Houdini uses to do most things. Do most people look at or care about the underlying implementation? It gives you a lot of control as to how to color one or many nodes based on several criteria. The code is also all centralized in one file.

I don't see the point in having a create script for each node type as in that case you have to create/manage tons of scripts individually where as this method allows more generalization and central control. In this case Hscript also has no access to any sort of tool information other than node type name so you have no way to color based on tab menu groups other than to manually create a script for each entry and assign a color.

As for working with .otl files, it already does. If your asset is a generator, it's colored. If it's in a tab menu group, it's colored. Don't like the color? Set a specific one in the config file or more simply just add a 1 line OnCreated script to the asset section. Alternatively you could add an OnLoaded section that inserted a cusom color tuple into the underlying data structure so the script handles it for you.

To make it more readable the section of the code dealing with color dictionary definitions could be split out to another file and be made to have a more straightforward config formatting if that's what people want.

Is there something obvious I'm missing here?

Edited April 3, 2011 by graham

[LaidlawFX]

Sorry to fire you guys up this morning. I just know there is a shorter code to type that is already implemented. I'm currently on vacation in portland so I don't have it with me. I ain't a savant with code, and I don't completely like the method that is implemented and there are some good things about the common toolutil python code. I've been doing a lot of asset management lately, so when someone suggest a change for H12, I just want people to know there was another method to compare and work with.

SideFX does not write about most of the pipeline management areas that are in place. It makes learning and trying to implement the stuff a pain. Most users will not modify this stuff, but as soon as you get into a company this stuff becomes important as you try and stream line work flow. Like making custom object level transforms to replace nulls, for animation especially to hot swap something out, I would use white on these nodes, but this isn't normal work flow, but for me it is. The style guide is a good idea, but we need to be able to easily modify this as we can now.

[Nerox]

@Ben, I understand your concerns according to my idea to automatically color nodes. How ever, with all due respect, I would appreciate it if you could focus on discussing the colors instead of the technic we're currently using. If SESI is going to implement it in de first place, they will do it their way and I'm pretty sure they will come up with something everyone can settle in.

The point of this discussion is to give it a head start by supplying SESI with a style guide. Last summer I've been interning with SESI. The idea of setting up a style guide came up when I asked why nodes don't have a color by default, the answer was that no one has ever took the effort to define a style guide, without a guide there is nothing to automate. The point that I'm trying to make is that this is the time for us users to say: 'we would this approach', then we can hand it over to SESI and then its up to them to take it or leave it.

Edited April 4, 2011 by Nerox

[zarti]

... . The point that I'm trying to make is that this is the time for us users to say: 'we would this approach', then we can hand it over to SESI and then its up to them to take it or leave it.

which approach ? i believe there is one already ( heard and seen it in few videos ).

but i admit ; it is a bit annoying while trying do something which ' naturally should happen by default ', just like the default naming .

now ... should we suggest a new palette ? why not ! but first that should be based on the SESIs pseudo-official-palette , because i believe there are already millions of hip files painted like that. add the fact that many users are used to that and respect it .

so that's the best starting point , imho .

so , i think , for as much as this feature is important ; nodes' color coding could be implemented like the actual pane's context is .

@SESI : ship 3 basic similar official palettes , which accompany the 3 basic color schemes ( just to better fit with their luminance ).

add the option to build a custom palette for those who already have build their own ' color-coding ' from years and we are done !

it might take some of your precious time , so do it when you feel it is appropriate ... but do not forget it .

if you wd ask me " wwwhen wd it be appropriate ?? " ... i wd respond " when this thread goes beyond 6 pages ... "

.cheers

[Nerox]

Yesterday by accident I've discovered that I uploaded Graham script without any modifications

Attached you'll find a new version of the script which includes all the colors I've described earlier. I've added a little printThis/debug function which prints the node: type, name, category type and if so in which menu location it shows up (only display's the first found) to the pyton Shell. You can turn this on by setting the debug variable to 'True'. I find this very helpful to figure out where and how to add a new node color to the script. This way I've discovery that the out context is actually called: 'driver', which makes total sense, not to mention the mantra output driver it's name: ifd

In addition to the previous colors I've added to the by menu location dictionary:

driver

"Geometry": (0, 0.53, 0), # green

"Utility": (1, 0.8, 0), # Yellow

"Render": (1, 0.4, 0.4), # Pink

OnCreated_V03.py.zip

Edited April 7, 2011 by Nerox

[graham]

Even though this thread sadly doesn't seem to be going anywhere I thought I'd upload a modified version of my previous system. Last night I was playing around with this and realized I wanted a bit more control so I made some changes. It is now more flexible and easy to modify. It is largely the same, however it's been reworked to rely on an external file to define the color settings. It also supports defining constant colors similar to .hcs files, which it is based upon.

The system supports 3 coloring operations, node types, tab menu locations and naming.

To color all Box SOPs a color I make an entry such as this:

node.sop.box: 1 1 0

To color any 'box' operator in any context I can do this:

node.all.box: 0 0 1

The sop entry has priority over the all tag so if both entries above are present the box will be yellow, not blue.

The same goes for tab menu entries.

tool.sop.Manipulate: 1 0 1

tool.all.Manipulate: 0 1 0

Precedence is as follows:

1. Context node type matching

2. Global ('all') node type matching

3. Context tab menu placement

4. Global tab menu placement

5. Manager flag

6. Generator flag.

Coloring based on names is also supported but not on an individual operator type basis.

name.sop.OUT: 1 0 0

This means that if you rename a SOP node to 'OUT' it will be colored red. As you might have guessed it supports 'all' as well. You cannot currently do something like

name.sop.box.OUT.

In the attached file is a collection of the system as it was designed to be used. Previously, for posting on this thread, I just jammed everything into the OnCreated.py script. All the work is handled by the nodeutils.py module. Features are run first through the 456.py file to create the dictionary of color mappings from the colors.ncs file. The mappings are stored in the scene using hou.session. Once the scene is loaded, the OnCreated and OnNameChanged handlers call the appropriate function inside the nodeutils module to do the coloring.

The colors.ncs file must be placed in a config/ folder inside the HOUDINI_PATH. i.e $HOME/houdiniX.Y/config/

The 456.py, OnCreated.py and OnNameChanged.py must be in the scripts folder.

nodeutils.py in scripts/python

The colors.ncs file is based on the color settings Nerox posted yesterday.

[graham]

Sigh, forgot to attach the file.

Edit:

On line 103, change tool_menu_colors.get("all") to tool_menu_colors.get("all", {}) to fix a problem for nodes in tab menus that are not set to be colored.

coloring.zip

Edited April 8, 2011 by graham

[zarti]

just tried adding manually menu-types like NURBS and Digital Assets .. and it works great .

but , if any is not defined , a warning message pops up . so , wd be great at least to avoid that ( which means ; default colors for non-defined nodes in .ncs file ).

for the moment i commented out the lines 105-to-108 and i do not get that message , but the default node's color .

i do not know if that is the right thing to do because i'm a beginner in Py .. but it works actually .

@moderators: , make a thread sticky and post " the base/starting official guide of nodes' color codes " + the Graham's post .

maybe this scripts should ship with H12 , also ..

great Graham ! and thanks .

.cheers

[graham]

Sorry about that. Missed something after a little last minute tweaking. Updated the post with instructions to fix it.

Edited April 8, 2011 by graham

[Nerox]

Hi Graham,

Awesome! Like you mentioned it's easier to configure and the automatic coloring based on the node name works like a charm.

At first look I noticed that you defined a different color for nodes named OUT in the SOP context, why is that? Shouldn't that be consistent across the board?

This is a bit of topic, but I've noticed you used the cPickle module. Having no clue, I've researched it a bit and for what I've understood it's basically used to save objects in ASCII to disk and read them back in. This makes total sense to me, how ever I also noticed writeToUserData(), I'm not sure what it does especially in conjunction with the purpose of colouring nodes.

Keep up the good work, It's more than appreciated :-).

It's said though that this topic doesn't seem to have the vipe/contribution I was hoping for. Maybe we should add a GUI to manually change the colours, being a bit frightened by qt I figured maybe I could create a HDA with and color selection interface with the primary purpose of modifying the color.ncs file?

[Nerox]

Install scripts on OSX

It took me quite a bit trial and error to figure this out but in order to install any script on OSX you need to do the following: (If you created the folders but Houdini doesn't seem to launch keep on reading).

- In your home folder create a Houdini dir: /Users/username/houdini11.0/scripts and /Users/username/houdini11.0/config

- From Graham's colouring.zip file extract all the files to the scripts dir, move the color.ncs file to config dir.

There is a chance that Houdini doesn't launch, in that case you need to tweak 456.py which you just placed in the scripts dir. This is less frighting as it sounds.

All you need to do is add the next two lines above the existing code and replace 'username' with your own username

import sys

sys.path.append("/Users/username/houdini11.0/scripts")

What it basically does is it tells Houdini to look in this directory for scripts or modules. I find it rather typically because 456.py is in that same directory, but for what ever reason when it tries to import nodeutils.py it suddenly has forgotten about this dir

[graham]

The naming ones were just for a quick example. No reason in particular, just showing you can change individual context ones when you have an all tag set.

cPickle and those functions it's used in, along with some other functions are totally unrelated to node coloring, but exist in my larger nodeutils module as they also do operation on nodes. I would recommend against using QT to attempt to build a GUI system to modify things as it is not usable with Houdini on some platforms. A digital asset that could modify the file is quite easy and probably about 30 minutes worth of work.

As for installing scripts on OS X, I'd recommend you not create the houdiniX.Y folder in your home directory. On OSX, Houdini stores that folder in your $HOME/Library/Preferences/houdini/X.Y directory. If you want to install any scripts you should put them in there since it is the "Mac" things to do. You can create the folder yourself in just $HOME but then it may start ignoring the other one and perhaps cause problems. Best to just put it there and you won't have any problems are have to modify any paths. Sorry about not mentioning that for Mac above.

[Nerox]

You can create the folder yourself in just $HOME but then it may start ignoring the other one and perhaps cause problems. Best to just put it there and you won't have any problems are have to modify any paths. Sorry about not mentioning that for Mac above.

Well I've deleted the other original scripts dir, it seems like Houdini picked this one up since it create new preference file in here. I'm not sure what SESI's reasons are to store the preference file so deep and almost hidden, since it's not consistent compared to Houdini on other operating systems. It might have been a demand from Apple but....

[graham]

Yes, Houdini will use the folder if it is located in $HOME over the one in the Preferences directory. The folder is stored there because that is the OS X way of storing application configuration data. As a whole the system configuration of the Mac version is not consistent with the other operating systems as most of the lib files are stored in /Library/Frameworks/Houdini.framework/Versions/ while the applications are located elsewhere.

[prashantcgi]

Hi Nick

Im sorry im asking a very basic question here

Can u tell me what SESI's stand for?

Im sorry if its annoying

[graham]

SESI is short for Side Effects Software Inc.