Full Version: Scripting the Trim command

Show messages:  1-15  16-32

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

Attachments:
StrangeOpenCircle.zip

---

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...

Attachments:
OpenEllipticalConeAndCylinder.3dm

---

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

---

Show messages:  1-15  16-32