VSS b-spline sections

Some dabbling with definition, constraint and continuity related issues.
It's a work in progress so if there appear to be inconsistancies; there are.
Enjoy what ye may if ye be so inclined. ;^)
.

.
2008-07-02_152939_b-spline_vss--wf2--.zip
2008-07-02_153038_curves.zip
(WF2)

for long time You have left "us"(Forum users) Jeff with no sign of life, and now, look at that, big comeback

I took a look on that. For first view, shape seems to be not difficult, but the way You handled it is top notch Pro/E driving. No less.

I am going to dig it deeper. As always I will get the clue -how jeff developed those feats - after weeks,

Good stuff Jeff, this'll give me something to ponder in betweencookouts &fireworks. There's something about the math behind the b-spline that just seems really cool. After having used pro-surface & ISDX for years, its interesting to see what's going on under the hood.

Looks nice, i`ll have a play with this in the morning. Its Beer-o-clock now

> its interesting to see what's going on under the hood


It is kind of interesting to watch the articulated 'mechanism'. ;^)


I think this is an improvement on the 3 piece curve control frame;
a little more logical, maybe a little 'smoother' and versatile.
It duplicates the knot placement of a Rhino Control Point Curve.


- - - - -
Oops... Notice that for this 'frame' configuration the
(n-1)/n term needs to be changed from 4/5 to 2/3.
- - - - -
(WF2)
2008-07-03_222659_200807032045-3pc_bspln_ctrl_frm.prt.zip


Edited by: jeff4136

amazing

I like the most the idea of creating special surfaces - You name them as trim - to create intersection curve for the next step which is Tangent surf made by VSS. This is nice walk around for creating such curves by sketching or offseting, what is always tricky while sketched spline need this "taste" of tuning(or a lot of relation as You-Jeff-do), on the other hand offset creates often curves to short, which do not like to be extended with its nature.

I do like aslo the tip of creating polygon for splines in sketcher by ordinary entities like lines. Is it only Pro/e suffering by lack of polygon for spline by default?

Still there are a lot of equations I do not quite understand what is the background for them. Example - curves for sweeps - sketch 8 group 4, sketch traj_1142, group 5



it seems this sketch - curve - keeps G2 transitions on its ends. But it lacks equations for it inside, having two different. In addition, I really do doubt that it is possible to set ordinary spline with 2 points(start, end) to keep curvature with relations. Am I wrong?

Next what focused my attention on were splines with 3 points with a nice plot of curvature without these "sharp" steps I usualy obtain while creating them



they are amazing

next questions - evalgraphs

first evalgrap in named Tan_def_75 but You use in relations different name

sd3 = 90 * evalgraph(38, trajpar)

Am I wrong or it should be the same name as feature has?

and in the end my favourite one - sketch 2 - I feel totaly lost while evaluating it

> the "trim_def_" surfs


I kinda liked that, too. First time I've tried it. Creating "the
right" trim boundaries is paramount in importance for any blending
type operation, 90% of the battle. Seems to be a useful method for
certain situations. I've the Idea that a further modification might
be to create a Round Feature surface, constant or variable rad,
between the trim_def and base surface.



> creating polygon for splines in sketcher by ordinary entities like
> lines. Is it only Pro/e suffering by lack of polygon for spline by
> default?

Creating the control polygon with sketched lines is a habit I
developed while experimenting because if you ever have to *turn off
the spline's polygon display you'll lose all the dimensions and
constraints. It's also sometimes interesting to sweep the polygon
geometry instead of, or in addition to, the spline curve. I've done
just a little experimentation blending between two polygon sweeps to
create curves for a spline sweep; kind of interesting and may have
practical applications.


(*) Something I should have mentioned in the original post for those
that want to try using the techniques for VSS sections. The VSS
usually DOES NOT LIKE it when the knots are constrained; either
failing to create the surface or creating a really whacky, poor one.
It's necessary to "release" the constraints. To do that you have to
_ Edit -> Modify.
_ Say YES to the "Cannot modify spline with dimensions to internal
points. ..." warning.
_ Visually check, realign if necessary, the CVs and OK out.



> sketch 8 group 4, sketch traj_1142, group 5


If I understand correctly; you're thinking those are bezier curves.
They are, in fact, 2 piece b-splines with a [b = a^2 / ((.5*r) * 2/3)]
equation for each end.



> In addition, I really do doubt that it is possible to set ordinary
> spline with 2 points(start, end) to keep curvature with relations.
> Am I wrong?


It's possible to define the curvature of a degree 3 bezier at both
ends within a limited range of (1) end point curvatures (2) chord and
(3) end point tangent directions. Or a degree 2 (conic), for that
matter, but the range is so small that it isn't usually considered
practical for the degree 3 curve and rarely, if ever, is for the
degree 2.
2008-07-04_203441_deg3_bezier-g2x2.prt.zip
(Many programs will simply create a degree 5 entity (six CVs, three
for each end) any time curvature is constrained at both ends.)



> splines with 3 points with a nice plot of curvature without these
> "sharp" steps


The primary reasons for my investigation:
1) Dragging CV's and knots around with the mouse is not acceptable
to me for most purposes.
2) I was looking for geometric and dimensional constraints that
could be used with the Variable Section Sweep.
3) I was looking for a way to appropriately constrain the knots
(and establish uniform, predictable "basis functions" which is
what I think is actually be modified).
Overall, I'm happy so far. You'll note after some fiddling that it's
possible to drive the curves into some pretty 'rough' states. I guess
that's just another demonstration of the limits of a finite number of
degrees of freedom, the tradeoff between simplicity of control and
attainable curvatures and rates.



> first evalgrap in named Tan_def_75 but You use in relations different
> name sd3 = 90 * evalgraph(38, trajpar). Am I wrong or it should be
> the same name as feature has?


That is a mystery, in more ways than one, and I'm Very Glad you pointed
it out. I can't fully explain it at present but some background ...
_ I routinely append FID#s to feature names to insure unique names.
_ So that looks like it was fid_75 in another file and I didn't
remember to change the name when I copied and pasted from the
original file (also looks like the sweep was copied and pasted,
I did a lot of starting over on this and a few times copied some
of the first features to new, clean files).
What's REALLY interesting is that the graph is fid_38. I ~think~
Pro/E replaced the original "string value" with the integer fid#
because I didn't know you could do that, would have thought it would
trigger an error. Just tried it though and it works. I think I
like that. ;^)



> and in the end my favourite one - sketch 2


Probably would have been easier if I hadn't typo'd [kd46] instead
of [kd48] in the comments, huh? I have a problem with Pro/E font
6's & 8's compounded by my characteristic 'dizziness' and dyslexic
(i.e. 2's instead of 9's; I know which finger, just forget which hand)
typing. ;^)

considering sketch 2 - both relations and entities make me feel lost

considering sketch 1 - what are the adventages to set polygon of spline in this way



rather than make it simplier



the first one requires twice or more mouse clicks. I suspect there is some great advantage behind this method. Could You explain it a little more?

another one - why instead of projecting curves like sketch 5(local group 2, or sketch traj 626 local group 3) You create VSS to obtain intersection curve then. This also costs more clicks! For me it would be easier to make simple project on main surface

next - sketch 7 local group 4. these two arcs seem to be created without any asociative way(radius values) to referenced trajectories(sketch 5 lg 2, traj_260 lg), is this true?

The workflow is a little confusing, butI think thepoint of it allare thevss surfaces that are C2 curvature by constraining the CV's with his relations. This is a big deal.

What can I say? I was confused. ;^)


Some of it is an indication of struggling with concepts or backing out of dead
ends. Some of it; there's no 'good' reason other than it's what felt appropriate
or I wanted to try out or demonstrate alternative ways to define the entities.


Sketch 2:
There is a tangent vector spanning two vertical lines (the ones measured by
sd3 and sd5). I wanted to define the "a" Control Polygon segment as a fraction
of that length (you'll note that I tried to do a lot of definitions that way).
Rather than drop a Ref Dim on it; it's calculated as the hypotenuse of a right
triangle with sides = kd48 and [sd3 - sd5]. (Ref dims don't work with VSS
sections. Practice for me, an arithmetard.) Then the "a" CP segments are
defined as [tangent vector length * factor] where sd20 and sd21 are the
'factors'. I could have simply Modified the "a" segs (sd46, 47) to adjust the
curve but was getting a feel for how it might be done in a VSS section where "a"
will vary with tangent vector lengths.


Sketch 1:
There's no specific reason for it being done that way. Just variations.
Note that the camber [sd25 = sd20 * (1 / .75)] and tangent (parallel to chord)
are defined / indicated.
sd9 = 270 * cos(sd7) just maintains an arbitrary front end to back end offset
of 270 normal to ortho plane.


> instead of projecting curves like sketch 5(local group 2,
> or sketch traj 626 local group 3) You create VSS to obtain
> intersection curve


I probably could have gone with a simple Project. I don't remember if I had
something else in mind at one time or if it's just habit. A surface, i.e.
Var Sect Sweep 4, can be G2 extended whereas (?) a curve cannot so I'll opt
for the surface.


> sketch 7 local group 4. these two arcs seem to be created
> without any asociative way(radius values) to referenced
> trajectories(sketch 5 lg 2, traj_260 lg), is this true?


They do trace back, i.e. _SRF_410 -> TAN_VEC_321 -> TRAJ_260.


Feel free to ask if something doesn't seem to make sense. It might not. ;^)

the most amazing and in the same time the most mystery features. In fact the most intresting are trim surfaces made by VSS(arc as section) and controled by evalgraph. This finaly provides side curves witch seems to have curvature transition with adjecent surfaces(green colour)



it is hard to start asking question considering them, `cause I do not know where to start)

ok, first - evalgraph(for all of 3 groups 4, 5, 6) : well yea, I do know that this is the core of whole funcionality. It drives trim surfaces which provide side curves for final VSS, but Jeff could You introduce some reason why You`ve done this as it is?



How it was and is possible to pretend and calculate that trim surf will intersect in right place?



I tried to obtain those curves - side ones - by creating Boundary blend with an option "Add side curves influence", but pro/e failed to do that

I'd also like some further explanation. Why are the spline framework graphs drivng the radius in the relations and how did you figure out what these graphs were going to look like? Actually I could go on and on with questions but I don't want to take away further from Jacek's request.

Jacek,


The keys to achieving transition (TRIM_DEF_852, _1185, _1512) sweep continuity
are ...
1) The start and end sections of the transitions are coincident with some
'intermediate' section of the existing sweeps.
2) The sweep section radius dimension is the product of [distance * factor],
both of which are either known or can be measured or calculated. The way
I did some of those was most inelegant, real hacks and I'd try to do it
differently, probably just measure curvature and distance between traj's
(either Sketch geometry or Evaluate Feature) at the points of interest
and calculate the factor.
3) Once the start and end factor values are known the factor graphs (VAR_*)
can be constructed. Graph curve 'entry' and 'exit' angles will have to
be set. 90 if the feature being intersected has a constant factor,
otherwise adjusted to match.
(a) Make Intersect 4,7,13 visible. Intersect 13 is a 'transition'
controlled by VAR_1184.
(b) Edit Definition VAR_1184, change sd3 from 93.15 to 90.
(c) Return and note the angle between the end of Intersect 13 and
Intersect 7, and the dihedral angle where Copy 6 and 8 meet.
The shape of the graph curve will affect the trimoffset. Ideally, I
guess it should result in a curve that's curvature matched to the curve
being intersected. (Looking at Intersect 13 again, now, it looks like it
could be nicer. I did spend some time struggling with tangency of the
finished surface (Copy 8 <-- _SRF_1307). That's one of the factors that
affect the final sweep continuity.)


- - - - - - - -


mgnt8,


All the 'outboard' curvatures are defined by the Evaluate Features; record
curvature, link to Evalgraph with Feature Relations and sorta connect the dots
with some massaging and manipulation. Note that many of the 'dots' are just
used for visual reference. (There are things going on there that need study,
i.e. matching entry and exit angles to maintain continuity. I have the notion
that if the graph baseline length equals trajectory arclength, or x,y are
uniformly scaled it's a straight forward process but ...)


The 'inboard' curvatures for the first three sweeps (_SRF_410, _584, _778)
are defined as the product of factor * distance (1*kd5, 2*kd5 and 2.5*kd5
respectively). The 'transition' graphs (IBCRVTR_*) are then created in much
the same way as those described above.

So, for example, OBCRVTR_1300, the 5 heights which are linked to curvature values in CRVTR_1299 are just there for reference. I'm not seeing where these specific relations are at, d444 = 1 / k1:FID_CRVTR_1299, d445 = 1 / k2:FID_CRVTR_1299, etc. SelectingTools > Relations doesn't show them. Do I need Behavioral Modeler? Also in _SRF_1307 there's the relation:


sd18 = sd17^2 / ((.5 * evalgraph("obcrvtr_1300", d443 * trajpar)) * 2/3)


I don't see d443 at all? Is it in CRVTR_1299?

I can't look at the model right now (maybe not for a day or three),
but ...


> for example, OBCRVTR_1300, the 5 heights which are linked to
> curvature values in CRVTR_1299 are just there for reference.


The graph curve end points are probably coincident with the vertical
construction line ends, though I remember playing with the idea of
offsetting them if necessary to get a decent 'average' without making
the curve too complex, e.g. adding knots. The three interior points
were used for visual reference; the idea being a simple, clean, smooth
curve is more important than a precise magnitude match.


(That's all "generally speaking". The forward transition piece was
too complex to do as a single curve so there are actually three(?)
graph curve segments. Not sure it was the 'best' way to go about it,
seemed like a good idea at the time.)

> I'm not seeing where these specific relations are at,
> d444 = 1 / k1:FID_CRVTR_1299, ...


They are defined as Feature relations. So Tools -> Relations ->
("Look In"?) Feature and selecting the graph feature should take you to
them.


(I'd prefer Sketcher relations but Sketcher limits reference scope,
i.e. sd## = k1:fid_... returns an error. About the only thing that can
be referenced are D## symbols or Part level parameters. That's the main
reason for creating all the RAD_DEF_*, I think I called them, sketches.
I can plop the sketch, couple of arcs, down quickly, return and create
necessary relations at Feature level. The idea of creating a bunch of
'global' Part level parameters just doesn't appeal even if they are
controlled by a Sketcher Relation.)


> Also in _SRF_1307 there's the relation:
> sd18 = sd17^2 / ((.5 * evalgraph("obcrvtr_1300", d443 * trajpar)) * 2/3)
> I don't see d443 at all?


Not sure. D443 ~should~ be the graph (obcrvtr_1300) base line (X value)
length. If that's not the case, then the dimension that defines base line
length should be somehow related, by Sketcher or Feature Relation, to D443.
If THAT doesn't appear to be true I may have just screwed up and referenced
an incorrect symbol.
(Remind me if it looks like a screw up and I'll take a look when I get my
computer ginnin' again.)

Thanks Jeff, I found them. I haven't used relations a whole lot in the past so I'm still trying to find my way around in there. I've been reading up on nurbs lately so I think I'm finally starting to see the logic behind your math. Like I said, it only takes me 10 or 20 times before it sinks in.