Don’t get me started with blocks 
1 Like
For the record, I never mentioned [redacted], purposely stopped at “instances…” 
Im not sure how this is fixed, but a concern i had reading through this thread is if the options becomes too polished. I actually didn’t mind that connect left control-points where the line used to be - even though i too hate mondane repeating tasks. But in such cases i simply make an alias which run the _simplifyCrv command after each use of connect (should be something like “_connect _pause _pause _simplifyCrv” - havent tried this one).
In anycase, the simplified connect could become the norm with good reason for most people, but please leave the simplify as an option to toggle on/off in the command (like solid=yes/no for extrudeCrv).
Sometimes the former points from a connect-operation is useful for further modifying the geometry.
Sort of same story goes for the controlpoints in multidegree polycurves. Its a great thing to simplify the way it controls as discussed here - however we still need the changedegree option to force straight lines to be controlled differently. It may be thought like this, but if there was a constant engine running to “dumb down” straight sections, it could interfeer with intentions.
Oh, on this topic - im not updated with the development of R7, but an other place where i already use the simplify curve command in alias - and where the general user may want it to be a toggle within a command too could be CurveBoolean - i always run the simplify after such.
Actually a small extra hack for you all: If i curveboolean a shitload of things (often in facade sketching on my side), the simplify can only take most points, but often leaves a point extra on one side - presumably because its the curve end/startpoint. So if you as part of the cleanup run: “! _simplifyCrv _CrvSeam _Enter _simplifyCrv” - all is good and well. All rectangles only have four points again…
Hell yeah !
ANSYS Spaceclaim Sketching - released 6 years ago is also a remarkable example for a very conviniently integrated advandced sketching. The approach of Rhino and Spaceclaim is of course not at all comparable, but there is a very comfy bridge available (or at least was available for Rhino V5), that I still use on a daily basis. Note - NX too is late on this ;). Rhino should definitely catch up here.
1 Like
Hi Claude,
I too very much like the sketche in Spaceclaim.
We also explored the workflow offered by the Spaceclaim link, but in our field, modifications in the design are so frequent that it makes it impractical to have the reference model and the draft work in separate software.
There were also sometimes bugs in conversion of the geometry ; in particular with rounded pipes.
Very very good.
Thank you.
On the same topic, I tried to get McNeel to discuss possible licensing of Solvespace with it’s creator who is anything but a corporate thug ; we all know where that went.
1 Like
Isn’t this what a a combination of Rhino + Bongo + Grashopper would kind of end up in?
// Rolf
Sketch constraints must be tightly embeded to the basic curve tools.
If it requires to open two Rhino plugins and possibly a plugin of one of those plugins, no one is going to bother.
Solvespace can be used as a free standalone, or it’s libraries can be licensed if embedded in a commercial program.
Amazingly, it not only does sketching but most of what a complete parametric CAD does including 3D modeling with booleans, assembly constraints,… all this in a 6.4 MB executable !
I really meant them to be integrated and so providing a combination of their power.
// Rolf
1 Like
Siemens also licenses a module for Sketch constraints :
But I can understand McNeel not wanting to be dependent on those folks.
Well @DanielPiker was up to something, but I guess he got involved in more sexy and exciting stuff, so I’m not holding my breath anymore…
1 Like
I really think that having Rhino, Bongo and GH as separate “plugins” is degrading the value of Rhino as a whole. Even the revenues that is. They are namely nearly worthless as separate plugins but if combined it would make Rhino into something much more than it’s parts, so to speak. A tight integration would be going from a slingshot to a bazooka. The screenshot you posted above clearly indicate its potential power.
Now this is a bit off topic but still a wet dream.
// Rolf
1 Like
Hi @osuire,
I can understand the frustration, and I’m sorry.
It’s not that I don’t still want to get this stuff integrated into Rhino, but doing that has turned out to be harder than I first imagined.
The solver itself was something i was able to develop as a more or less self-contained thing. It required knowledge about numerics and geometry, but not so much about things like the internal architecture of Rhino and its interface, event handling, command and object history, dependencies and so on.
I think really tightly integrating the solver of Kangaroo (or indeed most of the parametric behaviour possible with Grasshopper) into the main interface of Rhino would involve some pretty major rearrangement of how things currently work.
Maybe it is possible to break off a smaller chunk though, and rather than trying to rewrite the whole of Rhino to be fundamentally parametric, to at least make a somehow semi-separate-but-more-directly-integrated-than-now ‘sketch solver mode’. I’ll revisit this conversation with others in McNeel.
7 Likes
YES ! YES ! YESSSSS !
3 Likes
Note the ‘maybe’ - the ambition is there, but making this work would depend on some parts of Rhino I still don’t fully understand, so I don’t have a complete picture of how difficult this really is.