USER FORUM

*(you are viewing a thread; or go back to
list of threads)*

**Workplane driven by entities (API)**

*(by Tom Sato)*

Hi Jonathan,

I'm using the API and trying to great a workplane which is driven by entities (like 3 points), so when one of the points move, the workplane moves as well along with all the entities on it.

I know that using the UI you can create a workplane using a point and two lines (same as 3 points I assume). Is it possible to do something similar using the API? Basically, creating a driven workplane that would be moved (via its driving entities) as part of the solving process.

Many thanks,

Tom

I'm using the API and trying to great a workplane which is driven by entities (like 3 points), so when one of the points move, the workplane moves as well along with all the entities on it.

I know that using the UI you can create a workplane using a point and two lines (same as 3 points I assume). Is it possible to do something similar using the API? Basically, creating a driven workplane that would be moved (via its driving entities) as part of the solving process.

Many thanks,

Tom

**(no subject)**

*(by Jonathan Westhues)*

"Workplane from point and two lines" isn't achieved with constraints in the application. We just calculate the basis vectors (u = line1, n = u cross line2, v = n cross u), make a quaternion from that, and leave the workplane's definition (by its origin and that quaternion) fixed while we solve. The application does that with NORMAL_N_COPY and POINT_N_COPY, which aren't exposed in the library, but you could get the same effect by defining the workplane in terms of parameters in a group that's never solved for.

The same thing could be achieved with constraints, as attached. That ability (to solve for the position and orientation of a workplane in terms of entities that lie within that workplane) might be useful in some cases, like the example where we compute the basis vectors for an isometric view. In this case, where the solution is simple, it seems like a needless complication.

The same thing could be achieved with constraints, as attached. That ability (to solve for the position and orientation of a workplane in terms of entities that lie within that workplane) might be useful in some cases, like the example where we compute the basis vectors for an isometric view. In this case, where the solution is simple, it seems like a needless complication.

**(no subject)**

*(by Tom Sato)*

Let me give you a quick example of what I'm trying to achieve using the library, and maybe there's a clever solution to my problem.

On workplane W1 We define Segment S1 using points P1 and P2.

The segment S1 now allows me to create a second "Driven" workplane W2 whose parameters are:

V = W1.Normal

U= P2.Subract(p1).Normalize

N= V.Cross(U)

Now, we can proceed to create entities on W2.

As we move P1 or P2, W2 will be rebuilt and all entities on W2 will be relocated accordingly (defined by U and V coordinates).

All this is good and I can iterate through driven workplanes rebuilding entity coordinates. Using this method I'm solving each workplane independently without the need to solve the entire system in one go.

The problem exists when you start adding constraints using the points which drive the workplane. For example, since P1 and P2 exist on both W1 and W2, if you define a constraint on W2 which involves P1 or P2 the method above fails since it would require the entire system to be solved as one system (not each workplane separately).

If I can use the library to define the workplane dynamically (by deriving it from S1 or any other required entities), then I will not have to iterate through the workplanes and I can solve the entire system in one pass.

And just to clarify why I'm doing this, I'm trying to achieve workplanes which are driven (not hardcoded).

Any thoughts on how I can use the library to create such a driven workplane (to be dynamically solved for) as part of the overall solve operation?

Many thanks.

On workplane W1 We define Segment S1 using points P1 and P2.

The segment S1 now allows me to create a second "Driven" workplane W2 whose parameters are:

V = W1.Normal

U= P2.Subract(p1).Normalize

N= V.Cross(U)

Now, we can proceed to create entities on W2.

As we move P1 or P2, W2 will be rebuilt and all entities on W2 will be relocated accordingly (defined by U and V coordinates).

All this is good and I can iterate through driven workplanes rebuilding entity coordinates. Using this method I'm solving each workplane independently without the need to solve the entire system in one go.

The problem exists when you start adding constraints using the points which drive the workplane. For example, since P1 and P2 exist on both W1 and W2, if you define a constraint on W2 which involves P1 or P2 the method above fails since it would require the entire system to be solved as one system (not each workplane separately).

If I can use the library to define the workplane dynamically (by deriving it from S1 or any other required entities), then I will not have to iterate through the workplanes and I can solve the entire system in one pass.

And just to clarify why I'm doing this, I'm trying to achieve workplanes which are driven (not hardcoded).

Any thoughts on how I can use the library to create such a driven workplane (to be dynamically solved for) as part of the overall solve operation?

Many thanks.

**(no subject)**

*(by Jonathan Westhues)*

Long chains of circular dependencies tend to be hard for users to debug, and hard for SolveSpace to solve; but did you look at the example attached above? The workplane in g003 is defined in terms of the lines in g002, but that's just for clarity. Everything would still work the same if all the entities and constraints were placed in one group.

Take care that two parallel-in-3d constraints (on the new workplane's u and v) will overconstrain the orientation; you can't directly have what you wrote above, because your given u and v vectors aren't necessarily perpendicular. I used a parallel-in-3d constraint with a point-in-plane constraint here, though other combinations are possible.

Take care that two parallel-in-3d constraints (on the new workplane's u and v) will overconstrain the orientation; you can't directly have what you wrote above, because your given u and v vectors aren't necessarily perpendicular. I used a parallel-in-3d constraint with a point-in-plane constraint here, though other combinations are possible.

**(no subject)**

*(by Jonathan Westhues)*

Oh, and just to be explicit: three (non-collinear) points define a plane, but they don't completely define a workplane in SolveSpace, because a workplane also needs twist about the plane's normal. One possible complete set of constraints is:

workplane's origin coincident with P1 (3 DOF)

P2 lies in workplane (1 DOF)

P3 lies in workplane (1 DOF)

P2 and P3 horizontal in workplane (1 DOF)

workplane's origin coincident with P1 (3 DOF)

P2 lies in workplane (1 DOF)

P3 lies in workplane (1 DOF)

P2 and P3 horizontal in workplane (1 DOF)

**(no subject)**

*(by Tom Sato)*

I did look at the example attached, but it didn't help me understand how I could do the same using the library. You've mentioned that some needed functionality is not exposed.

Just to clarify, the driven workplane (W2) is a valid workplane with U and V perpendicular. U is defined by the orientation of the segment S1, and V is the Normal of the original workplane W1 which houses S1, so they are certainly perpendicular. Please take a look at attached image.

So going back to the original question, I would like to allow allow a workplane to move during the solve process via the library. Is this possible?

You've also mentioned parallel-in-3d constraint. Is this constraint type exposed in the library? I haven't seen any reference to it in the docs.

Just to clarify, the driven workplane (W2) is a valid workplane with U and V perpendicular. U is defined by the orientation of the segment S1, and V is the Normal of the original workplane W1 which houses S1, so they are certainly perpendicular. Please take a look at attached image.

So going back to the original question, I would like to allow allow a workplane to move during the solve process via the library. Is this possible?

You've also mentioned parallel-in-3d constraint. Is this constraint type exposed in the library? I haven't seen any reference to it in the docs.

**(no subject)**

*(by Tom Sato)*

In the attachment above, the left image shows W1 and the right image shows W2 driven by the segment with the following attributes:

U is defined by the direction of the segment

V is defined by the normal of W1

and the Normal is U cross V

Instead of hardcoding W2 (using origin U and V), I would like to define it using other entities whose parameters could change during solve.

U is defined by the direction of the segment

V is defined by the normal of W1

and the Normal is U cross V

Instead of hardcoding W2 (using origin U and V), I would like to define it using other entities whose parameters could change during solve.

**(no subject)**

*(by Tom Sato)*

Just realized that parallel-in-3d is probably the same parallel constraint but not projected onto plane. Would this work just by using 3D points instead of 2D points?

**(no subject)**

*(by Jonathan Westhues)*

The particular way that the SolveSpace application implements "workplane from point and two lines" uses a point and normal type that aren't exposed, but (a) the same effect may be achieved as discussed above, and (b) that has nothing to do with determining workplane position and orientation with the constraint solver, which seems to be what you want.

It doesn't matter if your u and v happen to be perpendicular. If you constrain more than three degrees of freedom of orientation, then you've overconstrained the system. I gave a set of constraints above that exactly constrains orientation, though others could be used too.

And see exposed/DOC.txt for a list of constraints, including parallel in 3d ("Constraints that may be used in 3d or projected into a workplane are marked with a single star (*)."). A parallel-in-3d constraint may be applied to vectors defined in terms of entities in either 3d or 2d, the latter being useful only when the entities aren't all in the same workplane.

It doesn't matter if your u and v happen to be perpendicular. If you constrain more than three degrees of freedom of orientation, then you've overconstrained the system. I gave a set of constraints above that exactly constrains orientation, though others could be used too.

And see exposed/DOC.txt for a list of constraints, including parallel in 3d ("Constraints that may be used in 3d or projected into a workplane are marked with a single star (*)."). A parallel-in-3d constraint may be applied to vectors defined in terms of entities in either 3d or 2d, the latter being useful only when the entities aren't all in the same workplane.

**(no subject)**

*(by Tom Sato)*

Many thanks! I'll certainly try the methods described above.

**Post a reply to this comment:**