Hi,
I make an contour brep
Everything is fine
but when I try to bake all but a couple of them appear,
does anyone know why this is due?
WORK 03.gh (53.5 KB)
WORK 03.3dm (9.3 MB)
WORK 03.gh (53.5 KB)
WORK 03.3dm (9.3 MB)
Very long delay in opening your GH file - and I haven’t opened your Rhino file yet so fear there might be another long delay when I do? Two SDiff components at the end, almost 50 seconds each. No change when I open the Rhino file because your brep is internalized in the GH file - so why post the Rhino file?
I see a DeBrep ‘E’ (Edges) output treated as a number - peculiar way to get curve length but it works.
Unexpected use of CrossRef, don’t know if that gets what you expect?
Looks like the ‘B’ inputs to both SDiff components are the same thickness as the ‘A’ inputs when they could (should?) be a little thicker? Might be solved by changing unit tolerance.
Flattening both inputs to SDiff is likely slower than matching smaller lists of geometry.
1 Like
My time was limited earlier but I just made one of the changes I recommended and it appears to work?
I added the two purple groups to scale the “cutter” boxes slightly in either X or Y, as appropriate, to make sure that intersections are distinct. My unit tolerance is 0.01,
WORK 03_2023Sep26a.gh (57.0 KB)
2 Likes
Good afternoon.
I was analyzing your recommendations, observing the points of view, but I think that the attempted solution is represented based on the size of the trimmed geometries.
Actually my main problem is that the pieces can’t bake.
When reviewing the “B” inputs, identify that:
The X direction represents all boundary representations
But in the Y direction a couple of Invalid Brep appear,
which are precisely the 2 pieces that cannot be baked.
I manage to think that it is an issue of the configuration of the parameters but I cannot understand how 26 elements can be baked and 2 specific ones are exempt from and this only happens in one direction.
I was thinking that there should be a way to divide this brep individually into 28 params, to be able to give it an extra definition or box and thus be able to generate the required baking through an extra definition.
I really appreciate your time invested
It looked to me like obviously missing parts in your Rhino file baked fine with my code. There are quite a few small fragments that should be filtered out because they are too small and deformed to be valid. But the big pieces all look OK to me. Can you identify by number which parts are missing for you?
P.S. The images you just posted above appear to not be using the code I added? (2 purple groups)
There are no open or invalid breps coming from the two SDiff components in my code.
WORK 03_2023Sep26aa.gh (71.1 KB)
1 Like
When I open the file you gave me it appears like this,
with an invalid brep and when I hit it to bake everything is baked except this piece.
This piece number 20 is the one that does not appear
I would love to tell you the piece but it is not seen in the hologram.
Could be a tolerance issue. You may want to try changing it in your rhino file
1 Like
I mentioned that in my first two posts:
In Rhino, ‘View | Display Options… | Units | Absolute Tolerance’
1 Like
Unfortunately I had already reviewed that so I didn’t comment on it and well apparently that is not the fault.
So it works for me but not for you… 
Something must be different. Are you on a Mac? R7?
From your image, it looks like the code has changed?
I’m on Windows. Rhino 7
From what I see everything is the same,
By logic it should already be the same as yours.
because I’m literally using the same file
I think the problem is solved
just something is wrong with my software
Hey @spitsfire8172, I doubt something is wrong with your software - it’s just intersection insanity. I deal with waffles daily, they are a pain in the brain, and there are countless issues always with more pieces/complexity 
Check this workaround/cheat.:
WORK 03.gh (67.0 KB)
No baking invalidities:
Note 1:
Everything is fast until you connect this to start slicing and dicing:
The file I worked on was your original .3dm, so I have not changed anything in terms of tolerance.
Note 2:
You will realize I delay the use of solids as much as possible until it is ‘necessary’, which is basically just for visual purposes as I assume you’ll be cutting these in the real world and for that matter you’ll need vectors not solids.
A lot of times I even skip surfaces/solids, because they slow everything down - so I stick to planar regions.
Good luck
2 Likes
Very strange. I did not examine all of your code, only the inputs to SDiff, so maybe the problem is somewhere else? The long compute time discourages trying different things…
Reviewing it now, I don’t like treating curves as numbers to get their length. Later, you are treating brep faces (surfaces) as numbers to get their area, which I don’t like either.
I see no reason for the CrossRef since BBX alone gives the same result if the ‘A’ input is grafted. Actually, while the geometry is the same, the data trees are different and perhaps more useful!
Later - I started some major surgery on this code but don’t know yet if it will be useful… 
SDiff is much faster than before - only 5 or 6 seconds each (before moving the cutters). Looking now at how the cutters are moved up and down?
OK, I’m done for tonight. I don’t thoroughly understand this code, which may sound foolish, considering that I made substantial alterations. I see one ‘Open Brep’ now, where I saw none before.
It is WAY FASTER now; SDiff components are only 4.4s and 3.3s. Bedtime for me. 
WORK 03_2023Sep27a.gh (67.4 KB)
1 Like
I almost forgot that I’ve done some “waffle” intersection stuff before, notably here:
And later in the same thread, version Waffling_Troubles_2019Nov24c.gh, where I did this:
cutting the slots BEFORE extruding the contour surfaces, thus avoiding the painfully long SDiff (two of them, ~1 minute each!) .
Food for thought? To be continued…
1 Like
This is the same code I posted last night with minimal cleanup. I examined the single 'Open Brep/ and find that it’s an artifact of cutter position, which still needs work IMHO. I can see other anomalies related to the same issue that might go away with a different algorithm.
WORK 03_2023Sep28a.gh (71.9 KB)
1 Like
The only significant change in this version is how the cutters are moved. Instead of using the area of one face (a weird choice), it now uses half the Z height of each cutter. Looks the same but I see no open or invalid breps. Still fast! 
WORK 03_2023Sep28b.gh (68.7 KB)
Does this work for you? The only additional refinement I can imagine would be to prevent the waffle sections from poking through the brep. Is that something you want? Ah, what the heck, I went ahead and did that by adding teal-colored groups to replace some bits. Clear the dream space 
WORK 03_2023Sep28c.gh (64.1 KB)
P.S. The expression “x-0.01” on the ‘D’ (Distance) input to Contour is mysterious? But I left it in both versions, though version ‘Sep28c’ uses DivLength instead of Contour.
3 Likes
I came back to it (for fun), mainly to run some speed comparisons as this definitely helps me.
WORK 03b.gh (80.6 KB)
I’ve added a second option/method - pick/connect one:
Still not using Solid Difference.
Sticking to Solid Trim.
Speed comparison:
A bit less than a second, ha!
A quick ‘bonus’ to revise ‘discrepant’ fragments:
Fun stuff, cheers + good luck!
1 Like
Hi. @René_Corella
I was checking your resolution.
- I find it interesting how you get the solution from the first definition I used, that is very useful at least for me to understand.
- I like using geometry only when necessary, in the first instance it seems like a valid point to not waste a lot of time, which I now notice is too important for many in software, I honestly thought there was no way to reduce this
- After several definitions I was able to completely bake my brep developed in Rhino, that seems excellent to me considering that I did not understand some definitions of the use of vectors, perhaps for less experienced users like me, it is still necessary to use the geometries as a visual support now Using vectors and points continuously and without volumes is a bit tedious at first.
Maybe you would be encouraged to do a tutorial on how to analyze these types of projects based on the use of vector forces without the geometric shape.
Thanks for the input.
1 Like
Hey @Joseph_Oster . I was checking that both in the code and in Rhino the definitions could be seen correctly.
In the same way, we began by completing the base definition and completed it with the non-graphic representation of the shape, using it only at the end. That is interesting
The detail comes when we are going to bake the representation
I find many inconsistencies
These come from the code because the trimmed geometries are represented but the cuts do not appear in the geometry, so it is not just an issue of baking but of the definition itself in my opinion.
Both senses
I will review the other solutions that you attached and suddenly the geometry that I developed makes it not work according to your definition.
Thanks @spitsfire8172 ,
'Glad I was able to pass on some stuff. Given how much I deal with eggcrate structures of this type (and many other types) I find it super interesting how every single project calls for a different solution/interpretation to get to the same type of fabrication style. The ‘advantage’ in your case is that you’re only dealing with two directions or orientations of the parts, as in parts facing X or Y. I typically have to fabricate waffles that are very complex, with many different orientations, tight angles, radiating, ‘floating’ parts, etc., or where the slices follow multiple organic curves. It is not uncommon in grasshopper to have to constantly check for (and adjust) the direction of lines or vectors, especially after ‘physical’ operations such as splitting or joining. Nonetheless, very interesting.
I learned a lot in the past from some ‘simple’ approaches, especially those by Satoru Sugihara shown here.
Cheers
1 Like