Animate the PI = 4 experiment

.

NOT a draft final - Testing only.  

I added two balls of radius w/2 to the track starting positions (in the init function). The animate function I include below directs them through their tracks. The two ball cross their marks close to the same time. The image shows the straight ball is slightly behind the curved. They cross their final 4r markers and are back at and past their starting positions without a pause.

This is neither a draft final nor desired product. There is no keyframing; no time checking; they are on an infinite loop, they soon drift apart. I had to try, and was happy to find I could add the linear and rotation animations without too much difficulty.

Code:


function animate() {

 requestAnimationFrame( animate );
 
 sphereC.position.x += 0.32;
 distL += 0.25;
 if ( (sphereC.position.x > 0) && ( sphereC.position.y = -r )){
 inLoop = true;
 };
 if ( inLoop ) {
 inLCounter += 1;
 currentAngle += 0.004; //
 rotation = currentAngle * Math.PI;
 sphereC.position.y = -r*Math.cos(rotation);
 sphereC.position.x = r*Math.sin(rotation);
 };
 if ( (sphereC.position.x > 0) && ( inLCounter > 500 )) {
 sphereC.position.set( -2*r, -r, 0 );
 inLoop = false ;
 inLCounter = 0 ;
 };
 sphereS.position.x += 0.32;
 if ( sphereS.position.x > 8*r ){
 sphereS.position.set( -2*r, -r-q-w, 0 );
 };

 renderer.render( scene, camera );

}


.

.

Incremental improvements are in order.

I’m building on yesterday’s results, including rationalizations. For example, all the animation function does is to guide the balls through their tracks; I believe that meets your criteria for 'the Controller'. Fine tuning the animation function seems like a good way to advance my more modest effort. I made the spheres large and wireframe as a necessary pre-requisite to view the attempts of my next intended animation - rolling.  Oops, the radius was 20, now it’s back to one. I used the continuous loop, trial and effort, and binary number divisions to come up with roughly equal distances, angular and linear.
var angInc  = what I add to the currentAngle the angular position of the ball on the circular track, the angle increment = 0.006;
var forInc  = the forward straight increment, x + = 0.0240384618125; // a tiny bit fast
I need a reality check. How are those numbers related? Given the angular addition of 0.006, how can I calculate the corresponding straight segment increment? That’s where I am at the moment.

Feel free to direct me otherwise.
.

If that angle represents the roll of the ball caused by its own motion, then the straight line increment represents the circumference of the ball, so they are related by PI. Which is backed by their mathematical relationship: 0.0240384618125 / 0.006 = 4.0064103020833.

However, that is the wrong PI to use, and that is why it is a bit fast. This calculation should use 3.14 because it is a geometrical calculation. I can't fault you for using PI=4 since you were looking at a ball in motion. I explicitly stated above that if motion is involved then use 4, but I should have been a lot clearer.

When something is in motion and that motion is along a circumference, then you use PI=4 when making calculations about the motion of it.

In this case though, we want to find the straight line distance covered during the same time that the ball has rolled a given angle. Which is just another way of asking for the equivallent straight line distance of the circumference over that angle.

Maybe another way to state the difference in PI's is that PI=3.14 is used for distances, but PI=4 is used for velocities.

So if you are using an equation containing PI and that equation also contains velocities, then it probably needs PI=4. This gets very tricky when an equation contains both distances and velocities, and even more so if you break the velocities down into distances so they are hidden. If there are multiple PI's, then they may actually be different versions of PI, so you may need 3.14 and 4 in the same equation. This is why it is so critical that the math is backed by good theory. Only the theory can tell us where each part comes into the equation and how to ensure that each part is treated correctly.

Here's another way to look at it. PI=3.14 is trying to approximate the circumference. It doesn't care how that circumference came to be, it just wants to know the real length of it. PI=4 is trying to approximate motion along the circumference. It does care about how that motion came to be, because it wants to know the real forces required to move along it.

Hi guys, long time no see. I hope you're well and fine

Just a few hopefully constructive remarks where I find your wording confusing, following what Miles wrote about differing between a length and a distance:

"A length is a given parameter that does not include motion or time. It is geometric only. But a distance is a length traveled in some real time, so it requires motion. A length is not kinematic, while a distance is. The circumference 2πr is a length. The circumference 8r is a distance."

(http://milesmathis.com/are.html)

On the other hand, velocity is length covered by a moving object over time. This is just to say that distance and velocity both already imply motion / kinematic situation, so Pi=4 would be used to calculate their traveled distance in both cases.

"A static circle and a circle drawn by motion are not the same. The number π works only on the given static circle, in which there is no motion, no time, and no drawing. Any real-world circle drawn in time by a real object cannot be described with π." (http://milesmathis.com/pi2.html

In my own interpretation of all this:


-> a straight line/track is simply the length of circumference of the circle described by the other track; expressed in r(adius). So it implies a static measurement, which should be done with Pi=3,14 when setting up the experiment. In other words, the length of curved path (when straightened out) is measured 21% longer than the length of straight path.

When motion is involved, the length becomes a distance. But there is a big difference between the two paths in the above experiment: one path also involves changing the moving ball's position on both y-axis and x-axis, while the other one is only about the ball's position change along its x-axis. So any distance and/or velocity along the curved path should be calculated using Pi=4 when looking at the moving ball. Such calculation then corresponds to the visual effect of apparent "slowdown" of the ball following the curved path (as noticed in SteveO's YT video) : as the ball moves on both x- and y-axis at the same delta t(ime) while inside the curve, it appears to our eyes as it slowed down, which the math correctly shows as true if we apply Pi=4 for the curved section's calculations of ball's linear velocity. But the slow down is only an illusion: if we calculate delta d(istance) for both x- and y-axis over delta t, and sum them up, we get the same delta d of the other ball moving along the straight path in delta t.

I think this means that the velocity of the ball is accelerated while inside the curve? Which then leads to angular velocity and momentum?

I'm absolutely clueless how to include this properly into the Airman's code...

.

Code:


function animate() {

 requestAnimationFrame( animate );
 
 var velocity = 1;
 var angInc = velocity * 0.015707963267949; // PI rad/200
 var forInc = velocity * 0.0200675; //= 0.02; slow // 0.020125;  fast
 sphereC.position.x += forInc;
 if ( (sphereC.position.x > 0) && ( sphereC.position.y = -r )){
 inLoop = true;
 };
 if ( inLoop ) {
 inLCounter += 1;
 currentAngle += angInc;
 sphereC.position.y = -r*Math.cos(currentAngle);
 sphereC.position.x = r*Math.sin(currentAngle);
 };
 if ( (sphereC.position.x > 0) && ( inLCounter > 300 )) {
 sphereC.position.set( -2*r, -r, 0 );
 console.log( 'inLCounter = '+ inLCounter +'.');  // inLCounter for the loop equals. = 400
 inLoop = false ;
 inLCounter = 0 ;
 };
 sphereS.position.x += forInc;
 //sphereS.position.x += 0.02403847; // commentary above
 if ( sphereS.position.x > 8*r ){
 sphereS.position.set( -2*r, -r-q-w, 0 );
 };

 renderer.render( scene, camera );

}


Current animate function. Corrections have, and hopefully will continue to be made.

Hi Vexman. Good to hear from you. Every year or so I keep coming back to PI=4, each time I’ve read Miles’ papers again and think I know the subject, needless to say, I still have plenty to learn.

I corrected a big error in my current angle calculation I’m sure you noticed. I made another ‘correction’, my initial choice of 0.006 as an incremental angle was arbitrary and poor. The total number of increments was between 333 and 334 which made no sense, This time I tried dividing the circle – 2PI rads by 400 (= 0.0157rad) and straight distance 8, by 400 (0.02) .

But that didn’t work. Believe it or not, the PI=4 layout is a lot like an old oscilloscope output display problem. I can synchronize two moving blips along the two tracks by controlling the values of two controls: angle increment and forward increment. Actually I keep var angInc constant and vary var forInc until I arrive at simultaneous tracks, I then look at the values.

var angInc = 0.015707963267949; // 2 PI rad/400
var forInc = 0.0200675; // 0.02 is too slow.

I wish I could explain why I deviate so far from 0.02. I very much enjoy working on such efforts and feel that the only way I can contribute is through dedication and perseverance.

For the time being Nevyn, I can only imagine rolling on the straight track.
.

Thanks, Vexman, calling it length instead of distance is a bit clearer. I was struggling to get the right words down and even started to get myself confused on exactly where we should be using PI=4 in this setup. In a loose kind of way, I've been assuming that PI=4 is about energy, where-as PI=3.14 is about length.

Airman, one thing to realise about the roll of the ball is that it rolls around the bottom/outer line and not the center line. So make sure that you are using the right radius to calculate that circumference. I haven't checked that, just thought I'd mention it in case. If that is part of the problem, then don't add that outside track to the data, just calculate the difference between the center track and the outside track by using the radius of the ball.

Another thing to mention is that the way you are creating the current code is leading to an animation rather than a simulation. But don't worry about that right now. We will just create another Controller to implement this with physics rather than animation. That's one of the great things about using the MVC architecture.

The rolling of the ball should not be a big problem. It should be quite static. You should be able to just give it a rotation and let it go. If the velocity is constant, ignoring curvature, then the roll should be constant too. They are inextricably linked.

For the record, I made an error in approximation of ratio in my previous post when looking at motion vs static picture. The correct ratio is Pi(static) / 4= ‭0,78539816339744830961566084581988‬ -> it is 21,460183660255169038433915418012‬ % difference

Airman : "var angInc = 0.015707963267949; // 2 PI rad/400
              var forInc = 0.0200675; // 0.02 is too slow. "

The ratio between Pi (static) and Pi (kinetic) should always be constant; ‭0,78539816339744830961566084581988‬. in your case I calculated 0,7827563606801545 as the ratio, which is slightly below the actual value. But the focus should be at another issue, in my opinion.

Airman: "This time I tried dividing the circle – 2PI rads by 400 (= 0.0157rad) and straight distance 8, by 400 (0.02) . But that didn’t work."

I think the issue is about the wrong aspect you were looking at. You took static circle's circumference = length and divided it by 400, while looking at the ball in motion. Here it should be PIk applied. In my opinion, the angle increment is 2*Pik / 400 = 0,02 rad within the circle.

Applying the same approach for the straight path, we are looking at 314,15926535897932384626433832795‬ incremental steps. Expressed in rad, It should be calculated as 2*PIs/314,159265... = 0,02.

In essence, incremental steps expressed in rad should be identical in both cases summing up to 360°. By the end of the event, the ball going through the curved path traveled cca 21,5 % more length in the same amount of time.

.

Vexman wrote. The ratio between Pi (static) and Pi (kinetic) should always be constant.

Airman. Here're the latest angleIncrement and forwarIncrement values.
var angInc = 0.015707963267949; // 2*PI rad/400
var forInc = 0.02008032128500; // 0.02 is too slow.

Absolutely, I agree, the forward increment should be 0.02. I’ve made a coding error somewhere that causes the 0.0000675 difference. I’m not suggesting otherwise.

So in addition to the latest forInc I changed 3 equality checks from strictly greater than (>) to greater than or equal (>=).
if ( (sphereC.position.x > 0) …
to
if ( (sphereC.position.x >= 0) …
No effect.

Showing centers of balls on the centerlines of the tracks.

Nevyn wrote. Airman, one thing to realise about the roll of the ball is that it rolls around the bottom/outer line and not the center line. So make sure that you are using the right radius to calculate that circumference. I haven't checked that, just thought I'd mention it in case. If that is part of the problem, then don't add that outside track to the data, just calculate the difference between the center track and the outside track by using the radius of the ball.

Airman. I believe the animate function only uses the track centerlines. The balls’ centers are always advanced or re-positioned onto the track centerlines. Here are the initial set commands:
sphereC.position.set( -2*r, -r, 0 );
sphereS.position.set( -2*r, -r-q-w, 0 );

Both spheres advance thru their straightaways strictly along +x - the forward straight increment
sphereC.position.x += forInc;
sphereS.position.x += forInc;

Once in the loop, sphereC advances around the circular track according to its current angle at radius r.
currentAngle += angInc;
sphereC.position.y = -r*Math.cos(currentAngle);
sphereC.position.x = r*Math.sin(currentAngle);

I don't believe an outside radius nor poor choice of PI is my problem. I believe you identified it when you indicated the need for proper boundary transition detection and response - like proper collision handling. In my case, I’m guessing the ball must initially overshoot the initial circular track section beginning at 6 o’clock. Other than taking the time to chase the problem further - I'll go ahead and try to properly identify the circular track boundary’s exact position. Beginning with determining whether the ball is within a forInc distance from the straight/circular boundary at (0,-r,0).

Vexman wrote. In essence, incremental steps expressed in rad should be identical in both cases summing up to 360°.

Airman. Yes. You succinctly described it before I could put it into words. I’m doing what StevenO did in his PI = 4 experiment, marking the equal velocity/distance sections of the circular track and straight tracks – showing both balls crossing their corresponding marks at the same time. The only difference is, in my math I’m subdividing the tracks into 400 sections instead of 4. In doing so I avoid using PI(g) or PI(k). If I’m mistaken please show me where the animate function uses PI. Calculating sphereC’s track positions with sin and cos and currentAngle is a lot simpler than working with forward vectors and distance calculations, although I would enjoy them more. Solving the problem in this manner – both balls crossing their 400 corresponding track markers at the same time in no way diminishes the kinematics of it.
.

Airman wrote:I’m subdividing the tracks into 400 sections instead of 4. In doing so I avoid using PI(g) or PI(k). If I’m mistaken please show me where the animate function uses PI.

I'm not familiar with program coding, but as much as I could understand from the code you wrote:

currentAngle += angInc
sphereC.position.y = -r*Math.cos(currentAngle);
sphereC.position.x = r*Math.sin(currentAngle);
...where:
var angInc = velocity * 0.015707963267949; // PI rad/200
var forInc = 0.02008032128500; // 0.02 is too slow.

The way I understand it, you have var angInc set as "velocity * (fixed value of) 0,0157...rad "; the fixed value was calculated by using PI rad / 200. This is where PI(g) was used to set the fix value. When you're calculating SphereC's position using sin or cos and currentAngle, you're indirectly calculating its position using PI(g).

Airman wrote:Both spheres advance thru their straightaways strictly along +x - the forward straight increment
sphereC.position.x += forInc;
sphereS.position.x += forInc;

In my opinion, the straight path should have the increment of 2PI(g)/400 = 0,015707963267949. When you parse the straight track by 400 incremental steps, the ball on the straight path would travel over 2Pi(g)r length, which is what we can observe.

Airman wrote:Once in the loop, sphereC advances around the circular track according to its current angle at radius r.

currentAngle += angInc;
sphereC.position.y = -r*Math.cos(currentAngle);
sphereC.position.x = r*Math.sin(currentAngle);

You're calculating y-axis position of SphereC by using PI(g) for radial increment and this is where I think you should be using PI(k) instead. That would set increment at 0,02 rad. In same delta t, the ball going through the curved path travels over 8r length and the ball going over the straight path travels 2Pi(g)r -> ratio Pi(g)/PI(k) is satisfied -> and that corresponds to ratio forInc / angInc . If the code follows such math, I think it should work.

Airman, I forgot to mention, I don't think you've made a coding error that causes the difference. When calculating forInc, I think you should try not to round the fixed value at 15th decimal, which then changes the Pig/PIk ratio. I'd suggest you should try and use 100th decimal (or even bigger). It would help maintain the ratio more-or-less constant, considering there are 400 calculations during a single track run.

You can't use 100 decimal places using standard numerical representations in programming languages. There are ways to use an arbitrary number of decimal places, but they would not be used in this type of situation (for efficiency concerns).

If this problem is related to the change from straight section to curved section, then you need to setup the animation so that the transition point is always on a frame change. Alternatively, you have to determine where the change is and calculate both the straight section and the curve for that particular frame (doing the same when it exits the curve too). The latter is more resilient and can handle arbitrarily sized sections, while the former requires that the sections be of certain sizes to accommodate the distance moved each frame which may get tricky because the number of divisions may not work for the curve as it does for the straight.

I recommend calculating both sections in the same frame because that is going to be required when this is done using physics rather than animation. Maybe a better way to say that last part is to be using dynamic calculations rather than pre-calculated data. In essence, they both use physics, but dynamic calculations only take the current position and velocities into account to calculate the changes to the next frame. Where-as an animation just breaks it down into small sections and treats them individually. The difference is kind of like 'the ball is moving' as opposed to 'the ball is being moved'. They may end up looking the same, but dynamic calculations are so much more robust.

For example, the Particle Interaction Model uses dynamic calculations which allows it to handle any situation. We can place protons and neutrons in any configuration and the system still works. Imagine trying to pre-calculate all of those scenarios. A nightmare.

I didn't want to stop your progress, as it is still beneficial to work it out as you are. Once you have a good understanding of the problem, it should make it easier to see how to make it dynamic.

.

Code:


function animate() {

 requestAnimationFrame( animate );

 var velocity = 1;
 var angInc = 2*Math.PI/400;
 var forInc = 8/400;
 clicks += 1;
 if (( sphereC.position.x + forInc >= 0 ) && ( sphereC.position.y = -r ) && ( inLoop = false )) {
 overShot = sphereC.position.x + forInc - 0;
 var fRatio = overShot/forInc;
 currentAngle = -angInc + fRatio*angInc;
 };
 sphereC.position.x += forInc;
 if ((sphereC.position.x >= 0) && ( sphereC.position.y = -r )){
 inLoop = true;
 };
 if ( inLoop ) {
 currentAngle += angInc;
 sphereC.position.y = -r*Math.cos(currentAngle);
 sphereC.position.x = r*Math.sin(currentAngle);
 };
 if ( (sphereC.position.x >= 0) && ( clicks > 500 )) {
 sphereC.position.set( -2*r, -r, 0 );
 currentAngle = 0;
 inLoop = false ;
 clicks = 0 ;
 };
 sphereS.position.x += forInc;
 if ( sphereS.position.x >= 8*r ){
 sphereS.position.set( -2*r, -r-q-w, 0 );
 };
 renderer.render( scene, camera );

}


Vexman, defining;  var angInc = 2*Math.PI/400;  // Worked perfectly!

Nevyn, please note I also went ahead and included a circle track boundary detector loop to calculate and include the overShoot just before it happens. I think that does the same as key framing but I haven't really look at your last post.

Status. It appears I can resume forward progress. To be perfectly clear, as our reader can tell, I’m learning as I go along. My console revealed variables at inexplicable counts, and so I had to change them as well but have yet to check.  

I still need to ponder your last post, both of you. Thanks for restoring my humility.
.

Nevyn, thank you for correcting me, I learned a new thing.

Airman, I don't want to be pain in the arse, but I think you have forInc and angInc reversed. In my opinion, angInc should be 8/400, and forInc should be 2*Math.Pi/400. Meaning, the ball going through the curve travels 8r and ball over straight path travels 2*Math.Pi*r .

Something I don't like about that code is that velocity is defined but never used, and time is never mentioned at all. These should be the front-and-center variables, along with distance. Everything should be revolving around them.

I recommend you start another function, maybe call it animateDynamic or something to that effect, that can be used in place of the current animate function. You can swap them as you need while you develop each one. This version will strictly use velocity. Here is the outline of the algorithm:

Code:


1) Get current position of ball
2) Calculate next position just using straight line velocity, we only care about length here, not actual position
3) Use current position and next position to determine which track sections we need to handle,
  this is why I wanted the length of each section to be in the data
4) For each section, in the order the ball will traverse them:
  4.1) Calculate the end position on this section,
          the end position is based on the time left for this frame,
          or the end of the section, which ever is closer
  4.2) Calculate the time it takes to move between the current and end positions
  4.3) Move ball to end position
  4.4) Subtract time for that change from total time of this frame change (the total time per frame should be a fixed value, not real time)


3) and 4) can actually be combined into the for loop declaration, but it might get tricky, so keep them separate until you can see how that might be done. It basically comes down to while I have time left, give me another section.

4.1) and 4.2) are where you need to handle the difference between a straight and a curve.

I think this algorithm will end up much cleaner

.
Good progress today. I made several changes - all that's left are the rolling animations for the ball in the curved track. I look forward to completing this version and moving to the more dynamic code. Correct, I didn't use velocity, I hadn't gotten to it yet, today I did.
1. Verified synchronized tracks. I created a console variable, difClick to verify the two tracks were synchronized – starting and stopping at the same times. The 2 code lines will be left in place but commented out.
2. Track velocity. increments = 400 was just for starters. Since the two tracks are synchronized, increments can now function as an inverse velocity control. Choosing 1000 increments, the two balls take about twenty seconds to complete their tracks. The balls complete 250 increments in about 5 seconds.
3. Moved all the var declarations out of the animate function to the top of the script.

Code:


<script>

 var camera, scene, renderer;
 var mesh, sphereC, sphereS;
 var r = 1; // Track radius
 var cTrackCenter = new THREE.Vector3( 0, 0, 0 ) ;
 var q = .2; // track separation
 var w = 0.75 * r; // track width
 var bRadius = w / 2 ;
 var bCircum = 2 * Math.PI * bRadius;
 var increments = 250;
 // Inverse velocity. The greater the number of increments the slower the ball's velocity along the track.

 var forInc = 8/increments;
 //var forInc = 2*Math.PI*r/increments;
 var angInc = 2*Math.PI*r/increments;
 //var angInc = 8/increments;

 var ang2rot = 10*r/bCircum; // the number of rolling rotations
 var ang2Inc = 2*ang2rot/increments; // the rolling ball is rolling
 //var cSphereAxis;

 var curTrackAngle = 0;
 var curBallAngle = 0;
 var inLoop = false;
 var overShot, fRatio;
 var cClicks = 0;
 var sClicks = 0;
 
 init();
 animate();
 
 function init() {

 camera = new THREE.PerspectiveCamera( 70, window.innerWidth / window.innerHeight, 1, 1000 );
 camera.position.set( 3*r, 0, 5*r ); // ( 3*r, -r, 5*r );
 
 scene = new THREE.Scene();
 
 // Set the background color // default black
 // scene.background = new THREE.Color('#0000FF'); // #009900 pool table green // #0000FF nice high contrast blue //
 var sphereMat = new THREE.MeshBasicMaterial( { wireframe: true, color: 'yellow' } );
 var material = new THREE.LineBasicMaterial( { color: 'yellow' } ); // markers
 var MAT_LINE_CP = new THREE.LineBasicMaterial( { color: 0x00cc00, linewidth: 0.25 } ); // distances
 
 // 3 concentric curved paths
 for(th=1;th<=360;th+=1) {
 var radians1 = (Math.PI/180) * th;
 var radians2 = (Math.PI/180) * (th + 1);
 if (th === 359) { radians2 = (Math.PI/180) }
 for ( i = -1; i < 2; i++ ) {
 configRadius = r + i*w/2;
 var XYPlaneLine = new THREE.Geometry();
 XYPlaneLine.vertices.push(   //viewing x and y.
 new THREE.Vector3( configRadius * Math.cos(radians1) + cTrackCenter.x, configRadius*Math.sin(radians1) + cTrackCenter.y, 0 ),
 new THREE.Vector3( configRadius * Math.cos(radians2) + cTrackCenter.x, configRadius*Math.sin(radians2) + cTrackCenter.y, 0 ));
 var XYLine = new THREE.Line( XYPlaneLine, MAT_LINE_CP);
 scene.add(XYLine);
 };
 };
 // S track markers
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( 2*r*Math.PI, -r-q-w/2, 0 ) );
 geometry.vertices.push(new THREE.Vector3( 2*r*Math.PI, -r-q-1.5*w, 0 ) );
 var line = new THREE.Line( geometry, material );
 scene.add( line ); // PI marker
 for ( j = 0; j < 6; j++ ) {
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*j, -r-q-w/2, 0 ) );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*j, -r-q-1.5*w, 0 ) );
 var line = new THREE.Line( geometry, material );
 scene.add( line ); // Section markers
 }
 // C track straight section markers
 for ( m = 0; m < 2; m++ ) {
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*m, -r+w/2, 0 ) );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*m, -r-w/2, 0 ) );
 var line = new THREE.Line( geometry, material );
 scene.add( line );
 }
 for ( k = -1; k < 2; k++ ) {
 // S track lengths: top edge, centerline and bottom edge
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r, -r-w-q+k*w/2, 0 ) );
 geometry.vertices.push(new THREE.Vector3( 8*r, -r-w-q+k*w/2, 0 ) );
 var line = new THREE.Line( geometry, MAT_LINE_CP );
 scene.add( line );
 // C track lengths: top edge, centerline and bottom edge
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r, -r+k*w/2, 0 ) );
 geometry.vertices.push(new THREE.Vector3( 0, -r+k*w/2, 0 ) );
 var line = new THREE.Line( geometry, MAT_LINE_CP );
 scene.add( line );
 }
 // C track markers
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( r-w/2, 0, 0 ) );
 geometry.vertices.push(new THREE.Vector3( r+w/2, 0, 0 ) );
 var line = new THREE.Line( geometry, material );
 scene.add( line ); // C track One Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( 0, r+w/2, 0 ) );
 geometry.vertices.push(new THREE.Vector3( 0, r-w/2, 0 ) );
 var line = new THREE.Line( geometry, material );
 scene.add( line ); // C track Two Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -r-w/2, 0, 0 ) );
 geometry.vertices.push(new THREE.Vector3( -r+w/2, 0, 0 ) );
 var line = new THREE.Line( geometry, material );
 scene.add( line ); // C track Three Marker
 // Balls
 var sphereGeom = new THREE.SphereGeometry( bRadius, 8, 8 );
 sphereC = new THREE.Mesh( sphereGeom, sphereMat );
 sphereC.position.set( -2*r, -r, 0 );
 sphereS = new THREE.Mesh( sphereGeom, sphereMat );
 sphereS.position.set( -2*r, -r-q-w, 0 );
 var ballOne = new THREE.Object3D();
 ballOne.add(sphereC);
 var ballTwo = new THREE.Object3D();
 ballTwo.add(sphereS);
 scene.add( ballOne, ballTwo );
 // scene.rotation.x += -Math.PI/6;
 scene.rotation.x += -Math.PI/6;

 renderer = new THREE.WebGLRenderer();
 renderer.setPixelRatio( window.devicePixelRatio );
 renderer.setSize( window.innerWidth, window.innerHeight );
 document.body.appendChild( renderer.domElement );

 window.addEventListener( 'resize', onWindowResize, false );
 
 }

 function onWindowResize() {

 camera.aspect = window.innerWidth / window.innerHeight;
 camera.updateProjectionMatrix();

 renderer.setSize( window.innerWidth, window.innerHeight );

 }

function animate() {

 requestAnimationFrame( animate );

 cClicks += 1;
 sClicks += 1;
 if (( sphereC.position.x + forInc >= 0 ) && ( sphereC.position.y = -r ) && ( inLoop = false )) {
 overShot = sphereC.position.x + forInc - 0;
 fRatio = overShot/forInc;
 curTrackAngle = -angInc + fRatio*angInc;
 };
 sphereC.rotation.y += ang2Inc;
 sphereC.position.x += forInc;

 if ((sphereC.position.x >= 0) && ( sphereC.position.y = -r )){
 inLoop = true;
 };
 if ( inLoop ) {
 curTrackAngle += angInc;
 sphereC.position.y = -r*Math.cos(curTrackAngle);
 sphereC.position.x = r*Math.sin(curTrackAngle);
 };
 if ( (sphereC.position.x >= 0) && ( cClicks > increments*1.25 )) {
 sphereC.position.set( -2*r, -r, 0 );
 curTrackAngle = 0;
 inLoop = false ;
 cClicks = 0 ;
 };

 sphereS.rotation.y += ang2Inc;
 sphereS.position.x += forInc;
 if (( sphereS.position.x >= 8*r ) && ( sClicks > increments*1.25  )){
 sphereS.position.set( -2*r, -r-q-w, 0 );
 curBallAngle = 0;
 sClicks = 0;
 };
 //var difClick = cClicks - sClicks; // consistently zero.
 //console.log( 'difClick = ' + difClick );  

 renderer.render( scene, camera );

}

 </script>


Current. Rolling. I may be here a while. The animation of the ball on the straight track rolling in the x direction with orthogonal y-axis spin is working, but the rate is a little off. Or I can give sphereC a z rotation corresponding to its orientation about the curved track – that works. But I cannot do both rotations at the same time.


A close up of the circle track's 6 0'clock position.

Vexman wrote. Airman, I don't want to be pain in the arse, but I think you have forInc and angInc reversed. In my opinion, angInc should be 8/400, and forInc should be 2*Math.Pi/400. Meaning, the ball going through the curve travels 8r and ball over straight path travels 2*Math.Pi*r .

Airman. No problem, except I don’t exactly see what you’re saying. My success using the increment variable as an inverse velocity would seem to me to strongly suggest there’s no problem with the code. I tried switching the two variables, which increased the speed through the curve but slowed the speed through the straight, as would be expected. The above diagram shows a length where both distances overlap, just to the left of the magenta vertical line going through (0, -r, 0 ), confirming  the incorrect linear distance comparison, 4PI(g)/400/8/400 = PI(g)/4.

P.S. Added the animate function and corrected a typo or two. Except for the curved track rolling animation it's close to being rough final complete - well, except for the continuous loop, and a few other things. I'll consider your suggestions and go with your directions.

P.P.S. Make that the whole script.  I eliminated a few lines I added while looking at switching forInc and angInc earlier.
.

Airman wrote:Airman. No problem, except I don’t exactly see what you’re saying. My success using the increment variable as an inverse velocity would seem to me to strongly suggest there’s no problem with the code. I tried switching the two variables, which increased the speed through the curve but slowed the speed through the straight, as would be expected. The above diagram shows a length where both distances overlap, just to the left of the magenta vertical line going through (0, -r, 0 ), confirming  the incorrect linear distance comparison, 4PI(g)/400/8/400 = PI(g)/4.

(scratching my head)....Uhmm...well, I may have misread or misunderstood what you wrote in an earlier version. Thanks for your patience and motivation, though, when dealing with my comments.

With the new code version, I'm completely lost and not versed enough to locate supporting math.

When mentioning speed - the speed through the curve should be increased in comparison to the speed  through the straight, as the curve is cca 21,5% longer in distance (same delta t). Speed change / increase within the curve is an expected outcome, no? Meaning, if the two balls were at the same length from the starting point when one ball is crossing the beginning of curved section, by the end of the curve, one ball covered more length in same amount of time. So its velocity had to change in comparison to the other ball. Pi(k) is saying exactly that.

Regarding 4PI(g)/400/8/400 : why is there 4Pi(g) rad / 400 suddenly involved? I can't seem to understand where number 4 came from. 2Pig rad / 400 is the length of the straightened out circumference section. 8 rad / 400 is the length of curved section. PI(g)/4 = 2Pi(g)rad/400/8 rad / 400 is true. I fail to find (and understand) what math supports your claim angInc = 4Pi(g) rad / 400 ...

About the diagram: was it drawn before or after you switched the variables? Because the text in the diagram says forInc=8/400, which is not correct in my opinion. Forward increment is along x-axis only, with 2Pi(g) rad /400 increments. Angular increment is along x- and y-axis, with 8 rad /400 increments.

Some of your if statements are failing because you have used the assignment operator (=) instead of the comparison operator (==).

e.g.

Code:


 if (( sphereC.position.x + forInc >= 0 ) && ( sphereC.position.y = -r ) && ( inLoop = false )) {
  overShot = sphereC.position.x + forInc - 0;
  fRatio = overShot/forInc;
  curTrackAngle = -angInc + fRatio*angInc;
 };


The first condition, ( sphereC.position.x + forInc >= 0 ), is fine and works as expected.

The second condition, ( sphereC.position.y = -r ), is actually assigning -r to sphereC.position.y. It is not comparing those values. Once it is assigned, the condition succeeds (evaluates to true) because sphereC.position.y has a value, not because it equals -r (even though it always will because we just assigned that value to it, it is not doing a comparison at all).

The third condition, ( inLoop = false ), does the same thing and sets the value of inLoop to false, which is then evaluated as false, and so the whole if statement fails and execution will never go in there.

Same with this block, except this one fails true, so it will always execute this code if the first condition is satisfied and will ignore the second:

Code:


 if ((sphereC.position.x >= 0) && ( sphereC.position.y = -r )){
  inLoop = true;
 };


sphereC.position.y = -r assigns -r to sphereC.position.y again. You must use double equals for comparison. Try to think of the comparison as 2 words like 'equal to', instead of just 'equals' which links to the 2 equal signs in the comparison operator, '=='. Think of the first = as 'equal' and the second = as 'to' and it will be easier to remember, or find some other way to remember it that works for you.

.

I've made corrections and am happy with this diagram. It agrees with what I coded and aids in the discussion. I even quoted your 21% measured value observation.

I like working with others and generally don't fault errors. It's all about Teamwork, commitment and getting things done. Thanks for cooperating. I’m always keen to create a new diagram. As usual, I make plenty of mistakes, thanks for pointing them out. Proof that by working as a team I can achieve more with others than I can on my own.

Starting with a circular path with radius r. The length of the straight path must then be 8r. Divide both tracks into 400 increments and view the circular track’s 6 o’clock position as shown.

Do we still have a disagreement? Are there any changes you'd like to suggest?


Thanks for the corrections Nevyn. I didn't make many errors. Sure, I've considered the difference between equal and equal to before, but had no idea that by using equal I was assigning values within the if statements. I do get embarrassed at times. Thanks again for working with me and for your patience.
.

Don't be embarrassed about that. Very easy, and very common, mistake to make. If, as a learning programmer, you don't make that mistake, then you probably aren't writing enough code.

It is important to realise that a statement in a programming language is a self-contained entity. It does not care where it is in the code. It does not get interpreted differently just because it is the condition in an if statement. This sort of stuff becomes more apparent when you write your own language. You start to see the language in its building blocks. I'll see if I can explain it.

At the most basic level, an if statement looks like this:

if statement then statement else statement

So it is really a construct that contains 3 statements (and one of them is optional). However, not all of those statements are treated equally. The first statement is called the condition and is expected to evaluate to a boolean value. Some languages absolutely require that and others will attempt to force it into one. Javascript is the type to force it, which means it will not generate an error unless it can't find a way to make it into a boolean (spoiler, it always can).

Now, you might be a little confused by the fact that the then and else statements are a single statement and not multiple. I'm sure you have written them with multiple statements, but that isn't strictly correct. It might look like multiple statements, but it is actually a single block statement, that then contains multiple statements.

In javascript, a block is encapsulated by { and }, and may contain any number of statements inside of it.

Generally, in Javascript and some other languages, a statement is terminated by a semi-colon, ;. However, some languages don't always require it if they can determine that it is the end of statement without it. I prefer to put them in regardless.

OK, I've made a silly error and would like to apologize for the possible confusion it may caused. Hope you won't hold it against me. I've somehow overlooked the way you visualized the whole concept and have made wrong conclusions about a few things. It made me blush when I finally comprehended my mistake.

a) the length of the straight track from the start to the finish line is, of course, 8r . How else could it demonstrate that both straight and curved paths are of equal lengths distances? But it didn't occur to me earlier that crossing the finish line means both balls have moved over the same 8r distance.

b) Of course, the section increment of straight track, forInc, is equal to 8/400 rad; angInc is equal to 2Pi(g)/400. My understanding of it was reversed.

c) If straight path = 8r, then I think my statement (which you quoted) is partially correct or plain wrong. The length of curved path is not measured 21,5% longer than the length of straight path; 8r=8r . Much more precise would be to say that the length of curved path is measured 21,5% longer than that, which is descirbed by the length of curve's circumference (2PIr).

.

Thanks Vexman. Here’s the latest iteration - the best yet - close up of the curved track start/finish line. I find this all very satisfying work, Please don’t hesitate to comment, add to or point out any error – etc.

I see Nevyn has replied to your other post - good - I have little to no confidence in answering 'atmospheric atomic charge flow' questions. I'll try to follow if you lead. 


PI=4 Experiment. Bottom edge view, the tracks form the center horizontal green line parallel to the x-axis. The image shows two series of images, each about 2.5 seconds apart. increments = 6000 and it takes a minute to reach this position and another minute to complete the tracks.
The straight path sphere is ‘rolling’ along in the x direction - just before, during, and after its spin axis aligns with the camera’s x position at 3*r. The camera is pointed in the positive y direction. The small sphere to the left is the ball moving along the curved track.  SphereGeometry( bRadius, 16, 3 ) makes the sphere appear as a rolling – 32 triangular sided cylinder capped with 16 sided cones each one third the total diameter on the spin axis – a very short pencil with two long sharp ends – the closest will point directly at the viewer. Intended to emphasize and allow a close review of the sphere’s rolling rate.  
 
Straight rolling. I reported that I’d coded the animation for the ball rolling along the straight track, but the rotation rate wasn’t correct. I think I corrected it and the fix deserves some discussion.
These are the pertinent variables and their values.
// Inverse velocity. The greater the number of increments the slower the ball's velocity along the track.

Code:

// Inverse velocity. The greater the number of increments the slower the ball's velocity along the track.
var increments = 6000; // Just over two minutes to complete the courses.
var forInc = 8/increments;
var angInc = 2*Math.PI*r/increments;
var kMult = (4/Math.PI);
//var kMult = 1;
var bRadius = w;
var bCircum = 2 * Math.PI * bRadius; // * kMult;
var ang2rot = 10*r/bCircum; // 8*r*kMult/bCircum; //the number of rolling rotations for the total
var ang2Inc = 4 * ang2rot * kMult/ increments; // the straight ball is rolling


The main change is the addition of var kMult = (4/Math.PI); The constant that allows us to account for the increased length of the curve due to curved motion. Note the ball radius, and circumference, bRadius, bCircum. Also ang2rot, the total number of rolling rotations for the total straight track, and ang2Inc is the straight ball’s rolling increment.

To make a long story short, it’s a cycloid. We all know a good roll when we see it. I tried dividing the total length of the straight path by the ball’s geometric circumference  and could not achieve a realistic roll - the top row of images. The tangent where the surface should reach zero velocity contact would instead glide forward over the track's imagined surface. When I introduced the kinematic multiplier, kMult = 4/PI(g), I saw proper rolling; the bottom row of three images.

Another example. Stuff like this is part of the reward of making this project effort in the first place. I suppose It would take program modifications (hint, hint) to study it further.
.

.

The balls are centered their own radii above the track. increments = n = 1000. Each track is divided into n incremental markers – grey lines orthogonal to the rolling direction, making it easy to confirm good rolling action when treating the ball’s straight rolling distance as a cycloid.

I'm considering changing those orthogonal lines into orthogonal circles which the ball will pass through - giving a tube-like appearance. I'll see how it looks and share it if it works.
 
Made the following changes to the tracks:
In the init function. I added straight and curved track increment markers – code below. I also cleaned up the comments, line and curve section titles.

Code:


// S track Increment markers increments
for ( n = 0; n < increments; n++ ) {
     var geometry = new THREE.Geometry( 1, 1, 1 );
     geometry.vertices.push(new THREE.Vector3( -2*r+n*10/increments, -r-q-w/2, 0 ) );
     geometry.vertices.push(new THREE.Vector3( -2*r+n*10/increments, -r-q-1.5*w, 0 ) );
     var line = new THREE.Line( geometry, material2 );
     scene.add( line );
};

// C track Increment markers
for( ang=0; ang<=increments; ang+=1 ) {
     var cDist = 2*Math.PI/increments * ang;
     var geometry = new THREE.Geometry( 1, 1, 1 );
     geometry.vertices.push(new THREE.Vector3(iRadius*Math.cos(cDist)+cTrackCenter.x, iRadius*Math.sin(cDist)+ cTrackCenter.y, 0));
     geometry.vertices.push(new THREE.Vector3(oRadius*Math.cos(cDist)+cTrackCenter.x, oRadius*Math.sin(cDist)+ cTrackCenter.y, 0));
     var line = new THREE.Line(geometry, material2 );
     scene.add( line );
};


.

.

Tubular tracks. Each track shows 100 circles or hoops the balls must travel through. Please excuse the field of view distortion.  

I must admit, they look better than I expected. I don't know if you wanted tube geometry or not. Flaming hoops might make a decent animation. Working out the details of arranging the hoops about the circular track provided some clues that might prove helpful in solving that last curved ball’s animation.
.

This really looks impressive, Airman.

Will you consider making such animation accessible at some website, open for general public? It would make an excellent accessory when discussing Pi(k) with people having different opinion about what's going on inside the curve when motion is involved.

.

This really looks impressive, Airman.

Will you consider making such animation accessible at some website, open for general public? It would make an excellent accessory when discussing Pi(k) with people having different opinion about what's going on inside the curve when motion is involved.

Airman. Thanks Vexman, I agree, a simulation of the PI=4 Experiment would be an a priori necessary accessory in trying to understand curved motion. With regard to my effort, you’re being kind. I’m still a relative beginner. My code is poxied with beginner’s mistakes and lack any sophistication whatsoever. I have no means of making the code more accessible than by posting my updates as I have already done. I’m not anywhere near experienced enough to create a cloud GIT (software development) PI=4 Experiment software repository that people could download or build upon.

My ulterior motive has always been to get Nevyn to post the final PI=4 experiment at his site *. Obviously he can do the job perfectly well on his own. As a civil engineer I’ve worked on many base level projects, large or small, as lead or member. I’ll point out that a final product created through a team approach to review and development can greatly improve the product’s quality. I present myself as a hard ass editor or semi-skilled enthusiastic free labor Nevyn may direct as he chooses.


Nevyn, in addition to the tubular track changes, I created the last animation of the curved ball’s z-axis rotation and so the animation has reached its initial/final draft. Sorry, that last animation doesn’t look right and will require your attention. I also added an orbital camera which causes errors if I move my mouse wheel **.  I’ll put my animate function on the shelf for the time being and begin following your 24 Sep directions by creating an alternative animateDynamic function that can replace it.

* https://www.nevyns-lab.com/

** OrbitControls.js:765 [Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/6662647093133312
.

I can't tell what version of ThreeJS you are using, and I suspect that you need a newer version, along with its version of OrbitControls.js, to fix this bug. I also can't execute the code without knowing the ThreeJS version.

.
The code began as one of the examples included in the three.js r87 download.

\threejs\three.js-r87\examples\webgl - geometry - cube

I used the orbital camera source from that same group of js source files.
.

That's a really old version, and browsers have moved on. The latest I used, which was a few months ago now, was r104. There are probably a few more versions out now, I haven't looked recently. I saw a comment in the wild a week ago that there is a WebGL 2.0 coming out, or is out, or is being tested, not sure. That will mean a lot of changes in ThreeJS coming up.

.

I downloaded the latest three.js. version 109 as a zip file. I then moved the zip file to my threejs folder and extracted it. No joy, I cannot run any of the new three.js files, I'm receiving the following console errors.

webgl_geometry_cube.html:1 Access to script at 'file:///C:/Users/Robert/Downloads/three.js-master/build/three.module.js' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

three.module.js:1 Failed to load resource: net::ERR_FAILED

Any clues as to how I might correct this? Am I lacking the proper permissions?
.

You're using a full file path. Make it relative to the location of the HTML file and it will work.

.
Sorry, I am not understanding. How am I using the whole path? I extracted the files, and go to the examples folder using windows explorer. I usually launch a three.js file by right finger clicking, then ‘use/chrome’, or I might select Run/Launch while coding in notepad++. The URLs are what appear in chrome’s file line. Are you saying I can change that? The examples are all installed relative to the build, I just don’t see where I can change the source relative to the example. Unless I selected a poor location to store the three.js-master?

Here’s the latest html header for v109. The import line is something new.

Code:

<!DOCTYPE html>
<html lang="en">
 <head>
 <title>three.js webgl - geometry - cube</title>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0">
 <link type="text/css" rel="stylesheet" href="main.css">
 </head>
 <body>

 <script type="module">

 import * as THREE from '../build/three.module.js';

 var camera, scene, renderer;
 var mesh;

 init();
 animate();

 function init() {

.

Don't use the import method, it has limitations including not being supported by some browsers. Use a script tag instead. In that script tag, use a relative URL rather than an absolute one.

So your above import should be changed to and move it to the section. That already uses a relative URL, too.

.
If I understand correctly, I may use the existing files if I replace the import method with the previous standard script source.

I attempted to do so by saving wedgl_geometry_cube as wedgl_geometry_pi4, then made several changes, replacing import with:

Code:


<!DOCTYPE html>
<html lang="en">
 <head>
 <title>three.js webgl - geometry - pi4</title>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0">
 <script type="text/javascript" src="../build/three.js" style="margin: 0px; padding: 0px;">

 </head>
 <body>

 <script src="../build/three.js"></script>

 <script>
 
 var camera, scene, renderer;


Resulting in - ReferenceError. THREE is not defined.

There must be an easier way. I did a search and found a question that may help.
Three.js : Very first setup…?
https://stackoverflow.com/questions/43617077/three-js-very-first-setup

The question was been answered 2yrs 5 months ago and doesn’t seem very clear. Would you agree that answer- instructions for installing three.js is correct? If so I’ll try to follow them next.
.

My guess is that your problem is with src="../build/three.js". That may not be the path to the file. I recommend following some of those instructions, but not all because you have already gotten passed most of it.

The part I was going to recommend yesterday, but didn't want to confuse things too much, was to copy the three.js file (and any other required JS files from ThreeJS, such as orbit-controls.js) into your project directory (in a sub-directory called js, and use any sub-directories inside of that that you want).

So your project file system should look something like this:

project.html
js/three.js
js/controls/orbit-controls.js

Then you replace src="../build/three.js" with src="js/three.js".

The best thing about doing it this way is that it keeps the project self-contained. You recently downloaded a new version of ThreeJS and put it into the same place as the previous one. This means that all other projects that refer to it just got upgraded but their source code has not been changed to reflect that. So they may not work anymore.

.
Thanks Nevyn, I've read up about minified installs that doesn't seem to help. src="../build/three.js" seems relative and correct to me. I'll continue with your latest directions.
.

The version you are using has not been minified. There is another file called three-min.js that is the minified version of three.js. Programmatically, they are the same, but the contents are actually different. A minified version just takes out all of the stuff that isn't needed to execute the file. So any comments are removed, extraneous whitespace, variables are renamed to shorter names, etc. The idea is to create a version that works exactly the same, but is the smallest it can be.

Try this: after the three script tag, add the ending tag.

Code:


<script type="text/javascript" src="../build/three.js" style="margin: 0px; padding: 0px;"></script>


It shouldn't need the style attribute either. I don't see what that would do because the script tag is not visible.

.
We have Joy, PI=4 is working under v109 in its own project folder.


Project files.


PI=4.

The cube kept giving me grief with the same - blocked by CORS policy; turns out  the cube code requests a crate gif (not in the source list) from the v109 textures folder. Rather than bring the texture in I tried PI=4 and it worked, well almost, the only thing not yet working is the orbital camera. Lines 62 and 63 are commented out since they are causing errors:
62 // controls = new THREE.OrbitControls( camera ); // comes with errors
63 // controls.damping = 0.2;
1. controls is not defined.and
2. TypeError: THREE.OrbitControls is not a constructor

By the way, that stye error was something strange. I routinely copy/paste forum comments into a word document as a back-up historical file. Often I read the word document instead of the forum post itself. In your quote  

Nevyn So your above import should be changed to script type …

Airman. Your instructions just after that quote - before you changed it - your text between the script signs converted the into a block of styling information which seemed like a complicated instruction. When I quoted you after the ... it turned back into simple text.

I need to catch up with your last set of directions.
.

You need a 2nd script tag to import the OrbitControls.js file. Put it after the three.js import (because it needs three itself). Then the controls will work.

.

Which way is up?

Plenty to do, thank you very much. Little things that will delay any dynamic animation function work for the moment.

Catching up with your instructions: I’ve replaced three.js with three.min.js. And, the Orbit controls tag is below the three.min.js tag:

Code:

<script src="js/three.min.js"></script>
<script src="js/controls/OrbitControls.js"></script>

Zooming the mouse wheel works on the screen, although it causes the following console error; the number at the left - 80 in this case, increases as with mouse wheel changes.  

80[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See

I’m trying to find out why – I have two intertoob orbit control documents open in separate tabs.

But first, I thought I’d like to try changing the perspective type camera for the orthographic. I’m in the middle of that. I’d like to make it perfectly clear that the two tubular tracks lie side by side on a flat plane, thus accounting for the rolling action. The orbit control allows me to really confuse myself, clearly the height and width don’t agree.

When I change the vector
//var cTrackCenter = new THREE.Vector3( 3*r, -r, 5*r );
from ( 0, 0, 0 ) to ( 3*r, -r, 5*r ), the objects comprising the two tracks aren’t all located at their proper locations. The track objects' positions need to be made relative to the c track as well as radius r.

Pardon me while I putz around a bit.
.

.

The current view of the PI=4 Experiment is again orthographic. I like it better than the perspective view.

All the new lines are ‘intended to make development easier’ and indeed they (perspective too) do. They make it clearer how the js camera operates. I went and included the new source in two new folders in the project files.

Code:


 <script src="js/three.min.js"></script>
 <script src="js/controls/OrbitControls.js"></script>
 <script src="src/helpers/CameraHelper.js"></script>

The white line begins at (0,0,0) and goes upward in a positive Z direction. The orbit controls in the current image also ‘rotates’ about that same up/down axis. The two tracks lie side by side on the plane marked by the red x.

I completed adding var cTrackCenter to all objects. Using it one may move the PI=4 Experiment anywhere in world space without effecting the animation. Above, cTrackCenter was used to move the tracks slightly away from (0,0,0) in order to more center the image's range of motion within the camera scene.

I had to go through my if statements again, made another == correction.

Not sure what’s next. I suppose I should go through all the coordinate point indices(?) to allow switching over to them instead of all the line segments that are currently used in the init function. There's also the zooming error and the height/width still don’t agree.

Feel free to add.
.

Airman wrote:I completed adding var cTrackCenter to all objects. Using it one may move the PI=4 Experiment anywhere in world space without effecting the animation.

That doesn't sound right. I'm sure it works, but what I mean is, it shouldn't be the way chosen to make it work. You're not using the scene hierarchy to your advantage. You should have all track parts in a group, then you just move the group where you want it. The current method is like moving a house brick by brick instead of as a house.

This happens when you do too much during initialization. It is easy to do that in this type of application (and many others), a lot of the ThreeJS examples do this, but it creates fragile code. You don't notice until you want some new feature and soon realise that you have to change lots of little bits instead of just one, or a few. You may also notice it when you try to copy code from one project to another to re-use it and you start to see how different the apps are.

.
Airman wrote:I completed adding var cTrackCenter to all objects. Using it one may move the PI=4 Experiment anywhere in world space without effecting the animation.

Nevyn wrote. That doesn't sound right. I'm sure it works, but what I mean is, it shouldn't be the way chosen to make it work. You're not using the scene hierarchy to your advantage. You should have all track parts in a group, then you just move the group where you want it. The current method is like moving a house brick by brick instead of as a house.

Airman. I thought cTrackCenter was a good addition, oh well, thanks for explaining why not, a lot of bricks. I couldn’t possibly enjoy starting my weekend without correcting it as soon as possible. I completely removed var cTrackCenter from the code. Instead, as you suggested, I added a new var grp = new THREE.Group(). All track objects are added to grp. If I wish to move the PI=4 Experiment elsewhere in world space, I can re-position grp before it is added to the scene.

Tested good.
.

.

Back in perspective view. The curved and straight track spheres have almost reached their starting points.

Beau coup changes. Imho, the passive animation has reached a fine draft final.
 
I couldn’t figure out how to get the whole table to rotate easily about the +z vertical axis. So I went and switched all the coordinates’ y and z values (including negating z). I changed the balls’ paths accordingly. Lo and behold, I see good rotations for the balls in either track. Do you agree?

Code:


<script>

 var camera, scene, renderer;
 var mesh, sphereC, sphereS;
 var r = 1; // Track radius
 var widt = window.innerWidth;
 var heit = window.innerHeight;
 var aspectRatio = widt/heit;
 var viewSize = 8*r;
 
 var q = r; // track separation
 var tRadius = 0.25*r;
 var tubeTot = 200;
 var tubeInc = 10*r/tubeTot;
 var w = tRadius; // r; // 0.75 * r; // track width
 var iRadius = r - w/2;
 var oRadius = r + w/2; // r + w/2;
 // Inverse velocity. The greater the number of increments the slower the ball's velocity along the track.
 var increments = 1000; // 5000; // Just over two minutes to complete the courses.
 var pathInc = 150;
 var forInc = 8/increments;
 var angInc = 2*Math.PI*r/increments;
 var kMult = 4/Math.PI;
 var bRadius = tRadius;
 var bCircum = 2 * Math.PI * bRadius;
 var ang2rot = 10*r/bCircum; // 8*r*kMult/bCircum; //the number of rolling rotations for the total
 var ang2Inc = 4 * ang2rot * kMult/ increments; // the straight ball is rolling
 
 var curTrackAngle = 0;
 var curBallAngle = 0;
 var inLoop = false;
 var overShot, fRatio;
 var cClicks = 0;
 var sClicks = 0;
 
 init();
 animatePassive();
 
 function init() {

 var grp = new THREE.Group();

 scene = new THREE.Scene();
 
 camera = new THREE.PerspectiveCamera( 70, aspectRatio, 0.1*r, 100*r );
 //camera = new THREE.OrthographicCamera( -aspectRatio*viewSize/2, aspectRatio*viewSize/2, viewSize/2, -viewSize/2);
 camera.position.set( 0, 0, 4*r );
 camera.lookAt(0, 0, -5*r);
 
 controls = new THREE.OrbitControls( camera, renderer ); // comes with errors
 controls.target.set( 0, 0, -5*r );
 camera.updateProjectionMatrix();

 //scene.background = new THREE.Color('FFFFFF'); // #009900 pool table green // #0000FF nice high contrast blue //
 var sphereMat = new THREE.MeshBasicMaterial( { wireframe: true, color: 'yellow' } ); // yellow
 var material = new THREE.LineBasicMaterial( { color: 'red', linewidth: 0.5*r } ); // markers
 var material2 = new THREE.LineBasicMaterial( { color: 'grey' } ); // Increment markers
 var MAT_LINE_CP = new THREE.LineBasicMaterial( { color: 0x00cc00, linewidth: 0.5 } ); // distances

 //cTrackCenter -4 curved paths
 for(th=1;th<=360;th+=1) {
 var radians1 = (Math.PI/180) * th;
 var radians2 = (Math.PI/180) * (th + 1);
 if (th === 359) { radians2 = (Math.PI/180) }
 for ( i = -1; i < 2; i=i+2 ) {
 configRadius = r + i*w;
 var XYPlaneLine = new THREE.Geometry();
 XYPlaneLine.vertices.push(  
 new THREE.Vector3( configRadius * Math.cos(radians1), 0, -configRadius*Math.sin(radians1) ),
 new THREE.Vector3( configRadius * Math.cos(radians2), 0, -configRadius*Math.sin(radians2) ) );
 var XYLine = new THREE.Line( XYPlaneLine, MAT_LINE_CP);
 grp.add(XYLine);

 configRadius = r + i*w;
 var XYPlaneLine = new THREE.Geometry();
 XYPlaneLine.vertices.push(  
 new THREE.Vector3( r * Math.cos(radians1), i*tRadius, -r*Math.sin(radians1) ),
 new THREE.Vector3( r * Math.cos(radians2), i*tRadius, -r*Math.sin(radians2) ));
 var XYLine = new THREE.Line( XYPlaneLine, MAT_LINE_CP);
 grp.add(XYLine);
 };
 };
 // S track markers
 for ( j = 0; j < 6; j++ ) {
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*j, 0, -(-r-q-2*w) ) );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*j, 0, -(-r-q ) ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line );
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*j, -tRadius, -(-r-q-w ) ) );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*j, tRadius, -(-r-q-w ) ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line );
 };
 // PI marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( 2*r*Math.PI, 0, -(-r-q-2*w ) ) );
 geometry.vertices.push(new THREE.Vector3( 2*r*Math.PI, 0, -(-r-q )) );
 var line = new THREE.Line( geometry, material );
 grp.add( line );
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( 2*r*Math.PI, -tRadius, -(-r-q-w ) ) );
 geometry.vertices.push(new THREE.Vector3( 2*r*Math.PI, tRadius, -(-r-q-w ) ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line );
 // C track straight section markers
 for ( m = 0; m < 2; m++ ) {
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*m, 0, -(-r+w ) ) );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*m, 0, -(-r-w ) ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line );
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*m, -tRadius, r ) );
 geometry.vertices.push(new THREE.Vector3( -2*r+2*r*m, tRadius, r ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line );
 };

 // parallel circles curved path's initial straight section
 for( ber=0; ber<tubeTot/5+1; ber++ ) {
 for(th=1;th<=360;th+=12) {
 var radians1 = (Math.PI/180) * th;
 var radians2 = (Math.PI/180) * (th + 12);
 if (th === 348) { radians2 = (Math.PI/180) }
 var yZPlaneCircle = new THREE.Geometry();
 yZPlaneCircle.vertices.push(   //viewing x and y.
 new THREE.Vector3( 0, tRadius*Math.sin(radians1), -tRadius * Math.cos(radians1) ),
 new THREE.Vector3( 0, tRadius*Math.sin(radians2), -tRadius * Math.cos(radians2) ) );
 var tCircle = new THREE.Line( yZPlaneCircle, material2);
 tCircle.position.set( -2*r+ber*tubeInc, 0, r );
 grp.add(tCircle);
 };
 };
 // parallel circles straight path
 for( num=0; num<tubeTot+1; num++ ) {
 for(th=1;th<=360;th+=18) {
 var radians1 = (Math.PI/180) * th;
 var radians2 = (Math.PI/180) * (th + 18);
 if (th === 342) { radians2 = (Math.PI/180) }
 var yZPlaneCircle = new THREE.Geometry();
 yZPlaneCircle.vertices.push(   //viewing x and y.
 new THREE.Vector3( 0, tRadius*Math.sin(radians1), -tRadius * Math.cos(radians1) ),
 new THREE.Vector3( 0, tRadius*Math.sin(radians2), -tRadius * Math.cos(radians2) ) );
 var tCircle = new THREE.Line( yZPlaneCircle, material2);
 tCircle.position.set( -2*r+num*tubeInc, 0, -(-r-q-w) );
 grp.add(tCircle);
 };
 };
 // parallel circles circular path
 var curAngl;
 var curAnglInc = 2*Math.PI*r/tubeTot;
 var yZPlaneCircle = new THREE.Geometry();
 for(th=1;th<=360;th+=18) {
 var radians1 = (Math.PI/180) * th;
 var radians2 = (Math.PI/180) * (th + 18);
 if (th === 342) { radians2 = (Math.PI/180) }
 yZPlaneCircle.vertices.push(  
 new THREE.Vector3( 0, tRadius*Math.sin(radians1), -tRadius * Math.cos(radians1) ),
 new THREE.Vector3( 0, tRadius*Math.sin(radians2), -tRadius * Math.cos(radians2) ) );
 };
 for( ber=0; ber < tubeTot; ber++ ) {
 var tCircle = new THREE.Line( yZPlaneCircle, material2);
 curAngl = ber*curAnglInc;
 tCircle.rotation.y = curAngl + Math.PI/2;
 tCircle.position.set( r * Math.cos(curAngl), 0, -r * Math.sin(curAngl) );
 grp.add(tCircle);
 };
 for ( k = -1; k < 2; k=k+2 ) {  
 // S track lengths: +/-z edges
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r, 0, -(-r-w-q+k*w ) ) );
 geometry.vertices.push(new THREE.Vector3( 8*r, 0, -(-r-w-q+k*w ) ) );
 var line = new THREE.Line( geometry, MAT_LINE_CP );
 grp.add( line );
 // S track lengths: +/-z edges
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r, k*tRadius, -(-r-w-q ) ) );
 geometry.vertices.push(new THREE.Vector3( 8*r, k*tRadius, -(-r-w-q ) ) );
 var line = new THREE.Line( geometry, MAT_LINE_CP );
 grp.add( line );
 // C track lengths: +/-z edges
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r, 0, -(-r+k*w ) ) );
 geometry.vertices.push(new THREE.Vector3( 0, 0, -(-r+k*w ) ) );
 var line = new THREE.Line( geometry, MAT_LINE_CP );
 grp.add( line );
 // C track lengths: +/-y edges
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -2*r, k*tRadius, r ) );
 geometry.vertices.push(new THREE.Vector3( 0, k*tRadius, r ) );
 var line = new THREE.Line( geometry, MAT_LINE_CP );
 grp.add( line );
 }
 // C track markers
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( r-w, 0, 0 ) );
 geometry.vertices.push(new THREE.Vector3( r+w, 0, 0 ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line ); // C track One Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( r, -tRadius, 0 ) );
 geometry.vertices.push(new THREE.Vector3( r, tRadius, 0 ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line ); // C track One Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( 0, 0, -r-w ) );
 geometry.vertices.push(new THREE.Vector3( 0, 0, -r+w ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line ); // C track Two Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( 0, -tRadius, -r ) );
 geometry.vertices.push(new THREE.Vector3( 0, tRadius, -r ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line ); // C track Two Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -r-w, 0, 0 ) );
 geometry.vertices.push(new THREE.Vector3( -r+w, 0, 0 ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line ); // C track Three Marker
 var geometry = new THREE.Geometry( 1, 1, 1 );
 geometry.vertices.push(new THREE.Vector3( -r, -tRadius, 0 ) );
 geometry.vertices.push(new THREE.Vector3( -r, tRadius, 0 ) );
 var line = new THREE.Line( geometry, material );
 grp.add( line ); // C track Three Marker

 // Balls
 var sphereGeom = new THREE.SphereGeometry( bRadius, 16, 16 );
 sphereC = new THREE.Mesh( sphereGeom, sphereMat );
 sphereC.position.set( -2*r, 0, r );
 sphereS = new THREE.Mesh( sphereGeom, sphereMat );
 sphereS.position.set( -2*r, 0, -(-r-q-w ) );
 var ballOne = new THREE.Object3D();
 ballOne.add(sphereC);
 var ballTwo = new THREE.Object3D();
 ballTwo.add(sphereS);
 grp.add( ballOne, ballTwo );
 grp.position.set( -2.5*r, 0, -6*r ); //repositions the world rotation point
 
 scene.add(grp);

 renderer = new THREE.WebGLRenderer();
 renderer.setPixelRatio( window.devicePixelRatio );
 renderer.setSize( window.innerWidth, window.innerHeight );
 document.body.appendChild( renderer.domElement );

 window.addEventListener( 'resize', onWindowResize, true );
 
 }

 function onWindowResize() {

 camera.aspect = window.innerWidth / window.innerHeight;
 camera.updateProjectionMatrix();

 renderer.setSize( window.innerWidth, window.innerHeight );

 };

 function animatePassive() {        

 requestAnimationFrame( animatePassive );

 cClicks += 1;
 sClicks += 1;
 if (( sphereC.position.x + forInc >= 0 ) && ( sphereC.position.z  == r ) && ( inLoop == false )) {
 overShot = sphereC.position.x + forInc - 0;
 fRatio = overShot/forInc;
 curTrackAngle = -angInc + fRatio*angInc;
 };
 sphereC.rotation.z -= ang2Inc;
 sphereC.position.x += forInc;

 if ((sphereC.position.x >= 0) && ( sphereC.position.z == r )){
 inLoop = true;
 };
 if ( inLoop ) {
 curTrackAngle += angInc;
 sphereC.rotation.y = curTrackAngle;
 sphereC.position.set( r*Math.sin(curTrackAngle), 0, r*Math.cos(curTrackAngle) )
 };
 if ( (sphereC.position.x >= 0) && ( cClicks > increments*1.25 )) {
 sphereC.position.set( -2*r, 0, r );
 curTrackAngle = 0;
 inLoop = false ;
 cClicks = 0 ;
 };
 sphereS.rotation.z -= ang2Inc;
 sphereS.position.x += forInc;

 if (( sphereS.position.x >= 8*r ) && ( sClicks > increments*1.25  )){
 sphereS.position.set( -2*r, 0, -(-r-q-w) );
 curBallAngle = 0;
 sClicks = 0;
 };

 renderer.render( scene, camera );

 };
 </script>

The camera helper isn't included in the 'neat' version - my working file is a mess with comments mistakes etc.


I edited the code comments to better agree with the code, I always include errors somewhere, so added a nearby image.

After I get through smiling I’ll be ready to begin the dynamic animation.  
.

.
Progress, I believe, but the product is far from complete - the process continues, as evidenced below. Some code changes I’ve made since last time.  

1. var tubeTot. Corrected. You can change the total number of circles or hoops in both tracks by changing the tube total, tubeTot. Say you’d like 10 divisions for each track section, then the initial section plus sections 1 through 4 make 5 times 10, so let tubeTot =50. Note, an additional circle will be added to the end of the straight track – if the value of tubeTot selected is divisible by 5.
Line 156 is included as a reference. From

Code:

156         // parallel circles straight path
157          for( num=0; num<tubeTot+1; num++ ) {

to

Code:

157         for( num=0; num<tubeTot; num++ ) {

2. And related, from

Code:

172          var curAnglInc = 2*Math.PI*r/tubeTot;

to

Code:

172          var curAnglInc = 2*Math.PI*r/(4*tubeTot/5);

3.  Eliminated var pathInc

Code:

39          var pathInc = 75;

pathInc was an unused variable.

4. Updated the coordinate points list - something I'll try incorporating next - made necessary after having switched y and z and negating z.

5. Centerline x value coordinate arrays. Adding lines 55-57; straight and curved track centerline x value arrays just before the init function call. Slight simplification, i.e. it eliminated the need for a separate - now gone - straight track PI marker code section. The thought is that, given r, w, q and these two arrays, the two tracks can be generated a lot simpler than I have thus far. Maybe expand to an indexed coordinate array. In any case, these two track arrays are the basis for both the Passive and the Dynamic animate functions.  

Code:


55          // Centerpath x coordinates.
56          var sTrack = [ -2*r, 0, 2*r, 4*r, 6*r, 8*r, 2*Math.PI*r ];
57          var cTrack = [ -2*r, 0, r, 0, -r, 0 ];
58
59          init();


Hope all is well.
.

.
Progress, I believe, but the product is far from complete - the process continues, as evidenced below. Some code changes I’ve made since last time.  

1. var tubeTot. Corrected. You can change the total number of circles or hoops in both tracks by changing the tube total, tubeTot. Say you’d like 10 divisions for each track section, then the initial section plus sections 1 through 4 make 5 times 10, so let tubeTot =50. Note, an additional circle will be added to the end of the straight track – if the value of tubeTot selected is divisible by 5.
Line 156 is included as a reference. From

Code:

156         // parallel circles straight path
157          for( num=0; num<tubeTot+1; num++ ) {

to

Code:

156         // parallel circles straight path
157         for( num=0; num<tubeTot; num++ ) {

2. And related, from

Code:

172          var curAnglInc = 2*Math.PI*r/tubeTot;

to

Code:

172          var curAnglInc = 2*Math.PI*r/(4*tubeTot/5);

3.  Eliminated var pathInc

Code:

39          var pathInc = 75;

pathInc was an unused variable.

4. Updated the coordinate points list - something I'll try incorporating next - made necessary after having switched y and z and negating z.

5. Centerline x value coordinate arrays. Adding lines 55-57; straight and curved track centerline x value arrays just before the init function call. Slight simplification, i.e. it eliminated the need for a separate - now gone - straight track PI marker code section. The thought is that, given r, w, q and these two arrays, the two tracks can be generated a lot simpler than I have thus far. Maybe expand to an indexed coordinate array. In any case, these two track arrays are the basis for both the Passive and the Dynamic animate functions.  

Code:


55          // Centerpath x coordinates.
56          var sTrack = [ -2*r, 0, 2*r, 4*r, 6*r, 8*r, 2*Math.PI*r ];
57          var cTrack = [ -2*r, 0, r, 0, -r, 0 ];
58
59          init();


Hope all is well.
.

.
How dynamic is dynamic? For one thing, spin seems arbitrary. Unlike the two tabletop tracks which must impart rolling spins on the two spheres, I imagine that the dynamic, non-rolling sphere can move linearly through the straight track, beginning to end, with no spin or change in orientation. As such, this simulation might resemble action in a vacuum. I imagine a non spinning sphere moving through a circular path must execute a single rotation. Or do we want a table surface in the dynamic model as well? Still thinking.


The control panel is present but not operational.

I keep procrastinating the dynamic animation, I’m trying to be productive here. How about controls? We’ll need them sooner or latter. We used them in the CPIM project. I looked at CPIM and dat.gui.

Code:

   <script src="js/three.min.js"></script>
      <script src="js/controls/OrbitControls.js"></script>
      <script src="js/libs/dat.gui.min.js"></script>


workshop.chromeexperiments.com
Simple instructions eh? The first of three,

The property must be public, i.e. defined by this.prop = value.

Trying to follow those instructions, many changes later, everything is still working - thank goodness. I created a new function; daControlValues (). All the variables defined within daControlValues are identified with the (this.) identifier. All the var values created in the init function now use this.values. For example, the radius will be identified as this.r instead of r. I placed daControlValues (); before init();.

Code:


 var mesh, sphereC, sphereS;
 
 var daControlValues = function() {
 // Some of these will hopefully be control panel variables
 this.r = 1; // Track radius
 this.q = this.r; // track separation
 this.bRadius = 0.25*this.r;
 this.tRadius = this.bRadius;
 this.tubeTot = 120; //  = 120;
 this.w = this.tRadius; // r; // 0.75 * r; // track width
 // Inverse velocity. The greater the number of increments the slower the ball's velocity along the track.
 this.increments = 500; // 5000; // Just over two minutes to complete the courses.
 this.widt = window.innerWidth;
 this.heit = window.innerHeight;
 this.aspectRatio = this.widt/this.heit;
 
 this.viewSize = 8*this.r;
 this.tubeInc = 10*this.r/tubeTot;
 this.forInc = 8/increments;
 this.angInc = 2*Math.PI*this.r/increments;
 this.kMult = 4/Math.PI;
 this.bRadius = this.tRadius;
 this.bCircum = 2 * Math.PI * this.bRadius;
 this.ang2rot = 10*this.r/this.bCircum; // 8*this.r*this.kMult/bCircum; //the number of rolling rotations for the total
 this.ang2Inc = 4 * this.ang2rot * this.kMult/ this.increments;
 this.curTrackAngle = 0;
 this.curBallAngle = 0;
 this.inLoop = false;
 this.overShot;
 this.fRatio;
 this.cClicks = 0;
 this.sClicks = 0;

 // Centerpath coordinate arrays.
 this.tracSep = this.r+this.q+this.w;
 this.sTrackX = [ -2*this.r, 0, 2*this.r, 4*this.r, 6*this.r, 8*this.r, 2*Math.PI*this.r ];
   this.cTrackX = [ -2*this.r, 0, this.r, 0, -this.r, 0 ];
 };

 daControlValues();
 init();
 animatePassive();



Here's the very rudimentary control panel at the end of the init() function - so far. Like I said, everything else is still running, no controls yet. I have no idea what's next, I'll keep trying to follow directions.

Code:


 renderer = new THREE.WebGLRenderer();
 renderer.setPixelRatio( window.devicePixelRatio );
 renderer.setSize( window.innerWidth, window.innerHeight );
 document.body.appendChild( renderer.domElement );

      //$('body').append(renderer.domElement); // ?????
      // call the render function
      // var step = 0;
      var controls = new function () {
        this.r = 1;
        this.increments = 100;
        this.tubeTot = 15;
 
      };
  
      var gui = new dat.GUI();
      gui.add(controls, 'r',0.1,10);
      gui.add(controls, 'increments', 50, 500);
      gui.add(controls, 'tubeTot',0 ,200 );
    //  render();

 window.addEventListener( 'resize', onWindowResize, true );
 
 };


.

I wouldn't worry about the spin of the ball. You can keep that preset. It is possible to work out how far the ball has traveled since the last frame and calculate the required rotation, but maybe try that once you have the main motions working correctly.

.
function animateDynamic() {}

Pardon my thinking. We wish to simulate the comparative equal velocities/ distances traveled by two spheres along two different paths through space: linear and curved. The two particles do not interact in any way (i.e no collisions). As shown by the PI=4 Experiment – the two paths provide equal distances when the straight track is 4 times the length of the curved track’s diameter. * PI(kinematic)=4.

I’d say this is a simple two case particle kinematic problem.  

As a reference, allow me to suggest –not for the first time – Euclidean Space. Copyright (c) 1998-2017 Martin John Baker

https://www.euclideanspace.com/
http://www.euclideanspace.com/physics/kinematics/index.htm

Martin John Baker's site is quite extensive and comprehensive. I'm happy with it, but as is quickly clear, it's getting a bit old. Many links no longer work. If you have another source, please consider sharing it.

Below, summarizing and outlining the relevant material from the Kinematics page as I believe it pertains to the current PI=4 ‘Simulation’.

Physics – Kinematics.
…Kinematics can be studied without regard to mass or physical quantities that depend on mass.
Movement in one dimension
If an object is moving in a straight line, and if we measure its position along that line, then its position, velocity and acceleration can all be represented by scalar quantities. This makes the analysis much easier, so lets start there.

Summarizing, we would expect to have to work with position, velocity and acceleration vectors, generally along the lines of.
• v = v0 + a*t
• p = p0 + v0 t + ½ a t2
• v2 = v02 + 2 * a * p

Orientation and position mean six degrees of freedom. Little more than standard high school physics. Except where it isn’t. Miles has identified the correct orbital acceleration equation, changing a = v2/r to a = v2/2r. I believe it’s necessary to include it, although I’m not sure how, i.e to explain why the sphere exiting the circular path would be leaving at a reduced 'velocity'.  

Moving to Euclidean Space’s next page,  

Physics - Dynamics
In the previous kinematics page the mathematics of moving objects was discussed. If the objects are representing physical objects, with properties like mass and inertia, then we probably want to calculate the kinematics from the dynamics

Point being, that until such time as mass is necessary, we can stick to the Kinematics page.

* Remember, linear ‘lengths’ are ok, but until everyone understands the new kinematic PI=4, lengths calculated along curves using PI(geometric) are wrong. We can generally translate length (L), to distance (D) around a circular path by, D=L*4/PI(G).  
.

You shouldn't need anything more than v=d/t for the straight section. We don't have any accelerations as used in those equations. The curves will be more tricky. You need to calculate the next position that the ball will end up at after this frame. I'm not sure if this will use PI=4 or PI=3.14, but calculate the angle using the balls velocity by assuming it will travel that distance on the curves circumference.

C = circumference = 2*PI*r
d = vt

So we want to know how much of C is d:

P = d/C
= vt/C
= vt/(2PI*r)

Since C represents the complete circle, we now have a percentage (actually, it is %/100 as it's just the ratio) of that, so we can convert it into an angle like this:

A = P * 2PI

We can put all that together like this:

A = 2PI*v*t/(2*PI*r)
A = vt/r

However, we must be sure that those to PI's are actually the same value before we can reduce it like that. My guess is that they are actually different versions of PI, so we can't reduce it. You will need to implement this to test which PI is the right one. The PI used to calculate the angle would be 3.14, but my guess is that the PI used for the circumference should be 4, but I'm not sure of that (fairly confident that it is, though).

I suggest you implement it using the full A = 2PI*v*t/(2*PI*r) equation, but have 2 variables for the PI values (piK and piG, for example) so it would become:

A = 2PIg*v*t/(2*PIk*r)
= PIg*v*t/(PIk*r)

Then you can adjust the values of PIg and PIk to determine which one looks right when viewing the motion.

Something to be aware of is that applying the angle, as a rotation, will actually spin the ball a bit, which will conflict with the rolling rotation of the ball. You may need to subtract the motion angle from the rolling angle to get it to look right.

It might be better to not use a rotation, but just calculate the point that it would rotate to (apply the rotation to the current position of the ball, as a vector). Then move the ball to that location and apply the normal rolling rotation.

Remember that the rotation must be applied with respect to the center of the circle.

I have just realised that the equation I just derived is almost the same equation I derived in my Spin Velocity paper. The only difference is that I used Miles angular velocity equation in the paper which is replaced by v here.

Once you have this up and running, we might try using that full equation and see how it goes. If we find that we need it, then that is good confirmation of Miles angular velocity equation.