Hi Dave, so it would probably help if you could make that line script example that leaves a ghost object, so I could run it over here and check it out.

For Trim, I guess it looks like the call to generate fragments will cause UI objects to be created, for things like the endpoints of curve fragments.

The automatic setting of the disable UI geometry flag happens inside of the call to calculate(), so that's why they are not being suppressed automatically, because the fragment generation thing happens before that.

Try calling factory.disableUIGeometry(); before the generate fragments call, that should manually set the flag that disables UI geometry so I think that would then prevent those extra things from being created.

- Michael

I never knew there was a glue language actually called GLUE ! :)

- Michael

Michael,

> Try calling factory.disableUIGeometry(); before the generate fragments call,
> that should manually set the flag that disables UI geometry so I think that
> would then prevent those extra things from being created.

I tried modifying the 'trim' function to be:

var trimmer = factory( 'trim', as_list( objects ), as_list( cutters ), 
                       object_list(), 'remove', arg( extend_lines, false ), 
                       arg( project_intersections, true ) );
trimmer.disableUIGeometry();
var result = trimmer.generateFragments();
var result = trimmer.calculate();
trimmer.reset();

but it did not have any effect on the problem. Note that the geometry I see all seems correct and expected. The problem is simply that the UI seems to be 'stuck' in some kind of picking mode at the end of the script. Pressing esc seems to end the picking mode and return everything to normal.

Michael,

> Hi Dave, so it would probably help if you could make that line script example
> that leaves a ghost object, so I could run it over here and check it out.

Here's a short script that shows the problem:

var p1 = moi.vectorMath.createPoint(  0.0, 0.0, 0.0 );
var p2 = moi.vectorMath.createPoint( 10.0, 0.0, 0.0 );
var f  = moi.command.createFactory( 'line' );
f.setInput( 0, p1 );
f.setInput( 1, p2 );
var result = f.calculate();

- Run the script (the viewport should still be empty afterwards).
- Start a new line using the normal MoI UI interface. Click to set the first point somewhere.
- After the click, the line created by the script should appear in the viewport.
- Click to set the second line point.
- The script 'ghost' line should now disappear and never appear again (unless you re-run the script).

Hope that helps...

Hi Dave, I see what you mean.

So there is actually an .update() being called by the system on your factory there.

Right now when a factory is created, it goes on the "active factory list", and in the pointpicker, if any binding was applied that set factory input value, update is then called on all factories in the active factory list.

That probably needs an overhaul so that it only calls update on factories that actually had an input modified. Also maybe there should be a flag that you could pass to createFactory to avoid it getting placed on the active factory list, or maybe just calling calculate() by itself should take it off the active list.

That active list is again something used for interactive commands, so that factories that are "running" are kept track of so that they can be canceled if a command is forced to exit.

The factory is removed from the active list is commit() or cancel() is called on it, so that's why calling cancel() fixes that up. You'll need to call cancel() for now to avoid unwanted updates on that factory later on.

- Michael

And when a command ends, part of the cleanup process is that the active factory list is purged, with cancel() called on any that were still in it, that's why it stops happening after you have run some command.

That's one of the things that commit() does to make the effect of an interactive command stick around, it removes it from the active factory list so that it will not have cancel called on it when the running factories are cleared.

- Michael

Michael,

> Hi Dave, I see what you mean.

Great, at least you're aware of, and tracking, the issue now. For now, calling 'cancel' is not a problem, since it is hidden within my procedural framework. But obviously it would be good if at some future point you could fix the issue.

As I said before, there also appears to be a somewhat more annoying related issue, presumably with the trim factory, whereby the MoI UI ends up in some kind of picking mode at the end of a script.

In the script I'm working on now, I do many trim operations, all of which seem to execute correctly and produce correct results. But at the end of the script, the MoI UI is in this weird picking mode. The only geometry that can be selected or deselected are visible trim points. If I hit 'esc' then the UI resumes normal operation. No combination of adding calls to disableUpdate, disableUIGeometry, reset or cancel to the trim factory code seem to fix the problem.

I've modified (as a test) the script to not add any of the trim points it creates to the geometry database. So at the end of the script, all I see is the original geometry (since the trim points are the only things that the script is creating). I am still in the weird picking mode, but now there is nothing that can be selected or unselected, since none of the trim points I created were added to the geometry database. However, 'esc' still allows MoI to resume normal operation.

This obviously is a more serious problem, since as of now there is no work-around (other than telling the user to press 'esc' after the script finishes :-) ).

Also, I've noticed that some factories alter the selection setting of other, unrelated geometry. Can you confirm this? I noticed it when I originally wrote my script to set selection 'on' for various created objects as the script iterated its way along. At the end of the script, only the last set of selected objects were still selected; the rest had become deselected (presumably by some factories that had run after they were created and selected). When I modified the script to select all of the objects at the end, then it all worked OK. This is not necessarily a bug, but perhaps a script design consideration, so it would be good to know if that is the expected behavior...

Hi Dave,

> As I said before, there also appears to be a somewhat
> more annoying related issue, presumably with the trim
> factory, whereby the MoI UI ends up in some kind of picking
> mode at the end of a script.

That's probably another side effect from the Trim factory being currently designed to work with the interactive command.

When you call generateFragments(), it sets a property called "Selection lock" on all the other objects in the geometry database. Selection lock prevents objects from having their selection changed - that helps with the Trim command because it wants you to select some of the fragments that were generated and not other objects in the model.

Selection lock is automatically cleared from everything in the cleanup step that happens when a command ends. That step is not happening with your procedural calls since you are not using them within the "command" framework.

Try something like geometryDatabase.getObjects().unlockSelection(); although that will only remove it from top-level objects, you may need to do something like put all objects and all their sub-objects also into a object list and then call .unlockSelection() on that big object list.


> Also, I've noticed that some factories alter the selection
> setting of other, unrelated geometry. Can you confirm this?

Yeah, this is what is happening in Trim. It looks like the only other one that I can find with a quick look that would also do it is Fillet when you are filleting the corners of a single curve, there is a vertex selection step there and that works similar to the fragment selection in Trim.


These various things you're running into are basically side effects from things being primarily set up and tested for use with the regular interactive commands.


- Michael

Michael,

> Try something like geometryDatabase.getObjects().unlockSelection(); although
> that will only remove it from top-level objects, you may need to do something
> like put all objects and all their sub-objects also into a object list and then
> call .unlockSelection() on that big object list.

OK, that seemed to do the trick! What I've done for now is to put that code in my script execution framework so that it gets called after every script executes. I did this since it seemed like it might be potentially kind of expensive to do after every trim operation (within a script), especially if it needs to be done on the complete object graph closure. Right now I'm only doing it on the top-level objects at the end of the script. At least now, if I still see weird behavior in the future, I'll know where to look. So thanks for the explanation!

> These various things you're running into are basically side effects from things
> being primarily set up and tested for use with the regular interactive commands.

Sure, understandably so. Another question is though, do you think you might be willing to target the clean-up of some or all of these script-level behavioral issues as a V3 work item? It may not be necessary, since so far the problems I've run into mostly all have viable work-arounds, but it would obviously help simplify a script writers life to remove some of the bumps in the road. Just something to think about.

Thanks again for all your help...

Hi Dave, I'm glad that you've got things working now!

> Another question is though, do you think you might
> be willing to target the clean-up of some or all of these
> script-level behavioral issues as a V3 work item?

Certainly! I've actually already added several of the things mentioned here on my todo list.

Also maybe during v3 we can discuss setting up a more procedurally friendly geometry creation API directly within MoI, like a function call based one like you have set up, rather than having to rely on the factory system for simple things like creating lines, etc...

- Michael

Michael,

> Certainly! I've actually already added several of the things mentioned here on my todo list.

Great!

> Also maybe during v3 we can discuss setting up a more procedurally friendly geometry creation
> API directly within MoI, like a function call based one like you have set up, rather than having
> to rely on the factory system for simple things like creating lines, etc...

Awesome! I'll start making a shopping list ;-) Actually, based on all the scripting work I've done so far, I've been coming up with a number of follow-on projects which, once you have your V3 hat on, might be worth kicking around.

Finally, is the moi.idl file linked to from the scripting wiki page up to date? I've been trying to package up a beta version of some of the scripting extensions I've been working on, and would like to add my MoI API documentation to the package. Since V2 is code complete, I'd like to make sure I've got all the API included, even if it doesn't all have a write up yet (last time I checked, it was about 70% documented).

The funny thing is, I've been using my API documentation a lot while writing scripts, and I've been reading the documentation I wrote previously as if it were all the unvarnished truth. LOL! Well, at least I haven't run across anything I wrote so far that is completely wrong...

Hi Dave,

> Finally, is the moi.idl file linked to from the scripting
> wiki page up to date?

No, it wasn't, it was missing a few newer things like the orientation picker object, and some various new options.

I've uploaded the final v2 version and updated the link on scripting wiki page now.

- Michael

> I've uploaded the final v2 version and updated the link on scripting wiki page now.

Thanks!