Hi Andrew, yes I definitely do want to explore various things related to these things you're describing in the future. These are some fairly different things that you've covering here though, like being able to go back and change a fillet radius and have your sequence of operations replayed is not quite the same thing as a full blown visual programming environment.

The visual programming environment stuff is really cool of course, but it's pretty hard to do that without heavily impacting the UI for controlling different aspects of it. When that UI is not used for basic processes it adds a lot of additional complexity to someone that's just trying to do basic drawing... and MoI is heavily focused on trying to make that basic drawing process very accessible and streamlined.

Have you taken a look at the Grasshopper system that's available for Rhino? It's another approach at doing a type of visual programming for model construction.

I have to say though that I think I kind of lean more towards doing more of that kind of stuff with more explicit code, there is a certain amount of overhead in trying to express programming concepts visually and things like conditional loops just take up more space in the presentation and just seem to get kind of unwieldy fairly quickly. And in order to use the visual programming layer really effectively it kind of seems like there's enough of a bar to that already that I'm not sure how much benefit there really is. A lot of people are not going to have enough "algorithmic aptitude" to really make use of the visual programming environment and meanwhile someone who is experienced in programming can be kind of inconvenienced by the visual programming stuff rather than being able to use more compact code... And it becomes specific enough that it's not as easy for someone to find existing tutorials or books for how it works. Like with JavaScript or Python or something there are a lot of pre-existing resources out there that you can use as reference material to learn some of the basics.

Those are some of the reasons why I'm not all that convinced why a very "visual programming" type approach would really be what I'd try to focus on in the future for enhanced procedural or generative type modeling...

Any of that is probably a fair ways out yet though, and I think I would be more likely to focus on a kind of tweaking and replay of just a captured history sequence of operations earlier than a more dedicated algorithmic/generative type toolbox.

- Michael

Such an in depth and thoughtful reply Michael. One of the reasons no doubt a lot of us keep both the Rhino and MoI licences.

Agreed - why would you need a parametric MoI when you already have a fully fledged Grasshopper (fantastic for those of us who never learnt a language)


- Rich

The non-destructive history / stack is definitely the most useful and practical for me doing stuff in MoI since there are no new skills to learn since all operations are existing ones they have already been done to generate the shape in the first place. I think the trickiest part of it will be handling selections when the thing being selected underneath has changed in geometry. For me though 95% of the time I just change the position of some points in a curve that is used to generate the final shape, so there aren't even any added or removed points.

I have checked some videos of grasshopper and it does look like an excellent tool to make spaghetti. I much prefer the ability to edit scripts that are generated on the fly through visual actions as shown in the video. Even if the scripts are generated in a more brittle way from exporting a history / stack of operations that could still be very useful.

I also just saw another post where it showed the kind of non-destructive construction I am talking about with the revolve tool, so thanks Michael for already starting on this stuff!

Hi Andrew,

> I think the trickiest part of it will be handling selections when the thing being selected
> underneath has changed in geometry. <...>

Yes, this is one of the generally tricky areas in history based modeling, if the model structure changes too much it can get difficult to figure out pieces of the changed model should have the further operations applied to them. It's most tricky when things change in such a way that what was one edge before is now split up into multiple edges and things like that.


> I also just saw another post where it showed the kind of non-destructive construction I am
> talking about with the revolve tool, so thanks Michael for already starting on this stuff!

Yes, there is some basic stuff in place already - after you have done any surface creation command you can usually edit the curves and the surface will regenerate.

These can be chained together to a certain extent as well, like you can generate a curve offset, enable history updates on the offset result (select the offset and run Edit > History > "Enable update"), and then do an extrusion from the offset, and then when you edit the original curve the offset will update and then the extrusion of the offset will update as well.

The main limitation is that all objects in the chain must be in the current model - many operations like booleans or trimming are the equivalent of deleting the current object and then putting in a new one in place of it, those kinds of operations will break the chain.

In the future if I can store a sequence of operations and old versions of objects in a kind of centralized history file it will help to avoid this limitation. But the tricky part is that the history list will probably tend to grow to be a pretty large file, and things that handle large amounts of data usually need careful planning and execution in order for them to work well.

- Michael