> Trim could be a good example where you would probably want a different
> script interface to it rather than the current factory one which is so set up
> to cater to the way the interactive command works.
> When the interactive command works in some distinct stages like Trim does
> (with the fragment picking stage), that becomes somewhat awkward to replicate
> in procedural code.
> Other more typical commands where it's just a matter of filling out all the inputs
> tends to be a better direct fit.
Well, I certainly agree, which is part of the reason I have been trying to create a procedural interface to MoI which encapsulates the MoI API into a more procedural approach. For example, I have a 'line' function which takes two Point objects as input and returns the expected curve object as the result.
BTW, I have been taking the approach that all geometry creating functions return objects that are not part of the geometry database. If the caller wants the user to see them, then a separate function must be called to register them. This makes it simpler to create intermediate results used to generate other final geometry.
At this point I have not completely encapsulated every MoI factory type using this approach. In fact, I just wrote the 'trim' function yesterday, which is why this question just came up now.
I'm still not completely clear on using the 'trim' factory. If I just want to create a set of trim fragments from the set of objects and cutters, do I need to call 'generateFragments' after initializing the factory object (I assume so). This returns a boolean, which means the factory must be keeping the fragment list internally at that point. So which method will return me the fragment list?
- Dave Morrill
|