Script for Epitrochoid, Slider flicker  1-20  21-40  41-50

Next
 From:  bemfarmer
6158.1 
Hi Michael,

The first script attached, Epitrochoid, makes epitrochoids. The Spirograph toy does these, as well as hypotrochoids.
Much of the code for the script is in the .htm file, and it works fine. Thought I would try a circular track model for a Roller Pinion System.

The second script attached is EpitrochoidSliderBadFlicker, with the code in the .js file. The "onmousemove" slider is
causing bad flicker. Is there any way to fix this?

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

- Brian

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
6158.2 In reply to 6158.1 
Hi Brian, for your question #2:

> The second script attached is EpitrochoidSliderBadFlicker, with the code in the .js file.
> The "onmousemove" slider is causing bad flicker. Is there any way to fix this?

It looks like the UI events that are fired on each mouse move get stacked up. You should be able to avoid the flickering by keeping track of what the last used value was and don't do any update if the current retrieved value has not changed.

I've attached an updated version of the .js file that does this, it should help to reduce flicker. There will still be some flicker though because it takes a while for the script to assemble the points since it will end up doing a couple of inter-process communications for each of the 200 points that are created and it's not easy to interrupt an ongoing calculation when a new one is supposed to be starting. That's what the whole async factory mechanism helps with but it's not possible to do an async factory in script right now, it's part of the C++ side of the toolkit.

Right now things are just not really optimized for this kind of looping and more involved calculation only directly in a script...

- Michael
Attachments:

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
6158.3 In reply to 6158.1 
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

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.4 In reply to 6158.3 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
6158.5 In reply to 6158.4 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
6158.6 In reply to 6158.4 
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

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.7 In reply to 6158.6 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
6158.8 In reply to 6158.7 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
6158.9 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.10 
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

EDITED: 13 Oct 2013 by BEMFARMER


  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.11 
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
Image Attachments:
Size: 217.1 KB, Downloaded: 46 times, Dimensions: 527x479px
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.12 In reply to 6158.11 
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"?
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Mike (MGG942)
6158.13 In reply to 6158.12 
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.









  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.14 In reply to 6158.13 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Mike (MGG942)
6158.15 In reply to 6158.14 
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.



  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  bemfarmer
6158.16 In reply to 6158.15 
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

EDITED: 9 Aug by BEMFARMER

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Mike (MGG942)
6158.17 In reply to 6158.16 
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.



  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  James (JFH)
6158.18 In reply to 6158.17 
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

EDITED: 9 Aug by JFH


  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Mike (MGG942)
6158.19 In reply to 6158.18 
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.

EDITED: 10 Aug by MGG942

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  James (JFH)
6158.20 In reply to 6158.19 
Hi Mike

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

James

EDITED: 10 Aug by JFH

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged
 

Reply to All Reply to All

 

 
Show messages:  1-20  21-40  41-50