Floris.

Could you please attach a zipped file of your ndbx file so I can try this myself?

Thanks!

Floris,

Thanks. I can confirm that there appears to be a problem with the compound node.

The problem begins from the first occurrence with the compound2 node. You form 30 wavy stripes then simply do a union between the first and the rest. In 3.0.52 the result is a path with 30 contours as you would expect. But in 3.1.0 the exact same compound node creates a path with 169 contours.

To show this I attached another contours node to compound 2 and then sliced it to view the first 7 contours.

In 3.0.52 you can see the first 7 wavy stripes. But in 3.1.0 you see 5 normal stripes and then 2 fragments. I turned on the points so you could see the differing control points. It looks like stripe 6 somehow got cut in half along its equator so that the upper half of each wave breaks into separate contours. Of the remaining stripes, some remain intact, others break into fragments. See comparison screenshots (attached).

I have also attached the slightly modified version of Floris's original test file.

I've been using 3.1.0 on an almost daily basis and so far have not run into this or any other problem. I know from many years of experience, though, that the Nodebox compound node has always been fussy. It constantly creates what I call "dust", microscopic contours smaller than a single pixel. And very similar inputs often come out very differently, with contours in different orders, some going clockwise, some counterclockwise. I am constantly having to inspect and clean it.

Still, this shouldn't happen. After I get some more sleep, I will see if I can find a workaround.

Meanwhile, Frederik, are you there? Do you have any idea why this is happening?

Thanks for bringing this to our attention, Floris.

Update.

Several findings:

• The Nodebox compound node is based on the java.awt.geom.Area class. There have always been some issues associated with its add, subtract, intersect, and XOR functions caused by rounding errors and quirks with the way paths are reassembled. But none of this would seem to explain the problem Floris found. What he was doing was dirt simple: creating a union of 30 non-overlapping shapes. There is nothing particularly challenging about this particular use case.
• I thought about making a Python external module to replace compound, but this would require a special library. And Clojure imports its area functions from Java. So I don't think external modules would provide a workaround.
• I tried MANY different ways of modifying Floris's code to fix this problem - including fattening the curves, resampling the curves, reducing the number of curves, changing length or period or amplitude, translating the curves, using triangle waves instead of sine waves, combining the waves 2 at a time, changing the order of the compound operations, etc. NOTHING WORKED. Some changes caused random changes to where the compounding operation failed, but in each case the changes were arbitrary and limited. There was no rhyme or reason that I could see.
• I printed a poster of my current library with demos for over 200 nodes - some of which use the compound node - and found only one problem. The demo of my Hilbert curve node, which intersects the curve with a circle, was affected in 3.1.0. Instead of breaking the curve into one big path and 15 small edge paths, it broke it into 24 paths including several different large chunks. As a result my demo shows a semi-circular Hilbert curve instead of a full circle. I can fix the demo by plotting multiple segments, but this is now a confirmed issue. The good news is that the vast majority of my library emerged unscathed. The bad news is that any network with a compound node needs to be checked. I have nearly 500 art pieces; I am now worried that one or two of them may no longer render correctly.

The upshot is that I see no easy fix for this problem. From now on, whenever you use a compound node you need to doublecheck the output. And in some cases, effects that used to be fairly easy may now be impossible.

Frederik, I don't know if you are following any of this, but I would dearly love to hear your thoughts about how your relatively simple change could cause such a bizarre side effect. Does Nodebox 3.0.1 use a slightly different version of Java? Any ideas how we could fix this?

Frederik, All,

I asked the Google Gemini AI about this issue and it came up with a likely cause and several possible fixes:

https://share.google/aimode/77QbW6JGfBrZmhpfy

The fixes require a new release of Nodebox, so it's something only Frederik could do.

To help with diagnosis, I devised an extremely simple Nodebox network that causes this issue to occur (see screenshot and attached zip file). I take a very simple shape with no Bézier curves, make 20 copies, compound them into a single path, then stack the resulting contours. The 19th contour fragments into multiple pieces.

This does not happen in 3.0.52.

If an improved version of Nodebox can produce 20 clean contours, we will have solved this problem.

John

Thanks for pointing this out! And John thanks for the test network, that's very useful!

I'm Currently working on 3.2.0 that should be much faster; I'll make sure this is also rolled in as a fix.

Frederik,

You just made my day! I can't wait to see 3.2.0. And, as long as you have your sleeves rolled up, please consider this:

http://support.nodebox.net/discussions/general-discussion/15406-sim...

Thanks in advance,

John