Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Factor primitives into a separate crate (Theon). #29

Closed
olson-sean-k opened this issue Jul 1, 2019 · 2 comments
Closed

Factor primitives into a separate crate (Theon). #29

olson-sean-k opened this issue Jul 1, 2019 · 2 comments

Comments

@olson-sean-k
Copy link
Owner

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.

@olson-sean-k
Copy link
Owner Author

olson-sean-k commented Jul 1, 2019

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.

@olson-sean-k
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant