Hi Brian, re # 3:

> The third script attached is EpitrochoidSliderHTMstyleSomeFlicker works pretty well, with
> some "onmousemove" flicker.
> Is there any way to improve this flicker?

I tested moving even more of the stuff over into the .htm file including where the factory is stored (see g_factory inside the .htm file), and that seems to get it going fast enough that there isn't any more "stacking up", does this version work better for you too?

Basically this version doesn't keep anything at all in the .js file, the .js file only calls functions Update(), Cancel() or Commit() which go into the .htm file, everything having to do with the actual factory is just kept in the .htm file. You can put global variables in the .htm file as well if you need something to persist in between function calls, rather than passing parameters over from .js to .htm .

- Michael

Fantastic work Michael!

The slider works excellently now.
Having the code in the .htm sure is a lot faster.
I'll have to study the changes some more.
I'm going to try it on the clothoid script next.

Thank you very much!

- Brian

Hi Brian,

> Having the code in the .htm sure is a lot faster.

Yeah the script code in the .htm file is running inside of the moi.exe process (which is basically the main process that also handles displaying the UI and stuff like that), not inside of moi_commandprocessor.exe , so every time it makes a call into a MoI object it ends up calling it directly instead of doing an inter-process marshaled call. That's where the increased speed comes from.

So if it's faster you may wonder why doesn't everything do it that way? The downside is that a script that is running directly inside of MoI.exe can easily do things like freeze the main program UI if it goes into an extended amount of processing, and it can't easily be canceled while in the middle of doing processing.

The regular way that scripts work is to run in that separate moi_commandprocessor.exe process so that they can easily be canceled (by terminating moi_commandprocessor.exe) at any time without any particular cooperation from the script.

Regular MoI commands only use the script for doing sort of high level control flow like hiding/showing UI and moving between different stages of a command, not anything like loops with several hundred iterations so the inter-process overhead doesn't really make much difference for that kind of script use.

- Michael

Hi Brian, also if it helps you simplify things a bit more it's even possible to put all the event loop logic into the .htm file as well and have the .js file contain only one single function call into the .htm code. That should then eliminate any need at all for passing your own data back and forth between processes, you can just have all data contained only in the .htm file side of things.

I've attached here a version that does that so you can see how that would be set up.

You can't make the .js file completely empty, since it's built in to the command system that the .js file is the entry point for the command, and when the .js file's script finishes executing that's the signal that the command has ended. But you can have just a single line in that .js file and have the .htm file script do really all of the work.

- Michael

Thank you Michael, I'll look it over.

So the g_ label is just a reminder that the object is "global" ? (No var...)
Putting var... makes an object non-global?

I worked on converting over the clothiod with two sliders last night, but the curve declined to be drawn. :-(
I'll try this current modification also. :-)

- Brian

Hi Brian,

> So the g_ label is just a reminder that the object is "global" ? (No var...)

Yup, it's just naming convention to keep in mind which particular variables are global, things can get confusing if you get local versus global variables crossed with one another.

Global variables in JavaScript can still have a var in front of them (and it's generally a good practice to always have the "var" for setting up variables), but if they are declared outside of any function then they will be global.


> Putting var... makes an object non-global?

Yeah if you put a variable with a var declaration and it's inside of a function that variable is then local to that function.

The way variables behave depending on where they are declared is called "scoping", here's a pretty good overview:
http://msdn.microsoft.com/en-us/library/ie/bzt2dkta%28v=vs.94%29.aspx

Variables can also be created in JavaScript without using the "var" in front of them, but those will end up as global variables and it tends to be best to always use the "var" method so that you're keeping track of things more explicitly.

- Michael

One thing that's not so good about having the script code in the .htm side though is I guess you won't get script error dialogs displayed for any errors like you will in the .js file one, so that can make development a bit more tricky.

- Michael

Here is the hypotrochoid script, without sliders.
It is like the epitrochoid script, with a few changes to +'s and -'s.

Edit: Re-uploaded corrected copy of Hypotrochoid script. The old one appears to have been
the epi version. No one complained :-)

- Brian

There was a script query in the Geomagic forum about umbilic torus.
Uploaded the corrected script to the prior post.
Used the hypotrochoid script to form a deltoid. R = 9, r = 3, d = 3.
Drew a big circle and unwrapped it for a baseline.
Used twist and flow to make an umbilic torus. I'll guess that it is not distorted? May try a complete
script to check accuracy.

- Brian

The _Epitrochoid script does not properly place "corner" points on variations which have "cusp" points, such as the nephroid, etc.
Interpcurce just makes a sharp curve. Also some curves are drawn "twice"?

Hi Brian,

For fun I've created Epitrochoid.nod. See to work OK though I'm sure that it can be make much fancier by those more skilled than I am.

Oh, and I've also created Hypotrochoid.nod (or Spirograph.nod)

Mike.

Hi Mike,
You have made some nice nodes.


For radius settings 2, 1, 1, the nephroid, the "cusps" are not quite right, so maybe some refinement could be done. (?)

- Brian

Brian, I'm afraid that I don't understand in what way they are not right.

Below is a composite image of MoI output using radii 2, 1 and 1 and a grab from a Wikipedia page: https://en.wikipedia.org/wiki/Nephroid

Look pretty similar to me, or am I barking up the wrong tree?

Mike.

Hi Mike,

It is not very important. Just came up when I wanted an actual half nephroid.
I was just observing that zooming way in to a cusp point shows a hairpin turn, rather than a corner point, a result of interpcurve.
Identifying the cusp points, and ending the interpcurve there, would result in a "corner."

For example, for 3 cusps in an angle of 2 PI, the ratio of a/b = 3. Numcycles = 1/3 becomes 2PI/3 inside the js code, and yields one lobe.
Numcycles could be changed from an integerValue to numericValue.
Circular array, or 3 interpcurves would yield the full curve...


A ranunculoid has 5 cusps.

- Brian

No sure that I've fully understood the point that you are making, Brian.
Nonetheless it has made me see that the .nod needs to be able to input multiples of pi with much greater accuracy.
So the birth of Epitrochoid2.nod
Mike.

Hi Mike,

Have you seen AL2000 (Speedy) post:

http://moi3d.com/forum/index.php?webtag=MOI&msg=7777.355

He investigates similar curve forms using CV manipulation via vectors transformation.
In the absence of a mathematical formula, he follows a mechanical logic to achieve a similar result,
As a consequence it offers greater parametric control.
If you have not already seen it, I thought you might find instructive, as I did:

http://moi3d.com/forum/index.php?webtag=MOI&msg=7777.366

James

Thanks, James, it's very impressive.

CV manipulation?

Looks like I'll need to widen my maths knowledge to begin to understand the strategy of this .nod.
And it'll be weeks or months before I've nutted out the function of many of the nodes used.

Mike.

Hi Mike

Sorry, by CV (control vertices), I mean "points".

James

Thanks for Trochoid.nod - not quite so intimidating.

Hi Mike,

To help with analysis of nod file, I've relabelled several of the nodes,
& simplified the steps by using "progression" & "extract"
rather than "interp" & "splitPts".

The vectors tips can be seen as points on the minor circle
that rotates as it orbits the origin along the path of the major circle.

Let me know if this needs further clarification.

James