Roadmap:: Design/Thoughts on the Modeling Context

[dcowden]

Cross-posting on behalf of @gumyr 👍

With respect to the modelling context, I would expect that it either stores enough information to regenerate the model at any state or stores the model at all states (classic trade-off between time and space). With such a context, one would be able to introduce new operations like "find the edges produced by operation x". What would the scope of such a context be: a Solid, a Compound, an Assembly? Would models/contexts be able to be combined - say create model one which would have its own context; then create model two with a separate context; then combine the two models - how many context are there now? 2 or 3?

[dcowden]

@gumyr Not an answer to your question, but here are some thoughts i have in thinking about this.

1. This is an interesting read about the confusion that exists with the current fluent+ stack. Design Direct API #47 The cake example was a good one.

2. In the current design, I opted to be memory efficient, but I think that was a mistake. At least, until we prove that these objects take a lot of memory. Everything i've seen has always been cpu bound.

3. Question: what assumptions do we want to make about object identity? My experience with OCC is that Shape objects are immutable. New ones are always created. However, a while back, i played with trying to get a stable identifier/hash, and i failed. I am thinking that the modeling context design is influenced quite a bit by whether we will assume that we can solve object identify, or whether we'll assume that we cant-- thus holding references in each case we need.

4. this is 1/10 baked, but right now my notion is that the modeling context would just greedily store OCP shape object references organized by several separate data structures:

   • a map for user tags
   • a map for operation id ( question: do we want to store everything or only ones users decide to name, showing us that its important)
   • a map of parent-> child for created/modified: if we can get identity!,

5. this is what i came up with playing around back in 2017. My thinking was that each operation would call log_shape_action as it works, logging the shape relationships. I

Its funny you mentioned merging contexts-- that's something i contemplated with the above example it appears ( merge_log)

[Jojain]

The modified/generated API of OCCT is based on faces changes. It expects that we are designing a Solid and that each Operation generates or modifies some faces from this Solid.
I think we should do the same and thin down the possibilites because right now the Workplane context can pretty much hold anything type of shape but if we wanted to keep that I think we would just struggle to get things working.

[dcowden]

If you were to perform an operation that doesn't modify a solid, does OCC still produce a copy of the original object, or in that case does it return a reference ?
Regarding thinning down workplane, I recall you had the idea to have a 2d modelling context and a 3d one. Do you think the user experience is better when they are strictly separated?

In Solidworks, there is a difference between a 2d sketch and a 3d sketch, but I found that confusing.

In SW you absolutely can't make 3d objects when editing a sketch, but a lot of cq users do that. One way is to have a sketch be a purely 2d construct, and then let users use a location or a plane to place 3d objects

[Jojain]

I think the generated things of OCCT are only available on class that modify the solid so there is no question (I'm not sure of this however)
I personally like having 2D and 3D sketches. However the sketches in CQ are faces based which doesn't make sense for 3D sketch. I still don't understand why it has been made this way.

Having all separated is a bit less friendly but it's easier to manage for the developers as well as for the user. So I'm in favor of that as well.

[gumyr]

I like the concept of separating 2D drawing (in Sketch) from general 3D operations (in Workplane or Part?). As a Sketch can be applied to any plane its very flexible when building 3D objects. It might also discourage doing CSG based design (although at times I'm forced to still do this to avoid weirdness).

Sketch being Face based allows very powerful operations like subtraction or intersection which isn't really possible with Wires (at least I can't imagine it). With .wires().vals() or .faces().val().outerWire() wires can be extracted if desired.