@gonzalocasas this problem still exists in many places. perhaps we should remove the explicit reference to equivalent geometry objects from the docs. the lower level function API then explicitly uses the minimal mathematical representation of these objects, and in the higher level object API, we do this conversion behind the scenes automatically...

also, i think we should rename the function to always list the lower dimensional entity first.

@tomvanmele
This came up again.
Just to make sure I understand

perhaps we should remove the explicit reference to equivalent geometry objects from the docs.

You mean rename the args e.g. sphere to point_radius?

in the higher level object API, we do this conversion behind the scenes automatically...

Where is the higher level API? you mean something like a new Sphere.intersection_line(line)?

also, i think we should rename the function to always list the lower dimensional entity first.

intersection_line_sphere ?

some lower level functions used to refer explicitly to objects like circle and sphere as valid input. if that is still the case, we should remove those references, and instead make it clear that when the input is, for example, a circle, the user should provide it as (point, normal, radius).

i indeed think that all of the lower level functions should be accessible through the higher level API. to avoid repetition, i would suggest to always make such functionality available on the lower dimensional object. for example

• line.intersection_plane(plane)
• line.intersection_box(box)
• line.intersection_surface(surface)

even better would be to make an intersection class that groups all of these...