You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spatial traits were factored out of Plexus and into Theon for #27. This freed Plexus from the details of abstracting geometry and also allows those abstractions to be shared.
Primitives (n-gons) are closely related to these abstractions. Theon provides geometric queries, but they are currently limited to bounding and simple geometric concepts like rays and axis-aligned bounding boxes. This leaves downstream crates to implement queries like ray-triangle intersection.
This change would not entirely remove the contents of the primitive module. Instead, it would only remove NGon, Polygon, and other types designed to represent primitives. It would also remove re-exported traits from Theon's composite API (like ZipMap). Generation and decomposition would remain in Plexus (since Theon should not be concerned with things like tessellation).
Once these types migrate, Theon can provide a richer API and spatial queries concerning these structures, especially triangles.
The text was updated successfully, but these errors were encountered:
I've tagged this as a discussion, because there are some points against doing this and it isn't entirely clear to me what the right decision is. Moving these types creates a much tighter coupling between these crates and introduces some friction if Plexus requires features that aren't already present in Theon.
One argument for keeping primitives in Plexus is the lack of type bounds on their vertex data. It would be reasonable for Theon to place a EuclideanSpace or AsPosition-like bound on the vertex data in NGon, but Plexus relies on placing arbitrary data in these types and could not use types with these bounds without a seriously negative impact on ergonomics. Of course, Theon could just define NGon as-is, but maybe that only makes sense in too broad a context...?
Moreover, I'm still not sure where to draw the line when it comes to features in Theon. For example, I'm currently working on spatial partitioning in Theon, but it may be better for that to be in its own crate too. This may take some experimentation.
After experimenting with this for a bit, I feel that keeping primitives like NGon and Polygon in Plexus is reasonable. However, I've moved the AsPosition trait into Theon and have re-exported fewer types from Theon in Plexus. 2c92439 and bcf7b2c refactor the primitive module with some of these changes.
Spatial traits were factored out of Plexus and into Theon for #27. This freed Plexus from the details of abstracting geometry and also allows those abstractions to be shared.
Primitives (n-gons) are closely related to these abstractions. Theon provides geometric queries, but they are currently limited to bounding and simple geometric concepts like rays and axis-aligned bounding boxes. This leaves downstream crates to implement queries like ray-triangle intersection.
This change would not entirely remove the contents of the
primitive
module. Instead, it would only removeNGon
,Polygon
, and other types designed to represent primitives. It would also remove re-exported traits from Theon's composite API (likeZipMap
). Generation and decomposition would remain in Plexus (since Theon should not be concerned with things like tessellation).Once these types migrate, Theon can provide a richer API and spatial queries concerning these structures, especially triangles.
The text was updated successfully, but these errors were encountered: