Hi -
If you use ExtrudeCrvAlongCrv with history enabled, updating a constrained curve will also update the 3D object.
-wim
nice
Nice workaround!
Just a bit counterintuitive.
Any plans to add parametric Arrays as a possible constraint? This might not be MVP but would be quite powerful. Until now, we have used Grasshopper for such parametric modeling, so not sure what the Grasshopper functionality vs. Rhino constraint features will look like.
I am beyond excited for this feature, being that Fusion360 refuses to add Rhino navigation as a âpan, orbit, zoomâ option. Briefly fiddling with the Rhino8 WIP to test the constraints feature, I have a couple of observations. I think there needs to be a mid-point constraint, and as others have mentioned, expressions like in Grasshopper would be very cool. The Osnap feature in Rhino might be a good indication of which additional constraints would be useful. I also havenât been able to add new geometry to an existing sketch. I select the geometry, click âadd objects to constraint sketchâ , then I click the name of the sketch I wish to add it to in the command line. The command line then shows the name of the sketch as âSketch (name of sketch):â It is awaiting some input in the command line, but what input it wants is not indicated.
I still find it unfortunate that my request to have layers work within sketches is ignored.
I can understand it may be difficult to have sketch items across different layers like this:
â
Layer 1
Layer 2
Layer 3
â
But not if itâs like this:
âSketch Nameâ
----Layer 1
----Layer 2
----Layer 3
Surely that has got to be something that could be considered, please?
That would be so much more indicative if you have lines in a particular layer offset from lines in another layer. Than you can atleast visualise which lines drive which other lines. And you would also be able to put some construction geometry in another layer, so you can hide it when itâs no longer necessary for new constraints.
You can orginize your sketches in sublayers.
Hi, this was one of the first things brought to my attention when work began on the project. It hasnât been ignored. The issue is open here and I plan on working on it. Iâm still kicking around trying to figure out how best to go about it.
Is this approximately what youâre after? The lights can be used to toggle the layer off and on. I canât see a lot of use in organizing the dimensions/constraints by layer since they may constrain geometry between them, especially in the case of construction lines.
There is a PointAlongCurveConstraint you can use. This takes a parameter between 0 and 1 that determines where along the curve the point while lie. Using a value of 0.5 will put it on the midpoint. Do you think a separate midpoint constraint would be preferable?+
Logged here, hopefully getting to it soon.
Itâs asking for a sketch here. It should use the selected sketch as soon as you hit enter. I need to tune up that portion of the command.
Good to hear it is considered, I just hadnât seen any response or logged task for this, so I didnât know.
As for dimensions and constraints, it would seem most logical to me that they would be associated to the sketch objects. Depending on which sketch layer you turn on/ off, the associated dimensions and constraints should turn on/ off as well.
I think I would use the layers panel for this. Tugging everything in the Constraints panel will probably make for a lot of scrolling or expanding/ collapsing dropdowns. So if it were to be in the layers panel, I would be able to avoid this. I guess I would add the Sketch icon in front of the parent layerâs name that contains a sketch or sketch objects. This then indicates they are there.
I did think about tabs for each sketch (or for the layers) within the Constraints panel, but that also results in a lot of digging/ clicking.
What I know presume to be the best solution is to have a master control panel to show/ hide all items of a particular sketch, but to leave the granular layer based control in the layers panel. As such I am not sure the mockup would work best with a dropdown for master control of sketch visibility or that it would need a tab for that. It could also be a ShowAllSketchLayers command.
I think the Constraints panel would have to do too much of the work if it also contains the granular layer based control. By splitting the layers ideas off to the layers panel, I think it is easier to control both. Most users probably have the layers panel open anyways. Docking them below one-another doesnât seem unreasonable either.
I just saw thisâŚ
I would also add my support for a area / volume constraint function, that would really be very, very interesting for architectural planning of spaces!
That surely depends on whether you want to use the sketch to constrain a single item (in which case the most likely scenario is to have everything on one layer) or to constrain a collection of items, as an assembly? Are you thinking of having different sketch âtypesâ for each? The use of, and allowing, construction lines that may be on their own layer - a layer that could then be used by several other sketches - further complicates matters. That matrix could get messy very quickly.
I think it would be worth outlining what your current design intent is where sketches are concerned, in a little more detail.
Design intent is everything when it comes to using contstrains, not only within an object/part/component but also between assembly parts and perhaps even sub-assemblies if that is (also) the intent.
If multiple layers are used within an object/part/component then constraints and construction lines should only be used by the component they belong to and it should not be possible for other components to use those same construction lines. I can imagine that updating a 2nd component that uses construction lines from a 1st component may wreck the 1st component when updating the 2nd component and possibly the construction lines. If that could happen it will be a disaster waiting to happen, depending on how constraints etc. will be implemented in the long run.
Use scenarios/design intents should be made very clear when wishing for improvements with constraints, one should not expect McNeel to know what is a typical use for their customers in certain areas or what may or may not be useful.
Iâm running into that with other software where I sometimes wonder why they didnât think of certain issues that might come up or where it shows they donât really know the typical workflow in certain disciplines and as a result came up with, ranging from somewhat to infuriating, inconvenient implementations.
Hi -
I think we are still trying to find out what the users really need, so please let us know what you need.
I see 2 previous posts from you in this thread - both on March 23rd. A lot of water has flown under the bridge since this thread was started and Constraints have come a long way. Have you had a chance to use it in a project? Among other things, you were wondering about assembly constraints and things like deformable coil springs. In this first iteration of constraints, this is not where the focus is, so Iâd like feedback on creating sketches as the basis for part generation.
I havenât been able to create constraints between curves that are both in separate and in a common sketch, so, I guess, so far, so good. I imagine that global parameters will allow some of that.
Yes, so please add specific requests (:
-wim
Yes, and make sure it works for splines as well.
(NX just got this feature, after a few decades of waiting⌠and similar to my previous post, I find it amusing that McNeel this time decided to start with a constraints browser, which is an advanced feature used only for locating errors in NX and something I donât even think Solidworks/Catia has⌠and some people upon seeing it are quite rightfully asking for an object browser instead).
@Joshua_Kennedy, yes a specific mid point constraint would be appreciated because it pairs with osnaps.
In general all osnaps could be a constraint.
Iâve not used them to try to model a âproperâ item since my previous post. The current upheaval in the UI design has made me hesitate to do anything further until that side of things has settled down a bit.
The intention of my last post was to seek clarification as to whether the current focus is on single object constraints sketching, or controlling some level of assembly (ie constraining a collection of single objects). To me, the obvious route for the latter is to be able to nest sketches, but if the sketches themselves are to reside on a layer (or even layers), then that gives rise to some interesting questions, similar to those for blocks and block management. Neither assembly sketches or assembly blocks really want to live on layers that can be shared with other objects - they merit a layer ordination of their own class.
Going back to sketches for single objects and especially the example of a coil spring with non-uniform pitch: That is the type of object to concentrate on in the early stages of development. Single object/sketch/layer removes logical semantics from the debate and allows one to concentrate on the core features for constraints. Being able to define a non-uniform 3D object in a single sketch would be something that could set Rhino apart from other modellers. I could also see it being hooked up to GH without needing intimate knowledge of GH, to give even more powerful control over object constraints.
I will try to spend some more time trying out the current implementation. Work pressures mean I donât have a great deal of spare time atm