DRAFT: Allow for `geo-3d` integration

[TimTheBig]

I have been working on a 3d port of geo , geo-3d, to which I would like to add an integration of csgrs.
For this I will need to make some changes to make more functionality optional.

Plan for the pull:

Make the BSP intersection test fully 3d.
Document all modules and structs.
Move main.rs to examples, split for maximum usefulness. And the example shape functions to a mod behind a the shapes feature.

Blocked on #31

[timschmidt]

Awesome to hear from you! I lifted a few of your initial changes to csgrs back into mainline already. Thanks for your help!

The planned modifications to the code structure sound OK to me. Please create a restructuring branch for these changes, separate from the geo-3d changes, so I can pull them in first. Please create a geo-3d branch for the remaining work to make keeping things in sync up to the pull easier.

I've got some work in the robust branch to integrate https://github.com/hayashi-stl/robust-geo/blob/main/src/geo.rs which is based on https://people.eecs.berkeley.edu/~jrs/papers/robustr.pdf into csgrs. Does geo-3d have anything like this?

Could you speak a little about the relative advantages / disadvantages of geo-3d compared to current implementations in csgrs?

[TimTheBig]

I was thinking of adding an adapter module to geo-3d, are you talking about using geo-3d in csgrs?

I've got some work in the robust branch to integrate https://github.com/hayashi-stl/robust-geo/blob/main/src/geo.rs which is based on https://people.eecs.berkeley.edu/~jrs/papers/robustr.pdf into csgrs. Does geo-3d have anything like this?

It has some robust algorithms, though I would be open to adding a robust feature with greater coverage.

[timschmidt]

I found this as well recently: https://github.com/georust/robust Same underlying paper, different implementations. This one looks like I might be able to use it more directly without pulling the functions into csgrs.

I was thinking of adding an adapter module to geo-3d, are you talking about using geo-3d in csgrs?

I've only glanced at geo-3d so far, and haven't yet had a chance to read through it thoroughly. So I'm not sure if it's a good fit for use in csgrs or not. It is what I was thinking you were suggesting. What would your adapter module look like? Just converting between csgrs and geo-3d types? Something more?

[TimTheBig]

What would your adapter module look like? Just converting between csgrs and geo-3d types? Something more?

A wrapper that makes the type conversion transparent, while maximizing efficiency. If I think something is missing, that only makes sense in geo-3d, I will make a util function for it.

I need polygon ops for a project. With a structure something like this:

/// This trait defines the boolean and offset operations on polygons
pub trait PolygonOperations {
    fn offset_from(&self, delta: f64) -> MultiPolygon<f64>;

    fn difference_with(&self, other: &MultiPolygon<f64>) -> MultiPolygon<f64>;

    fn intersection_with(&self, other: &MultiPolygon<f64>) -> MultiPolygon<f64>;

    fn union_with(&self, other: &MultiPolygon<f64>) -> MultiPolygon<f64>;

    fn xor_with(&self, other: &MultiPolygon<f64>) -> MultiPolygon<f64>;
}

[TimTheBig]

I found this as well recently: https://github.com/georust/robust Same underlying paper, different implementations. This one looks like I might be able to use it more directly without pulling the functions into csgrs.

This is used in some part of geo-3d, anything that uses GeoNum.

[TimTheBig]

I will add some equivalents of the methods of csgrs::Polygon to geo-3d.
Does Polygon need all it's vertices to be on it's plane?

[timschmidt]

Does Polygon need all it's vertices to be on it's plane?

Yes.

[TimTheBig]

This may make geo-3d unsuitable for Polygon, as the points are not required to be co-planar.
This may also add some conflict to my use case, for now it's okay, though as the project is a non-planar slicer that will not last for long.

Do you think using geo-3d would allow for making polygon ops work on non-planar polygons, or will more then Polygon and some small changes be needed?

[timschmidt]

The requirement for polygons to be planar really stems from the use of the BSP for polygon splitting. Check out bsp.rs and plane.rs

I think it is probably possible to extend the BSP with a suitable intersection test, but it seems like there may be many corner cases compared to always splitting on a plane. If you decide to experiment on this front, I'll be interested in your results. Could have implications for supporting curves as well.

[TimTheBig]

Interesting I will have a look

[TimTheBig]

Why is Vertex repr(C), is it faster or more memory efficient?
I'm considering changing Coord to repr(C) as it would make conversions for many librarys cheaper.

[timschmidt]

Where are you seeing that?

[TimTheBig]

Oh my mistake, I mistook it with nalgebra::Vector3

[TimTheBig]

w is the y-intercept of the plane correct?

[timschmidt]

w is the y-intercept of the plane correct?

Yes, but in 3D. Normal defines the vector which is perpendicular to the plane, and w is the distance along that vector at which the plane crosses it. Was thinking about renaming w to 'distance'.