Move complex geometries into Grid system with automatic addition

[Joseph_Oster]

@Joseph_Oster

So why go to the trouble of separating paths in single digits? Perhaps to ensure “kinks” at appropriate places from IntCrv. That makes sense to me.

But why add vertical lines in the font clusters at the start and end (entry and exit) of paths when those points can be easily derived later?

So I went to the trouble of implementing that strategy, removing font points that created vertical lines and using multiple paths (strokes) to make IntCrv work properly. Had to fix gaps in “0” and “8” by duplicating their start points because making IntCrv periodic isn’t appropriate here.

Only four digits are single path now: 0, 6, 8 and 9. PLine has been removed.

Caligraphy_2024Oct7b.gh (85.7 KB)

Way simpler and better in my opinion. Robot control software will need to enter and exit each path vertically - or not, when the next path starts where the the current path ends,

This finally addresses most of the issues that kept me away from working on this project.

[Joseph_Oster]

@Joseph_Oster

Robot control software will need to enter and exit each path vertically - or not, when the next path starts where the the current path ends.

Here is a visualization tool added to see two things:

1. the sequence of paths (white, green, blue)

2. start points to make sure “the next path starts where the the current path ends”

Based on what I saw, I had to fix both issues in cluster NR.5 (digit “5”).

Caligraphy_2024Oct7bb.gh (79.6 KB)

[e11 (Ekke)]

Joseph, I arranged the path (stroke) dynamic according to how a calligrapher would paint the number. The 7 needs to be broken up in two paths to get the corner sharp, the lag in the brush demands a clear entry and exit point. Once this is established, I can go and further manipulate the planes to these entry points, to get the brush “flow” into the stroke. I will test your scripts on the small ABB robot today and hope to send some pictures later.

[Joseph_Oster]

@e11

The 7 needs to be broken up in two paths to get the corner sharp, the lag in the brush demands a clear entry and exit point.

Might be a good idea to examine my code before you reply.

[e11 (Ekke)]

I am working on it as we speak!

[e11 (Ekke)]

Robot following point sequence without lifting :

Lifting line sequences at start, end is not resolved in some:

03.Oster_Calig_P_sequence.gh (89.5 KB)
Joseph, took me a while to get through all your code, I made a few adjustments to the grid direction (reads left to right, then down) and it now all works fine apart from the very last sequence, where I need to lift the brush when one number is finished to move it to the starting point of the next number, which hovers above the initial line sequence. As there is a mixture of line/ curves to each number, I could so far not figure how to determine the last point in some numbers. Once this is resolved, this should finally work!

[Joseph_Oster]

@e11

Robot following point sequence without lifting :

I never said it doesn’t need to be lifted What I said was lifting should not be part of the font definition (vertical lines at both ends of every path).

@e11

now all works fine

It all worked fine yesterday when I posted Caligraphy_2024Oct7bb.gh.

[Joseph_Oster]

@e11

As there is a mixture of line/ curves to each number, I could so far not figure how to determine the last point in some numbers. Once this is resolved, this should finally work!

Did you figure out how to do that? It really helps to understand data trees.

The teal (blue-green) group labeled “First / Last points” at the bottom right of this image places a green sphere at the first point and a red sphere at the last point of each digit. Those points are the same for “0” and “8”. Paths and points in between are sequential.

Caligraphy_2024Oct8a.gh (82.6 KB)

• Digits with one path: “0”, “6”, “8” and “9”
• Digits with two paths: “1”, “2” and “7”
• Digits with three paths: “3”, “4” and “5”

[Joseph_Oster]

@e11

Joseph, took me a while to get through all your code

Probably not as much time as I spent writing it? It’s unfortunate that you modified the grid instead of just adding robot code to what I wrote. I don’t have Pufferfish.

All orange components in this image are disabled because I don’t have Pufferfish Flip Plane when there is no need for it. GH has a standard PFlip.

Looks like you also replaced the R7-compatible Area component with the R8 version so R8 is required now.

[wim (Wim Dekeyser)]

Hi Joseph -

@Joseph_Oster

Looks like you also replaced the R7-compatible Area component with the R8 version so R8 is required now.

Which version of Rhino 7 are you running? This should work fine.
-wim

[Joseph_Oster]

@wim

Which version of Rhino 7 are you running? This should work fine.

Hello @wim,

My R7 is Rhino 7 SR36 2023-12-12 (Rhino 7, 7.36.23346.16351

I don’t understand your comment that “This should work fine.”? It has long been known that R8 Area has extra outputs added (hidden by default) that are not compatible with R7:

I replaced this with R7 Area on October 5th but the R8 version is back in the file @e11 posted yesterday (03.Oster_Calig_P_sequence.gh), making R8 required again.

My R8 is Rhino 8 SR12 2024-9-17 (Rhino 8, 8.12.24261.13001

[wim (Wim Dekeyser)]

Hi Joseph -

@Joseph_Oster

It has long been known that R8 Area has extra outputs added (hidden by default) that are not compatible with R7:

Yes, and that (amongst other issues) is why, after 4 weeks with service release candidates, 7.37 was released 5 months ago.
-wim

[Joseph_Oster]

@wim

Yes, and that (amongst other issues) is why, after 4 weeks with service release candidates, 7.37 was released 5 months ago.

I checked before I posted an hour ago and it said I was up to date, now i see this:

So will close R7, install the update and look again… Hmm, it doesn’t seem to work that way, how do I install this new version? Always an adventure…

[wim (Wim Dekeyser)]

Hi Joseph -

@Joseph_Oster

Hmm, it doesn’t seem to work that way, how do I install this new version?

You don’t have “Enable Updates and Usage Statistics” checked.
It does say that 7.37 is downloaded, though. That means that you should find a 7.37 exe file in one of the subdirectories in C:\ProgramData\McNeel\McNeelUpdate\DownloadCache.
-wim

[Joseph_Oster]

@wim

You don’t have “Enable Updates and Usage Statistics” checked.

I don’t want to participate in Usage Statistics.

@wim

It does say that 7.37 is downloaded, though. That means that you should find a 7.37 exe file in one of the subdirectories in C:\ProgramData\McNeel\McNeelUpdate\DownloadCache.

Way too much trouble Thanks anyway. Why is it so difficult

[wim (Wim Dekeyser)]

@Joseph_Oster

Why is it so difficult

@Joseph_Oster

I don’t want to participate in Usage Statistics.

I suppose we all make our choices and end up where we are…
-wim

[Joseph_Oster]

@wim

I suppose we all make our choices and end up where we are…

McNeel has made choices that make updates conditional and difficult.

[e11 (Ekke)]

Joseph, make no mistake, I have no doubts about how long you spent on this code, this code is, as we say in German, ein absolutes Brett.
You are also correct that I have to work on my data tree skills, I am well aware of it, but bare in mind that I am a professor for sculpture and not robotics, I have never worked in any code until 2020, so given the time available to me, I have actually come a long way.

Now, the robot doesn’t accept the data structure I give him, the start, curve and end points follow first branch in all data trees.(start point, first branch of each digit, then it moves to end point, from there to start again (same with if I only use the start and digit (as in number) data tree. So the 0, 6, 8 and 9 work… ) I think I need to split the group again into sub groups ( perhaps again 0 to 9) or into how many paths they have ( as you eluded to above).

I have to say that this is gradually getting well beyond my pay grade, skill wise, I attach the screenshots which hopefully illustrate the problem. I have to take a break from this for a bit as I will be out of the country until next week, again , thanks so much for your help ( but equally understand if you leave it here) ,
Apologies for using third party plug ins, I was not aware of it. I do work in R8 , it has good improvements, I teach basic Rhino and GH to my sculpture students hence I need to use the latest version.

[Joseph_Oster]

@e11

Now, the robot doesn’t accept the data structure I give him, the start, curve and end points follow first branch in all data trees.(start point, first branch of each digit, then it moves to end point, from there to start again (same with if I only use the start and digit (as in number) data tree. So the 0, 6, 8 and 9 work… ) I think I need to split the group again into sub groups ( perhaps again 0 to 9) or into how many paths they have ( as you eluded to above).

I was surprised to see you using control points from my IntCrv output and ignoring the points from font creation (used by IntCrv) that I had so carefully labored to preserve. If that works best for you, we could have more easily generated a group (for each digit) of 1, 2 or 3 path curves instead of struggling with the points.

As you can see in this image, PShift in the teal group consolidates all points for each digit into a single list that allows me to get the first (green sphere) and last (red sphere) point for each digit.

The paths and points are in sequence so there is no reason to lift and lower the robot between paths in each digit. That makes sense only when moving between digits (red to green spheres). See the cyan lines between the end and start points for each digit in this image:

Caligraphy_2024Oct9a.gh (94.5 KB)

I would love to have a robot to play with
Images of code (especially icons) are meaningless to me.

Have a good trip.

[e11 (Ekke)]

@Joseph_Oster

The paths and points are in sequence so there is no reason to lift and lower the robot between paths in each digit.

Joseph, I am writing this from the airport lounge,
thanks for reply, it is EXACTLY the point what I have to do, " lift and lower the robot between paths in each digit"! I am writing this not with a hard tipped pen or pencil, but with a soft tipped ink brush, so artistry is the problem, as the code has to accommodate the lag in between the strokes.

If I go from start , through all paths within a a digit, the lag in the brush will not paint the digit correctly, it will round all corners, so a Nr.7 will end up looking like a bit like a ), (a kinked hook, a Nr. 2 will end up more like mirrored “S”), they will never be sharp.

Imaging you have a pointy ,soft tipped brush, you move every stroke in and out of the paper, and in the middle of each stroke you might need to apply more pressure for the stroke to look nice ( go x/y negative at midpoint) , the angle at start finish might have to be changed in order for the tip to enter and leave the page nicely. The robot has to mimic all movements a human hand does when using a brush for numbers, hence at the very start I broke all curves up in segments with up and down movement.
I much prefer the code you have written, as I can always go back to the number clusters and change plane positions within.
It’s a bit of a shame really, I think it would be so interesting to work with you hands on in the lab, as it would make things so much easier, what I like about working with robots is the physical outcome of what we write as code.
As for price of robots, you might be surprised as to how cheap they have become, I have a ABB1200, a very good professional 7 kg industrial robot, second hand from sources in China, cost me 5000 USD. It took me a while to get it going, but I figured it out and now I can run all test at home and scale things up at the University lab, where we have a large ABB , that , yes, was 6 figure…
This somewhat illustrates it quite well :

Numbers in Calligraphy Tutorial #numbers #shorts

I hope this makes sense to you , language is imprecise by it’s very own nature…