Attached is a draft copy of Clothoid2pt, which draws a clothoid between two picked points.
Please consider it a test version. There are comments in the script.
The script does not function properly if points are selected in the "Right" view.
This seemed strange, because the Front view worked well.
So the script has a bug, or else maybe var cplane = pointpicker.ptframe; has a problem in the Right view?
The spur gear script uses this cplane, pintpicker.ptframe, but the circular symmetry could be masking a problem?
Are there any other scripts which plot a curve, using pointpicker.ptframe?

This script took a lot of hard work, but was fun and a very good learning experience.
Due to installing windows 7 on a new hard drive, because of severe clutter in the old windows 7 install, did not test it on MoI version 2.
It has not been tested on a Mac.

Thought about adding a selection for angle variation in degrees, to produce a family of curves.
Did not figure out "recurrence" mathematics. The composite simpson integration could likely be done with adaptive simpsons?

I also made up a tangent selection version, but the ending tangents did not quite match up with the initial selected tangents, probably
due to Fresnel estimation, because the clothoid curve cannot be exactly plotted in NURBS.




Edit May 10, 2013. Removed one comma. The script now runs in Moi2, with same "limitations."
Edit May 10, 2013. Reposted script with Michaels corrections. Script runs well in Top, Front, Back, Right, and Left windows, if both points are picked
in the same window. For 3D view, some additional "plane restriction" is still needed.

Edit May 11, 2013. Added "GetCircle" behavior for selecting points in two different views. The end point is selected first, then the start point.
Edit May 13, 2013. Made two slight changes. Modified cplane z value of ending point to match clothoid curve. Also selection of 2 points in 3d view
with different z values, and same x,y values caused a nonfatal Moi error, so now, if 2 such points are selected, return occurs, time to pick 2 new points.
Was not able to use the Alert message in the if statement.

The script works well in Top and Front view, in 2 dimensions, but picking the two points in different views does not work properly.

Hi Brian, your screenshot above looks really cool, like some kind of elegant art deco plant!

re:
> but picking the two points in different views does not work properly.

Do you need the 2 points to be all on one single plane? Do you want it to behave like the Circle command where you can pick in 2 different views but the first pick establishes a kind of 'base point" and then the second pick will go on a plane parallel to the view that it's picked in but with the plane passing through the first pick?


If you want something like that check out GetCircle.js, it sets up that "make this point on a parallel plane to the view but going through the fist picked point" type of pick in the GetCircleRadius function, like this:

	pointpicker.restrictToPlaneThroughPt( pointpicker.pt, false );
	pointpicker.stickToSurfacesMode = 'max';
	pointpicker.disableVerticalStraightSnap = true;

The "stick to surfaces" mode the first pick on a surface to use a plane aligned with the surface normal - that's why you can draw a circle onto the side of a box in the 3D view for example, or onto a sphere with the first pick defining the plane as being tangent to the sphere at that point.

The disable vertical straight snap part is to avoid getting a vertical tracking snap line coming off the sphere normal when doing the "on surface" type circle drawing.

- Michael

Thank you very much Michael.

Your code seems to be just what is needed.
I'll try it out after work.
The two selection points need to be on a 2d plane.
The plane needs to be addressable in x and y coordinates, in order to plot the curve created with points
derived by mathematics with x and y values, which I guess is what the var cplane = pointpicker.ptframe; does.
I do not know why it did not work with the Right view.

Or maybe I can set a frame on the 2d plane?

I think that the catenary curve could also be done this way...

- Brian

Hi Brian,

> The two selection points need to be on a 2d plane.

So there are a few different possible ways you can do this, but each way will involve setting up pointpicker restrictions.

It's possible to make the points go on one completely predefined plane like only on the world x/y plane. But then someone has to be able to get at that plane in the view they are working with, like if they had a maximized Front view they couldn't get stuff created there because they plane they need to pick on is exactly edge-on to that view. Basically their picks would have no effect until they switched to a view that was not viewing that plane exactly at 90 degrees to it. So it's kind of nice to have the plane pick up something about what is being picked rather than totally hard coded.

Then the possible ways it can be controlled by picks is to either take the plane from the first point pick and then restrict the second point pick to that particular plane, or to do like the circle command does (and like I described above), where the first pick just sets up a "through point" and then the second pick defines the plane from the view the second point is picked in, and the plane taken is one that is parallel to the second pick's view but going through the first pick point. That allows for some flexibility with setting the depth of the plane with the first pick basically.


> The plane needs to be addressable in x and y coordinates, in order to plot the curve created with points
> derived by mathematics with x and y values, which I guess is what the var cplane = pointpicker.ptframe; does.

Once you do: var cplane = pointpicker.ptframe; cplane will contain a coordinate frame object that has it's origin at the picked point and has the x/y axis directions coming from the grid plane of the viewport that it was picked in. You can then use that coordinate frame to plot 2D points by doing: var pt = cplane.evaluate( x, y, 0.0 );


> I do not know why it did not work with the Right view.

Now I'm a little confused, you wrote above that it did work ok if both picks are in the Right view? With both picks in different views probably you are getting 2 points not on the same plane and causing problems from that.


> Or maybe I can set a frame on the 2d plane?

Basically a frame _is_ a 2d plane - it's an origin point with x/y/z axis directions, the origin and x/y axis directions form a plane, and if for example you want to create a point in world coordinates that has local coordinates at x = 5, y = 2 in that frame, you call frame.evaluate( 5, 2, 0 ); (the 0 is for the z value to use for elevation above or below the plane origin).

- Michael

Hi Michael,

Thank you for your help. I'm still studying your messages.



Installed MoI version 2 on the new hard drive.
The jscript picked up the error in the following code at line 334(plus)

return { 'K': K, 'Kprime': Kprime, 'L': L, };

Note the final comma after L -----The comma should not be there.
This error was not found in the current MoI Beta3 javascript. (webkit?)

Removed the comma, and the script runs in Moi version 2, when both points are selected in Top View plane, z=constant value,
or Front View, y=constant.

Right view does not work properly. Either var cplane = pointpicker.ptframe;, and evaluate do not work properly in
Right view, (1% probability?), or the script is defective, (99% probability?).

- Brian

Hi Brian,

> Installed MoI version 2 on the new hard drive.
> The jscript picked up the error in the following code at line 334(plus)
>
> return { 'K': K, 'Kprime': Kprime, 'L': L, };

This probably depends on which version of Internet Explorer and JScript.dll are installed on your system that v2 ends up using.

What you have there is a "trailing comma", and I think it's supposed to be ok but some versions of the IE scripting engine do not allow it. This difference in behavior in IE scripting compared to other script engines sometimes causes grief for web developers, if you do a web search for "jscript trailing comma" you can find some stuff about it.


> Right view does not work properly.

I'll take a look and see if I can figure out what's going on.

- Michael

Hi Brian, ok so I think the problem is the script is not quite getting the correct 2D coordinates for doing your calculations.

At the start of your function buildClothoid you've got some calls to cplane.evaluate() there - but that's probably not right, you use cplane.evaluate() for converting from the frame's "local coordinates" into world coordinates.

At that point in the script for buildClothoid() you actually need the reverse I think - the points given to you by the pointpicker are in world coordinates and you want to get them into 2D coordinates within that cplane's local coordinate system before you start doing calculations with them. Then when you're done doing your calculations that's when you want to use cplane.evaluate() to convert from 2D local cplane coordinates back into world coordinates.

The .evaluate() call is only for doing the last part (2D local into 3D world conversion) - you need something different for the first part (3D world into 2D local cplane conversion).

For doing the 3D world into 2D local conversion you can get the local 2D plane coordinate from a 3D world coordinate by doing cplane.distancex() and cplane.distancey() which get the signed distance of the given 3D point from the x-axis plane and y-axis plane of the frame, something like this:

var localx = cplane.distancex( worldpt );
var localy = cplane.distancey( worldpt );

So if you use that in the start of buildClothoid() it should then give you uniform behavior in all views, here's an updated buildClothoid function that should work:

function buildClothoid(BasePt, theta0, OtherPt, theta1, numintervals, cplane)
{
//Convert to cplane frame.
	var base_x = cplane.distancex( BasePt );
	var base_y = cplane.distancey( BasePt );
	
	var other_x = cplane.distancex( OtherPt );
	var other_y = cplane.distancey( OtherPt );
	
	var deltax = other_x - base_x;
	var deltay = other_y - base_y;
	var r = Math.sqrt( (deltax * deltax) + (deltay * deltay) );
	var phi = Math.atan2(deltay, deltax);
	var deltaphi = normalizeAngle(theta0 - phi);
	var deltatheta = normalizeAngle(theta1 - theta0);
	
	var Aguess = 2.4674 * deltatheta + 5.2478 * deltaphi;
	var A =	findA(Aguess, deltatheta, deltaphi);
	var a = 0.0;
	var b = 1.0;
	var maxR = 50; //maxrecursion
	var L = r/ adaptiveSimpsons(A, deltatheta, (deltaphi + Math.PI/2), a, b, maxR );	
	var K =	(deltatheta - A) / L;
	var Kprime = (2*A)/(L*L);
	
	return 	{ 'K': K, 'Kprime': Kprime, 'L': L };
}	

Hope this helps!

Looks like some cool stuff! I wish I had more time to experiment with some stuff in this same area as well myself.

- Michael

Thank you very much Michael.

I was using the spur gear script for a "pattern"

What you are saying makes perfect sense.

hmm... I'm thinking that BasePt is at cplane 0,0,0, so base_x = base_y = 0 (?)

Report: Made the recommended changes, and they work correctly.
Uploaded corrected script.

Still need to work on other point picking permutations.

-Brian

Hi Brian, you're welcome!

> hmm... I'm thinking that BasePt is at cplane 0,0,0, so base_x = base_y = 0 (?)

Yup, I think that should be true, you could just set those to 0 if you want in this case since you know BasePt is right at the cplane's origin point.

- Michael

Added "GetCircle" selection behavior for point selection in two different views.
The end point is entered first, then the start point.
Posted updated script to first post.
It looks like only about 6 or less downloads have occurred, so not very many people have the older versions.

I like the new iteration.

"The endpoint is selected first"

Works as before. If you select the start first, the direction in the viewport quadrant will produce different results! Kindof neat.

Thank you BurrMan.

I was just comparing the curve to a 2d Blend curve.

I wonder what code it would take to Bind and move an end point around?

- Brian

Posted version 2b, with two slight changes. See first post for details.

Hi Michael

Is there some way to get the end point tangent of a curve, by script?
I was thinking of correcting the interpcurve version of a clothoid curve between two existing curves, and to
correct the slight errors in the beginning and ending tangents by doing a MoI Blend between the start point, and the second interpcurve point,
and also a second Blend between the next to last point, and the end point.

Or maybe there should be extra points between the beginning and first point, and also between the next to last point, and the end point?

I have read that for these types of curves, it is not possible to perfectly display the curves by NURBS, but only to within some tolerance?

Also wondered if you will be improving the slide bars for scripts, as the sliders that you do for your factory commands work so much better?

Thank you

-Brian

Hi Brian,

> Is there some way to get the end point tangent of a curve, by script?

Sorry no there is not currently any curve tangent evaluation set up for script access.


> I have read that for these types of curves, it is not possible to perfectly display the
> curves by NURBS, but only to within some tolerance?

Yeah that's pretty common, usually any specific kind of curve can't be 100% exactly represented by a different kind of curve but can be approximated using a bunch of points to some tolerance level.

NURBS curves can exactly represent conic section curves though.


> Also wondered if you will be improving the slide bars for scripts, as the sliders
> that you do for your factory commands work so much better?

Probably what you're running into here is that the script is running in a separate process so every call that it makes into MoI has to do some inter-process communication. But it's also why a command script can't easily crash MoI, because the separate process that the script is running in can be just torn down without really needing any cooperation from the script itself.

One thing you could try is to put more of the logic into a <script> tag inside the .htm file - that will run inside of the main moi process and won't have to do any inter-process communication when it makes calls into moi.

- Michael

Michael, thank you very much.
I'll have to learn more about how *.htm files work, and how they work with MoI.

-Brian

Hi Brian, *.htm files for commands in MoI are the same as HTML files that are displayed in web browsers, the upper-right area of MoI's main window basically has an embedded web browser there that loads the HTML content. You can also have script in that HTML content same as you can in HTML files that are displayed in a regular web browser. There are a few different ways that scripts can be declared on a web page, it's possible to have an event handler declared in something like an onclick="" attribute on a button but if you have some pretty big functions it's more typical to have those functions declared in a <script> block that you put in the <head> portion of the HTML page.

The command script (the .js file part of a command) can call script functions that are in the HTML page, the root object of the HTML page is available under moi.ui.commandUI , and any script functions declared on that page end up as global variables there, so if you have a function in HTML called blah() like this:

    <html>
        <head>
              <script>
                  function blah()
                  {
                      .....
                  }
               </script>
        </head>
     
      .......

That function defined in the HTML file can be called from the .js file by: moi.ui.commandUI.blah();


I've attached an example where I've edited your Clothoid2ptDraft2b command to move a bunch of the script construction logic over into the HTML file which is then called in this manner from the .js file.


The script code that is declared inside of the HTML file will have fairly different performance characteristics than the code that's run in the .js file - that's because the HTML page runs directly inside of the main MoI.exe process, while a regular command's script file runs in a separate process: moi_commandprocessor.exe and it talks to MoI.exe whenever you make calls into any MoI object. The main reason for this inter-process communication is to make it harder for scripts to be able to crash or lock up MoI, with the script being in a different process it's a lot easier for MoI to forcibly terminate that script at any time without anything happening to the main moi.exe process.

Script code that you run directly inside of the main MoI process will have less overhead to each MoI object call that's done in it, but it will also be easier for the script to lock things up if it goes into a tight loop or things like that as well.


In the future I'd like to make a type of "script factory" mechanism that would make it possible to write some script that would run in a separate worker process but have in-process calls for geometry access and vector math type functions so that the script would not have as much overhead.

The way regular MoI commands are set up though the scripts are mostly used for control flow logic and not for doing heavy duty calculations directly in a script - heavy calculations happen in the geometry factories that are currently written in C++ and they have that kind of direct geometry access even though they run in a separate worker because any geometry that's being used by the factory is sent over to the worker process so that it can then access it locally as it does calculations on it.


So anyway basically right now things are not really optimized for the case of doing heavy calculations directly in script, but you may get some lower overhead for scripts that are contained inside of the HTML part of the command which is normally where the UI controls go. You can have script code in there as well though if you want by using <script> tags. Hope this explains a bit more of how things are currently set up to work.


- Michael

Michael, thank you very much for these details.
I'll study them after work...(I've been to busy to do much lately.)

There is a new paper called "Super Space Clothoids," which are 3D, but the math is very difficult.
http://hal.inria.fr/docs/00/84/03/35/PDF/eulerspiral.pdf

-Brian

Made in France! :)