Animate the PI = 4 experiment

My bad. You can't reference the prototype like that. So you have to refer to the actual class that you want to find the method on.

Code:


Section.prototype.init.call( this, distance, params );


This is not ideal, because if the class hierarchy changed and we put a different class in between Section and StraightSection, for example, then we need to change this reference also.

I've fixed those up and pushed a new commit.

Airman wrote:The first difficulty occurred when I tried to alter the Track.init method to include the distance along the section, adding the variable d to the parameters passed to Track.init. Changing from s.init( params ); to s.init( d, params ). This resulted in increased tube section radii as shown in the image. The straight section tube radius = radius and the curved track tube radius becomes twice the params tube radius. That change was left in place.

This is caused by doing half of the job before testing. If you change the parameters to a method/function, then you have to update all references to that method/function so that the calls pass in the correct parameters. If you changed Track.init, but didn't change the call to it, then the params parameters was actually stored in the distance parameter. So when Track.init checked to see if params was valid, it found that it was not defined, and created a new instance of it with basic values.

Code:


Track.prototype.init = function( distance, params )
{
}

function init()
{
  track.init( params );
}


See how the call doesn't match the method declaration? Javascript doesn't care about data types, so it will just pass in whatever arguments you give it when you call the method.

.

See how the call doesn't match the method declaration? Javascript doesn't care about data types, so it will just pass in whatever arguments you give it when you call the method.

Yes, including all function parameter variables in their proper order is important. I had a good learning moment when I moved the new distance variable to the first, second and third parameter positions, observing the varying track abnormalities.

If the ball travels CCW on the kinematic track, and CW for the geometric track, why is isPositiveRotation true for the K track?

I made the same variable name change, d to distance, you Committed them first.

Current Status. I don’t understand why I don’t see any motion.

I have a couple of console log outputs setup in the animate function.

Code:


if( running )
{
   console.log( "hello" ); // Many fine hellos
   // apply motion to each track  // no motion yet
   for( var i=0; i<tracks.length; i++ )
   {
      console.log( "hey hey" ); // No hey heys
      console.log( frameTime ); // No frameTime
      tracks[i].applyMotion( frameTime );
   }
}


The first console log outputs many fine hellos but the second log does not output. It appears there’s no looping through the tracks, no tracks[i].applyMotion calls.

Another console log positioned in Track.applyMotion does not output. Track applyMotion calls StraightSection, which also has a console log that does not output. CurvedSection is not yet changed, the parameters passed are correct.

The sections call Ball.applyMotion. The ball method currently increments the ball’s distance, position, and rotation with dummy values that should nevertheless show motion. No motion, a console log in Ball.applyMotion also does not output.

I'm overlooking something.
.

Airman wrote:If the ball travels CCW on the kinematic track, and CW for the geometric track, why is isPositiveRotation true for the K track?

Because a positive rotation is counter-clockwise when viewed from above.

Airman wrote:I have a couple of console log outputs setup in the animate function.

They don't show because there are no tracks. At least, there aren't in the correct place. So the loop never happens.

The problem is in the init method of the main app code. In there, it initializes the tracks like this:

Code:


var tracks = [
  createKTrack( radius ),
  createSTrack( radius ),
  createGTrack( radius )
];


But that is wrong. Mostly right, but seriously wrong, too. The problem is the var part. It should not have that because tracks is a global variable. What this does is create a local variable in the init function, which hides the global variable. So the tracks that are created get added to the local variable, and not to the global variable. But the animate function is using the global variable, so for it, there are no tracks.

The next problem is in the Track.applyMotion method, which is expecting a time object, and not the value that it is being given. I would have written that because I tend to pass around the time object (from the animate function) since sometimes you want to know the change in time since the last frame, and other times you want to know the elapsed time of the application. However, for this app, we will leave it as passing in the time difference.

Code:


Track.prototype.applyMotion = function( time )
{
  // TODO move the ball along the sections given the time to do so
  var t = time.delta; // the amount of time we have to move the ball
  // find index of current section that this.ball is in
  var index = this.findCurrentSectionIndex();
  while( index < this.sections.length && t > 0 )
  {
    // allow section to move ball, it will return the amount of time left over
    t = this.sections[index].applyMotion( t, this.ball );
    index++;
  }
};


The problem is the var t = time.delta;, which can be replaced with var t  = time;.

The next problem is that the Ball class does not have a distance property.

Code:


 function Ball( radius, velocity )  
 {
   this.radius = radius;
   this.velocity = velocity;
   this.distance = 0;
   this.material = null;
   this.object3D = null;
 };


Lastly, the Ball class does not implement the applyMotion method. The following code will get motion happening, but not the rolling effect.

Code:


Ball.prototype.applyMotion = function( changeVector, distance, time )
{
    // TODO adjust the position and distance properties
    this.object3D.position.add( changeVector );
    this.distance += distance;
    // TODO apply rolling effect
};


.

We have straightSection ball motion, traveling and rolling, exiting stage right.

I thought we were ready for motion, not expecting a whole series of corrections. Thanks for the clear directions and explanations, glad you didn’t drag that out for days.  

Nevyn wrote. What this does is create a local variable in the init function

Airman. var tracks in the init function, adding tracks to a local variable, I had no idea.

Nevyn wrote. Sometimes you want to know the change in time since the last frame, and other times you want to know the elapsed time of the application. However, for this app, we will leave it as passing in the time difference.

Airman. I'd intended to ask about time.delta. I know that Track.applyMotion receives the global variable frameTime, 1/60, and so it must be the incremental time; and I saw that there are plenty of references to time.delta at Mozilla so I left it alone.

Nevyn wrote. Lastly, the Ball class does not implement the applyMotion method. ...

Airman. It’s my understanding that the Section subclasses, straightSection and curvedSection call ball.applyMotion( v, distance, time - timeLeft ). You’d aready provided Ball.applyMotion with TODO tasks included. The changeVector 3,0,0 seems unusual to me, I guess the curved track will pass a changeAngle.

Among my errors I incorrectly tried applying the ball changes to ball.distance, ball.position and ball.rotation.z. I see I needed to use this.distance, this.object3D.position.z, and this.object3D.rotation.z instead.

The rolling motion uses my tracksData global variables, I need to change the calculation to include ‘local’ variables only.

The balls need some sort of restart/reset when they reach the end of the track.

Plenty of details to work on for the time being, thank you very much.  
.

Airman wrote:The changeVector 3,0,0 seems unusual to me, I guess the curved track will pass a changeAngle.

No, all Sections will pass in the actual position that they want the ball to end up in (relative to its current position), as a vector (it is a vector so that the curves can be handled). The other parameters to Ball.applyMotion, distance and time, will be used to calculate the rolling effect. Those 2 parameters tell you the actual distance traveled (in this frame) and the amount of time it traveled in. So you can calculate how much roll must be applied.

Something must be wrong with you new changes. When I made the changes I suggested this morning, the balls all stopped at the end of the straight sections that they were in. It can't be any other way because the curved sections do not have motion code yet. So I am wondering why your picture above shows all of the balls on the right. Quite clearly they are outside of the sections. Perhaps you have some initial code in the curves for motion?

The Track class can have a new method to determine if the Ball has reached the end of the track or not. It would look like this:

Code:


Track.prototype.isComplete = function()
{
  var d = 0;
  for( var i=0; i<this.sections.length; i++ )
  {
    d += this.sections[i].length;
  }
  return this.ball.distance >= d;
};


When all tracks are complete, then you can call the reset function (app function, not Track.reset).

Actually, let's split that into 2 methods, since some of that is useful on its own:

Code:


Track.prototype.getLength = function()
{
  var d = 0;
  for( var i=0; i<this.sections.length; i++ )
  {
    d += this.sections[i].length;
  }
  return d;
};

Track.prototype.isComplete = function()
{
  return this.ball.distance >= this.getLength();
};


I noticed that you altered the Ball constructor to take in a distance. That isn't needed. It would only be useful for starting the ball part way through the track, but we don't necessarily know how long the track is when we create the ball. In the very least, you should expect it to not be supplied to the constructor, so check it and set it to 0 if not found:

Code:


function Ball( radius, velocity, distance )
{
  this.radius = radius;
  this.velocity = velocity;
  this.distance = distance;
  this.material = null;
  this.object3D = null;
 
  if( typeof this.distance !== 'number' || this.distance < 0 )
  {
    this.distance = 0;
  }
}


I also threw in a check for negative numbers, since that is illegal.

What this allows is for a call to the constructor to not pass in a distance value, and everything still works.

Code:


var b1 = new Ball( 1, 2 ); // distance will get set to 0 by default
var b2 = new Ball( 1, 2, 3 ); // distance will be set to 3
var b3 = new Ball( 1, 2, -4 ); // distance will be set to 0 since it can't be negative


After a bit of searching, and head scratching, it turns out that the balls not stopping at the end of a section was caused by the issue I mentioned in my last post. Making distance an argument to the constructor, and not passing in a value for it, caused this.distance to equal NaN (Not a Number). Adding the code that I suggested above fixed it.

Code:


   function Ball( radius, velocity )  /////////////////////////
   {   
     this.radius = radius;
     this.velocity = velocity;
     // this.distance = distance;
     this.material = null;
     this.object3D = null;
    
     if( typeof this.distance !== 'number' || this.distance < 0 )
     {
         this.distance = 0;
     }

   };


You can choose to either not pass in distance and set it to 0, or pass it in and check it for the right type of value. The code above is doing half of each job. It works, but it is doing too much for the outcome that it gives. The only possible outcome from the above code is for this.distance to equal 0. So just set it to 0. It doesn't matter much which one you choose, but it should be one of these:

Code:


   function Ball( radius, velocity )
   {   
     this.radius = radius;
     this.velocity = velocity;
     this.distance = 0;
     this.material = null;
     this.object3D = null;
   };


or

Code:


   function Ball( radius, velocity, distance )
   {   
     this.radius = radius;
     this.velocity = velocity;
     this.distance = distance;
     this.material = null;
     this.object3D = null;
    
     if( typeof this.distance !== 'number' || this.distance < 0 )
     {
         this.distance = 0;
     }
   };


Since it is already done, you may as well use the second version which does give more functionality than the other. We don't actually need that functionality, but it won't hurt, either.

.

The balls now ‘correctly’ stop at the ends of the short and long straight sections, the curved track ball motion is not yet written.

Since yesterday, I made your most recent code corrections, thank you.
Today’s forward progress is adding rolling motion to Ball.applyMotion using this.distance and both kinematic and geometric pi. Since we know how easy it is to screw up implementing kinematic pi, please see if you agree.

Applying Rolling Motion. My approach to coming up with a rolling angle was in identifying a rolling angle ratio: The rolling angle is to 2PI radians as the incrementalDistance is to the ball’s circumference.

this.object3D.rotation.z/2*Math.PI = distance/2*Math.PI*this.radius;
While I believe the ratio is ‘correct’, given my understanding of kinematic pi, I don’t believe one can simplify by eliminating 2*Math.PI from both sides.

this.object3D.rotation.z -= distance/this.radius; // Geometric

Doing so anyway, with the comment // Geometric

Back to the rolling angle ratio, I believe the 2*Math.PI denominator on the left involves the definition of the radian angle and is therefore geometric pi. The 2*Math.PI on the right is distance traveled around the circumference and must be kinematic.

this.object3D.rotation.z -= (distance/2*4*this.radius)*2*Math.PI; // Kinematic
Note that with no cancellation of pi, but instead using both pi values, the kinematic rolling distance is 4/Math.PI greater than the geometric roll. The cycloid roll. The kinematic roll looks good to me.  

/////\\\\\/////\\\\\/////\\\\\

I haven't given your latest post much thought yet. This comment may or may not be pertinent. If we intend to have a physics violating geometry track, there’s no way that the straightSection can turn cycloid rolling on or off or the curved section can vary the distance traveled by the ball. Perhaps Ball.applyMotion can do both by using the distance variable. For example, to switch between the cycloid and non-cycloid roll.   
.

I had the following written out before you posted, so it may sound like it is ignoring your last post, which it is.


I also noticed this code in the Ball.applyMotion method:

Code:


 Ball.prototype.applyMotion = function( changeVector, distance, time )
 {
 // TODO adjust the position and distance properties
 this.object3D.position.add( changeVector );
 this.distance += distance;

 // TODO apply rolling effect
 // The rolling angle is to 2PI as the incrementalDistance is to the ball circumference.
 // (this.object3D.rotation.z/2*Math.PI = distance/2*Math.PI*this.radius)
 
 //this.object3D.rotation.z -= distance/this.radius; // Geometric

 this.object3D.rotation.z -= (distance/2*4*this.radius)*2*Math.PI; // Kinematic
 
 };


The interesting thing is the 2 types of rotation at the bottom. At first I thought you were trying to handle the curves in the Ball class, which shouldn't be needed or desired, but I finally realised that it was the actual roll itself that can be geometric or kinematic. I've tried both and can't seem to choose between them. Neither one of them looks wrong, but it is difficult to tell.

However, it does present something to think about, since there are 2 ways for the ball to roll. We should allow the user to choose between them or we choose different rolls for different tracks. So how do we implement that? We could introduce 2 new Ball sub-classes: GeometricBall and KinematicBall. We could also introduce a new property of the Ball class that sets which type of roll to use. I am leaning towards the new property, but even that gives us options.

We can just create a boolean property that tells us which roll to use and then add an if statement in the applyMotion method to choose which one to execute. Alternatively, we could make it a function property which provides the actual code itself.

I've just realised that there are really 3 options, because we could not have a roll at all. So the boolean option would need to be some other data type, such as a number, that tells which options to use. The function version remains as-is, since we can just supply a function that does nothing or if the function property is not a function, then don't execute it.

As it presents a new programming lesson, I am going to choose the function approach. This lets us see some of the ways that Javascript allows us to use functions as objects.

Code:


   function Ball( radius, velocity, distance )
   {  
     this.radius = radius;
     this.velocity = velocity;
     this.distance = distance;
     this.material = null;
     this.object3D = null;

     this.roller = null; // optional function that applies the roll, must accept 3 parameters: ball, distance, time
    
     if( typeof this.distance !== 'number' || this.distance < 0 )
     {
         this.distance = 0;
     }
   };


The applyMotion method now changes to look like this:

Code:


 Ball.prototype.applyMotion = function( changeVector, distance, time )
 {
  // adjust the position and distance properties
  this.object3D.position.add( changeVector );
  this.distance += distance;

  // apply rolling effect
  if( typeof this.roller === 'function' )
  {
    this.roller( this, distance, time );
  }
 };


Now we create some functions to implement the roll:

Code:


function geometricRoller( ball, distance, time )
{
  ball.object3D.rotation.z -= distance/ball.radius;
}

function kinematicRoller( ball, distance, time )
{
  ball.object3D.rotation.z -= (distance/2*4*ball.radius)*2*Math.PI;
}


We will also add a new method to the Ball class to set the roller so that it can make sure that it is a function.

Code:


Ball.prototype.setRoller = function( fct )
{
  if( fct == null || typeof fct === 'undefined' || typeof fct === 'function' )
  {
   this.roller = fct;
  }
  else
  {
    throw "Ball.setRoller must be given a function";
  }
}


This method allows fct to be a function, undefined, or null, and it will set this.roller to that value. Anything else will cause an error.

By default, there is no roll because this.roller is set to null. But we can apply one easily by calling our new method:

Code:


ball.setRoller( kinematicRoller );


If we had an existing roller function, but wanted to remove it, we just call it like this:

Code:


ball.setRoller( null );


or

Code:


ball.setRoller();


or even this

Code:


ball.setRoller( undefined );


This shows how we can use external functions to apply functionality to a class or object. This is called Composition, which we can choose to do instead of Inheritance (i.e. sub-classing).

Note that we could do a lot more than just apply a rolling effect. Let's say we wanted to make the ball lerp between 2 colors as it moved along. We could do that with a new roller function (which we should not call a roller anymore):

Code:


var COLOR_SHIFTER_START_COLOR = new THREE.Color( '#000000' );
var COLOR_SHIFTER_END_COLOR = new THREE.Color( '#ffffff' );

function colorShifter( ball, distance, time )
{
  var t = Math.sin( time );
  ball.material.color = COLOR_SHIFTER_START_COLOR.lerpHSL( COLOR_SHIFTER_END_COLOR, t );
  ball.material.needsUpdate = true;
}


The problem here is that I had to declare 2 constants so that we had some colors to lerp between. This is not ideal because it means all balls will use the same colors. To change that, we could introduce some color values on the Ball class, but I don't want to do that since they are not needed most of the time. Instead, I am going to create a function that creates a function:

Code:


function createColorShifter( startColor, endColor )
{
  return function( ball, distance, time )
  {
    var t = Math.sin( time );
    ball.material.color = startColor.lerpHSL( endColor , t );
    ball.material.needsUpdate = true;
  };
}


We can do this because functions are just objects. In order to use it, we do this:

Code:


ball1.setRoller( createColorShifter( new THREE.Color( '#ff0000' ), new THREE.Color( '#0000ff' ) );
ball2.setRoller( createColorShifter( new THREE.Color( '#ff00ff' ), new THREE.Color( '#00ffff' ) );


Note that we invoke the createColorShifter function, we do not pass it in because we want to pass in the function that it creates.

Well that is fine and dandy, but how do we apply both a roll and a color shift?

Quite easily, actually, we just create a new function that will merge the 2 together:

Code:


function mergeRollers( roller1, roller2 )
{
  return function( ball, distance, time )
  {
    roller1( ball, distance, time );
    roller2( ball, distance, time );
  };
}


Which we use like this:

Code:


ball.setRoller( mergeRollers( kinematicRoller, createColorShifter( new THREE.Color( '#ff0000' ), new THREE.Color( '#0000ff' ) ) );


The color shifter implementations use the time as a way to create a varying value, but this won't actually work because that time will always be the same. Unfortunately, the same applies to distance, so we don't really have a way to determine how to vary the color. This is why I usually pass through the time object that contains both delta and elapsedTime values. We could use elapsedTime in this scenario.

Actually, the time won't always be the same value, but it doesn't vary in the way I want it to. It only varies when the ball is crossing over from one section to another.

.

Today we have reset, meaning continuous, but not exactly non-stop motion. The curved track balls still stop at the ends of the initial 2*radius straight section, but when the straight track ball reaches the end of its track (ball.distance > 10*radius), all three balls are reset back to beginning of their straight tracks to resume or continue forward motion and rolling action. I’m sure that the 10*radius condition is wrong, I guess I need to figure out how to use Track.isComplete before going further, but I’m not at all certain.

I take it you don’t see any problem with my rolling angle ratio approach. I’m certain the same ratio applies to calculating the correct (kinematic) or incorrect (geometric) positions of the ball about the kinematic or geometric tracks. At some point I would like to be able to satisfy anyone's curiosity about whether the geometric or kinematic rolling types are correct. I would do so by installing linear graduations say every 0.001*radius, just below the ball, perpendicular to the x axis in order to see which roller type kinematic or geometric provides a ‘stationary’ contact point.

Nevyn wrote. As it presents a new programming lesson, I am going to choose the function approach. This lets us see some of the ways that Javascript allows us to use functions as objects.

Code:

this.roller = null; // optional function

Ok, starting with two or three ball rolling alternatives – kinematic, geometric, or no roll at all, each may be represented by a single new property, ball.roller. Roller will be defined by a function, but it doesn’t need to be defined here, there are alternatives, we’ll start by letting it equal null. We must ensure that it is set to a function. Thanks for using the the app possibilities, it makes following your code description easier. Apparently one needs to remove the roller function before resetting it to another function (?). Apparently I have my limits. Launching into lerps almost knocked me for a loop. Composition, which we can choose to do instead of Inheritance sounds beyond my keen. I’ll need to reread that post a few more times. I don’t believe you gave me any direct instructions or tasking.

Once again, my intent is to resume working with circular track motion.

PS changed parallel to perpendicular and moved that description above your quote.
.

I wasn't looking too closely to the rolling code. I was thinking more about the higher level stuff. They didn't look too bad on screen, so they can't be too far wrong, if they are at all.

Airman wrote:Apparently one needs to remove the roller function before resetting it to another function (?).

No, not at all. You can just set one over the top of the other. I just wanted to show how you could remove one, if a ball already had one that you did not want it to have. There really is no need for that in this app because everything is setup at the start and doesn't change.

.

Working on the balls' circular track motion. All over the place. This may take longer than I suspected.

Quick update. Some progress. I haven’t Committed or Pushed it yet, a solution that resets all tracks when all tracks are completed. I used Tracks.isComplete() in the animate function. Please ignore the 10*radius condition that will be removed shortly.

Code:


if( running )
{
 var trkDoneCounter = 0; // Will count completed tracks

 // apply motion to each track  
 for( var i=0; i<tracks.length; i++ )
 {

 if( tracks[i].isComplete() )  // Now this looks right
 {
 trkDoneCounter += 1;
 };
 //if( tracks[i].ball.distance >= 10*radius ) // Actual, temporary code.
 // The above ( >=10*radius ) is temporary, until the curved sections are added.
 // All tracks are reset when all tracks are completed
 if ( trkDoneCounter >= tracks.length )   // This is the replacement code
 {
 reset();
 }
 else
 {
 tracks[i].applyMotion( frameTime );
 };
 };
};

The Track.isComplete method is designed to tell you whether the track you invoke that method on has finished, that is, the ball has reached the end of the last section. It is only for that single track, but we only want to reset when all tracks are complete. Some tracks will finish before others because there are velocity differences in the curves. We want those tracks that finish first to just wait at the end until the others are complete. Then we move the balls back to the start of each track.

It is the application of motion that causes a ball to reach the end of its track, so we want to test for completion after we apply motion. However, we don't want to act on those answers until all tracks have been tested.

Code:


   function animate(  )
   {       
      time = clock.getElapsedTime();
      // do any common pre-tasks here      

      requestAnimationFrame( animate );

      if( running )
      {
         // boolean value to determine when all tracks are complete
         // assume true, and set to false if an incomplete track is found
         var allTracksCompleted = true;

         // apply motion to each track 
         for( var i=0; i<tracks.length; i++ )
         {
            tracks[i].applyMotion( frameTime );
            // check if the track is completed
            if( !tracks[i].isCompleted() )
            {
               allTracksCompleted = false;
            }
         }
         
         // now check if all tracks are completed and reset if so
         if( allTracksCompleted )
         {
            reset();
         }
      }

      renderer.render( scene, camera );
   };   


However, that won't work at the moment because the curves don't apply motion. Note that this also means that a completed track will still have its applyMotion method invoked. I think that may cause some problems, but they are easy to handle, so I'm not worried about them. Actually, I just checked what I thought would cause the problem but it doesn't. The condition is already handled. I thought it would keep finding the last section and trying to apply more motion because the time had not gone down to 0. But it already increments to the next section, which won't exist when the ball is at the end of the last one. So it falls out with no motion being applied.

Actually, you know what, I don't like relying on that check. I'm going to refactor the Track.findCurrentSectionIndex method, and the Track.applyMotion method to handle things a bit better.

Code:


   Track.prototype.findCurrentSectionIndex = function()
   {
     var d = 0;
     for( var i=0; i<this.sections.length; i++ )
     {
      d += this.sections[i].length;
      if( d > this.ball.distance )
      {
        return i;
      }
     }
     return -1;
   }


I changed that to return -1 if no section is found. It was returning 0, which would mean that the first section was used, but I want to avoid that now.

This means that the Track.applyMotion method must now check for that and avoid applying motion if no section is found.

Code:


   Track.prototype.applyMotion = function( time )
   {
      // move the ball along the sections given the time to do so
      var t = time;
      // find index of current section that this.ball is in
      var index = this.findCurrentSectionIndex();
      if( index > -1 )
      {
         while( index < this.sections.length && t > 0 )
         {
            // allow section to move ball, it will return the amount of time left over
            t = this.sections[index].applyMotion( t, this.ball );
            index++;
         }
      }
   };


.
Pardon, there seems to be some miscommunication. You indicate that my code doesn’t check that all tracks are completed before resetting. It does. tracks[i].isComplete(), is used for each track, and when that track completes, increments the trkDoneCounter. When the number of tracks done equals the number of tracks, (trkDoneCounter = tracks.length = 3 ), then all tracks are reset.

Nevyn wrote. I'm going to refactor the Track.findCurrentSectionIndex method, and the Track.applyMotion method to handle things a bit better.

I’m not sure you want me to make those changes or you will. Letting you know I've made them and will Push them tomorrow so you might Push them first if that is your intent.
.

While your code appears to work like that, it only does so because of the circumstances. It would not work like that if the curve motion was implemented, because it is watching the long straight track and only when that completes, does it consider everything to be complete. That may work with the given tracks, but it isn't fool proof.

I realise that you have to watch the straight track for now, because curve motion is not implemented, and that is fine, but I wanted to show the code as it should be, once everything is in place.

Here is the code that I was looking at:

Code:


   function animate(  )
   {       
      time = clock.getElapsedTime();
      // do any common pre-tasks here      

      requestAnimationFrame( animate );

      if( running )
      {
         var trkDoneCounter = 0; // Will count completed tracks

         // apply motion to each track 
         for( var i=0; i<tracks.length; i++ )
         {
            if( tracks[i].ball.distance >= tracks[i].getLength() )
            {
               trkDoneCounter += 1;
            };

            if( tracks[i].ball.distance >= 10*radius ) // Works.
            // The above ( >=10*radius ) is temporary, until the curved sections are added.
            // All tracks are reset when all tracks are completed            
            //if ( trkDoneCounter >= tracks.length )  // Replaces ( >=10*radius )
            {
               reset();
            }
            else
            {
               tracks[i].applyMotion( frameTime );               
            };
         };
      };

      renderer.render( scene, camera );
   };   


The main points I wanted to make were how to use the Track.isComplete method, and that the call to reset should be outside of the for loop. As it is currently implemented, a reset can happen part way through that loop (since it is the middle track that is being watched). That could cause the third track to be reset and then apply motion in the same frame, so the ball of the third track would creep ahead of the others. So that code actually doesn't check all tracks before resetting. I can see that you are trying to do that, or have tried because it is commented out, but it doesn't.

I wasn't going to push those changes. I am trying to refrain from making any changes and just try to push you in the right direction when needed, or I think it will help, or is just an interesting thing to show.

I should also mention that what I write, and how I write it, does not necessarily reflect on you or what you have written. My intent is to show good programming practices, when applicable, but also to show my thought processes. I want to show how I think through a problem, and why I am making certain decisions. These are very important, and things that only come with a lot of experience. I've been through the pain that you are currently experiencing. The frustration of not knowing why something is not working as you intend it to be or not knowing how to proceed with a given problem. I still experience such things, when I don't fully understand what I am doing or how a certain tool might work. I'm trying to help you to see how to get around such things, when I can. Even when I see code that you wrote, but don't think it should be that way, I am still often happy that you got something to work. I saw you using the straight track to check for completeness, knew that it was wrong, but there was nothing else you could do in the current circumstances. Nothing wrong with that, and I don't have a problem with it, but I do want to show how it should be, and where we want to end up.

.

The balls are moving ‘properly’ on their tracks, although properly isn’t yet well defined for the geometric track.

You're right, I did indeed code incorrectly by including the reset inside the animation 'loop'. Thanks, that's now corrected. I'm very grateful for this great learning experience. I was afraid you weren't having a senior moment, of which I'm too familiar.

In the image, the piG track ball has ‘completed’ it’s distance of 2*this.radius + 2*Math.PI*this.radius. It stopped and is waiting until the piK and straight track balls reach their endpoints. When they do, all three balls are reset to their starting positions.

Here’s my rationale.

Ball.prototype.applyMotion = function( changeVector, distance, time )

The ball is advanced in the Ball.applyMotion function, requiring a changeVector v, distance, and time. We know the distance and time. Find the changeVector v.

v is found by subtracting the ball’s initial position from it’s final position. Calculate both. Of course the ball (and v) begins and ends on the circular track, advancing in frameTime angular increments. The kinematic motion of the ball around the circular track is described by:  

positionAngle/2*piG = distance/2*piK.
In terms of a ball’s changing angle: positionAngle = 2*piG*distance/2*piK*this.radius.

The positionAngle might be considered as a vector rotating about the circular track’s center.
We want two position angles, initialAngle and finalAngle.

And the corresponding code for finding the changeVector.

Code:


if ( this.length == 2 * Math.PI * this.radius ) // geometric
{
 var initialAngle = -Math.PI/2 - Math.PI*ball.distance/4*this.radius;
 var finalAngle = -Math.PI/2 - Math.PI*( ball.distance + distance )/4*this.radius;
 // convert to rectangular coordinates.
 var initialPosition = new THREE.Vector3( this.radius*Math.sin( initialAngle ), 0, this.radius*Math.cos( initialAngle ) );
 var finalPosition = new THREE.Vector3( this.radius*Math.sin( finalAngle ), 0, this.radius*Math.cos( finalAngle ) );
 var v = new THREE.Vector3( finalPosition.x - initialPosition.x, 0, finalPosition.z - initialPosition.z );
}
else // kinematic.
{    
 var initialAngle = -Math.PI/2 + Math.PI*ball.distance/4*this.radius;
 var finalAngle = -Math.PI/2 + Math.PI*( ball.distance + distance )/4*this.radius;
 var initialPosition = new THREE.Vector3( this.radius*Math.sin( initialAngle ), 0, this.radius*Math.cos( initialAngle ) );
 var finalPosition = new THREE.Vector3( this.radius*Math.sin( finalAngle ), 0, this.radius*Math.cos( finalAngle ) );
 var v = new THREE.Vector3( finalPosition.x - initialPosition.x, 0, finalPosition.z - initialPosition.z );
};


The curve track balls still need their y-axis rotation, equal to their final angle.
.

That's a great start. The rolling isn't working too well, but that was always going to be tricky. Not worried about that at the moment.

I know this is a work in progress, but when you thought about splitting it into geometric and kinematic parts, you should have put each into their own classes: GeometricSection and KinematicSection. I don't blame you though, because I explicitly said it could be done in CurvedSection (which it can, but without splitting it).

Here is my idea on how to calculate the angle:

CurvedSection knows the length that is represents, and it knows that it represents a complete circle. So it knows that its length, whatever that is, represents 360°. Therefore, it can take the distance to be moved and divide it by the length to get that distance as a percentage (/100). Then you multiply that number by 2PI (PI=3.14) to get the angle that that distance represents around the circle. That gives us the angle of change.

Then we find the current position of the ball, in the same way as we can't rely on the ball.object3D.position value here, which gives us a vector positioned somewhere on the curve. Then apply the angle of change to that vector (use a THREE.Quaternion and use either 0,1,0 or 0,-1,0 for the axis depending on which way the circle curves), which gives us the change vector.

By doing it this way, the same code handles both types of curve, since it is the length property that provides the difference.

It is quite similar to what you have done, but it removes the need for any version of PI.

Let's see if I can provide some of that code for you:

Code:


CurvedSection.prototype.calcPositionVector = function( distance )
{
  var ratio = distance / this.length;
  var angle = ratio * 2 * Math.PI;
  var pos = new THREE.Vector3();
  var axis = new THREE.Vector3();
  if( this.isPositiveRotation )
  {
    pos.set( 0, 0, 1 ); // starts at the bottom of the circle (not sure if these are the right way around)
    axis.set( 0, 1, 0 );
  }
  else
  {
    pos.set( 0, 0, -1 ); // starts at the top of the circle (not sure if these are the right way around)
    axis.set( 0, -1, 0 );
  }
  var quat = new THREE.Quaternion().setFromAxisAngle( axis, angle );
  pos.applyQuaternion( quat );
  return pos;
};


That gives us a method that will calculate the position vector, relative to the start of the circle. Now we can use that in applyMotion:

Code:


CurvedSection.prototype.applyMotion = function( time, ball )
{
  var distance = ball.velocity * time;
  var lengthLeft = this.length - (ball.distance - this.distance);
  var timeLeft = 0;
  if( distance > lengthLeft )
  {
    // we've gone too far
    // calc time left
    timeLeft = (distance-lengthLeft) / ball.velocity;
    // adjust distance
    distance = lengthLeft;
  }
  // find current position on the curve
  var currentPos = this.calcPositionVector( ball.distance - this.distance );
  // find the next position on the curve
  var change = this.calcPositionVector( distance );
  // find the difference between the 2
  change.sub( currentPos );
  // apply motion to the ball
  ball.applyMotion( change, distance, time - timeLeft );
};


I think that will be pretty close. It handles the positive and negative rotations, too.

I think rolling around the Y axis will be better. The curves won't need to be handled, then.

.

The piK ball has no problem, the piG track ball won’t stay on the track.

Sorry Nevyn, the image shows the best I've been able to do implementing the CurvedSection axis angle code.
ratio = distance/this.length. This.length can be one of two values:
this.length = 2*Math.PI*this.radius; // for the piG track or
this.length = 2*4*this.radius; // for the piK track.
var angle =  ratio * 2 * Math.PI;
There are just two different rotation rates.
I believe I’m making the necessary effort. I don’t know why it’s not working. For example, when I add a multiply by two to both the top and bottom of the calculation, they should cancel, but no, the spinning speed doubles. I guess I need to review axis angle math again.  

My parametric solution has the piG track operating the same as the piK track. Currently, the piG ball reaches the PI (3.14…) position and stops because when ball.distance > 2*Math.PI*this.radius it’s told to stop. The easy solution might be to multiply its incremental distance by 4/(3.14…) and let its motion around the curved track continue past ball.distance = 2*Math.PI until the piK and straight tracks are done.

With respect to the curved track balls’ y axis rotation. There is unnecessary complication. We calculate the balls’ initial and final angles and positions in CurvedSection.applyMotion; and then pass changeVector to Ball.applyMotion. Ball.applyMotion must then recalculate the ball’s final angle again. I tried a solution but it looks like the curved track balls have some sort 180deg spin reversals, I think that means zero crossing problems in the angle calculation.  Why not just add the finalAngle along with the other three parameters passed to Ball.applyMotion( changeVector, distance, time )?
.

I fixed the problems with curved motion. There were some problems in the code that I supplied, but once I got it back to that, and spent a bit of time trolling through it, I found the issues and patched them up. The main problem was using the wrong distances when calculating the position vectors.

.

In order to observe the balls’ spin directions as clearly as possible, I replaced the white straight track sections which wash out the yellow ball color with high contrast blue, then gave the balls 3 color axes for easier rotation monitoring. Easily confirming the balls’ are flipping their y axis spin directions 180 degrees at the curved tracks’ three and nine o'clock positions.

Excellent. You didn’t just fix the problems with curved motion, you’ve made noteworthy additions to the PI=4 application. I'll list them. By the way, please excuse my screwing up the axis angle calcs, I was going to come back to them, likely make things worse, thanks for the quick correction.

1. We now have a resetTimer. The balls wait two seconds at their starting positions before resuming forward motion. A definite improvement.

2. A Ball.reset function of its very own as befitting its class, taking load off the Track class Track.reset function. I actually considered that.

3. And Holy McGillicuddy, a “debug framework”. It enables altering the tracks by adding straight and curved sections(?) for debugging!(?). How exactly?
.

Yeah, I kind of got carried away after fixing those bugs.

I thought the reset timer was useful. The balls jumped back to the start before you realised what was happening. You can adjust the wait time, there is a variable for it (can't remember the name right now).

That's great that you thought of putting a reset method on the Ball class. Next time, go for it! Try to think of whose responsibility what you are trying to add belongs to.

I had a play with adding new sections to the track just to make sure everything still worked correctly. I was about to delete those changes when it occurred to me that they are useful. So I setup a bit of a framework for it. Basically, just an easy way to turn various things on and off.

In the first instance, it is just a collection of global variables that can be used to decide if certain behaviour should be used or not.

In the second instance, it also has a single variable that can be used to turn all debugging on or off. When it is off, no other options matter, but when it is on, the other variables can be used to determine individual options.

It declares a new global function called __assert, which takes in one of the global variable options. It will return true or false depending on if the over-all debug option is enabled, and the given option is enabled.

You can add new debug options if you want. Follow the naming convention that I have used: __DEBUG__name__. Note that they are all double underscores, but the name part should use single underscores to separate words.

Code:


var __DEBUG__MY_NEW_OPTION__ = true;


Then you just use it with the __assert function like this:

Code:


// in some function
if( __assert( __DEBUG__MY_NEW_OPTION__ ) )
{
  // do something special
}


These are meant for app level code, not inside of the classes. If you really want something like that, then you can if you want to, but it ties the classes to the app, which we should avoid if we can. Not a big deal, though.

When I said that I thought the rolling should rotate around the Y axis, I meant the top level coordinate system (where the user is looking down the +Y axis). Maybe the balls have a different orientation because they are currently rotating around the Z axis.

I had a play around with the rolling effect, trying to get it to roll nicely, given the different ways that the tracks curve. I added a new property to the Ball class, isPositiveRotation, that made it rotate in opposite directions. It didn't work very well though. One of the balls on the curved tracks looks like it is moon-walking!

What we need to do is change the axis of rotation based on the change vector being applied. You can't just rotate around 1 axis when the direction of motion is changing. We need to find the vector that is perpendicular to the change vector, which will become the axis or rotation. Before that though, we need to change the code to work with quaternions, as that will make the next changes easier.

Ok, you've already done it. Not with quaternions, but it looks like what I wanted anyway. Actually, I just looked at the code and it passes in the angle from the calling code (the section). I don't like that. It can be calculated with the info that was already available. We can come back to that later, though. I might be convinced to do it the way you have.

.

I understand the moon-walking reference alright, maybe call it moon-rolling, moving forwards with a backward rolling z-spin.

As you noticed, I'd just gotten the curved track balls’ y axis rotation working. The solution uses the math function atan2 which I first read about and used yesterday. At first I tried finding the
finalAngle = atan(changeVector.z/changeVector.x) inverse tangent function, unfortunately the atan function is undefined at the curved tracks’ 3 and nine o'clock positions (where changeVector.x = 0), and the balls y’axis flipped at those locations. Turns out, the atan2 is the practical tool that provides the angle for any pair, changeVector.x and changeVector.z values. If you want to switch to a quaterion or axis angle solution, just say so, you’re the boss.  

As for whether the calculaton belongs in Track.applyMotion or Ball.applyMotion, I’d say it‘s a toss-up. We rely on the track to provide the changeVector, the next incremental forward motion position. finalAngle uses the same changeVector information but different form. I suppose the section might need to know its length and direction, which justifies leaving the calc in Track.applyMotion. The ball knows how far it has traveled. Does the ball need to know what direction its going? Actually, I’m convincing myself to move the atan2 function to the ball, I’ll go ahead and do so. Again, feel free to direct me otherwise.

I believe you indicated that resetTime, your new global variable indicating the number of seconds for the balls to delay at start should be user controlled. The datgui control panel is back, and StartDelayInSecs is the first control item. My only objection to the datgui is that it obscures part of the app title/headline. I routinely turn it off by pressing the h key.

There are two other things that I would most like to see user controlled, ball.velocity and ball.radius. Those are ball class variables that don’t sound like app level control items to me. How would we go about changing them? Anyway, towards that end, I found I can control the ball radius, but that appears to be part of a larger problem with the balls’ rolling spin rates that I’m having trouble figuring out.

In the app, we initialize the tracks and pass params for the tube radius. var params = { tubeRadius: 0.25 * radius }; and, tracks[i].init( params );. radius is the global track radius variable.

In Track.init, the balls are created by the call, this.ball = new Ball(params.tubeRadius,1 ); The first variable passed corresponds with the ball.radius. The second parameter, 1, becomes the ball.velocity. If you change params.tubeRadius, you actually change both the tube radius and the ball.radius which are both set equal to tubeRadius.

I think we have a radius problem. The global variable radius is set to 1. If I double it, there is no change in appearance, the tube and ball radius are functions of the track radius and so they expand proportionally. Logically, doubling the track radius makes the track twice as long, but if the ball.velocity remains the same, the ball must travel half its previous velocity, which it does. The spin rate however more than doubles, which can’t be right.

In Ball.applyMotion the proper ball z axis rolling effect is `calculated using:
  http://this.object3D.rotation.z -= distance/this.radius; // Geometric
  this.object3D.rotation.z -= (distance/2*4*this.radius)*2*Math.PI; // Kinematic
The distance in the numerator is the ball.distance as a fraction of the total track distance traveled, which increases from zero to 10 times the track radius. The this.radius in the denominator is the ball’s radius. For some reason, the calculation is not working for any changing radius.
.

You will often find that you need to use atan2, as the atan function has issues, as you describe.

I understand what you are saying about the change angle, and I'm a bit mixed myself. I was trying to avoid the section having to think about rolling type effects, since they have nothing to do with it. However, the change angle isn't that different to the change vector, so I'm happy for it to stay at the moment. I would prefer if it could be calculated in the Ball.applyMotion method, but it's not that big of a deal.

One thing, though, change the order of parameters in the Ball.applyMotion method so that the change vector is first, then the change angle. The vector is more important, so it should go first. Don't forget to change the calling code as well.

I didn't mean for resetTime to be adjustable by the user, but that is a good idea anyway. Go for it.

The ball velocities can easily be controlled by the user, and is a great idea. However, the radius is a different beast. The problem is that the radius is used to build the 3D scene nodes, so if you want to change its value, all of the nodes need to be rebuilt. I don't think it is worth the effort. It effects too much, such as the camera position. We can get around that by setting the camera position such that it always keeps the complete tracks in view, but I just don't see what changing the radius gives the user.

Airman wrote:In Track.init, the balls are created by the call, this.ball = new Ball(params.tubeRadius,1 );

I meant to talk about that yesterday. That line needs to go. I tried setting some properties on the balls yesterday, and they didn't work because of that line. The Ball is created in the Track constructor, so it should not be created again in the init method. By creating it in the constructor, the calling code (app code in this instance) has a chance to change the properties of the ball. They get lost if the ball is re-created in the init method. What you should do instead, is set the radius (and maybe the velocity) directly:

Code:


this.ball.radius = params.tubeRadius;


You do that before you call Ball.createObject3D (which we should rename to Ball.init for consistency).

The problem with the roll is that the math is incorrect. Here is what it currently is:

Code:


this.object3D.rotation.z -= (distance/2*4*this.radius)*2*Math.PI;   // Kinematic


which looks fine until you think about operator precedence. Multiply and divide are of equal precedence, so they happen in the order that they are specified in, so the above code is the same as this: 4 * this.radius * distance/2, which is not what we wanted at all.

Here is what it should be:

Code:


this.object3D.rotation.z -= ( distance / ( 2*4*this.radius ) )*2*Math.PI;   // Kinematic


It just needs some parentheses make sure the circumference is calculated in total, before it is used to find the ratio with the distance.

.

Today’s changes include graduated color markers and different ball colors. The blue ball is about to reach the incorrect, geometrically assumed, track end distance, 2*r + 2*(3.14…).

Thanks for showing me the error of my rolling ratio calculation. Another */+- math order error, I didn’t see the operation as that complicated, it’s amazing what a difference a good pair of parenthesis can make.

I said I’d like to be able to change the ball.radius, and you said you don’t see what changing the radius gives the user. You once indicated that for the PI=4 animation you’d prefer balls as large as possible in order to see the curved motion as clearly as possible. I thought the balls should be the same relative size as the metal bearings to track radius in StevenO’s experiment, the computer lets us zoom in if we like. Using large balls looks like a clunky exaggeration but I’m used to them. Just splainin.

Like usual, I launched SourceTree and made my initial fetch of the day. After a minute, not yet completed, I cancelled the Fetch and went about my routine. That’s happened several times before. And again an hour later. Recalling that one may always commit one’s changes, but one should never pull without Fetching, I went about my usual routine. I staged my changes and began my Commit comment when I saw myself an entry away from a new branch. There were 11 Pulls that SourceTree did not show me earlier. I un-staged my changes, cancelling the Commit, and saved them elsewhere. No stress.

You completed the markers in one fell swoop. I like the color gradation change. They seemed a bit ‘wide’ at first, making them any narrower would make the color gradation less visible. I can see how adding a PI marker makes a bit of a problem. But wait, I thought Marker was supposed to be another class, beginning with
Marker.prototype = Object.create( {} );?
That didn’t happen, I need to figure out how you did it.

My attempt at a controlling the ball velocity began by adding a new property, ballVelocity, to params, then making params a global object instead of an init object.

var params = { tubeRadius: 0.25 * radius, ballVelocity: 2 };

I made the assignment change in Track.init,

this.ball.velocity = params.ballVelocity;

Then added the parameter and onChange function to the datgui.
bVelocity: 2,

var theBallVelocity = gui.add( parameters,'bVelocity').min(0).max(10).step(0.1).name('BallVel');
theBallVelocity.onChange(function(value)
{ params.ballVelocity = value; });

No surprise, it didn’t work. The tracks probably need some sort of init or reset. Maybe a new setVelocity function might be required. You indicated that the ball velocities can be easily controlled in plenty of ways. Pardon me for asking, what am I missing?
.

I wanted to see how the markers would work and flesh out what I had already started. It took a bit of effort, with many issues, so I thought I would push the changes and save you the pain that I had to go through.

The PI marker is not really a problem, you just need to calculate where it is as a total distance along the track. I setup a marker creation function that just puts markers at regular intervals, but the system is not limited to that.

I also made all tracks have the same markers, but that is not required either. Each track can have its own set of markers.

The markers still use the Marker class, but I allowed a number to be passed in as well. When a number is encountered, it creates a new Marker object with that number set as the distance. You can create your own Marker objects and pass them in to Track.addMarker too. In fact, the color functions I created do exactly that. It might take you a bit to unwind what I have done, though, as it makes use of function references.

The problem with the ball velocity is that it is not being applied anywhere other than Track.init, which is only called at the start of the app. We don't want to call that again just to set the velocity, so we need a new way to do that. However, there is a potential problem that must be handled first, as it will dictate where and how the velocity must be changed.

You see, we can't just set the velocities when the user changes the value. The user can change that at any time, so when the app applies the new velocity, it could be half way through applying motion to the tracks, so some balls may have their velocity changed during the same frame that others have not. This would make the balls lose synchronicity.

What we have to do is only change the velocity when we know that motion is not being applied. The only place we can do that is in the animation function because that is where motion is applied. I'm going to set that up, but not the rest of it. You can apply the GUI elements and call the function that I will provide. I will just handle applying the velocity to the balls in a safe manner.

I've set that up, and added a test function for it.

You will need to setup the GUI and add a listener to the velocity control that calls the setBallVelocity function, giving it the new velocity to apply. For example:

Code:


setBallVelocity( params.ballVelocity );


.

Things appear to be coming together very nicely Nevyn, and quickly. Using the structure and comments you’ve provided allowed me to add a PI marker to the tracks on my very first try – I think I did it correctly. Likewise for spectrum colored markers, red to blue. I added the ball velocity (0-20) to the datGui; it worked with or without .listen();. Your safe/synchronized velocity change function allows velocity changes while the balls are moving, each and every velocity change is applied equally to each and every ball.

I’ll try adding point lights to the balls next. Yikes, the uncommented __updateVelocityTest function has been on in the background for a while now, the ball velocities are over a thousand, the balls are switching between beginning and end, waiting briefly at each. Of course you’d do a much better job of it, any comment/objection to me trying to add spacebar Pause and right arrow Advance Frame functions? See if I can pause at 10000.  
.

.

Showing that only the geometric track ball’s point light is ‘working’. The ball material is changed to meshStandard for better lighting effects.  

Progress report. Not so much, aside from the extra doses of humility, of the fun variety. At first I went after the Pause button; but after some difficulties, hoping to make some tangible progress, I decided to try the ‘easier’ task of installing pointLights in the balls instead.

In Ball.init. My thinking is, every time ball is initiated, once per track, a pointLight will be included. The result is shown, looking down at a sloped angle, the scene and the piG track ball are in low ambient light, but it’s clear the piG track ball has a pointlight which is illuminating the closest sides of the yellow and magenta balls. If I remove the piG track, then only the straight track ball is emitting light. Either there’s only one pointLight, or only the last pointLight installed appears to be operating correctly.

For the record, I said "I thought I had installed the PI markers correctly". Granted, I’m an over optimistic person. I see by SourceTree’s code change record you had to correct my effort, thanks. I was installing as many PI markers as there are other markers – combined. You’ve done so much, I hope you don’t mind my saying, I like the PI marker color you selected.    
.

Only one light is working because there is only one light!

You've created a global variable that is a light object, and then added it to all balls, but a node can only have one parent, so only the last one works. If a Ball needs a Light, then just create one in the Ball.init method and add it to the object3D node. I would actually create a Ball.headlight property to keep it accessible. We could hook up the GUI to turn those lights on/off.

You were pretty close with the PI marker, just needs to add it outside of the loop. This also allowed me to change the color, which was a bonus.

Creating a pause control should not be that hard. The animation function is already setup for it with this code:

Code:


if( running )
{
  ...
}


You just need to move that running variable into your object for GUI values (along with the ball velocity, etc), alter the reference in the animation function, hook up a DAT control for it, and you are good to go.

.

We have three this.ball.light pointLights.

Update. Accounting for all my doings on a regular basis, whether I make ‘good’ progress or not, definitely improves my understanding of the problem at hand. Your patience is appreciated.

I would actually create a Ball.headlight property to keep it accessible. We could hook up the GUI to turn those lights on/off.

HuAh Nevyn. That turned out to be a good problem. I can claim partial credit, or a start. The Ball constructor now has a new property this.light = new THREE.PointLight();,  

It can be switched to a spotlight instead, assuming I haven’t made any major errors. I followed your ball.velocity GUI solution closely. The ball.light.intensity is now user controlled, where one can change the 3 light intensities to the value selected, zero is currently the far left position on the slide bar.

How the heck do I turn lights on and off? Never did that before. Subtract them from the ball.object3D?

I'm thinking I could try to hooking up the other pointLight parameters like ball.light.distance (the light limit distance) next. I haven't made sense of your Pause button directions yet, but it's got to be easier then installing controls for ball.lights.
.

A Light is just an Object3D, and every Object3D has a visible property, so you can set that to false in order to disable a light. If you have multiple lights that you want to turn on/off together, put them all into a Group and turn that invisible.

.

Showing datGUI progress. The ball.light.visible on off switch looks like it would fit in my house's circuit breaker panel.

Nevyn wrote. every Object3D has a visible property

Airman. Object.visible. Of course, thanks. Come to think of it, I remember you've mentioned visibility in the past. My ears were red for a minute. I don’t recall ever having seen the property used in any threejs examples before, or I didn’t notice. It makes perfect sense now.

A small problem. I replaced the pointLights with spotlights and noticed they rotate with the balls’ z-axis roll. I’d like to solve it so the spotlight can be a proper alternative to the pointLight. I don’t expect any datGUI in your PI = 4 page animation plans and consider the current effort to be mostly for learning purposes.

And another. I expect you will use keyboard controls. You'll notice I’m in the middle of installing a datGUI Pause button. Just the GUI button, not the spacebar yet. It’s acting funny though, the first press just slows the balls’ velocity. The Pause button usually works on the second or third press.

Happy to have problems to work on.
.

.

We have 3 broad beam spotLights.

Quick update. Thank you Sir, I see you broke the ball’s this.object3D into two separate groups, this.alignGroup which moves forward with the ball’s position, and the this.rollGroup contains those ball items that must roll with the ball’s z-axis roll, such as the ball’s surface markers. A pointLight is omni-direcional, it doesn’t matter if it rolls or not. The spotlight operates comfortably in the non-z-axis-rolling alignGoup.

I haven’t worked on the Pause button today, other posts and a review of your latest changes took precedence. I'm surprised I posted this. It is nice to see the app come together in its current form. Forgive me for asking, have you thought of applying lessons learned here to your stacked spin apps?  
.

Actually, Ball is split into 3 groups with this.object3D being the root and moves the position, this.alignGroup rotates about the Y axis and represents the forward direction, and this.rollGroup which applies the rolling effect.

What lessons do you think need to be applied to the spin apps?

.

What lessons do you think need to be applied to the spin apps?

Sorry, my question was sort of casual chit-chat, seeing the project coming to another end. I recognize the PI = 4 app’s current form will allow any number of modifications, hoping you might have and share some insight. I’m currently preoccupied with planetary particles, trying to flip them with charge imbalance.

One modification may be to build a better solar system. The sun at the center provides the gravity and charge repulsion to drive the moving planets. For the record, I reread Miles’ Bode paper yesterday. I admit, I’m not smart enough to understand it on the first half dozen reads unless I devote myself to studying it. The mere fact that the orbits’ and charge emissions of the planets 'stack' is amazing, but I think I understand how.

Modifying the tracks. The emission fields of the sun and planets are modeled with two, north and south overlapping hemispheric toruses. That’s how the planet’s stack, constrained to orbit as close as they can to the sun and the planets at lower orbit, over the sun’s equator, along the v-shaped slot between the +/-30 deg charge repulsion maximums.

Add an assortment of planets with different sizes and velocities and see what happens.

I'll get back to work now.
.

.

Selecting roughly ball width spotLights from above.

I had let a few problems pile up: the intermittent Pause button; not starting the ball lights in the off state; I’d added a second and third update functions that I knew wasn’t efficient; turn the spotLights into headlights; let a space bar press equal Pause.

You swept through and knocked the top items off the list, and then some. The Pause button works – I see my error, thank you; the lights are initialized off – I still need to figure out how you did that. The dat GUI function altered beyond all recognition – so spare and clean. It took some time but I found where the parameters ended up. Nice.

With respect to the spotlights. I needed to add a spotlight helper to see they were pointed “down” in very broad beams covering the whole track. I appreciate each tracks' separate center coordinates. The spotLights are now positioned above the track at (0, 5*radius, 0) and point directly to the balls. I’d like to keep that set of spotLights (default off) and add another set spotLights that are of the forward pointing headLight variety if that’s OK with you.

Nevyn code commented // Creates some functions to add straight sections to shorter tracks so that they all end up the same size.

I must ask. Huh? How long are the straight sections needed in order to make all the tracks the same size? The piG track is the “shortest” with a geometric length of 8.28*radius, the others are 10*radius and in spite the two commented out console.log indicating those values I don't see how you're referring to them. Ok, do you mean the customizable tracks of arbitrary sections that would otherwise end in an assortment of lengths?

I added a Reset button that just calls your reset function. The easiest task yet, thank you very much.

We need a better ball velocity Control for velocities less than 1. Maybe a one's unit and a tens unit.

What did I miss?
.

The values are initialized correctly now because I used the updateValues data directly. Previously, there were values set in the classes as defaults, then there were parameters to the GUI, and then there were the update values that actually get applied. There was a disconnect between the parameters and the update values.

I added that code to make all tracks the same length because I wanted to see that the geometric track was correct.

Code:


   function ensureSameTrackLength()
   {
      var max, d;
      max = 0;
      for( var i=0; i<tracks.length; i++ )
      {
         max = Math.max( tracks[i].getLength(), max );
      }
      ensureTrackLength( max );
   }


Code:


   function ensureTrackLength( length )
   {
      var d;
      for( var i=0; i<tracks.length; i++ )
      {
         d = length - tracks[i].getLength();
         if( d > 0 )
         {
            tracks[i].add( new StraightSection( d ) );
         }
      }
   }


The first part calculates the maximum length of any track. The second part adds straight sections to any track that is not that length. It doesn't need to calculate the difference between geometric and kinematic tracks (it actually does, but in a round-a-bout way). They could be any length and it will still work as intended.

I think the max ball velocity control is just to high. It could be as low as 5. That will make adjustments below 1 a bit easiers.

The real annoying thing is that it rotates the tracks if you use the sliders. I've had that problem before, but I can't remember how to get rid of it.

Fixed that rotation problem. Just needed to create an explicit canvas for the renderer and give the orbit controls a specific element to bind its events to rather than to the document.

I updated the spot lights so that they work like a head light.

.

Using a spotlight from above pointing to the track just in front of the ball makes a wicked looking elliptical end to the illuminated tube section that reminds me of an injection needle, more dangerous than a locomotive cow catcher. Your image showed it from the top just fine, this image shows more of a side view.

Any objection to the additional alternative set of spotLights (default off) pointing downward directly to the balls? Seems like it.

Up till now I’ve been pecking at the approximate slider positon I wanted to adjest it too, or resign myself to turning and recentering the view. What an improvement finally being able to use the slidebar as it was intended.

You’ve been making sufficient changes to declare this project initially done at any moment.

I like the Markers on/off switch. Why would we want to turn them off? Wait, that reminds me.

Requesting a special set of markers on the ‘bottom’ of the track such that the user may view the ball’s rolling contact – or lack thereof, to their complete satisfaction. I expect people will gain a better appreciation of the cycloid roll because of it.
.

I've changed the code to support using either a head-light or a top-down-light. You can't change it during execution. It is set by the developer and that's it.

Personally, I prefer the head-light. I thought maybe using the 2 together might be ok. Reduce the distance for the top-down-light so that it is about 2-3 radii above and you just get a little bit of light before and after the ball. Then the head-light can stretch out in front. Might work okay.

I thought being able to enable/disable the markers seemed like a good thing to do. Sometimes you just want to get rid of everything and just look at the motion.

Rolling markers? Do you want them to be added as the ball rolls along, as if the ball was marking the track every complete rotation? Is it a line representing points along the track that a point on the ball's surface reaches? That would show the wave motion of such a point. Not sure if that is desired, but I'm just throwing out ideas.

.

Rolling Markers. Here’s the bottom of the track side of the straight ball’s red marker at the 4*radius green track marker. The red ball marker has a slightly larger radius than the track marker so it penetrates the track marker making it easily visible and almost stationary, or rather, not moving forward. Since the ball markers are slightly larger than the ball they may appear to moon-walk slightly forward or back Catching this particular image at the top of the ball is more difficult as the ball’s marker would be moving at twice the ball’s forward velocity.

As a wheel or ball rolls along, the very bottom of the rolling object is in contact with the track’s surface, momentarily at zero forward velocity. Meanwhile, the tangent point at the very top of the rolling object moves forward at twice the object’s forward velocity. New track rolling markers would allow someone to see whether the ‘bottom’ contact point of the ball's contact point is in fact stationary with respect to the track markers or whether the ball glides forward or backward at all over the track rolling markers.

Currently, the ball in our PI = 4 app is sized such that the straight track and kinematic curved track balls rolls about the z axis once for every 2*radius length. Five full 360 degree z rolls for the straight and piK tracks. There are four ball surface marks for every rotation. Replace the existing markers with new rolling markers at zero, and every 0.5*radius for a total of 21 rolling markers. Or provide a more accurate 42 markers, just slightly fore and aft of the anticipated stationary ball marker locations. We might further double the number of roll markers by doubling the number of ball markers.  

I hope I haven't confused you. I believe this should make it easy to see whether the balls have proper rolls or not.

We'll probably need those PI switches for the geometric track again.
.

.

Here's a side view. I tried tracing the motion of one red/green ball marker as it rolls along forming a cycloid shape between the straight tracks 4*radius and 6*radius green track markers. The other three ball markers describe their own cycloids offset every 0.5*radius length along the straight and piK curved tracks. The roll markers would be placed at the bottom of the track at each cycloid end, (or bracketing the ball marker - slightly fore and aft) where the ball markers make 'contact' with the bottom of the track.
.