Inter_color and Morph_color Nodes

Attached is a demo showing TWO new nodes: inter_color and morph_color.

Inter_color returns intermediate shades between two colors based on a T value between 0 and 100. It is useful both for gradients and for animations.

Morph_color varies all three drawing characteristics - fillColor, strokeColor, and strokeWidth - at once, thus reducing the number of nodes and links needed to gradually change the color and/or thickness of a shape or path. It takes the T value, the shape, and a reference object with all three of those properties in their end state. By varying T in an animation you can gradually change all the drawing characteristics of a shape at once using only this one node.

If you need to simultaneously change the object itself (e.g. unwind a path or change the numbers in a time display) you can still use morph_color to change the drawing characteristics and then feed it into the reference port of an apply_color node to apply all three changes at once to the object. This technique greatly reduces the complexity needed to perform this common task (see this inside of the reshape node for an example).

The demo shows a morph color change on top, and an inter_color change on the bottom. Morph_color is used to shift the fillColor, strokeColor, and strokeWidth of a set of numbers and the circles behind them. Inter_color is used to create a color gradient showing how light wavelength affects color perception.

Both of these nodes use a linear interpolation for hue, saturation, brightness, and alpha. If someone requests it, I would consider supporting additional types of transformation.

These node will appear in version 3.2 of my Cartan Node Library. Go forth and create!

John

A brief followup...

Morph_color and apply_color are very similar. In fact, if you set T=100, morph_color works identically to apply_color. So do I really need two different nodes?

I constantly wrestle with questions like this when deciding which nodes to add to my library. Too many nodes and the catalog becomes overwhelming, harder to search through, and the library file takes longer to launch each time.

One way to reduce the number of nodes while still retaining a wealth of capabilities is to make "Swiss army knife" nodes that combine a number of related functions in a single package by setting different parameters. So in this case I could have one node that works as both a color morpher and a color applier by simply setting the T value. One less node in the catalog.

But more complex nodes also come with a price: they are larger, with more bytes, more subnodes, and slower performance. Nodebox switch nodes execute each option even though only one is needed, so adding more options tends to slow performance.

Morph_color is roughly four times as "big" as apply_color; it has 3.6 times as many nodes (65 vs. 18) and 4.2 times as many bytes (15,921 vs. 3,832).

And apply_color is used inside a number of workhorse nodes like clip, clean, contours, fit_curve, join, join_contour, push_pull, reshape, rev_dir, and sub_path. These nodes are used repeatedly in many projects, so replacing apply_color with morph_color could add many times the 10K byte load and 47 node count increase. And because those workhorse nodes often fire many times, the extra weight could slow things down significantly, especially when rendering animations.

Burying functionality inside multi-functional nodes can also make those functions harder to find. If I were to combine apply_color and morph_color into a single node, what would I call it? It may not occur to people that they could apply a color by using a morph node and setting T to 100. Similarly, it may not occur to people that they could use an apply_color node to morph colors. Simplicity is key to usability, and multi-functional nodes, for all their advantages, are less simple.

So after much thought I decided it was worth keeping both nodes.

A followup to my followup...

Both apply_color and morph_color originally allowed the reference to be optional. If left empty, the reference would default to a transparent fill with a one-point black outline.

I did this by setting the reference port to list instead of value, then adding a default value and taking the first value in the list. If no reference was supplied, the default value would be used instead; if one or more references were supplied, I would use the first one.

If a port is set to value, the node cannot fire until a value is supplied. If a port is set to list no value is required; the node will fire even if it's left empty. So if you want to make an input optional, you can do this by setting that port to list.

I thought making references optional with a commonly-used default was a nice added feature. But on further thought I realized that taking the first value in a list prevented both of these nodes from using multiple references.

Supposed you have a bunch of colored balloons and you'd like to draw a bunch of squares the same colors. With multiple references allowed, you could just attach a single rect node to the shape and the balloons to the reference: Voila! One colored square for each balloon.

So for version 3.2 of my library I have decided to allow both apply_color and morph_color to take multiple references. I did this by simply changing the reference port from list to value. This does mean that a reference is now mandatory for both nodes, but this seems like a net gain to me.

Version 3.2 should be coming soon. Stay tuned!

John