tag:support.nodebox.net,2012-11-01:/discussions/show-your-work/568-inter_color-and-morph_color-nodesNodeBox: Discussion 2023-04-05T21:22:00Ztag:support.nodebox.net,2012-11-01:Comment/583624322023-03-24T21:51:31Z2023-03-24T22:00:49ZInter_color and Morph_color Nodes<div><p>A brief followup...</p>
<p>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?</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>So after much thought I decided it was worth keeping both nodes.</p></div>johntag:support.nodebox.net,2012-11-01:Comment/583624322023-04-05T21:21:57Z2023-04-05T21:21:57ZInter_color and Morph_color Nodes<div><p>A followup to my followup...</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Version 3.2 should be coming soon. Stay tuned!</p>
<p>John</p></div>john