Don't think it is necessary. The bridge-curve is associative so it will adapt to changes, and therefor it doesn't need to be constrained.
What would be your use case?
Ronald van den Broek
Senior Application Engineer
Winterthur Gas & Diesel Ltd
NX9 / TC10.1.2
Building new PLM environment from Scratch using NX12 / TC11
I design consumer products and also custom electric guitars and on things like an inlays or logo designs,the bridge curve is quick and easy to adjust blends.
I can do it with a spline and constraints and i can create a bridge curve across two separate sketches but it would be a nice addition to sketch tools also I would like a split curve command in sketch mode if it were up to me.
Thanks, Buddy.
The problem is more architectural than anything. Both a 'Sketch' and a 'Bridge Curve' are 'features'. And a 'feature' is an object which contains the data (recipe), both geometric objects, as well as the numerical parameters and/or the rules that define how these objects are related to each other and how they are to update when one or more of the objects or parameters are changed. But the issue is that each 'feature' must contain ONLY a single recipe, even though it might be very complex, it only defines the behavior of a SINGLE 'feature'. As a consequence of this, a 'feature' cannot be part of another 'feature'. Also, 'features' update in timestamp order (this will be important in a minute) but inside a 'Sketch' the relationships are solved simultaneously, or all at once.
To see what I mean, let's take your 'Bridge Curve' inside a 'Sketch' scenario. Now we might be able to handle this, after a lot of really creative coding, if there was ONLY one 'Bridge Curve' in the 'Sketch', but if that was possible, people would immediately demand for support for more than one and here's where that fails. Let's say you were able to create a true 'Bridge Curve' feature in a 'Sketch' and you decided that you really needed TWO 'Bridge Curves' and even if the geometry that they were related to was not directly shared, since all of that geometry was part of the 'Sketch' when the sketch updates all the relationships, as previously mentioned, need to be solved in one turn of the crank, as it were, but how can that happen when the 'Bridge Curves', which must be solved in timestamp order, are going to also contain relationships (constraints) relative to other 'Sketch' objects and if one of those other objects is a second 'Bridge Curve', how can a solution be found? It just doesn't work that way.
The important thing to remember is that each 'feature' must contain ONLY the data (recipe) that is part of that 'feature', period. Yes, it may be related to another 'feature' and even depend on it when it updates, but that's fine, because they will be updating one at a time, in timestamp order. That can't happen if 'features' were allowed to be created inside another 'feature'.
Anyway, I hope I made it clear as to why this is NOT possible.
You can create a spline in the sketch that is constrained to other objects in the sketch. The spline can serve as a "bridge curve", but it won't give you the same UI tools to adjust its shape (you will need to drag poles on the spline in the sketch instead of using the sliders on the bridge curve dialog).
Yes, thanks to all, I understand I can use a spline, that is what I have been doing and it is no big deal, I am not at all saying it is big need, I just like the way bridge curve works in 3D and thought that would be a nice sketch addition.
John, thanks for your explanation into the mechanics as well.I will say most all of my work is not heavy on the side of parametric constraints and history based, I tend to work free form and no history but that is just me and the type of work I do.
