hi McNeel team,
I’m trying to work on a model with history to make overall surfacing and sizing changes to a product based on evolving constraints (since of components, cooling requirements, etc).
The product I’m working on is symmetric in both X and Y so working on one quadrant with history with curves as my input defining the form. This would allow me to make variations of surfaces (generated from those curves) and then also create blends also generated from those surfaces’s edges (so the history propagated from curves to surfaces, and from those surfaces to secondary surfaces.
The concept/idea of working this way is very appealing, and it feels very close to be useful, delightful in fact. But there are so many glitches, limitations, and just not enough real-world testing in these workflows.
The problems I have encountered so far when working with History, because I’m sure this is a very complex subject with lots of implications, especially for users not expecting something to change.
-
- Blend Curves built from surfaces’ edges sometimes flip and break the entire model.
-
- Loft to Point is not using curves + a p[point as input. only using the curves and the ‘point’ of the loft it merely snaps to what I wanted to be my input point but is not history associated. So I can move all my inputs of a loft, except the point.
-
- Copy/move a bunch of objects with History to try a variant of a design on a copy deletes the entire history, defeating the existential point of history IMO.
-
- Copy>paste history items to a new file flushes the inferred history, so in the example I described above, after pasting to a new file input curves are still connected to their output lofts, but the blends created from those lofts’s edges are not history updatable anymore.
-
- Some Rhino tools are really unruly about in which direction they build surface normals, it seems like the surface normal direction is random? that should not happen. For example, creating a Patch from edge surfaces that all have the same normal orientation should not create a patch with its normal opposite to all its input edges’ surfaces.
-
- Related to the one above flipping a surface normal: Flip nurmals of a surface or direction of a curve should not delete history.
-
- Joining also should not delete history IMO. If the goal of a model is making a solid I want to have a solid that is history editable.
-
- ChangeDegree should not delete history, especially if it’s used in an input-only object, like a curve used to build surfaces with History.
-
- _Match should not delete history, especially if it’s used in an input-only object, like a curve used to build surfaces with History.
-
- BlendSrf settings and BledCrv settings (the dialog boxes of each tool) should be re-invokable though history, so I can change the continuity of a Surface to an existing edge after I built it. That’s the point of History after all.
-
- SelObjectsWithHistory is a lazy tool. It does not tell me who is an input only, or an output only, or both. And it does not let me replace an input for another one.
Other tools that should work a lot better for also a history workflow being better:
NetworkSrf: Oh God, do I need to say more, what a horrible tool with so much density and so bad continuity. Any advanced workflow makes something super obvious over and over and over: we need a new NetworkSrf, It’s silly how bad this tool is.
Xnurbs: I like their history and quality gut also unfortunately doe snot propagate history to child surface of other surfaces with history the way Rhino does. (cc. @XNurbs if you ever read this).
Whoever is working or interested in working on these issues at McNeel, please let me know if you need any clarifications or examples.
Like I have been saying in some other topics, Rhino is full of great tools, but most of them are half-done, not tested enough, and not complete enough to be awesome. History is repeating itself here. Let’s change history!
Thanks,
G