End Point is then Start Point and so on.

EDIT: Just found the "CURVES!" post. I think this will get me unstuck. But if there is another way to go about the method below feel free to let me know! So I will leave the original here. Essentially, I'm trying to draw designs that are visually a single line (and when I do some versions with layers, etc, it will cross over and under itself) - I am just assuming using the start and end points for all the places where a line and arc or line and line meet as variables to share those between them was the best way to 'parameterize' the design itself along with some applied symmetrical stuff so they are similar in however many directions around origin.

So I've read most of what I thought would be the related documentation on the site and pretty thoroughly scanned over majority of the rest especially the node references (which by the way, only shows me a white box with a black border about 20x20 px at the top and the parameters which only say the same thing the do in the software - don't know if that's something to look into. Shows this for all node reference pages.)

With what I'm doing, I can connect any arbitrary lines at their start and end points (though I'm sure there is a much better or best practice vs what I'm doing) - however, currently, I'm stuck trying to connect from the end or start point of a line to the end or start point of an arc. I first just tried adding some ports. But I'm assuming I need to do something like a mapping to create a link between the end parameter in degrees to coordinates right? I've attached a rough diagram I made in paint but also a finished example of what I am aiming to accomplish. Ideally to make my design process less tedious. (Mainly to create precise designs the are rotated, translated correctly, etc and connected at the shared points using the pattern in the title.

By the way, thanks, I can't believe I had yet to find this program for a decade or more - it's the missing piece. What I've not gotten out of any other program. Probably tried close to a hundred; yes even stuff from Github.

Sorry if this is a duplicate post. I can't find the original. Tried searching, Account page says 0 discussions created and 1 replied but "1 replied" isn't a link like the stats before and after it. So idk. Haven't posted any replies yet though.

Edgeofinnerspace,

Again, my apologies. As I said in my response to your note in General Discussion, your original posts were misclassified as spam, so that's why they didn't immediately appear in the forum.

Your comments about the limited Nodebox documentation are, sadly, correct, It's pretty minimal. Fortunately this forum provides a wealth of questions and answers and I enjoy helping Nodebox newbies.

Joining paths together in Nodebox is, in one way, quite simple: just feed them into a combine node - this will draw them together. The problem, though, is that they remain as separate paths. You can group them, but what you really want to do is join them together into a single path.

This is also fairly simple (but not as obvious). To join two paths together, convert them into their constituent points by feeding them both into point nodes. Then combine the output of those two point nodes with a combine node. Then feed that into a connect node. Voila! The points are now joined into a single path.

I do this so often that I made a join node in my Cartan Node Library available here:

https://forum.nodebox.net/t/2160535262/cartan-library-3-1

The join node is actually a subnetwork. You can peer inside it to see how it works by selecting it, control-clicking it, and choosing "Edit Children". Search for subnetwork in the forum to see many conversations about the joys of subnetworks.

When you are making designs like the one in your example, with line segments cleanly joined to arcs, you will need to do a little more work. You will want your arc to begin at the exact end of the line segment (or vice versa). There are a few tricks that make this easier.

See attached screenshot and demo.

This demo is a general purpose line-to-arc maker. Enter line angle, line length, arc radius, and arc length (in degrees) at the top; a single joined path will appear at the bottom. This should work for any combination of settings.

The path starts from the origin, but you can move it anywhere by either entering a different start position in the line_angle2 node at the top, or using a translate node at the bottom.

As you can see by examining the demo, I do this by finding the end point of the line, the start point of the arc, and then moving the arc into place using a translate node and the handy rel_change node from my library.

You can use a similar technique to string together any number of line segments and arcs.

Another trick is that I take the value for line angle, subtract 90, and feed that into the start angle for the arc. This ensures that they join neatly. But if you want your arc to join at a different angle, just adjust that arc start angle accordingly.

This should be enough to get you fully unstuck. Please write back and let me know that you saw this note and let me know if you have additional questions. Whenever someone gets lost in the spam folder I worry that they give up and never return.

I appreciate your final comment. I had the same reaction when I first stumbled onto Nodebox about 8 years ago. As far as I know there's nothing else out there quite like it, and with a little practice you can get it to do anything you want.

Welcome to the Nodebox community!

John

So I was trying to get your library integrated; I can open it in NodeBox fine. But when I try to copy a node from this window into mine, nothing appears after I paste it. Though, strangely, under undo it does say "undo paste node". Yet still I see nothing.

This is (regarding your response) at the moment still over my head (and I've had about ten or more traumatic brain injuries - so this stuff may remain top shelf; will only know when I get there or not). I see now that I have mistook your "Curves!" post the wrong way. Or misread it. Do you have a node that works the same as that for Arcs? with start and end parameters?

What I am really trying to do I guess is have a way to adjust parameters that I can use for ideas for another design... I currently do them all line by line in whatever graphics program I think is working best at the time. (And all fail for my needs so far - I think nodebox will be what I need.) Nothing on Android, web, or windows meets my needs. Doing them by hand I really only need a way to customize my snapping grid. But amazingly, nothing yet allows for it.

NodeBox appears it gets beyond that. As once I come up with the framework I'm working on here (the one in question currently) I can do whatever I need from it,

Regarding separate or unified paths: I don't think right now that I necessarily need them to be ONE path, just that they always start or end on the start or end points of the respective path before or after (line or arc). The rules I am using for the designs are fairly simple, constraining things like angles, having a smallest unit (as an example) that can be used as a shortest distance, steps outward from origin, minimum distance between parallel paths, etc. Things like that.

Right now, just struggling to understand the program because this will really open the doors I need to have opened (and also allowing my work to not rely on shortcomings of other software, or other dependencies and be self-contained, self-referencing, etc.) I just want to get the parameters of designing these pieces to always sync to the "anchor points". I'm thinking that the anchor points will be something I am mainly adjusting. The parameters of the start/end points and things like angles, steps, etc will change based on that. But I can also adjust those if needed and still have everything else stay synced. ....Atleast is what I imagine. I've attached examples of more of my stuff to give you a better idea. Thanks for the help! When I get rich, I'll make sure you've been thoroughly compensated for the huge amount of work you do and have done for free then hire you to help me figure ore of these problems out! lol

on one of them, just ignore the red lines behind the main shape. It's embellishment.

And I keep forgetting (head injuries) to add: they don't necessarily need to be joined as a single path because I may end up in another program to tweak all the aesthetics of each design from there, until I learn nodebox better, so I may end up doing quite a lot still by hand. Right now, I am just going to use this to get the idea for the designs.

The smallest unit for example in the "knot" with the red lines visible behind it:
near the center, where the line almost intersects but shifts to go the other direction, the shortest of those, if i remember right, is my smallest unit in this one.

What that means, for the rules, is basically all line lengths are multiples of that but also, all start and end points between a line turning at an angle or an arc or meeting the arc smoothly/head-on are steps/multiples of that same unit from the center point and fall on a line (invisible) from the center point at either 30 degrees or a multiple of that. Probably more like 60 degrees, 30 when I get really frisky.

Those are the rules I aim for - or some of them - but with nodebox I hope I can ensure that those are some of those rules and they are adhered to. Because this is what I waste alot of time on. The decisions when it comes to a rule. Neurological disorder too so get stuck for I don't know how needlessly many hours because of fixation when I could avoid it by enforcing certain things. (That apparently I would never remember on my own.)

I have a hunch what might be causing you not to see a node after you copy paste it from my library...

After you hit paste, try zooming way out in the network pane. When you paste a node from another program it lands at a point based on its original location that may be far away from where the nodes in your program are located. When you zoom out, the pasted node will be a tiny speck, but look carefully - it's probably there somewhere lost in space.

This is a very silly problem with Nodebox that makes for a frustrating user experience. It happens to me all the time. It would be easy to fix, but unfortunately Nodebox's creator is no longer regularly maintaining the code, so we have to work with what we've got.

I like your designs. It looks like most of them are symmetrical. If you are clever you can save yourself some work by forming part of the path and then using the copy node to rotate the other thirds or quadrants or whatever.

My curves node lets you create a Bézier curve from any start point to any end point. I do have something similar for arcs called find_arc.

Find_arc works quite differently than the standard arc node. You can give it start and stop points and then click the Inward checkbox on or off and change the offset value to get the arc you want. You can see the actual center point and radius as you adjust your arc by turning on the Show Marks checkbox; be sure to check that off before using your arc.

If I get a chance I might make a new node for you that would automatically join a list of segments and arcs together end to end without you having to identify each start and end point. This would just involve using the technique I showed you in the demo and making it general purpose for any number of segments.

I think you find that Nodebox takes a little getting used to, so don't be surprised if you find things a bit puzzling at first. Be patient, stick with it, and don't be afraid to ask for help when you get stuck!

John

Thanks again.

Yes, all these designs in particular will be symmetrical three ways. For a collection I call KryptoNaughts.

The curves in any given design are always a part of a circle and if they do not end in an abrupt change of direction, they will always meet a line at the one of the same lines of symmetry (from the center point of the arc's circle) as the overall piece or half of that. If that makes sense. So the underlying symmetry of the pieces I guess is hexagonal. But there will never be any ambiguity for that part of a curve

Also, what I'm struggling with, that also is a big part of why I can't code.... is for example, when I tried to copy a design I'm using to try and figure nodebox out at the moment, at the combine node, I have inserted a copy node. And in my logic, this is where things all seem backwards. I've read the "How NodeBox Works" page and I can understand that or so I thought... But if I want to copy that shaped plugged into the combine node... what then plugs into the copy node?! There is no port for geometry.... Based on the assembly line concept this node doesn't seem to apply. And that's true for code in general for me (it seems to work backwards from what I read and understand and then come to try to apply) as well as many of the nodes so far.

I'm not sure why but some of this got chopped off or something. MS :Paint is really weird at times. This is to better explain what I meant. An arc will meet a line at a tangent I guess is the more correct way of saying it. Or at an abrut turn but nothing in between or less than a 60 degree turn. (inward).

Also, copying your find_arc then trying to paste that into the window with my nodes only pastes the last node copied in my window again.

You said I could plug line nodes into point nodes which seems backward to me so I did not know was possible. So I tried this just to see.

Several questions in your recent notes. My responses:

Copy pasting from library to your app should work. Other Nodebox users, on both PCs and Macs, have been able to do this without difficulty. Keep trying. If still having trouble try exiting and rebooting Nodebox and try again. If still having trouble try to gather more clues about what's going on (e.g. try copy pasting in other apps, etc. to see if this is a Nodebox problem or a problem with your OS). This should work.

Yes, feeding a path into a point node does seem a little backward - it didn't occur to me at first that I could do this. But it is the standard way of turning a path into a list of its points.

In Nodebox, arcs (and curves in general) are actually made out of quadratic Bézier curves. Each such curve has 4 points, a start point, two control points, and an end point. An arc of 90 degrees or less is composed of one such curve; longer arcs may require additional curves.

So yes, if you feed a short arc into a point node you will see four points. You can see the numeric values of these points by switching from Viewer to Data in the upper left of the display pane. If you check the Points box while displaying an arc you can see these points - the start and end points in blue and the control points in red.

As for your earlier comments about how you structure your symmetrical drawings: yes, I understand. In theory, you could take advantage of these constraints to further automate your drawings with simplified parameters. In practice, though, your drawings are complex enough that it may be simpler just to make each segment with standard nodes and then combine them, using a subnetwork to automate the joins from end point of one to the start point of the next. I may make such a subnetwork for you to show you what I mean.

John

Thanks. So I tried recreating one of the first pictures I posted. I got it for the most part. but there are some values I can't seem to figure out how to parameterize...

For instance, the highlighted line in the picture attached. I think I should solve it as a hypotenuse but I've tried several equations with no luck. the X vaues for the horizontal side of the triangle are -68.30 and 50. Yet 118.30/sin(60) produces a line going into the opposite direction from 'position' at (50.0, 50.0) and -118.30/sin(60) gets really close but is still not right. Though the real issue is that when generating designs, if I were using this one as a template, is that at this point only one third of the design, technically, is rendered/has yet to be copied so I don't know of where else I could derive that value ahead of time from the original third of the design. I'm getting the horizontal side of this triangle now from the copy of the same line that I'm actually trying to get the length of (when it is copied, rotated, and is then the vertical line with X at -68.30...

118.3 / sin(60) does get you 136.6 - which is the hypotenuse you seek. See attached screenshot.

The triangle diagram was made using my handy triangle node. Note that the Nodebox sin function takes values in radians, so you have to use the radians node to convert 60 degrees before feeding it into the sin node.

There are many ways of finding critical points, angles, and lengths in situations like this; you just have to be careful and constantly do reality checks to make sure you are getting the right values. I constantly plot them as I go as a double check. For example I will draw the triangle, calculate my point, and also draw a small ellipse at that point to make sure it landed where it should have.

An alternative to using equations for everything is to draw a base shape and take your measurements from that. You can isolate points from it then feed them into angle or distance node to find those values. You can isolate line segments from the sides of polygons then use point_on_path (or my point_in_path) to find a point one third of the way along an edge. You can draw two lines from points in your base shape and find their intersection using my intrsct_line and intersect_circle nodes. And so forth. Values obtained using these techniques are almost identical to the ones you would get through pure equations.

I've been thinking more about the best way to do your designs in Nodebox. I did modify my join node so that it can automatically place line segments and arcs end-to-end. This simplifies things, but you still need to know the exact angles and distances for all your line segments. The angles are easy since everything in your designs is a multiple of 30 degrees. But finding the distances is hard and requires a grid.

I went ahead and recreated one of your designs to show you one way of doing it. I will write a post about that next.

John

Attached is an example showing one way of making one of your designs in Nodebox.

The basic idea is to simply combine a bunch of line and arc nodes, join then using my newly improved join node with the "end-to-end" box checked, then feed that into a copy node to rotate the path 3 times.

Each line node needs an angle and a distance. The angles are easy; they are all multiples of 30 degrees and you can see the value just by looking at a sketch of the design.

But the distances are hard. They have to be exact; getting the first wrong even by a tiny amount throws off all the segments after it, getting the second one wrong increases the damage, etc. I tried eyeballing the distances to see if I could keep adjusting my way to success, but that proved hopeless.

So you either have to use equations to calculate each distance (as you were trying with your triangle design) or create a precise grid that you can use to manually size each segment. For this example I choose the later approach.

See screenshot one. If you render the combine4 node at the bottom left you will see a multicolored grid against a black background with the first third of your design in white. If you leave this display rendered, you can then go to each line_angle node at the top at adjust that segment until it hits the correct grid line.

So first set up all 15 segments of your design with the correct angles and join them to feed into the grid display. Then adjust the length of each line segment until the path is complete. Then render the combine5 node at the bottom right to see the final design after its been rotated and colored (see screenshot two). Voila!

This technique depends on defining a grid to measure against. The grid for this design is simply a series of nested hexagons with lines extending from each side. I made a subnetwork that produces one such hexagon for each radius you feed it. I noticed that this design only needs 10 hexagons to measure all the segments, and that all radii were multiples of 7. So I just created a list of those 10 radii using a make_numbers node, multiplied them by 7 (which serves as the sizing factor), fed that into my hex_grid subnetwork, and colored the radiating lines using my color node.

One final subtlety is that in order to get the symmetry right you need to start your one-third path from a corner of a small triangle centered at the origin. This triangle needs to be inscribed into the smallest hexagon of the grid. So I made another subnetwork that takes the base size of the grid (in this case 7) and uses that to draw that small triangle and use its first point at the starting point of the first line segment.

Once you have figured out your grid and have a rough sketch of your design you can generate a finished design fairly quickly. Of course the grid and other details like the starting point will be different for each project, so that will take some thought and setup time. Since you are eyeballing the segment lengths instead of calculating their exact values, your design won't be perfect, but since Nodebox lets you zoom way in you can get these values indistinguishably close to perfection quite quickly.

Alternatively, you could calculate each segment length precisely by isolating the correct gridline and using my intrsct_line node to find the exact point (and thus the exact distance) where that segment crosses the gridline. You can parameterize this by making a subnetwork for each segment that would take two gridlines to define a starting point, an angle, and a third gridline to calculate the distance; the subnetwork would then return that line segment. You would need some way to identify each grid line, but this should be doable with a little thought.

The bottom line is that your designs are definitely doable in Nodebox. I don't think you could ever make them effortless; the designs are too intricate and unique for that. A certain amount of work is unavoidable. But Nodebox makes it easy to check your work as you go and try variations.

Hope that helps! I look forward to seeing more of your designs in the Nodebox forum.

John

Edgeofinnerspace,

Still there? I am curious to hear if you were able to try the approach I described in my previous note. I'd be happy to continue this conversation if you want.

John

I'm here. Just really bad at social media. Trying to keep up with everything you say. I tried something new today though. I haven't refined it. So all this stuff still needs to be put into cleaner subnetworks and such.

It's all over the place, I know. But the top left node is a modified version of your altGrid.

Also, curious about this post. Is there a way yet, to share the values of variables? And about the reply from the guy mentioning the bounds.height, etc, stuff. Are these documented somewhere?

https://forum.nodebox.net/t/14772154/property-nodes

It just makes it so hard to believe so much time went into this software if someone who could put it to good use like myself can't even find the first explanation when searching online or any thorough documentation out there. Leaves me with so many questions I can't even use this forum effectively because I can't keep up with them all.

Are those calls he mentioned some kind of standard python? Or is there any way to see the 'code' that this program is writing that underlies a project? etc. Mainly interested in variables without a bunch of string all over the place though.

here is an update but it looks like one of my comments didnt post.

oh nice. i see your other post now too. i think the page was being slow to load all the comments earlier. by the way when i say modified alt_grid, its basically the same except where one cell height or width is X then the other is the length from the centerpoint to the midpoint of the hexagon of which X is the side.

I didn't really know how to best implement it though. (was thinking > from 'last' point, decide length and define 'turn' in terms of which of the 6 grid points would be the vertices of the hexagon - 'last' point being the center.)

i think it is now under 'oldapproach subnetwork' at the top left in 'hexgrid3.ndbx'

the way im getting the length now is easy enough to see in this one. im getting some strange but 'playful' results in the bottom 'arcKnotLine' subnetwork. play with its parameters and the lines before it and you'll see.

i think the way i took is a very remedial approach but its easiest for me to revisit the next day and decode everything i've forgotten. concussions are no joke. i have to relearn things on a day to day basis. so this should be color by number for you. i think this method could make for some interesting and easy to do animations of finished pieces too.change all the integer parameters to floats though.

You are making excellent progress!

Your lens2grid node can be done in a much simpler way. All you need to do is use the alt_grid node and set cell width to sin(radians(60)) * cell height. This creates a standard isometric grid, which is what all of your art seems to be based on.

This is a clever idea. It makes me wonder if I should make that easier for people to do by adding an isometric option to my alt_grid node, or let them enter angle instead of width. I will think about it.

With that isometric grid in place, you can express your line segments as grid offsets. Each segment subnetwork would just take one of 6 angles (North, Northeast, Southeast, South, Southwest, or Southeast) and a length measured in dots (1 dot away, 2 dots away, etc.).

This is essentially what you are doing in your updated version. You could simplify further by using my improved join node with the end-to-end option to manage all the start and end coordinates automatically. You could also just hardcode your unit lengths and use a scale node at the end to adjust the overall size.

This would be a combination of our two approaches. To make a design you would just set a starting point (expressed as an isometric grid point number as you do now), combine a bunch of segment and arc subnetworks (each taking one of 6 turn angles and a distance expressed in dots), join them using my join node, then just scale and color.

To make this even easier, you could print out isometric graph paper and sketch your designs on that. Then just enter the turn angle and dot distance for each segment!

So keep at it. I think you're heading in the right direction.

I will answer your other comment separately...

Regarding your reaction to the question I posted eight years ago when I was a newbie...

No, bounds.width and height are not documented anywhere, and I agree this is a major hole in the documentation, one of many.

I also share your frustration that the enormous power and potential of Nodebox is bottled up and hidden by the scant documentation, minor UI glitches, etc. This is one of the sad realities of open source software. Nodebox was developed by a tiny team of researchers at an art college, so they were underfunded from the outset. And then the research institute hit a financial iceberg and the team was scattered, leaving no one to make improvements and only me to keep the lights on at the forum. I do this as a labor of love to keep Nodebox alive. Maybe someday it will get new funding and achieve the notoriety it deserves.

You asked about ways to find out more of these hidden secrets and about the code beneath Nodebox...

One way of finding secrets is by using the keys node. Attach keys to any other node and it will list the hidden properties of the object output by that node. You can then do a lookup on those property names. This is one way of discovering the bounds property I was asking about. You can also attach a keys node to that lookup to determine subproperties and look those up directly using dot notation (e.g. bounds.width).

The code itself is also freely available (one of the advantages of open source software). Nodebox is built on Jython, a Java-based version of Python, which is itself build on Java. You can find all the code in this GitHub link:

https://github.com/nodebox/nodebox

Even if you are a Java or Python developer familiar with Github, it is not easy finding your way though the code. To understand it you need to figure out how the founders organized it all. I have gleaned a few insights from pawing through the Github code, but it was mostly over my head.

In theory, an experienced developer willing to devote years to this project and work for free could fork the code and start filling potholes and keeping Nodebox current - but I have yet to see any volunteers. It would also be possible for a talented tech writer to add more documentation, but this would be a ton of work for a small audience and, again, no money. This conundrum is all too common among open source projects.

I have chosen to put my spare time into developing my library, which is a way of extending and improving Nodebox without forking the code. I also answer forum questions in detail and document my own work there as well. So the forum has become Nodebox's best form of documentation, but I agree that it is hard to search and not a true replacement.

You said these designs of yours could make for interesting animations. I agree!

As a generative artist I regularly use Nodebox to create animations. As part of that work I took the liberty of animating the example I sent to you earlier showing how to make one of your designs using my proposed grid system. When I posted this on Instagram I emphasized that I was just helping you and that the design was yours - I even added a signature for you.

Animation attached.

Let me know what you think. It is quite easy to create animations like this. I think you should consider animating all your designs!

John

Hey John,

I've been mostly a hobby user of nodebox but I love it's procedural nature, I'm also a houdini user and I often think of nodebox as the 2D Houdini. Maybe reach out to SideFX Software the makers of Houdini and see if they have any interest in the code/project?

Also another suggestion might be to try running the code through Chat GPT and asking the AI to write user documentation based on the code? Just a thought.

Best,
Bill

thi9s guy's got the right idea. chatGPT could do that actually

kurtzwrk, edgeofinnerspace,

Interesting idea! I started a separate thread to discuss it here:

https://forum.nodebox.net/t/2804112772/using-chatgpt-to-document-nodebox

John

Edgeofinnerspace,

Hope you are still there...

On further though I realized that what you REALLY need is an isometric drawing system. So I made one. You can make drawings fairly quickly be simply snapping together copies of the same three nodes.

Documentation and demo here:

https://forum.nodebox.net/t/2804121272/isometric-drawing-paper

Give it a try!

John