is this a bug or just idiocy on my part.

[chessdenman]

let p = Plane(normal: Vector(0,0,1), pointOnPlane: Vector(0,0,5))
if let ls = LineSegment(start: Vector(2.5,2.5,10), end: Vector(2.5,2.5,5)) {
    let intersection = p!.intersection(with: ls)
    print(intersection)
} else {
    print("No intersection")
}

this returns nil swapping to LineSegment(start: Vector(2.5,2.5,5), end: Vector(2.5,2.5,10)) returns the intersection.

[nicklockwood]

@chessdenman looks like you've found a bug. There was a missing abs() in the code, so it only worked in one direction. I'll push a fixed version asap!

[nicklockwood]

@chessdenman I've pushed version 0.7.6 which fixes this problem.

[chessdenman]

Hi, Speedy beyond belief. I am writing a slicer using Euclid and an algorithm from a paper I found. Do you want the code when it is done? I am only an amateur so I am not very github/contributing savy. Chess Denman

On Wed, Jan 31, 2024 at 7:50 PM Nick Lockwood @.***> wrote:

@chessdenman https://github.com/chessdenman looks like you've found a bug. There was a missing abs() in the code, so it only worked in one direction. I'll push a fixed version asap!

— Reply to this email directly, view it on GitHub https://github.com/nicklockwood/Euclid/issues/111#issuecomment-1919824332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBHY5JDWPVOKW5G4QKRILTYRKOCBAVCNFSM6AAAAABCTSS35CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJZHAZDIMZTGI . You are receiving this because you were mentioned.Message ID: @.***>

[nicklockwood]

I am writing a slicer using Euclid and an algorithm from a paper I found. Do you want the code when it is done? I am only an amateur so I am not very github/contributing savy.

Yes please! Don't worry too much about how you contribute it, I'm happy to clean it up and handle writing the tests, documentation etc.

[chessdenman]

Hi Here is the current state of play.

a few issues/questions. 1) it is not all that fast taking a number of seconds once you get up to bigger numbers of triangles in the mesh. I have had to write some lazy extensions to PathPoint to do some sums and I may have slowed things down by not using the right Euclid objects. An alternate would be to just work in pure vectors and try my hand with Accelerate Framework

2) The algorithm I used is extensible to adaptive slicing but I haven't implemented that bit of the code but I could if you wanted.

3) I do have my own algorithm for producing a spiral toolpath which I'd be happy to share/implement but it does require a step I don't quite know how to do in Euclid. (long explanation that might not interest you below)

Spiral tool paths are only really implementable on topological tubes. Step 1 find a straight line that passes from the bottom to the top of the object inside every polygon Step 2 use that line to define a half plane that cuts the mesh (now a stack of polygons) in a nice lined up way. Step 3 rework each polygon so that each one has a vertically aligned start point and the same total number of evenly spaced points. Step 4 for each point in polygons 0 - penultimate travel round the polygon moving the point along the line connecting it to its vertically aligned counterpart by a fraction that ranges from 1/(total number of points in each layer) to 1

2-4 are easy to write using Euclid objects.

Step 1 is the problem. Python I did this by using Shapely (python implementation of GEOS) to take the intersection of each sliced layer treated as a polygon and then find a point inside that intersection. The vertical line at that point becomes the required initial line. I haven't implemented this in Euclid because it would add a package dependency. If you didn't mind that I could use swiftGEOS.

Another option would be to write Euclid its own Delaunay Triangulation routine and then use that to compute alpha shapes for each layer. Then intersect circles not polygons which is easier (I have had a look at polygon clipping but it's hideous and actually the sharp accuracy isn't needed. any point will do)

Chess Denman

On Wed, Jan 31, 2024 at 9:11 PM Nick Lockwood @.***> wrote:

I am writing a slicer using Euclid and an algorithm from a paper I found. Do you want the code when it is done? I am only an amateur so I am not very github/contributing savy.

Yes please! Don't worry too much about how you contribute it, I'm happy to clean it up and handle writing the tests, documentation etc.

— Reply to this email directly, view it on GitHub https://github.com/nicklockwood/Euclid/issues/111#issuecomment-1919966405, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBHY5IVO3ATTEQSP2CUXZ3YRKXQBAVCNFSM6AAAAABCTSS35CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJZHE3DMNBQGU . You are receiving this because you were mentioned.Message ID: @.***>

[nicklockwood]

it is not all that fast taking a number of seconds once you get up to bigger numbers of triangles in the mesh

If you've not already tried it, running with optimization enabled (either in Release mode, or by enabling -O in the Swift compiler settings) makes a huge difference to performance. Even so, Euclid is not as optimized as some libraries, certainly. It does use SIMD in places, but a truly fast implementation would use the GPU.

The algorithm I used is extensible to adaptive slicing

I must admit this isn't a use case I know much about, but I'd be happy to look at the code and maybe even optimize it for you.

I do have my own algorithm for producing a spiral toolpath which I'd be happy to share/implement but it does require a step I don't quite know how to do in Euclid

I wouldn't want to add an external dependency since part of the reason I wrote Euclid rather than using an existing library was to avoid any dependencies concerns, but again if you're happy to share I can take a look and maybe reimplement what the external library is doing in Swift.

Another option would be to write Euclid its own Delaunay Triangulation routine

This would definitely be very useful. I've wanted to implement Delaunay for a while as a replacement for my home-grown tessellation routine that doesn't produce very nice results and fails for some edge cases.

[chessdenman]

Ok I'll start on Delaunay I've simply no idea about how to use the GPU effectively. Too much of a novice for that C

On Mon, 5 Feb 2024 at 23:16, Nick Lockwood @.***> wrote:

it is not all that fast taking a number of seconds once you get up to bigger numbers of triangles in the mesh

If you've not already tried it, running with optimization enabled (either in Release mode, or by enabling -O in the Swift compiler settings) makes a huge difference to performance. Even so, Euclid is not as optimized as some libraries, certainly. It does use SIMD in places, but a truly fast implementation would use the GPU.

The algorithm I used is extensible to adaptive slicing

I must admit this isn't a use case I know much about, but I'd be happy to look at the code and maybe even optimize it for you.

I do have my own algorithm for producing a spiral toolpath which I'd be happy to share/implement but it does require a step I don't quite know how to do in Euclid

I wouldn't want to add an external dependency since part of the reason I wrote Euclid rather than using an existing library was to avoid any dependencies concerns, but again if you're happy to share I can take a look and maybe reimplement what the external library is doing in Swift.

Another option would be to write Euclid its own Delaunay Triangulation routine

This would definitely be very useful. I've wanted to implement Delaunay for a while as a replacement for my home-grown tessellation routine that doesn't produce very nice results and fails for some edge cases.

— Reply to this email directly, view it on GitHub https://github.com/nicklockwood/Euclid/issues/111#issuecomment-1928477601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBHY5MHW5TYDJNYFRCYL2LYSFR6FAVCNFSM6AAAAABCTSS35CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYGQ3TONRQGE . You are receiving this because you were mentioned.Message ID: @.***>

-- Chess Denman

[chessdenman]

HI I am just writing the Delaunay triangulation algorithm but I have run into a bug/ or idiocy on my part. Although Vertex says it conforms to Hashable the compiler doesn't like it if you try to use a vertex as a dictionary key. I will use a workaround for the moment.

Chess Denman

On Mon, Feb 5, 2024 at 11:20 PM Chess Denman @.***> wrote:

Ok I'll start on Delaunay I've simply no idea about how to use the GPU effectively. Too much of a novice for that C

On Mon, 5 Feb 2024 at 23:16, Nick Lockwood @.***> wrote:

it is not all that fast taking a number of seconds once you get up to bigger numbers of triangles in the mesh

If you've not already tried it, running with optimization enabled (either in Release mode, or by enabling -O in the Swift compiler settings) makes a huge difference to performance. Even so, Euclid is not as optimized as some libraries, certainly. It does use SIMD in places, but a truly fast implementation would use the GPU.

The algorithm I used is extensible to adaptive slicing

I must admit this isn't a use case I know much about, but I'd be happy to look at the code and maybe even optimize it for you.

I do have my own algorithm for producing a spiral toolpath which I'd be happy to share/implement but it does require a step I don't quite know how to do in Euclid

I wouldn't want to add an external dependency since part of the reason I wrote Euclid rather than using an existing library was to avoid any dependencies concerns, but again if you're happy to share I can take a look and maybe reimplement what the external library is doing in Swift.

Another option would be to write Euclid its own Delaunay Triangulation routine

This would definitely be very useful. I've wanted to implement Delaunay for a while as a replacement for my home-grown tessellation routine that doesn't produce very nice results and fails for some edge cases.

— Reply to this email directly, view it on GitHub https://github.com/nicklockwood/Euclid/issues/111#issuecomment-1928477601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBHY5MHW5TYDJNYFRCYL2LYSFR6FAVCNFSM6AAAAABCTSS35CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYGQ3TONRQGE . You are receiving this because you were mentioned.Message ID: @.***>

-- Chess Denman

[nicklockwood]

@chessdenman it's difficult to diagnose why that might be without a code sample. It should work in theory.