Questions about the solver, entities, and groups

[phkahler]

I'm working on some new construction tools and have questions about entities and the solver. I'd like to implement extrude along a path #439. The plan is to have multiple extruded segments that can be bent or curved with 3 DoF each. This will involve making a copy of the base sketch for each segment, but each copy will involve a transformation of the previous copy. Each transformation will have its own parameters. I'd like all the segments to be in the same group but I'm not sure the internals of the solver will permit that.

Each entity created via copy includes the CopyAs parameter which tells what type of transformation to apply to the original entities (I'll just use points for examples). At the time a copy is made the numPoint vector is set equal to the actPoint of the entity copied from.

Q: Is that the only time numPoint is set?

That would be a problem for me because a copy of a copy within the same group will not work as expected. Transformed points apply the transform to numPoint and if that doesn't change as the previous entity in the chain is moved things won't work out correctly with the second one.

Q: Should I build all my copies with POINT_IN_3D which sees to have 3 free parameters?

That would seem to put undue burden on the solver. There doesn't seem to be an equivalent entity type for normals or faces either.

Q: Is it OK to use copies of entites within the same group? (this is the general question).

I don't want to create a separate group for each segment of the extrusion because 1) it's less flexible and 2) The NURBS system will have to figure out and eliminate the coincident end surfaces between sections. I can write code to build the entire thing as one shell if they're all in the same group.

Q: I'm assuming each set of entites (per copy of the sketch) can have its own transform parameters. These are usually copies of the group parameters, but can't I create new parameters for each segment?

Thanks!

[Evil-Spirit]

@jwesthues can answer this questions

[jwesthues]

You definitely want a single group for the whole thing. It seems like for your sweep, you don't actually need the constraint solver to do anything (since the surface operation is already fully defined, unlike e.g. in an extrusion where the depth is determined by the solver)? So you could just use POINT_N_COPY and friends, and apply whatever transformation you want numerically, outside the solver. Then to keep associativity, you'd just number them as Remap(originalEntity, sweepSegmentNumber).

[phkahler]

I think the answers to my questions are:

Yes, that is the only time numPoint is set - it will not change because of the solver.

No, I should build each "station" of entities with POINT_N_ROT_TRAN. That will ensure that each set is a clean copy of the original sketch with minimal transformation applied - as opposed to doing N mirror transformations along the extrusion for the Nth copy. Constraint equations will enforce the correct movement so segments will be 3DoF instead of 6 allowed by that transform.

Maybe. Is may be OK to use copies of entites within the same group, but mine will all be copies of the base sketch elements, with each group having a unique transform (found by the solver).

Yes (I think). Each station along the path will require 11 new solver parameters. 7 will be for the generic rotation/translation to go from the base sketch to that station. 4 more will be used to define a mirror plane between a pair of station to enforce movement that is equivalent to rotation (each segment will be along a circular path). The entities at a station will share the 7 parameters for the transformation, and a set (a large set) of constraint equations will be created linking a station to the previous one using the 4 mirror parameters.

Lots of experimenting and testing still to do. And many new construction features should come out of all of it, but I can't promise anything ;-)

[phkahler]

Update. Current thinking is that each "station" along the extrusion will be a POINT_N_ROT_TRANS of the original base sketch. That's 6 DoF (7 parameters and one constraint on the quaternion) but we can add constraints to get the desired effect.

Going from station N to N+1 can be accomplished with a rotation and translation (not the same as the one from the base sketch). If we want to rotate from P[n] to P[n+1] we take a unit vector V pointing from P1 to P2. Using the cross product (N.cross(P)) where N is the unit normal vector of station N. That cross product give the 3 imaginary components of the rotation needed and the real component will be computed to make a unit length quaternion. We then translate whatever is needed to move the rotated P1 onto P2 (tranlation = P2.minus(rotated P1). Once the station-to-station transform is calculated algebraically we can use that (applied to station N) to constrain the transformation to station N+1. I think.

I've decided it might be good to allow scaling and rotation (within the plane) of each station too. Have not figured that out completely, but it should be possible to apply that prior to the above without affecting the constraints between stations. Or maybe after?