Something peculiar is going on when copying different versions of a script to the MoI command directory, and using customUI.

A functional script named _TrimCurve07.js, and .htm is in MoI's command directory.

A copy of the script named "_TrimCurve07 - Copy" is modified a little bit, with a missing "curve" variable, and copied to the MoI command directory.
The - Copy (seems) to run in MoI

If the defective "_TrimCurve07 - Copy" is renamed to "_TrimCurve08" it does not work.

So the lesson is do not use " - Copy" versions when testing.

This happened a couple of months ago... when this "crazy" behavior was first encountered.
This example is on a different computer...

- Brian

(See next post.)

Okay, here is a very simple example of a version of the problem with Somescript - Copy.js, which is created in Windows7, 3rd option when copy pasting a script into MoI's command folder, using the _Angle.js script.

Copy _Angle.js from the command folder, to the command folder, using Windows7 3rd paste option, which yields _Angle - Copy.js.
Do not copy _Angle.htm.

Copy _Angle.js again, and rename copy to _AngleSecondCopy.js,
and do not copy _Angle.htm to _AngleSecondCopy.htm.

_Angle - Copy (seems) to run fine.
_AngleSecondCopy will not run correctly.

- Brian

Using TAB and MoI's command entry window line, has the same behavior.

(Revised) conclusion, MoI does not recognize _Angle - Copy.js. Instead MoI just runs _Angle.js. (???)

(A reminder to myself, not to jump to conclusions, there could be another explanation:-)

Hi Brian - you can't have spaces in command names. That's because of being able to have command line parameters sent as well, which are separated by a space from the command name.

So for example if you set up a shortcut key with: SaveAs c:\temp\test.obj , it won't try to run a command script of "SaveAs c:\temp\test.obj.js" , it runs SaveAs.js and the c:\temp\test.obj after it is a command line parameter to the SaveAs command.

Similarly if you try to run "Somescript - Copy" it's going to look for Somescript.js and the "- Copy" will be a command line parameter, not part of the command name.

- Michael

Michael, thank you very much for the explanation.

When testing scripts, so as not to overwrite a version, I sometimes used the 3rd option on the copy/paste, which has the not-allowed spaces.
I'll stop doing that :-)

I wonder if there is some version control software that uses notepad++?

- Brian

Google of "version control with notepad++ is getting some hits. I'll do some more reading...

I somehow managed to create an open curve which has strange behavior.
Running _TrimCurve on it with a setting of 8 segments, results in 7 segments.
One of the 7 segments is of double length. It failed to divide.
Multiples of 8, such as 16, 24, and 32 also fail to divide all of the segments. Approximately 1 or 3 segments are lacking.

This strange curve, as an open cone, came up while testing _ObliqueConeUnwrap script, which works for a right circular cone, but not for
an oblique cone, (yet). :-) The shape of the Net is not quite right...

- Brian

Hi Brian,

re:
> I somehow managed to create an open curve which has strange behavior.

Looks like this is a tolerance related bug in the Trim command, on this particular curve it's ending up using too tight of a tolerance which makes it think that point was not on the curve.

I've got it tuned up for the next v4 beta so it should work ok then. Thanks for posting the file!

- Michael

Hi Michael,

Thank you.

Is it possible to fix in MoI3?
Or is the "tolerance bug" in the C++ Trim factory?

MoI4beta seems to be working very well overall, so one of these days I'll move over to version 4!

- Brian

With _TrimCurve test script, on higher powers of 2, or 8, such as 512, 1024, and even 512+1024, the segment count is 3 short.
In either MoI3 or MoI4Dec2017beta. At these "high" point counts, MoI3 has a several second lag in Done completion,
MoI4Beta is very fast.

Testing with stock Trim command in MoI3 or MoI4DecBeta, show the "bug," for this particular curve. Other open curves work just fine.

Scaling the curve, 2X, also shows the "bug," But a new arc "on top of it," does not show the bug.

Two last tests:

Using 64 points, _TrimCurve yields 61 segments. (3 are of double length, unsplit)

For standalone open curve, if the 61 segments are then Joined, and the _TrimCurve repeated, 64 segments result, the correct number.
(For an open edge, using Merge on the 61 segments, and repeating _TrimCurve with 64, results in 64 segments.)

Second tests, with stock Trim command, with start point added, yielded 1023 points versus 1024, one less than correct number of segments.
I'll try adding start point to _TrimCurve test script...

- Brian

For standalone curves, I'm going to put a scripted "Join" and re-Trim in the _TrimCurve test script, as a "workaround" for MoI3.
Likewise for script in progress _ObliqueConeUnwrap.

For edge curves, I'm going to attempt to put in a scripted "Merge".

Adding startpoint to the already arrayed points seems to do no harm, in case of open standalone curves or open edge curves,
and so will be added for consistency with closed curves.

- Brian

Hi Brian,

re:
> Is it possible to fix in MoI3?
> Or is the "tolerance bug" in the C++ Trim factory?

Yes it's in the Trim factory. Right now it doesn't seem likely to get fixed in v3, all my effort is going into v4.

- Michael

cool :-)

- Brian

Great, thank you.

Thank you Michael.


I see, by adding an alert to the BlendCap script, which starts with a Closed edge, that the number of edges is stated as 3.
Since TRIM resulted in two "half" edges, is this an overstatement by 1, or is there a 3rd edge? (Or something else?)
(The index count in the BlendCap for loop would seem to be 0, 1, and 2... ?)

var brep_edges = trim_res.getEdges();

//// Test Code added by Brian:
moi.ui.alert ( 'number of edges = ' + brep_edges.length )

(Result is 3)

>>>>>>>>

(When Trim is applied to an open edge my tests in _TrimCurve12, (work in progress), show an "overstatement" of the number of edges as 2. ???)
(I'm planning on deducting this 1 or 2 count, for doing number of segments comparison...)


- Brian

Hi Brian, well probably there are 3 edges being generated somehow, although maybe it's something like an edge is being repeated in the list.

Can you please post your modified BlendCap script with anything that's required to duplicate your test so I can try it over here and see what's going on?

- Michael

Hi Michael,
Here is the Test BlendCap with simple alert message.

- Brian

(For standalone curves, I've got _TrimCurve12 script working with Join and second Trim, to "fixup" the Trim problem with 8X trimpoints on the strange open curve.
But merge with open edges and reTrim is being stubborn.)

Edit 1/25/18: Brian removed the test script to avoid confusion. A knowledgeable programmer can easily add an alert message of # of brep edges.

Hi Brian, is there also any companion .htm file for the script, and when you are running it and getting that message are you using a particular object as the input? If so please post that object as well so I have all the same pieces as you when I try to reproduce your result over here.

- Michael

Hi Michael,

Attached is simple open elliptical cone, and open cylinder.
BlendcapTest of edge of open elliptical cone, with closed edge, yields reading of 3 edges.
BlendcapTest of open cylinder with closed edge, yields reading of 4 edges.
There is no .htm file for this particular testing.

- Brian

Maybe I'll go at it using the nametags assigned...

Hi Brian, thanks for posting the file.

So when doing this:

var trim_res = trim_factory.getCreatedObjects().item(0);

The 'trim_res' object is the full brep which for the cone will now have 3 edges - the original "seam edge" plus 2 edges from the closed edge that was trimmed. The cylinder started with 3 edges (2 closed edges at the ends and one seam edges), and when you trim one of those in half there will now be 4 edges.

Probably the thing that's got you tripped up is you were expecting to receive edges as the output, but when you trim an edge the output is a brep.

So yeah probably tagging the edge with a name before trimming it would be good so you could find the new edges when looking through all the brep's edges. The name should inherit into the trimmed pieces.

- Michael

Thank you Michael, your response is logical, and makes sense :-)

(I just did a blend with a cylinder and a pentagon, and got 18 (brep) edges, with BlendCapTest, on the open circular edge)

- Brian