Repository navigation
Define orthographic projection geometry and source provenance - #1459
franknoirot wants to merge 7 commits into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1459 +/- ##
=======================================
Coverage ? 38.83%
=======================================
Files ? 33
Lines ? 1818
Branches ? 0
=======================================
Hits ? 706
Misses ? 1112
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
franknoirot
changed the title
| #[cfg_attr(feature = "arbitrary", derive(arbitrary::Arbitrary))] | ||
| #[cfg_attr(feature = "ts-rs", ts(export_to = "ModelingCmd.ts"))] | ||
| #[cfg_attr(not(feature = "unstable_exhaustive"), non_exhaustive)] | ||
| pub struct PlanarFrame { |
There was a problem hiding this comment.
We don't have anything similar already?
There was a problem hiding this comment.
Yeah I wondered the same thing at first. The camera view plane used for Named Views has other data for object visibility, and the base KCL plane has an engine scene entity which idk if this would; here's a table from Codex:
| Type | What it represents |
|---|---|
| Named view | Camera intent plus object-visibility choices |
| KCL Plane | An oriented plane with execution/artifact identity and potentially an engine scene object |
| PlanarFrame | Just the origin and axes needed for the computation |
| pub end_angle: f64, | ||
| /// Whether the arc advances counter-clockwise from start_angle to end_angle. | ||
| /// A full circle has an angular sweep of 2 pi; equal angles mean zero sweep. | ||
| pub counter_clockwise: bool, |
There was a problem hiding this comment.
I'd prefer for this to be more explicit:
enum Winding {
#[default]
Counterclockwise,
Clockwise,
}
| #[cfg_attr(not(feature = "unstable_exhaustive"), non_exhaustive)] | ||
| pub struct ComputeOrthographicProjection { | ||
| /// UUID of the BREP body to project. Other scene bodies do not occlude it. | ||
| pub object_id: Uuid, |
There was a problem hiding this comment.
I like the data structures so far. I'm wondering whether a sole object ID is enough and what the ramifications are if we permit more than one.
If we consider assemblies, for example, we may want a projection of two distinct solids that are able to occlude each other. Returning one Vec<Curve> per solid (Vec<Vec<Curve>>) in ok_response::ComputeOrthographicProjection comes to mind.
There was a problem hiding this comment.
Oh interesting. Would that be a breaking change if we were to add that later? I don't see an immediate need for that capability but it does seem cool
Taking a stab at the protocol slice of the ZDS drawings prototype: define a read-only
ComputeOrthographicProjectioncommand so engine can return projected geometry for client rendering.The reason I didn't include "Drawing" in the names is that I'd like for us to reuse these schemas when we turn our attention to implementing a "Project/Use" tool within sketches: that tool will use the same algorithms and very similar data. So the initial command projects one complete body; selected-edge/face inputs are deferred to a follow-up.
This is the contract for a paired extraction of alteous’s engine #4329. Let me know if
PlanarFrameis a bad type. I was trying to follow her initial work and then tie its payload to @therapon's work on named views, which will need to be accepted as inputed into the to-be-made KCL functions for projections to be dropped into drawings.TIL modeling-api doesn't have any struct definitions for like actual 2D segments.
PathSegment::Lineis kind of a misnomer: it's really a pen move, with an implicit start, not a segment at all.