> Actually there is one kind of recording mechanism already in place, which is
> used by MoI's current history function.
> When a geometry factory produces its objects, the factory name and all of
> its inputs are converted to a chunk of text and stored on the output objects.
> This is what is then used during history updates, like when you do an Loft for
> example and then edit the curves that were inputs into the Loft and then the
> Loft updates.
> That kind of recording is happening all the time when you just do any modeling in MoI.
OK, that's really good stuff to know. Thanks!
> So there's kind of one ingredient of that in place, but that does not really mean that
> it would be at all easy to make a macro recorder though, it would probably need to
> have some additional stuff for reconstituting factories and analyzing inputs on history data
> and stuff like that set up.
Sure, but as long as the information is available through the API, the problem moves from being "impractical" to "doable", which at least means it is still worth thinking about.
> There are plenty of other confusing issues involving recording macros, like when you
> select an object while the macro is running, do you intend for that particular object to
> be used when the macro is replayed (say as a cutting object in a boolean), or would you
> want to be able to pick objects to use at that point, stuff like that. There's probably enough
> issues that it would be more properly part of a larger and deeper history mechanism that
> had various mechanisms set up for modifying parameters on a sequence of operations.
Maybe. But these issues always exist in every macro recording system I've seen. For simple tasks like "clone the current selection and move it +8 feet along the x-axis", then the recorder is just the ticket. For more complex tasks, the recorder is just the beginning.
Usually the user takes the output script from the recorder and tweaks it by hand to create a reusable, parameterized result. Having running code in front of them is usually a huge positive for a user. They can see how the steps they need to do translate into code, and from there it's usually not too big a leap for them to abstract out the parameters from the constants, or introduce loops, etc., provided they've got some guidance or examples about what needs to be done. We're all much better at "copy and paste" than we are at RTFM :-)
For example, as I recall, in XSI you don't have to explicitly record a macro. You just do something, then open up the command history and copy the last few lines worth of stuff you did into a new macro and start tweaking.
So, I'm sure it's still a fair amount of work to do, but I don't think a macro recorder facility has to handle everything itself. Just converting user actions to code is a huge first step...
- Dave Morrill
|
