Cartan Node Library 2.3

Attached is the latest upgrade to my node library! Version 2.3 includes 92 nodes. All nodes are free for use with no restrictions.

To use: with your current project open use File/Open Recent to open node library 2.3.ndbx in another window. Then just copy/paste the desired node from the library into your project. A few of the nodes also require adding a code library module (included).

As you can see in the screenshot, he nodes are all grouped together in the lower left part of the network pane; they are arranged in columns by type and within each type alphabetically. Hover over each one to see caption.

The big tree to the right and above contains demos for each node. Look inside to see examples and also find additional related nodes. By default I render the empty poster view so the library will open quickly. Render the node next to it to see the whole poster (takes a few seconds).

WHAT'S NEW

New Nodes:

• Image. https://forum.nodebox.net/t/19506698/image-node
• Corners. https://forum.nodebox.net/t/19473621/corner-node
• Stack_tight. https://forum.nodebox.net/t/19544995/stack-tight-node
• Triangle. https://forum.nodebox.net/t/19518373/triangle-node
• Turtle_drive. https://forum.nodebox.net/t/19566949/turtle-nodes
• Reshape (formerly turtle_morph). https://forum.nodebox.net/t/19566949/turtle-nodes
• Unwind. https://forum.nodebox.net/t/19566949/turtle-nodes
• Point_in_path. https://forum.nodebox.net/t/19571832/point-in-path-node
• Parabola. https://forum.nodebox.net/t/19573512/parabola-and-trajectory-nodes
• Trajectory. https://forum.nodebox.net/t/19573512/parabola-and-trajectory-nodes
• Node_card. https://forum.nodebox.net/t/19551296/node-catalog

Improvements:

• Tangent node now faster, no longer requires code module
• Grid_plus now faster
• Conver_base now takes floats without errors and properly pads numbers
• Poisson renamed to scatter_evenly
• Poster simplified to reduce render time
• Make_curve replaced with curve; no longer requires code module
• Other nodes which used make_curve also no longer require a code module:
• explode
• intersect
• mask
• rev_dir
• spiral
• sub_path
• trace
• waveform

Deprecated Nodes

• Evolve. Too complicated, I always had to modify it
• Bounce. Can now use Easing node instead.
• Fit_curve. Not much better than round_segments

If anyone misses any of the three deprecated nodes please let me know and I will restore them.

I would really appreciate hearing from anyone who uses this library. I can't tell if anyone even views this discussion, let alone downloads the library. It would be great to hear some feedback on what works, what doesn't, and requests for additional nodes.

Go forth and create!

John

My node library may be the largest NodeBox network ever created.

Some stats:

Total Nodes: 64,481
Total Connections: 79,622
Maximum depth: 11 levels

A week has passed and I still haven't had a single confirmation that anyone out there has even seen my library post, let alone downloaded and tried it. If anyone is still following my "Show Your Work" posts, please reply with a simple "like" or "thanks" or "saw this, will try it" or "am using it".

If I get no such responses soon I will assume that I'm just talking to myself here.

I will keep improving my node library because A) I enjoy it, and B) it's incredibly useful. But if no one else is interested, I will keep future releases to myself.

John

:-) Nah, I regularly check this site and use node box.
Thank you for continuing to move this project forward!

and thank you for sharing the Library!

Hi John, Thanks for sharing the new library! I haven't been able to look at the new additions and improvements, but I have found the previous version tremendously useful and have been using it a whole lot, so I suspect the same goes for this library.
Floris

Thanks, D and Floris. Quite a relief to know there's still a few of us left.

Let me know if you have any feedback. One of the challenges with this project is the sheer number of nodes. Only a small percentage of the nodes I create make it into my library, but I could still easily hit a hundred by the next release. A hundred nodes are hard to search through and understand and remember. The same is true with Nodebox and its almost 150 nodes. How many nodes is too many? Is there some other way of organizing and releasing nodes that would be less overwhelming?

John,

Since your were asking on some feedback on your Node Library and listed some questions, I’ve listed some information on how I am using it.

The nodes I am using fairly regularly are:

• Mask
  • It gives an error quite frequently: ‘Divider cannot be zero’. Which seems to be caused when the mask is to close to and end- or startpoint of a line. I’ve found that scaling the artwork up, apply the mask, and scaling down helps with getting the necessary accuracy. Don’t know what consequence this has for performance.
• Waveform
• Scatter evenly
• Join
• Image
• Grid_plus
• Hexgrid

Nodes that I am using a lot, but I regard as a basic tool. They are quite simple, but very useful

• Explode
• Diff_List
• Indices
• Drop_last

Nodes that I like and use in specific cases

• Treemap
  • I have used this as a lay-out tool. So I am scaling it to fit the shapes, with the result of a circlepacking like effect. Which would be nice with squares instead of rectangles
• Spiral
• Contours
• Curve
• Area

Which doesn’t mean that the Nodes that are not mentioned are not usable in any case, just that it doesn’t suit my needs, or I do not understand how to use them (yet). Sometimes, when I am trying to solve a problem, I browse the library or the forums whether there possibly already is a possible solution.

In regard to your questions on how to keep an oversight on the amount of Nodes. The most user-friendly solution would probably be that these kind of functions would become available in the ‘new node’-menu/’create new node’-function. Is there any any change on an update such as that? As far as I know, the development of Nodebox was part of a research project, but are there any plans to continue developing/updating it?

Currently you’ve grouped the different Nodes in certain ways, right? Is this in some way similar to the same categories listed in Nodebox itself? I mean: Math, String, Color, List, Data, Geometry, Network, Core, Other? Or is is possible to do so? In that case it is possible to conceptualize specific parts of your Node Library as add-ons to this and maybe to provide a separate Node Library on each of these subjects? Managing and using the Cartan Node Libraries (plural) this way could maybe be easier.

Another possibility is to get more user feedback as provided above. Nodes that apparently aren’t used can be become omitted in updates.

Hopefully this helps,
Floris

Floris,

Thank you VERY much for this detailed feedback. Very helpful.

Re Mask. Try using the latest version from my library instead of the original version you and I developed together. I can't quite remember, but I might have fixed that division by zero error in the mask node. If not, please send me a copy of a network triggering that error so I can replicate it and fix it. Thanks.

Re Area. Note that Area only works with poly-line paths. If you give it a shape with a curve in the path it will give a wrong answer. If you do want to take the area of a curved shape, resample it first.

I wish I could add my nodes - or anyone else's - into the New Node dialog. This is something Frederik wanted to allow, but never got around to and probably never will now.

NodeBox was indeed a research project at a Belgian research institute (EMRG) that was disbanded a few years ago. Its creators have scattered and are now working on other things, though they may step in to help every now and then (as Frederik did with the recent update). But there are teachers and artists around the world still using NodeBox. And I plan to be here helping on the forum until they haul me away.

Yes I have grouped the nodes by approximately the same categories Nodebox uses. You can see that in the color of the nodes (which follow Nodebox output category colorings). I agree that at some point it might make sense to break the collection in multiple libraries. I might also issue special "node packs" focused on a niche area - maybe plotting nodes could be such a special collection.

Thanks again,

John

The image node fills such a huge hole. Thank you so much John, I look forward to digging into the new nodes this weekend.

Woohoo!
Drew

Amazing! So many nodes that fit into ui requirements. The nodes for colors, shutters and gears are so awesome. I could not get wind_letters display text though. Thanks for all the work done there.
Ramanraj K

Ramanraj,

The wind_letters node will be unresponsive until you hook a path into its path node. The only path that really works is a spiral, so you should get a spiral node (from the library) and try that. See the demo_wind node (near the bottom of that big tree of nodes that feed into the poster) for a working example.

I really should just build a default spiral node into the wind_letters node so this won't happen. I'll put that on my list of improvements for the next release.

Please do play with as many of the other nodes as you can. If you find any problems or have any other feedback, please let me know.

Have fun!

John

Hi John!

I was interested in:

1. Dynamically defining points located on any type of geometry, e.g., a line or paths from an imported SVG file
2. Translating shapes (e.g., ellipses) to those points along the path
3. Getting the pixel color values from the underlying image based the points along the path
4. Using the color values from Step 3 to fill the shapes from Step 2

For this test, I had to modify lines 98 & 99 of image.py (included in the attached zip) forcing x & y to integers.

Drew,

This is very interesting! Clearly you have studied my library and made good use of it. Your general goal of sampling SVG paths and coloring them using an image is a simple but powerful idea that could have endless beautiful and surprising results.

A few quick comments:

• Your technique of placing green comment nodes with step numbers is kind of brilliant; I've never seen anyone do that before. It would be great for tutorials. I just might steal this idea for some future project!

• If you are going to use your network like a tutorial (even if you are the sole audience) you should make it as tidy as possible. Like most people I notice you tend to cram your nodes tightly together, sometimes obscuring connection links. This makes the overall network harder to read and modify. One of these days I'm going to write a guide to arranging nodes for maximum beauty and readability. It's an art a bit like flower arrangement.

• Three of your nodes in step 4 (image1, img_reg..ft1, translate4) are doppelgängers. Dopplegangers are duplicate nodes sitting directly on top of original nodes. To see this, carefully drag each one of these nodes to one side. It's all too easy to make them by accident when a copy-drag goes awry, and once formed they are invisible! They may not cause an error at first, but later, when you modify them, some connections will attach to the originals while others attach to the doppelgängers. The first time this happened to me I almost pulled out my hair trying to figure out what was going on. Since then, I am constantly on the watch for them.

• It was clever of you to modify image.py, but not necessary. Instead you could just snap the sampled points to integer coordinates before feeding them to the imp_color_map node. You can do this by extracting the x,y values, rounding them, and recombining them with make_point.

• In step 4 you made a subnetwork (imp_regPt_topLeft) to realign the image. Because the subnetwork uses photo_bounds (which provides the bounds of the original image) to find the center of the raster matrix created by my image node (which, depending on settings, may have a slightly different width and height), your alignment is slightly off. And there's an easier way to do this: just use an align node set to Left and Top - no subnetwork and translate node needed!

• When sampling along SVG curves you may notice that the total_points node (actually a shape_on_path node) does not space your ellipses evenly; instead they bunch up around the curves. This is standard Nodebox behavior when resampling, but may not be the effect you want in this case. As an alternative you might try my even_sample node. It will provide evenly distributed points along each curve; you can then feed those into the position port of your ellipse node (or whatever stamp you are using) to place the stamps.

As I said, I am genuinely impressed by this network. If you continue to play with it, I suggest you start a new thread in the Show Your Work section so that other people can find it more easily and comment on it. I'm curious to see what kind of art you could produce with this technique.

Thanks again for sharing!

John

Thanks John for the extremely helpful tips and your insight! I created a new post in the Show Your Work section, which can be found here:

https://forum.nodebox.net/t/19606835/cartan-node-library-2-3-getpixels-on-a-path-s

I have a follow-up question about getPixel's big brother, a Moore Neighborhood. Do you know of an existing method within Java that returns the direction of the darkest pixel from the 8 pixels surrounding a specific pixel? I'm sure you're familiar with a Moore Neighborhood, but for those who aren't, here's a good description:

http://www.imageprocessingplace.com/downloads_V3/root_downloads/tutorials/contour_tracing_Abeer_George_Ghuneim/moore.html

Woohoo!
Drew

Hi Drew,

I'm not really a Java coder (even though that's what NodeBox is ultimately built on), so don't know if such a function exists. But it would be pretty easy to make one - in NodeBox or Java.

Using it to do contour tracing, though, would not work in Nodebox alone, though, because the algorithm is recursive and Nodebox doesn't do recursion. There are some workarounds, but they have limitations.

John

amazing library! — @John what's the best way to work through it; when I open node library 2-3.ndbx it's a little overwhelming — be super helpful to have a readme or similar to get started.

For example, if I wanted to explore scatter_evenly, do I find and then copy the network into another nodeBox file and should I always copy all the py files?
— thanks for sharing, opens up so much :)

Hi Sundar,

I'm so glad you are trying out my library. And yes, it is overwhelming even for me. It does need a readme, but in lieu of that, here are some tips.

• When you open the network you will see there are two basic parts:
• To the left are all the nodes in columns based on type (gray = math, black = geometry, light blue = point, med blue = list, dark blue = data, dark gray = string/other) sorted alphabetically in each column
• To the right is a tall tree that forms the illustrated chart. If you examine that tree you will see a demo subnetwork for each node
• Each node on the left has a comment; roll over it to see a brief description
• If a node requires a code module, the final part of the comment will say which one in all caps. YOU ONLY NEED TO COPY THE MODULE INDICATED BY THE COMMENT. Most nodes are really subnetworks and do not require any code modules.
• The tree on the right is set to render the combine4 node which displays a quick loading plain text chart. If you instead render the combine20 node next to it, Nodebox will display the full illustrated chart, which you can then save as a PDF if you want. It may take 15 or 20 seconds to draw that full chart.
• Each demo node on the right provides a compact example of a node. You can double-click to render that node and see the demo displayed.
• If you open that demo node (control-click, Edit Children) you will see the demo as a mini network. If you are unfamiliar with the node, you can copy its entire demo and paste it into a new network to play with it.
• Some of the demos contain extra bonus nodes. For example, the arccos node demo (demo_arccos) also contains an arcsin node. The triangle node demo (demo_triangle) also contains a tri_center node and an in_circle node.
• The most efficient way to copy nodes from the library is to first open the network you are working on and then, when you need a library node, choose "Open Recent" from the File Menu. If you regularly use the library, node_library 2-3 will appear near the top of the recent list. Maximize both network windows to make it easy to switch back and forth between them. Then just select the node you want from the left columns, copy, switch to your own network, and paste. Once you get used to this it goes pretty fast.
• I don't have a readme file, but I do provide release notes each time I post a new rev of the library in the forum. In many cases I also provide separate release notes for each individual node when I first share them. So if you are still puzzled about how to use a node, try searching for it in the forum and see if there are some notes about it.

If all else fails, PLEASE just post a note In the forum and ask me any questions you have. I will be delighted to answer. Chances are if you have a question others will have the same question and thank you for posting it.

Hope that helps. Go forth and create!

John

P.S. In the example you mentioned, scatter_evenly, if you view the comment for that node you will see that it says REQUIRES POISSON.PY at the end of the comment. So in this case you do need to copy the poisson.py module, and only that one module. If a module is required I always quit Nodebox, create a folder to hold my new network and place both the network .ndbx file and a copy of the .py module in that folder, then relaunch Nodebox, open my new network, and add the code library BEFORE I copy paste the node from my library. That way you avoid triggering error messages. It's kind of a pain, which is why I try to avoid requiring custom code modules unless there's no other way,

Thank you John! That's super helpful and appreciate the tips :)

John,

As you’ve mentioned to release an update to your amazing library, I was wondering whether you could also make a minor adjustment to the Hexgrid node. I’m using it fairly regularly, and I often change it to control both the horizontal and vertical spacing, which are currently linked together. Since you’re library is a Nodebox file which I keep open on the background to keep all these tools at hand, it would be great if you could update the Hexgrid node in this way.

Floris

Floris,

I've had the same experience using the hexgrid node. Its uses go way beyond hexagrams and yes, horizontal and vertical spacing need to be decoupled.

Would you suggest replacing radius with cell width and cell height? Or adding a vertical stretching factor to radius (100 = normal hexagon cells, less than 100 = skinny hexagons, greater than 100 = fat hexagons)? And do we need a skewing factor as well? In other words, maybe in addition to horizontal and vertical spacing we also need an alternating row offset to skew every other row to the left or right.

Maybe I should also change the name from hexgrid to something more generic. Hexagon grids are really just triangle grids (with alternating triangles flipped to form a tessellation). Is it even useful to think of these grids in terms of tessellations? What would be a better name for this node?

What do you think?

John

John,

Good to hear you feel the same regarding the decoupling of horizontal and vertical spacing. I would just replace the radius with two values that can be changed (see attached example). That’s what you mean with cell width and height, right? I have a preference for more absolute values instead of relative. I’m having trouble to imagine what a skewing factor would add. Could you expand on this?

We’re getting in terminology territory here, but I guess, it would not be a hexagonal grid anymore. When I want the impression of a isometric perspective I need a 30 degree angle of the diagonal points. But I usually do the alignment by eye. But it could be useful to determine this more exact. I would consider this an alternating grid (because every row alternates between different starting points) or maybe a diagonal, rhombus or diamond grid. Would these be more suitable?

Floris

Floris,

Just a quick note to let you know I'm thinking about this. I would like to create a new node, alt_grid, with even more flexibility than this. I am examining some common tessellations (some with more than one shape) to see what else might be helpful.

Stand by!

John

Floris,

I am making good progress on my alt_grid node and will post it soon in a separate thread. Stay tuned!

Meanwhile, I will respond to the note about categorizing library nodes you left in the Typography chat:

Posted by florisdejonge on Feb 19, 2022 @ 04:38 AM

John,

Thanks for expanding on your use of the translate node. I’m gonna work the kern_plot node into my add text node. I want to add a switch to be able to change the fonts easily.

In regard to categorizing your library, do we need to continue that conversation in this thread? I haven’t looked much under the hood of Nodebox. If you mention the properties of a subnetwork, are you referring to the metadata? I saw that under settings there’s a mention of an image. Changing the image is probably part of the installation and so it isn’t something that can be changed, correct?

Currently the library is one file and I think I would keep it that way, as long it’s possible taking performance into account. A master network file sounds a bit like the adding of a new node function though. So it could be more user friendly.

Is it possible to add green nodes to every column of subnodes of the current library? These could contain tags (instead of categories - which bypasses the fuzziness problem) corresponding with the categories of the ‘new node’ panel. Maybe you could add these same tags to the overview/example table. That might be a nice way to check whether a categorization in a main file would be feasible.

In addition, right now the overview/example table has an alphabetical ordering for the whole, while the nodes have not. When these two would correspond it makes finding specific nodes easier. The combine nodes of the examples could also be renamed to correspond to the tags for quick reference. These improvements are quite small, but might add to the usability of the library.

The 2.3 library file is usually available under ‘open recent’. I do have a folder in which I keep generic subnetworks in separate files I regularly use for plotting (like for adding text, paper size, and different fill patterns - if anyone's interested, let me know). I hadn’t considered putting these in one file yet. That might be useful, although the pattern nodes (which uses the mask node) can be terribly slow.

So, these are my thoughts on categorizing the nodes of the library. Hopefully this helps developing another release. I’ll get back on the generative typography.

Floris

(My response follows...)

Floris,

Good questions and suggestions...

Re image. Yes, this is a reference to the little PNGs Nodebox uses to put icons in the left part of each node. These PNGs reside inside the installed NodeBox app. On the Mac you can see them by control clicking the app, choosing "Show Package Contents", and burrowing down to Contents/app/resources/libraries/(node category)/(node).png.

I've never tried this, but in theory I suppose you could try replacing these PNGs files to change the icons. But I do NOT recommend mucking about with app internals like this. These PNGs have to be in a special format, so it would be easy to break things. And it wouldn't help with this situation anyway.

It would be possible to add little green tag nodes atop each column or clump of nodes in the library. Might be worth doing. Currently I clump them by output type.

I could place the green tags in a single alphabetical column with matching library nodes placed to the right of each tag. You could then scan down the green tags in order and scan across the library nodes. In order to work well you would not want more than about a dozen or so nodes for a given tag (to avoid massive horizontal scrolling or panning across multiple rows for a single tag). So the tags would have to be fairly focused. But you would not want TOO many tags to avoid endless vertical scrolling. And you want to avoid a giant "Miscellaneous" bucket.

The downsides are that this would A) require a lot more space and thus more scrolling and panning, and B) require multiple copies of any nodes belonging to more than one tag. Some of my nodes are fairly beefy, and the overall library NDBX file already weighs in at over 17 megs, making it slower to open each time. Having redundant copies of the nodes also complicates management if I every have to upgrade any of them.

It also raises the much thornier question of just what those tags would be. If you want to propose a spreadsheet of tags for the current hundred nodes, I would certainly consider using them. But I think if you tried that you would quickly discover just how hard it is to come up with good tags.

I'm afraid tags really only work well when you can search or filter or sort with them. Sadly we can do none of these things from inside the Nodebox design-time environment. And I fear the large file size and spatial arrangement would do more harm than good.

As for ordering, It's not entirely true that the library nodes are not in alphabetical order. Each column or column group is in alphabetical order. The tree of demo nodes is also in alphabetical order.

I could arrange the library nodes in a single tabular arrangement matching the overview table. I did try this once. But the table is so big now that I found it a tad cumbersome to scan and hunt for nodes that way. I find it faster to first pick a column based on node type and then scan that much shorter column group. With much practice I can find my most often used nodes very quickly.

sigh. It's a hard problem with the limited tools we have.

I do agree that it's better to keep things in a single file if we can. One exception might be special topics that stand apart from main library and require multiple nodes at once designed to work together. The 3D modeling nodes I'm working on might be a candidate for a separate "package" like that. Your separate set of plotting nodes might be another good use case.

Feel free to push back on this if you have some more ideas.

John

Floris,

I thought more about your observation that the nodes in the demo tree are not in alphabetical order. Technically they are, but I named the nodes to start with "demo" and had to shorten the rest, muddling the names and making them harder to scan.

So for the next release of my library I have renamed all those nodes to the actual node name plus a trailing underscore. Now they are clearly in alphabetical order. This makes it much easier to find a node in the tree.

Thanks for the suggestion!

John

John

Thanks for expanding on the topic of increasing the usability of your node library. Apologies for the somewhat late reply. I had not occurred to me that the demos were in alphabetical order as well. Most of the time I just copy/paste the nodes I know and need from the library. But sometimes I use the demos as a reference or to see whether any nodes provide a solution for some problem I run into.

And that is when things get a little difficult. Because where can I find the corresponding demo for the node that might be suitable? Usually this involves zooming in and out and panning to find the right one. This would improve when, as you say, the names don’t get muddled the added ‘demo’ text. But it might also be helpful if the ‘combine’ nodes provide some pointers to the kind of nodes I am looking at. Especially since the nodes are presented vertically and the demos horizontally (so this involves counting in which column or row I’m able to find a demo).

I’ve tried to do this in the screenshots below. This is just to give an idea, other labels might be more suitable. Please let me know whether this is a useful suggestion.

Floris

In addition. I keep forgetting to mention this: your 3D modeling nodes look absolutely insane (I mean this in a positive way). It’s incredible that this is possible in Nodebox. My question of course would be: is it plottable ;)

Floris,

Thanks for your excellent suggestions about the library UI.

Putting green category labels atop each category section is helpful and easy - consider it done.

Labeling the combine nodes is an interesting idea. The problem is that the demo nodes feeding into each combine node are not segregated by category. These nodes literally form the alphabetical periodic table style layout of the main poster, so are in that order. Each combine node gathers demos from different categories depending on where the node names happen to occur in the alphabet.

I suppose I COULD rearrange the nodes into the same category-based order then add some logic at the bottom to sort them back into the periodic table order.

But maybe it would be better to strike at the root of this problem and not have an alphabetical periodic table at all. It's compact, but is increasingly hard to scan (which is why I broke the actual nodes into category columns). So maybe I should make a new poster which resembles the category layout. It would be huge - probably requiring a 10K by 10K canvas, but would probably be easier to scan. And then we would have one layout for everything instead of two competing layouts.

Another root problem is that actually making the poster inside the library file requires a whole tree with dozens of combine nodes and wires all over the place. So maybe I should go a step farther and dispense with the actual construction of the poster itself.

I could do the construction of the poster in a separate Nodebox file and save the result as a PDF. So if you ever want to consult the poster you could simply open that PDF in a separate window. (Incidentally I can no longer save it as an SVG - it's too big! It's now so big that it gets an out of range error when I try to export it as an SVG.)

Once freed of the need to actually construct the poster, I could simply place all the demo nodes disconnected in exactly the same category-based layout as the nodes themselves. So you would have one block of nodes and, below it, another identical block of demos. I could even color each demo node to match the color of the node it was demoing. That should make it much easier to find the demo matching a given node.

(An even more radical step would be to have only one block of demo nodes. To get just the node itself you would have to open up the demo node and copy it from inside. But that would add an extra step each time you copy paste a node from the library, so I think that's going too far.)

One drawback of this approach would be that it would complicate my own maintenance of the library. I would have to maintain two separate files, the library and the poster. Every time I added or changed a node to the library I would have to carefully make the same change to the poster in that separate file. But I might be willing to do that extra work for the cause of better usability.

(Of course I could give up on the poster altogether. But I like having it and I think it's a genuinely useful reference for users. It's also be useful for me in making sure I haven't accidentally left out a node or got one in the wrong place.)

So the proposal is:

• one block of nodes in category columns with green labels atop each column
• a second block of demo nodes below that arranged in exactly the same way
• a poster showing the same category layout as a separate PDF file

What do you think?

John

P.S. Re the 3D modeling nodes. Thanks. I am also excited by that and eager to get back to working on it after I get all this library stuff straightened out. And yes, it should be plottable - sort of.

At least a given shape should be plottable because I currently calculate which faces are occluded and don't even try to draw those faces. However, when there are multiple objects I simply draw them in order from back to front, so that part would not be plotter friendly. But if need be, you could probably use the occlude node and/or some additional logic to sort that out.

Another issue would be that I currently just fill each face with a color. To make this plottable you would have to replace those fills with line shadings or something equivalent. this may require some cleverness to handle different levels of brightness, but in theory it should be possible.

But one step at a time. I am now determined to get library 2.4 straightened out first. Then get a basic 3D modeling kit out (which still has a ways to go - I've already had to rewrite it from scratch several times). THEN we can see about making some or all of it plottable!

John,

Your proposal sounds really good. A rendering of the poster is in my opinion not necessary within the library file (I for one never render it within Nodebox). I agree with you that the poster is useful as a reference. But it also communicates in a clear way what your library can do. This could also be, as you say, very well achieved with a separately rendered pdf. So, as far as I’m concerned, the library could just consist of the nodes and the demos.

I understand the drawback of maintaining two files: one of the library and one for the poster. Of course it’s more elegant to render everything within Nodebox, but perhaps it’s also possible to render demos from the library file separately and compile the poster in Illustrator or Inkscape? I can’t really judge whether that solution would be extra work (I am willing to help out), but that way you can keep a single file up to date.

Please don’t feel pressured to finish your 3d modelling kit. For now I’m intrigued by your experiments and would be excited if you’re willing to share it whenever you feel like it.

Floris