History for modeling/surfacing in Rhino needs a lot of work

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

4 Likes

Excellent write-up, @gustojunk! :clap:

1 Like

Hi Gustavo, History is a huge subject, so for now I’m only responding to the items that should work in current Rhino:

If you provide an actual point object it should work.

This works here in both v7 and v8 when I change the degree of an input curve I used for loft

This works here as well, so I wonder what you are doing differently. If I create two curves, make copies of those curves, and loft through those copies, matching the base curves to each other (or only one for that matter) updates all copies and the surfaces.

At least in this instance there’s a fix in the WIP. A separate command called JoinCopy has history enabled and does this exactly.

One issue I had while working on Constraints and History, since I think they go together nicely, is lots of joins/explodes with history enabled created a multitude of duplicate objects. How would you like that handled?

thanks @Gijs and @Joshua_Kennedy for the feedback. I will revisit my example file and see if I missed something. I was surprised by all the things I see as not working that Gijs says should work. Maybe part of the problem is not having a clear visual of which objects have history, and related to who; so I probably messed up. This week is nuts, but I’ll try to get back on this next week.

G

@Joshua_Kennedy

I think it would certainly be helpful if there was some continuously visible on-screen depiction of the fact that an object has history active. Perhaps a mouseover of the indicator could highlight the history drivers - at least the ones that are on-screen. Maybe clicking the indicator could open a list or map of all the history connections for that object. Kind of like Excel’s cell auditing functions: Antecedents, Descendents, etc.

2 Likes

@gustojunk Apparently just recently @mikko has made a change that should make history updating of surfaces and blendcurves more reliable where possible. To give a bit of background: this stuff works based on indices of edges, and the change now tries to keep those indices the same as much as technically possible. When next WIP is released, and you still encounter issues where BlendCrv, BlendSrf, etc. is getting messed up, let us know, thanks!

For example this test in v7 is not happening in my current v8 build of the day:

BlendCrv and BlendSrf have the option to edit. Once you start these commands and hit the Edit option, applicable curves and surfaces will be highlighted. There is however a bug in BlendSrf that resets the sliders which is listed as
RH-69363 BlendSrf Edit should preserve BlendSrf options

I’ve added this thread