Animate the PI = 4 experiment

.

Both spheres traveling along their tracks in a downward direction have just past their initial sections and red starting lines. The track angle rotation of the curved track sphere is already apparent. Oh, and buttons. And off of daylight savings.

Using a check-box to control pausing is bad

Like teats on a boar bad? The new Pause and Next Frame buttons work slightly better than they did as check boxes. If in haste, one presses Next Frame instead of Pause, the screen will still pause. Here’re the two new items on the end of the parameters list.

Code:


 parameters =
 {
 timeInSecs: 40,
 CycloidRoll: true,
 twopivt: false,
 twopir: true,
 color: "#FFFF00",
 StepAhead: false,
 pauseButton: function(){ pauseButtonPressed() },  
 nFrameButton: function(){ nextFramePressed() }  
 };


The gui additions.

Code:


      gui.add( parameters, 'pauseButton' ).name("Pause");
      gui.add( parameters, 'nFrameButton' ).name("Next Frame");


The two event functions.

Code:


 function pauseButtonPressed()
 {
 // toggle the current state
 paused = !paused;
 };
 
 function nextFramePressed()
 {
 if ( paused ) {
 stepA = true;
 }
 else if ( !paused ) {
 paused = true;
 stepA = false;
 }
 };


I haven’t begun thinking/worrying about using the spacebar.

The PI switch is working. Here’s the current animate function’s circular track section code again, with two new if/else statements.

Code:


 else if (( distNextC >= cTracSectK ) && ( distNextC < cTrackLengthK )) {
 // Curve motion. distance traveled/CTrack circumference.
 // 2PI*v*t/2*PI*r = PI*v*t/PI*r).  
 if ( piTopKOrNot ) {  
 numerator = piK * (distNextC - cTracSectK);
 }
 else {
 numerator = piG * (distNextC - cTracSectK);
 };
 if ( piBottomKOrNot ) {
 denominator = piK * r;
 }
 else {
 denominator = piG * r;
 };
 var trackAngle = numerator/denominator;
 sphereC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
 sphereC.rotation.y = trackAngle;
 distTraveledC = distNextC;
 curSectionC = nexSectionC;
 }


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

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.

Airman. A is the angle traveled by the object in circular motion. You said that if the pi’s used in the numerator and the denominator were the same, the angle traveled would reduce to, A = vt/r.

As you guessed on 10 October, and as I had previously coded correctly through trial and error - but which can now be verified true, motion around the circular track operates correctly only when the distance traveled is based on geometric pi, while the circumference must be calculated using kinematic pi. The simplification A = vt/r is not valid.

Would you care to elaborate on why this is a good confirmation of Miles angular velocity equation? I understand that curved motion is, in fact, a function of the radius of motion. How does that affect ( effect/affect I don't know how this word works either) the PI equal Four application?

P.S. remembered to add the gui additions.
.

It currently is not confirmation of Miles' angular velocity equation, because it is not being used. You need to replace the v variable in my equation you posted above with the angular velocity equation. My guess is that it won't make much difference, if any. At the sizes we are working at here, the curvature of that equation is so close to straight that the differences will be small. However, the smaller you make this track, the more it will become important and needed.

It would probably be more correct to add it in rather than leave it out, but it isn't that important for this problem and what you are trying to show. I guess I would be interested to see it applied, and maybe run 2 tracks next to each other: one with and one without that equation. Your code is not setup for that, though, and it would take some thought to make it so. Actually, as I think about it, it wouldn't be that hard, but probably not worth the effort regardless.

I knew that A=vt/r was not right. It doesn't even look right. I was also pretty sure that the top half of the equation I was building would use 3.14, and the bottom half would use 4, once I realised that I had re-derived the same equation that I did in my Spin Velocity paper. It is always good to have confirmation, though.

I noticed you expanded this function out a bit:

Code:


 function nextFramePressed()
 {
   if ( paused ) {
     stepA = true;
   }
   else if ( !paused ) {
     paused = true;
     stepA = false;
   }


But you didn't need to. They are actually equivalent, but yours uses more effort to perform the same work. Firstly, you don't need that if( !paused ) of the else statement, because if the first condition fails (if( paused )) then you know that paused is equal to false, so you don't need to test it again. Secondly, you don't need the if statements at all, because we don't care about the current state of anything. We just want to set paused to false, so that the next frame is executed, and stepA to true, so that it will pause after it executes it. This way, the next frame button works in all situations. Even if the system is not currently paused, it will pause it after executing the next frame.

I think I see a slight misunderstanding of how boolean logic works. When a boolean expression is being evaluated, not all of that expression may actually be evaluated. Let's look at some examples to see how this operates.

AND

In an AND expression, generally denoted by && in the languages we have been dealing with, you have at least 2 terms in the expres​sion(we will keep it simple and only have 2). The AND operator requires that both sides evaluate to true, or the whole expression fails. Therefore, since we need both to succeed for the whole expression to succeed, if the first part fails, then we don't need to execute the second part. We already know that the whole expression is going to fail, so why waste the time evaluating the second expression?

OR

In an OR expression, generally denoted by ||, we find the opposite of an AND expression. In this case, either expression can make the whole expression succeed. So if the first part evaluates to true, then there is no need to evaluate the second part. Only if the first part fails will the second part be evaluated. So if the second part is evaluated, we know that the first one failed. There is no need to check it again.

The same things apply to if and else statements. If an else expression is being evaluated, then we know that the preceding ifs and else's have already failed. There is no need to check them again.

For these reasons, you must never rely on the execution of code in a boolean expression. That is, you should not call some function that performs something that you need done, because you don't know if it will get executed. That sort of code belongs inside of the if or other control structure, never in the boolean expression. Note that you have not done this, I am just pointing it out.

.

The latest includes html information: Miles Mathis’ Physics page link, Title, list of controls and minimum Spacebar directions.

Here’s the extended Spacebar directions; holding the spacebar down allows action to continue; releasing the Spacebar pauses motion. Briefly pressing or tapping the spacebar advances the scene by frames. Perfect, although a Spacebar escape might be nice.

Sir, I tried following your directions as carefully as I could, thank you very much. I deleted the else condition but I couldn’t make the Next Frame button work without the if statement. As it turns out, the Next Frame button is also working perfectly. Using Next Frame will create a Pause, and each next Frame button click advances the scene a frame forward. Here's the current next step event handler.

In trying to post this message I see you are getting more into the logic. Good.

Code:


 function nextFramePressed()
 {
 if ( paused ) {
 stepA = true;
 }
 else {
 paused = true;
 stepA = false;
 }
 };


I found a threejs example that contains html info and uses the keyboard, “three.js - platformer demo”, and wittled the nine keys and two functions down to one. The same Next Frame logic now appears in the new keyboardControl function.

Code:


 var keyboardControls = (function() {
 var keys = { SP : 32 };  
 var keysPressed = {};
 (function( watchedKeyCodes ) {
 var handler = function( down ) {
 return function( e ) {
 var index = watchedKeyCodes.indexOf( e.keyCode );
 if( index >= 0 ) {
 keysPressed[watchedKeyCodes[index]] = down; e.preventDefault();
 if ( paused ) {
 stepA = true;
 }
 else {
 paused = true;
 stepA = false;
 }
 }
 };
 };
 window.addEventListener( "keydown", handler( true ), false );
 window.addEventListener( "keyup", handler( false ), false );
 })([
 keys.SP   ]);
 })();


This PI Equal Four application runs horribly slow on my internet Explorer. I saw a tutorial and read somewhere that requestAnimationFrame functions varied across different browsers. They recommended adding the following code at the top of the script. I did and saw no change, does it have any value or should I get rid of it?

Code:


 window.requestAnimationFrame =
 window.requestAnimationFrame ||
 window.webkitReqeustAnimationFrame ||
 window.mozReqeustAnimationFrame ||
 window.oReqeustAnimationFrame ||
 window.msReqeustAnimationFrame ||
 function(callback) {
 window.setTimeout(callback,1e3/60);
 };


Seems like I’ve been making lots of changes lately, I haven’t included the CSS style or div info code changes, I’ll wait a bit.

However, the smaller you make this track, the more it will become important and needed.

The tracks don’t need to change size, they are a maximum distance reference limit, 10*r, with r being a millimeter or a light year. Allowing spheres to be much smaller than the tube – in radius, as small as we like, they will travel along the tube centerlines. It would then be possible for this app to show Miles’ or your full angular formula.
.

.

Nevyn wrote. I think I see a slight misunderstanding of how boolean logic works. When a boolean expression is being evaluated, not all of that expression may actually be evaluated.

You’re right, using the if statement I assumed I needed to cover all cases. Saving energy at if statements and explaining why makes for very interesting lessons. You demonstrate a fine ability at logic, you explaining why I do something wrong is scary, and greatly increases your credibility. I've missed some of what you've said, overall you've certainly taught me a lot, and forced me to learn it too by golly.

Airman said. They will travel along the tube centerlines.

Ok, that’s not correct. The PI=4 Experiment application shows a circular tube track at a fixed radius of curvature, regardless of the sphere size. The tubular tracks mimic StevenO’s PI=4 Experiment. You required it and I must admit I very much like the app’s tubes. Let the animated experiment tracks represent some maximum size, what good is it if we allow smaller spheres without greater curvatures of motion? One may vary timing slightly to accommodate the full formula but then nothing is being compared.


Seven parallel/concentric sets of PI=4 tracks.

How might we simulate the full circular motion formula? I submit the above diagram as one possibility.

Seven green parallel straight tracks each 10*r long, each tangent to a different concentric blue circle at varying radius of r. Seven initial overlapped 2*r straight sections. The two tracks would be separated according to the spheres’ diameter. The red lines are the 2*r distance markers.

At which point I think, why include straight tracks? We know pi=4. We might want to compare the circular motions of any two different radial tracks. One thought led to another and soon I was looking down at the solar system.

I’m back. I think the existing app’s initial setup might be tweeked or not. I’m happy with it, and feeling pangs of post partum blues. I’m glad you agreed to this project. I’ve learned a lot – concentrating on circular motion. Glad you required the tubes. You never indicated your aproval of the hoops. Come to think of it, I suppose I should try and see whether wireframe tube material is an alternative to the parallel hoops.

Looking slightly ahead, how does this process end? Do I simply post the existing code? Can a standalone app be compiled – able to run without the complete .js sources such that anyone might be able to see it? Did you have any interest in making a running copy available at the Lab?
.

.

That last set of seven parallel/concentric track distances was a bit off.

The distances in this diagram have been corrected in order to allow a closeup.  
.

You've lost me with these latest multi-track images. I don't see what they offer or what they are trying to achieve. I think you may have misunderstood what I meant by the track being smaller and requiring Miles' angular velocity equation. I meant a complete scale down to the photon level. This would not change the track dimensions in a relative manner, but would just change the absolute distances to be around 10^-24m.

Where does this process end? With something that is publishable, if that is what you want to achieve, or it stops whenever you want, if you just wanted to learn about circular motion and/or programming techniques. I wanted you to take more control of the application and development process, and you have done that. I wanted you to own it. I wanted you to see that you can tackle an idea and progress through it using 3D models to help you see it a bit deeper than just thought alone might have done. I wanted to rip away the training wheels so that you might gain the confidence to approach these sorts of things on your own. I am still here for help and guidance, but you can do things on your own, too.

So, I see this going in one of two ways: you develop a web page that both contains this animation, and a description of what it is showing; or you look through Miles' PI=4 papers and find somewhere that this animation will fit into it so that it can be added to my Interactive Papers section. The latter might be easier, and you may find multiple spots for it, so don't limit yourself to just one. If you want to go that way, then we will need to go through how I put those pages together, but it isn't much different to what you are doing already, so don't be worried about that.

.
Those latest two multi-track images were just concept ideas. Having given it a fair amount of thought I believe concentric orbitals can provide a good way to demonstrate the full circular motion formula. I’ll be happy to work the idea up formally in due course. In no way do I wish to alter the current app as indicated by those two diagrams.

Ripping off my training wheels indeed! I thought it was a race against time to produce a semi-complete package before it was too late. The thought of carrying-on is a great relief. Glad to be at your disposal. Adding to your interactive papers would be wonderful.


In this image, the 122 hoops (alas, no flames yet) – 61 per track, have been replaced by two cylinders and a torus.

Cylinders and Torus. Rather than some transparent solid, I went with wireframe material. The code is far more efficient, saving 73 code lines, (down from 526 to 453), including 122 distance hoops built into the geometries. The downside is – the spheres are much less visible. The cross sections of the tubes or torus should appear round; four sides is an unacceptable diamond square that draws way too much attention to itself. Eight sides is round enough, and is shown in the image above, but with 8 long 10*r lines come two new alternate spin sets of 8 long spiral lines; 24 grey lines compared to the previous four long green lines. The spheres are much less visible. The only other problem is the “Cannot use import statement outside a module” errors when accessing both new threejs geometry sources.

Tossing out the cylinders and torus and their sources, and sticking with the previous grey circles and long green lines, I nonetheless corrected a gross inefficiency I knew I would eventually get around to. Circles were being re-created 3 times in both the straight sections and curved. Now, yZPCircle is created once. Saving appox 21 code lines, ending at 505. I think I’ll do the same with the 11 track markers. Good to know I’m finally saving energy.
.

Can you use a transparent tube and show some screenshots? Wireframe can be useful, but rarely what you want in a final product.

Don't be afraid to use a heavy transparency. Maybe 0.2 for the opacity. You might have to play with the color so that the tube is still visible. Tube transparency could also be added as a menu control, if you want. However, if used for an interactive paper, the menu will be unavailable, so don't get too attached to it.

The markers should be more visible than the rest of the tube, too. They could use some labels for the main ones we care about, showing how they match on both tracks.

What I would really like is for the current section of tube that the balls are in to light up somehow. Maybe they become a different color, a bit brighter than normal, or even a completely different color, whatever works well. The labels could also light up, even if the tubes don't.

.

Can you use a transparent tube and show some screenshots? Wireframe can be useful, but rarely what you want in a final product.

Amn. Of course; here are two sets - white and blue clear materials for comparison.

Yes I was skeptical, it’s easy to see the mostly transparent, aerogel-like material making up the cylinders and torus do make the tracks appear more unified or defined; the lines aren’t just hanging in empty space. Even though your suggested opacity level looked best there’s no way around the fact objects inside the tube are dimmer. All the lines and hoops were inside the tubes, note the two-toned blue sphere at the right, so I expanded the hoops and marker lines outward.


There’s one exceptional odd area, the section of torus that intersects with the initial straight section leading to the starting/finishing lines.

The markers should be more visible than the rest of the tube, too. They could use some labels for the main ones we care about, showing how they match on both tracks.

Amn. I eliminated grey hoops that were drawn at the same locations as the red markers and so now the markers are more distinct, let me know if you’d like to make them moreso. Points if you notice the marker horizontal arms are still a bit short.

What I would really like is for the current section of tube that the balls are in to light up somehow.

Amn. Two possibilities come to my over-optimistic, in-experienced mind. 1) install point lights inside each sphere, The tubes, made out of meshBasicMaterial ‘don’t react to light’. They may need to be upgraded to Lambert in order to make the track light up where the sphere is. Or 2) use shader material. That sounds sexier but probably way more complicated.    
.

You definitely don't want to use lights, nor shaders either. All you need is to create individual track segments with their own Material object (not shared) and update the color property of the Material depending on whether the ball is in that segment or not.

I don't think the grey markers are needed. They just clutter up the track. The red ones are fine. Maybe make the PI marker a different color to differentiate it.

That small section is caused by the additive blending on two transparent things that are inline with respect to the camera. You can change the blending method, but I don't know what is available and whether it will fix it as you want it to. Worth a go, though.

While transparent tubes will lower the intensity of the ball color, only you really know that. The general user will just see it in that subdued way. It is easy to get used to vibrant colors, but that doesn't mean they are better. I get hooked on vibrancy quite often, and have to convince myself away from it.

.

Thanks for calling me off the lights, I had gotten two stuck in the tube openings.

Just when the hoops and markers were cooperating – the hoops are gone. I take it you want me to drop the four long green lines as well? Done. The red horizontal and vertical lines too?

I'll change the pi marker next. Do you still want labels? Lighting sections of the tubes eh, interesting. I must contemplate that.

Noticed today that there’s no DAT gui when I run this thing in fireFox. No problem, I'll continue using chrome.
.

Looking better already!

The red markers could be replaced by something a bit more 3D. They can go outside of the tube, and they can be wider than a line. They also don't need to be transparent, if that works. Think of some sort of join across 2 separate tubes that rises above the tube, with beveled edges that connect to the tubes. That would be 3 pieces: 2 beveled edges and a center piece. The center piece could be what highlights as the ball passes that marker. That's just one idea that could work.

Some textures would probably be useful, too. At least for the balls, but even the tubes, maybe. That does get complicated but you can use the textures from my site to avoid cross origin problems.

What are those red and green thingy's on the bottom right? Failed spheres?

I'm kinda liking the idea of a light being inside the ball. But it would not roll with the ball, but must curve around the circle. Could be tricky, but could look good too.

.

The two images are intended to convey the resulting ‘dramatic’ light and shodows cast, especially on the curved track.

It wasn’t too difficult to install a point light in each sphere and advance them along with the spheres. They don’t need to rotate. The red line markers are currently transparent rubber grommets that don’t always light up.

The red and green thingy's were point light helpers. Now the helpers are much smaller blue spheres and white octagons identifying the point light source.

I have no problem with the torus/initial straight section overlap.

Now that the grey lines are gone, I turned them into 50 or 60 tube sections. The result, all the internal walls, worked just as well as the grommets and were just as distracting as the grey lines. Now I’m happy without them. Keep it pure and simple, there’s plenty involved in getting the lighting right. That is, of course, if you agree.


Here, the section markers are two concentric circles.

How do I ensure that all surfaces - front, back, and inside of the grommets and tubes are reflecting light?
.

Airman wrote:How do I ensure that all surfaces - front, back, and inside of the grommets and tubes are reflecting light?

Every Material object has a side property which can be THREE.FrontSide, THREE.BackSide, or THREE.DoubleSide. This determines which side will be rendered. If the camera is facing the back side, but only the front should be rendered, then it won't render. Set the grommets (and probably the tubes) to DoubleSide and it should work as you want it to.

Try using a SpotLight. This has a position and a direction, which should point along the velocity vector for the ball. This may require some special handling for the curved section (which I was referring to in the last post). You may be able to just set the lights direction to the velocity and everything will work out. Just have a play with it and see what you can do.

.
Thanks, DoubleSide makes both the cylinders and torus look better.


A spot light from above.

Nevyn wrote.  Try using a SpotLight.

Copy that. My first effort at including a spot light is included. You can’t tell from this image, the spotLight helper shows the light is directed at the center of the circular track. This first ‘opportunity’ for learning lights has been more fun than I’d expected.

With respect to the spot light, it's a bit slow at present. The: position, intensity, angle, no problem. I haven’t pointed it reliably yet, let alone at a moving target. The world and the group coordinates are off a little, allowing coordinate simplicity and orbital camera ease.  

I’ll keep at it.
.

I was thinking that the spot light would be inside the ball. Like head-lights on your car.

.

The track's top and bottom views.

Understood. Spotlights inside the spheres, acting like car headlights. I usually post regularly, wherever I am. Yesterday, I could only manage pointing a stationary spotlight at (0,0,0).

After that post and a few more hours frustration I found the answer to my question.
spotlight-cant-set-target-correctly
https://discourse.threejs.org/t/spotlight-cant-set-target-correctly/3674
That reference includes an interesting horizontal spotlight that might make a good spinning emergency vehicle light - or a rolling particle (?).

Apparently the spotlight, spotlight.position and spotlight.target all must be global variables which are added to the scene and updated in the animation loop.

I installed the spot light in the sphere on the straight track. The sphere in the curved track still has the internal point light. There’s also an ambient light, and a point light also in the straight track sphere.

Why does the bottom of the track look so much nicer than the top?
.

You don't want to use the target property. That is used to make the light point at that target, but you don't have a target to follow.

You should be able to put the light into a Group that contains the ball, but is higher than where the rolling rotation is being applied. If you don't have one, create one. That is, the Group is used to move the ball along the track, while a lower Group (or maybe even the sphere itself) is rotated based on the rolling action. This allows the light to move along with the ball, but is not rotated with it. However, you do need the rotation from the curved track to be applied to that higher level Group, so that the light always points along the track (i.e. forward). You may need to separate out some objects to accomplish this.

The bottom of the track may look nicer because of the way the light is pointing. It may not be symmetrical along the track axis.

.

You don't want to use the target property. That is used to make the light point at that target, but you don't have a target to follow.

Woe’s me to disagree, so I led with the image above. spotlight.target works fine. spotLight.position and spotLight.target are both advanced by using sphereC’s trackAngle position. Here’s most of the curved loop portion of the animate function (excluding the pi switch lines).  

Code:


     else if (( distNextC >= cTracSectK ) && ( distNextC < cTrackLengthK )) {
          // pi switch stuff omited
          var trackAngle = numerator/denominator;
          sphereC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
          pointLightC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
          spotLightC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
          spotLightC.target.position.x = r*Math.sin( trackAngle + Math.PI/3 );
          spotLightC.target.position.z = r*Math.cos( trackAngle + Math.PI/3 );
          sphereC.rotation.y = trackAngle;
          distTraveledC = distNextC;
          curSectionC = nexSectionC;
     };


ballOne (or ballTwo) is a 3D object. sphereC is a mesh that is added to ballOne. ballOne (or.  ballTwo) is added to the group, grp. grp is added to the scene. Have I screwed up wrong or right? Can we add point lights at the sphere’s north and south poles?


PI = 4 Experiment. Lights. At present, each sphere moves along with: 1) a point light – a tiny sphere at the center of the yellow spheres; 2) a point light helper - tight wireframe octahedron; 3) a spot light and 4) a spot light helper - the wireframe ‘headlight’ which indicates the extent and direction of the spot light beams. Along the curve, the beam is directed at a constant angle trackAngle + Math.PI/3. In the main image, the tracks are lit up by an ambient white light at the default intensity of 1. The ambient light for the two inset loops is 2.5.

After some effort at playing with the spotLight I found it made small difference through the curve. The pointLight is much more effective. The opposite is true along the straightaway, where compared to the pointLight, the headlight is more effective at illuminating the walls along the straight tracks.
 
Notice the 'bottom' of the torus's most distant side in the image at the top. I flipped the track torus and cylinders - top and bottom – and found I was able to reverse the colors from the image I posted last time. Akin to application of a reflective or on half of the inside walls, top or bottom. Seems like a property but i haven't looked.
.

.

Of course I had to try adding north and south pole point lights. The image shows the results. The red and blue pole pointLights remain at the poles for sphereS in the straight track at the top. Not so for the pole lights for the curved track sphere sphereC, the roll matches that of sphereS.

The pole lights for the curved path sphereC continue spinning with the initial z axis roll. The center of sphereC moves around the curved track as per the trackAngle. sphereC’s pole lights need one more rotation – the rotation of the spheres about its y axis, equal to the track angle.

Nevyn, I hope I haven't offended you. I earnestly wish to learn how to do these things more efficiently. As a rule, I do not ignore your directions, if anything, I’m routinely guilty of plain old misunderstanding.  
.

.

Attempting to replace the wireframe spheres with a new sphere material.

Both sphere’s pole point lights are now rolling correctly. I used an axis angle operation. Here’s the changes to the same animate frunction loop section I posted last Thursday.

Code:


      // pi switch stuff omited
 var trackAngle = numerator/denominator;
 var sphereCenterPoint = new THREE.Vector3( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ) );
 sphereC.position.set( sphereCenterPoint.x, sphereCenterPoint.y, sphereCenterPoint.z );
 pointLightC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
 var sphereAxis = new THREE.Vector3( 0, 1, 0 );
 var northRoll = new THREE.Vector3( ptLtPos*Math.sin( sRotation ), ptLtPos*Math.cos( sRotation ), 0 );
 northRoll.applyAxisAngle( sphereAxis, trackAngle );
 var southRoll = new THREE.Vector3( ptLtPos*Math.sin( sRotation + Math.PI ), ptLtPos*Math.cos( sRotation + Math.PI ), 0 );
 southRoll.applyAxisAngle( sphereAxis, trackAngle );
 var northVector = new THREE.Vector3( sphereC.position.x + northRoll.x, sphereC.position.y + northRoll.y, sphereC.position.z + northRoll.z );
 var southVector = new THREE.Vector3( sphereC.position.x + southRoll.x, sphereC.position.y + southRoll.y , sphereC.position.z + southRoll.z );
 pointLightCN.position.set( northVector.x, northVector.y, northVector.z );
 pointLightCS.position.set( southVector.x, southVector.y, southVector.z );
 spotLightC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
 spotLightC.target.position.x = r*Math.sin( trackAngle + Math.PI/3 );
 spotLightC.target.position.z = r*Math.cos( trackAngle + Math.PI/3 );
 sphereC.rotation.y = trackAngle;
 distTraveledC = distNextC;
 curSectionC = nexSectionC;


You indicated there usually isn’t a good reason for a final wireframe object. Now seemed like a good time to try a transparent sphere; like I did with boids. I tried transparent Lambert and Phong spheres so as to be able to enjoy the rolling motion. Unfortunately, the spheres blink in and out of view – depending on the angle of view. When out, the center and two pole point lights are perfectly visible rolling along. Oh well, I certainly enjoyed the excersize in including them, I won’t feel obliged to keep them there. But I do want anyone to be able to get a good view of the rolling action and that requires more that a featureless surface.
.

.

As shown, the straightaway particle rolls only about it z-axis. In addition to the z-roll, the curved path particle must also rotate about its y axis.

You indicated I should change my object structure, I believe I’ve made progress. Here’s the latest changes to the section I posted last time.

Code:


// pi switch stuff omited
var trackAngle = numerator/denominator;
var sphereCenterPoint = new THREE.Vector3( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ) );
ballOne.position.set( sphereCenterPoint.x, sphereCenterPoint.y, sphereCenterPoint.z );
ballOne.rotation.y = trackAngle;
spotLightC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));
spotLightC.target.position.x = r*Math.sin( trackAngle + Math.PI/3 );
spotLightC.target.position.z = r*Math.cos( trackAngle + Math.PI/3 );
distTraveledC = distNextC;
curSectionC = nexSectionC;


The animate function now advances ballOne instead of sphereC. sphereC is still added to ballOne, the point lights and new set of three grommets are now also added to ballOne in the init function.

I haven’t attempted to move the spotlights yet. I also want to install rear direction spot lights and four more point lights. I suppose I can add a larger transparent sphere to remove any possible bumps and improve the final product’s visual appeal through some phong adjustment.
 
Hard to tell with just a single view, but I think the spheres look good and they show rotations well. Having no desire for some sphereical texture like a favorite celestial body or an eyeball, would I need to create a local server in order to do so? I would rather come up with geometric features. At first I tried making hemispheres and the like from spherical buffer geometry without any success whatsoever, and no idea why - save for the Muses. All the better to find a ‘grommet’ solution that looks quite distinctive and goes well with the curved track’s quartertrack markers – see what I mean?
.

I feel like using the target property for the light is wrong. Yes, it works, but that doesn't mean it is the right way to get it to work. However, the alternative is complicated because it requires setting up the scene graph in the right way and then requires the rolling motion to be handled in a special way. Using the target property as you are does not really produce the strictly correct angling. The light is pointing towards the inside of the circle, like a car that is drifting instead of driving around the curve. However, that isn't a big issue.

The balls should not be transparent. Only the tubes because we need to see through them to see the balls.

In order to use textures, yes, you need to run it in a server with special permissions (which require some advanced web server administration), although if it is being served from the same place as the app, then those permissions are not needed. However, you can refer to the textures on my site because I have setup those permissions. It is fine if you don't want to use them, but they do make a really nice touch.

I am a bit concerned about statements like this:

Code:


spotLightC.position.set( r*Math.sin( trackAngle ), 0, r*Math.cos( trackAngle ));


Not because it is wrong, exactly, but it looks wrong. If I found this app, and looked over the code to see if it is valid, and found that statement, then I would assume the whole premise is wrong and PI does not equal 4. Why? Because that statement uses PI=3.14. Any time you are using trig functions, you are using 3.14.

Now, it isn't wrong, because it is the calculation of trackAngle that uses PI=4, and that value is setting the distance around the circle, but most people won't see that distinction. You would have to make that argument, assuming that you were even given the opportunity to argue it. Most would not give you that opportunity because they want this to be wrong. We are on the back foot on this one and don't need to be giving ammunition to the other side.

The main reason I don't like it, though, is because it is not based on motion. It is based on trigonometry. It might give you the right answer, but it doesn't do it in the right way. Remember every time your math teachers told you it isn't about getting the right answer, it is about how you got it? This is what they meant.

The math you are using is based on a circle. The ball moving around the track is not based on a circle. Effectively, what that math is doing is equivalent to the ball reaching the curve, shooting a tether to the center of the circle, and letting that tether pull it around the curve. The real ball, however, is pushed around the curve because it meets resistance to its intended path. One is from the inside and one is from the outside. They both achieve the same motion, but one represents reality while the other does not.

I can't figure out if this matters enough to worry about. I would do it based on motion because that represents the problem. That creates an app that is harder to refute because it operates in a more direct manner. However, visually, they create the same animation. I'm not even sure that the math would end up that different anyway. The same position needs to be calculated, the circle still needs to be taken into account, so they might end up very close anyway. I am more inclined to worry about getting it looking good and fit into a page for publishing.

.

Today’s images include low ambient and downward directional lighting, showing how nine separate lights within each sphere illuminates more than a 2*r portion of track (the circular track’s centerline diameter).

The spheres are traveling through ‘transparent tubes’ and so they are never observed ‘directly’. I suppose that might make a specific visual product more or less difficult to achieve. I just started learning the subject. Do you have any comments, suggestions or recommendations you require or would like to see? Please pardon my earlier texture comment, of course if you directed me to use textures I would gladly comply. Shaders might be an option, any thought about that?

I feel like using the target property for the light is wrong

I made a change which may correct that a bit; the code line you quoted is gone. I created a new variable – ballMesh*. All the individual objects making up each sphere is first added to ballMesh. ballMesh is then added to the 3D objects ballOne and ballTwo. Eliminating those two spotlight positions in that animate loop section. That still leaves the spotlight targeting alongside advancing ballOne and ballTwo.

I should mention, about the spacebar option, holding down to advance the motion, releasing to stop motion. I noticed that a single press and release of the spacebar counts as two frame advances. Works fine if you’re aware of it, till you need finer control such as changing the rolling increments on the control panel. I would expect we need some controls. You know the constraints and the big picture.

I’m running out of ideas and tasks, what’s next? Do you have site requirements?

Reading your most recent post - the app may look and work correctly; its objectionable because of its use of geometric pi? True, the application is simple, I though it was based on rate*tine=distance, it certainly isn't based on force equations. Geometric pi is a tool. We recognize the limits of the tool, not just reject the tool for subjective reasons. I'll try to understand your comment better.

*ballMesh contains: 2 concentric spheres (solid yellow and slightly larger transparent); three mutually orthogonal rings; and nine different colored lights. Six point lights at the ring intersections, and another point light and two spotlights (forward and backward directed) at the center.


Close to the 8*r marker, both particles are almost back in y-synch.
.

Are you sure that all of those lights are actually being used? ThreeJS has a limit on the total number of lights that can be used, and I think the default is 6. That is because lights are very expensive to handle. There is so much code used to handle them (which is in the shaders, so you don't see it) and a lot of things need to be calculated for every object that can use them (the lambert and phong matrials). You can change the light limit, but the real problem is performance. I don't think using 9 lights is an effective use of them. You shouldn't need that many. Think about using an AmbientLight, or maybe a DirectionalLight, for the overall lighting. These mimic a light source like the sun. Then add smaller lights for specific things. You should only need 1 SpotLight or PointLight per ball, ending up with only 3 lights.

Ignore textures for the balls for the moment. Try using a more advanced material such as lambert or phong and see how that works with the lighting. You should see some specular highlights on the balls, especially if you use a DirectionalLight or HemisphereLight as the main source. Those lights allow you to set the direction that the light is coming from, so you can play with that and see how it effects the balls.

I don't like the way the user has to press the space bar to make the animation work. Ideally, there would be buttons to Play, Pause, and Step. However, given the context we are planning to use this app in, you won't even have that. I could get something working to handle it, but the interactive papers are meant to be just simple animations that loop. There should be minimal user interaction apart from camera movement and the like. Stepping seemed like a good idea at the time, but probably isn't needed on this one now.

I like the markers. Simple but effective.

.

Yesterday’s code - festive eh? The outer spheres have been omitted to expose the light filled innards. Each sphere contained seven pointlights and two spotlights, their helpers and optional pointlight representations – tiny solid colored spheres.
 
A quick search - threejs+maximum+number+of+lights - and brief review of several discussions later I understand the general limitation. As you indicated, shaders create light in the scene –  I thought shaders was a whole other lighting option. It takes lots of registers to handle light creation/parameter requirements. The main limit is the webGL pipeline or graphics card used. If the system is overloaded by too many lights, the lights are the first to degrade/fail.

There didn’t seem to be any fixed numbers. There are different numbers for the different types of lights. With plenty of exceptions and alternatives I couldn’t follow. For example, if more lights are needed there’s something called deferred rendering; but that would require its own source code, not likely anything like you use at the Lab. Someone else mentioned the maximum number of pointlights was 6, another person said 10 or 12. No way around it.

The image below shows each ballMesh now contains three pointlights and two spotlights. I think I’ll place tiny yellow sphere buffer geometry spheres at each of the ring intersections. I cut as much as I could for the moment, you said you wanted the spheres to illuminate a portion of the track, I tried one pointlight and two spotlights and didn't like the results. These two particles are the central objects of this app, are you certain you can't spare it three pointlights. In my defense, I'm sure you realize I am a very visually oriented person.


Today’s code. The scene has 1 ambient and 1 directional light (not counting spotlights). The helpers will be removed. You said one spotlight and one pointlight per ball plus a sun. Yikes, I couldn't do that much cutting all at once. In the image four of the seven pointlights have been removed and the rest are distributed equally around the sphere’s rolling contact great circle. Are you sure we need more cutting?

I’ve been considering your geometric pi comments, how do we not to use it? Miles said we are free to measure lengths with geometric pi, but then length doesn’t equal distance traveled along a circular path. In order to determine the true distance we must multiply the geometric length by 4/pi. The actual distance traveled depends on the objects radius of curvature. The practical matter is, as you said, finding positions on the circle, in order to do that we need geometric pi.

P.S. Added "of curvature" after radius two sentences above.
.

You don't want an ambient light and a directional light. They both do the same job, but in different ways. An ambient light is homogeneous. It has no direction and basically represents all directions. A directional light has a direction that it is coming from. If the ground is represented by the XZ plane, and you placed a directional light coming from 0,1,0, then it would represent midday. Usually some other angle works much better. The hemisphere light is like an ambient light but it fades from one color, representing the sky, to another color, representing the ground. Probably not what you want here.

If you find that the ambient or directional light is not enough, then play with its settings, don't add more lights. It can be helpful to connect the light properties up to DATGUI controls to get a feel for how they change the scene as you change the settings. Find what works and then set them as the default values. Then remove those controls from the menu (comment them out so they are available if you need them again).

The ambient light, whether an actual ambient or directional or hemisphere light is irrelevant, should provide enough light to see everything without other lights. This is the general light level of the scene. Get that right before using any others.

For the balls, a point light is going to give you light in both directions of travel. The light has a point and shines in all directions from that point. A spot light is a point light that also has a direction, so it is more like a torch. You might try having a low level (intensity) point light and a higher level spot light for each ball. Maybe even get rid of the spot lights if they aren't working very well. The idea of these lights, for this app, is to highlight where the balls currently are, and maybe where they are going. They are not there to see things, per se, but are about bringing attention to something.

With respect to the limit on the number of lights, this effects the code generated for the shaders. These are not custom shaders as we have generally talked about on this forum, but are ThreeJS shaders used for all rendering, and there are many of them. Everything goes through a shader. In the shader language, a variant of C in this case, you can't do some things dynamically, such as allocating variables for the light data. So Three makes you set the number of lights that you have, and it will make sure there are enough variables to store that data so that the shaders can use it. I'm not sure what happens when there are more lights than variables for them. It may take the closest ones that it can and ignore others, or it might just be first come first serve.

Also, as you say, the graphics capabilities of the system it is running on have to be dealt with too. Most graphics cards these days have plenty of room for this stuff, but some systems are not built for graphics, so they may struggle with too many lights. It is better to keep things to a minimum, rather than trying to add as much as you can. You may find that it works fine on your own computer, but you can't see a thing on others.

.

Above a new table. The tube radius spheres are smaller than usual for variety’s sake. The lights at the spheres’ ring intersections are the octahedral vertices of the single pointlight helper.  

Adding lighting controls for the purpose of lighting optimization given a minimum of lighting. Setting up things to start with the ambient light.  

1. A track table has been added. A pale grey (0x0c0c0c) table 10*r below the track, peeking at you from the lower left hand corner. By looking straight down on the track the table surrounds it, in accord with the orthographic view. The table is far enough away that it is out of the frame for most not from-the-top images. The table serves as a light detector. It ‘registers’ the ambient light. So do the the PI = 4 tracks, as well as transparent tracks would be expected to do, i.e. very little. The table works.
 
2. Ambient. Ambient intensity, is added to the top of the control panel, varies from 0 to 100. It works. 25 is a good number at present.

3. A Color, the ambient color is a grey – again 0x0c0c0c color. It works.  The ambient color can saturate things quickly so I’ve learned how to make lower edge color box ambient color changes.

4. pt Intensity. For the pointlight.intensity. I believe it should be very low values, setting it up from 0-3 in 0.1 increments. Not yet working.

5. pt Distance. For the pointlight.distance. 0 to 10*r. Not yet working.

6. pt Color. For the pointlight.color. Not yet working, it doesn’t allow the dat gui to function.

7. Nowhere near adding the spotlight, intensity, etc.

8. I also expect I'll try a rectangle area light as an alternative to the ambient light.

Adding the new controls has been more difficult than I'd expected - with small joys to go with it.
.

.

New light optimization controls; all except the Rect Area light folder are working properly.

Check out the great transparent tubular reflections - due to the new rect area light. Its dimensions match the table I mentioned yesterday, 11*r by 4.5*r, at 10*r above the track, keeping its helper out of view. Intensity is 5. Note the reflections on the tubes and spheres show the table 10*r below is reflecting the new light.

When all is ready, as you suggested, the first order of business will be to toss out the helpers and get the ambient light correct.

I'm stunned the new light works so well, I hope you're Ok with it. I'm almost ready to suggest tossing out both the spotlights and the ambient light.  

You may have noticed before I did yesterday, the curved track markers were wrong. The only casualty of stress testing the scene by changing r from 1 to 1.5. That problem has been corrected.

Going over the controls again seems to be working, almost everything went much more smoothly than ever.
.

.

All the new light optimization controls are working. Hemisphere lighting is fully ready but commented out.

The sphere spotlights are removed, their biggest drawback was the fact we cannot have both forward and backward pointing spotlights – it breaks the minimum requirement.

The light controls are ready. Those spheres may be a bit too shiny. A requirement for using the rect area light was converting all the objects to a MeshStandard material. I see I need to add material controls – addressing the shininess, etc, before looking for optimum lighting.

Doh dee doh.
.

LongtimeAirman wrote:
The sphere spotlights are removed, their biggest drawback was the fact we cannot have both forward and backward pointing spotlights – it breaks the minimum requirement.

What requirement is that? The spot lights were to show the direction of travel, or at least that was my intention when I suggested them. I don't think there is a need to have backward facing lights, although I don't object to them either. I thought a nice mix should be able to be found. I also don't mind if they aren't used if they aren't needed.

LongtimeAirman wrote:
The light controls are ready. Those spheres may be a bit too shiny. A requirement for using the rect area light was converting all the objects to a MeshStandard material. I see I need to add material controls – addressing the shininess, etc, before looking for optimum lighting.

Why are there 2 specular highlights on the balls? Is there another light above the tubes?

It looks like the minimum value for the ambient intensity is 1. That can be a floating point value and the minimum should be 0 so you can turn it off. I see that the other lights look like they go to 0, so it is probably a mistake.

I'm not sure I like the rect light. It creates strange looking highlights on the balls.

I love MeshStandardMaterial. It really needs some special textures to make good use of it, though. A lot of my textures are designed for it, but it is also very easy to create simple ones. The difficulty is in putting them onto the objects, which requires quite a few steps. It really does bring things alive though. Worth the effort. Have a play with what you can, and we can discuss that later.

Have you put this project into GIT? Do you want me to put it into mine and give you access like the other projects? You will still be driving it, but it would allow me to create branches to show some things. Also makes it much easier for me to test it and see it in action.

.

Why are there 2 specular highlights on the balls? Is there another light above the tubes?

The image shows the rectArea light only - the ambient and sphere point lights are at zero. The variation across the three is due to different rectArea width and height values. Another light above the tubes? I can see the lower specular highlights as internal reflections in the tubes, but those spheres are supposed to be ‘solid’, I don’t know how to interpret the lower specular highlights which to me suggest another light below the tracks. At first I thought it was a reflection of the plane 10*r below the tracks, but that plane has not been added to this scene.

While not currently active, I thought the hemisphere light might balance the upper and lower highlights by giving them different colors.

I suppose I should add a rectArea light position control before jumping to any conclusions.

It looks like the minimum value for the ambient intensity is 1. That can be a floating point value and the minimum should be 0 so you can turn it off. I see that the other lights look like they go to 0, so it is probably a mistake.

Ok, ambient and the rest of the lights are now currently initialized to zero, for better control panel control. I should mention, if a pointlight distance is “set to zero the light is not attenuated”, so the distance minimum value for the pointlights is set to 0.1.

I'm not sure I like the rect light. It creates strange looking highlights on the balls.

Affirmative. I’ll include rectArea light position controls next.

I love MeshStandardMaterial. It really needs some special textures to make good use of it, though. A lot of my textures are designed for it, but it is also very easy to create simple ones. The difficulty is in putting them onto the objects, which requires quite a few steps. It really does bring things alive though. Worth the effort. Have a play with what you can, and we can discuss that later.

The tubes are transparent and do not seem to be affected by meshStandard material roughness or metalness. So I changed the control panel material object from track to red marker without having changed out the word track yet. The spheres and the markers are the only opaque solids, the only objects that could possibly benefit by a texture.  

Have you put this project into GIT? Do you want me to put it into mine and give you access like the other projects? You will still be driving it, but it would allow me to create branches to show some things. Also makes it much easier for me to test it and see it in action.

No Sir, I have not put this project into a GIT folder. I’d greatly appreciate you handling it like your other projects.
.

Now that I think about it, it does make more sense that the light in above the scene, not sure why I was thinking that it was below (maybe because that is where the table was a few posts ago).

I would not expect to see any reflections of light from other objects in the scene. That is extremely expensive to calculate. There are ways to do such things, but I would not expect ThreeJS to provide those. I once read a great article about the way the game Metal Gear Solid V does this and it required many rendering passes and various temporary images to be generated. Basically, a highly customized rendering pipeline. This could be done in ThreeJS too, but is beyond the scope of ThreeJS to provide (I imagine, anyway). Interestingly, the new big thing in graphics cards is all about this (called ray-tracing), but you need dedicated hardware to do it (that's how expensive it is to calculate) and only the most expensive cards have it at the moment. I am unaware of ThreeJS supporting that yet, and wouldn't expect it for some time.

Airman wrote:
Ok, ambient and the rest of the lights are now currently initialized to zero, for better control panel control. I should mention, if a pointlight distance is “set to zero the light is not attenuated”, so the distance minimum value for the pointlights is set to 0.1.

I didn't mean to initialize them to 0, just for the UI control to allow the user to drop it all the way down to 0.

Using 0.1 as the minimum point light distance is fine.

Airman wrote:
The tubes are transparent and do not seem to be affected by meshStandard material roughness or metalness. So I changed the control panel material object from track to red marker without having changed out the word track yet. The spheres and the markers are the only opaque solids, the only objects that could possibly benefit by a texture.

In order to use metalness and roughness, you need to supply special textures that provide that information, one for each. You set the textures on the metalnessMap and roughnessMap properties, then you can alter the metalness and roughness values (floating point values between 0 and 1 inclusive) to determine how much impact those textures have.

The tubes can still benefit from some textures. I'm not saying they actually need them, but there can be benefits from using them. For example, using some amount of roughness would alter the light upon the tubes, potentially making it look more like PVC.

.

Here’s a view of the latest rectArea light control including position and rotation, along with the helper which is a bright white square when viewed from the other side. The helper isn't changing dimensions with width or height changes - I may need to include an update(?), but the light does change correctly. A little bit of rectArea light can do a lot.

The straight track white pi marker is still transparent and so the backside on the other side of the tube is obscured.

My hemisphere light is gone, must have been lost during the great spotlight purge a day or two ago, I’ll do it again.
.

.

Adding a fine light source alternative, Directional lighting – from the top right in the scene above, along with material controls for all scene objects. At present I’m working on adding the directional light target coordinates control. Everything is going well – knock wood.
.

Try slerping the colors on the markers, while still using the same color for each corresponding part of each track. I'd like to see some way of quickly identifying the correlation between the track positions. you might have trouble since 2 markers on the curve are in the same position. It would be awesome if those 2 actually changed color depending on whether the ball had passed that point or not.

Slerping works by changing one color into another color based on a value between 0 and 1 inclusive. So use the distance along the track, divided by the length of the track, to set that value. Then you just need to pick 2 colors to vary between, or 2 shades of 1 color, or a single color slerped from white, or something like that.

.

Try slerping the colors on the markers… It would be awesome if those 2 actually changed color depending on whether the ball had passed that point or not.

I agree, this can be the Flaming Hoop option. If so, I’m going down, worse, without the flames. Searching on threejs+slerping+colors I get no overlap except for a hidden note someone left on the threejs color page, https://threejs.org/docs/#api/en/math/Color, “add slerp”. Do you have any reference you could share? There's real problem here. If slerp isn’t a coloring option, what is? How can I change an object’s color during an animation? The only answer I can find involves tween.js.

https://stackoverflow.com/questions/12504449/how-to-tween-between-two-colours-using-three-js
https://stackoverflow.com/questions/22506406/three-js-animate-a-mesh-with-color-transition-tween-js

Slerp – spherical linear interpolation - is always described as a quaternion operation involving an initial position (and possibly a rotation) and final position (and rotation). https://en.wikipedia.org/wiki/Slerp. Slerp is all about quaternions. I gather that if one defines beginning and end quaternions, one may slerp any number of linear interpolations between the two end positions. As you suggested weeks ago, one could describe a complete circular path about a point using slerp - quaternions. I wasn’t able to find a quaternion solution and used the parametric form instead. Is that what this is about? Do you still object to the parametric equation r = rcosθ + rsinθ and are leading me down the quaternion path?

Geometric pi divides the curved path into equal lengths. Please consider the following reference, the Wikipedia link above includes it in its list of references.
The Inner Product, April 2004. Jonathan Blow (jon@number-none.com). Last updated 26 February 2004. Understanding Slerp, Then Not Using It
http://number-none.com/product/Understanding%20Slerp,%20Then%20Not%20Using%20It/

Coordinate-free derivation of slerp

Our inputs are two unit vectors, v0 and v1, and a scalar t.  We are solving for a vector r whose angle with v0 is θ = t θ0, where θ0 is the angle between v0 and v1.

Figure 1 illustrates the problem.  I have drawn v0 in the direction we usually use for the X axis when drawing the XY plane.  This by itself suggests a solution.  If we had some vector v2 that was orthogonal to v0, as the Y axis is to the X, then our solution r = v0cosθ + v2sinθ.

Assume our input v1 is linearly independent from v0.  (If it isn’t, then the entire slerp problem is ill-formed; robust implementations of slerp contain a preamble to handle this case).  Since v0 and v1 are independent, we can orthonormalize v1 against v0 to yield v2; see Figure 2.  That’s it, we’re basically done!  The rest is implementation details, like finding θ0 from v0 and v1.  Listing 1 contains pseudocode for the whole function.  That’s slerp; slerp is not some scary 4-dimensional thing.  Listing 2 contains actual C++ source code.  Though this code is written specifically for some type called a Quaternion, it is valid for vectors represented in an arbitrary number of dimensions; so if you have some dynamic n-dimensional vector class, you can just plug in the same source code.  (Perhaps you want to interpolate surface normals on the unit sphere in R3).

As I understand it, the initial and final positions should be independent. If they were not independent – like the hands on a clock or postioning the sphere on the PI=4 track, the linear interpolation simplifies to the parametric form, making the quaternions gratudinous(?). Anyway, if so, I’ll try to comply. Come to think of it, I believe you might have used a quaterion placement example positioning spheres in the Hosohedron configurations. Or would the following approach to incrementally advancing the sphere around the circular path acceptable?
360-degree-quaternion-interpolation
https://gamedev.stackexchange.com/questions/117726/360-degree-quaternion-interpolation
It doesn’t really explain and sure it’s broken somewhere but being optimistic I wouldn’t expect that to be an issue.

Thank you Sir, I cloned the bitBucket PI=4 repository, added a public_html copy of my piEqFour project files and Pushed them back to bitBucket. What do you think? What other docs are needed? How are we going to use this platform in creating interactive papers? By the way, I expect to be otherwise busy here over the next couple of days. Being on another side of the planet, I hope you don’t mind my saying, Happy Thanksgiving.  
.

My bad. I didn't actually mean slerp, I was thinking of lerp, but knew that colors are different and have to be treated differently to get reasonable results. I jumped onto the slerp term but that is for angles, as you point out.

The actual function you want is lerpHSL. The THREE.Color class has both lerp and lerpHSL, but the latter one works better. It really depends on the actual colors you are lerping, but in general, lerpHSL will transition through all colors in a better way than the lerp function.

.

Mostly back to work. Above, a sequence of 15 images showing the balls crossing their starting markers. The straight track's marker colors are changing color per Hsl lerping.
 
How nice, I created my first color animation using the track’s table, all those flashing lights made me think of the eighty's. I was then able to code two different straight track lerps, toward and away from the track markers, and within proximity of the ball’s radius as shown in the series above. The total track time is 19 sec for 10*r. bRadius is 0.175*r. The color sequence is not the red to green toward the marker, and green to red going away from the marker as I had intended. There are way more colors present but they do seem to match going toward as going away. Colors sure add a whole new dimension of complexity to things, I’d need to work with them for quite some time before I feel the least be confident.

I can't say it's an awesome change, if I can get these marker colors right, it would amount to a nice touch. It's difficult to see the markers changing colors unless one views the scene up close and advances the scene frame by frame. To make the color change more noticeable changes would be necessary. Flames may not be enough, how about larger, or discreetly exploding/expanding/fading rings?

I don't know that there needs to be any additional animations or not.
.

I didn't mean for the each marker to be dynamically changing color. I just meant for each marker to be advancing from the last one. The color varies across the set of markers, for a given track, and match the other track so that the user can immediately see which markers represent the same distance along each track.

.

I think your suggestion is working out well, at least according to my latest working interpretation/solution; that is, until you make any additional necessary suggestions.

When the balls are in their starting locations, the straight track marker colors are: magenta, dark blue, light blue, green, yellow, white (the 2xpi(g) marker) and finally red.

The initial curved track markers are in the same order but without either the white (pi(g)) or final red marker colors.

As the balls pass the first magenta markers those markers are hsl-lerping through the same various colors while the balls are within a ball radius of their markers. The lerping may not be real clear, but the flickering does grab one's attention. After the ball passes an additional ball radius away, both magenta makers turn black.

As the balls pass within a ball radius of the dark blue markers the makers begin hsl-lerping. On the straight track, after the ball travels another ball radius the dark blue marker it is turned black. On the curved track, when the ball enters the curve, the dark blue marker turns red.

Again and again as the balls pass the markers, they hsl-lerp until they stop, then turn black.

When both balls pass through the final red - now lerping marker, all the initial marker colors are restored.

The ball/marker interaction, including shutting down the past makers makes it very easy to ‘correlate’ the motions of the two balls in both tracks.

Everything is working up to the point shown above – I’m entering the curve.  
.

.

At today's photo finish, only the spheres and final markers are well lit.

The markers are behaving close to the animation I described yesterday. No surprise, as you anticipated, that curved track start/final marker was going to give me a problem, two different markers must occupy the same world space. Well I haven't solved that one yet, the consequence is fairly minor. Only the circular track's final (start(?)) marker does not lerp - all the other curved and straight track marker animations are working properly. The final color in the straight track's final lerp sequence is red, and so we still have a matching photo finish.

I had another, more significant problem which you’ve anticipated and I must describe. The curved and straight track markers were not quite synchronized. Compared to the straight track markers, the curved track markers took a slightly longer amount of time – more frames – to lerp as well as turn to black. The difference between the tracks was clearly distracting and unsatisfactory. Based on previous experience on this project I quickly came up with the ‘correct’ solution. I think I even almost understand it, an aspect of circular motion. I narrowed the ball’s angular width from,  

var ballWidthAngle = 2*Math.asin( bRadius/r );

to

var ballWidthAngle = (Math.PI/4)*2*Math.asin( bRadius/r );  

Both tracks now lerp colors and change to black on the same frames - simultaneously.  
.

.

The PI=4 Experiment, including transparent tubes, lighting and marker color animations are working properly and looking good; clean and elegant. Your ideas have pushed this project well past my expectations. Thanks boss.
.

.
I believe this project is ready to compliment one of Miles' PI papers, do you agree?

You asked me to think about which one. I suggest adding it to the end of Miles’ most recent PI paper, A Simple Experiment Proves Proof Pi=4. Once that’s complete, and the animation is available for review by others, we might ask Miles and StevenO what they think.

Does that sound like a plan?
.

.

Consider this latest change.

As we know, if the curved track were straightened out and laid against the straight track, it would be as long as the straight track 2*PI marker; which, according to now out moded conventional geometric theory, is where the straight track ball should be at when the ball in the circular track completes the circle. Given circular motion, we now know that the distance traveled by the ball in the circular path will 4/PI(g) longer.

Of course nothing special happens when the straight track ball reaches the 2*PI marker. As such, I suppose it’s appropriate, indicating the ‘extinction’ aspect geometric pi. On the other hand, if there’s a straight path 2*PI marker, why is there not one on the curve, showing where the curved path ball actually is at that moment?

The straight track 2*PI marker stands alone till it is passed by. In my mind, adding a curved track marker in the same place adds balance. Like using two apostrophes instead of one. I would not use the curved path 2*PI marker as an illustration of the A Simple Experiment Proves PI = 4 paper. I would try to match StevenO’s layout as much as possible. A lot of subjective choices are unavoidable, requiring agreement and coordination.

Please redirect me as you see fit. I’m still trying to add a dat gui pull down option. Of course it isn't needed for a single paper illustration. The current project includes all the bells, whistles and extra sinks. Any illustration would begin with a sharp reduction in source files – say as to match StevenO’s experiment as closely as possible.

I’ll keep busy. I also want to be able to change cameras. A few more things. Please let me know if there are any problems.  
.

It's looking pretty good. I think the ball and track diameter is too small. The camera is not centered at the start. The view should be from directly above.

It is currently implemented as a full screen app, but it will not be used as such in an interactive paper. It will be much smaller, so this needs to be thought about. You probably can't do too much until it is put into the paper, where you can actually judge it, but just think about it only using the center half of the screen and make sure that things are still easily visible.

As far as code goes, it will be much easier to put it into another page if all of the code is in a JS file, and not in the HTML file. You can leave ThreeJS setup code in there, but try to get all PI=4 specific code into a JS file. Then it can be included into another page easily, and how it fits into that page is separated from your stuff. I will need to juggle a few things to fit into my interactive paper code and this will make it easier to do so.

I wasn't sure what some of the menu items were supposed to do, and playing with them didn't seem to change much, but it did create errors. The balls got out of sync with each other at one stage, just from checking and unchecking some check-boxes. That shouldn't be possible. It might not be a problem in the final product, because those menu items won't be in there, but it is good to think about those sorts of things anyway.

From a physics standpoint, the ball on the curved track obviously slows down once it reaches the curve. Is that a problem, or is it expected? I must say that it is messing with my brain and makes me doubt this hypothesis. Maybe it would be worth while having a second curved track where the ball moves at PI=3.14 for comparison. We might not use it in the final product, but it may be useful for our own analysis.

.

The current initial output view – including the ortho camera helper.

The ball radii and track diameters have been increased. For the record, StevenO's experiment included a 17.6cm diameter circular track traversed by 12mm diameter balls. 1/X = 1(17.6/1.2) = 1(14.6666). x = 0.0681818cm. The balls in the animation image above are now twice that, bRadius = 0.136363*r. No problem, the larger diameter tracks are easier to see. Unfortunately, StevenO’s experiment didn’t include spins, but I want people to see the spins. Do you agree? Is it right or wrong to include the spins? Would using spins with caveats suffice?

Is the above properly centered (ignoring the new pi(g) track) ? Given a 50% smaller canvas, I tried to ‘enlarge’ the camera view, but that resulted in too much track front edge clipping; I ended up restoring the camera view size.

I’ve tried converting to a smaller canvas in the html style block. The “title” and info went to the top left of the larger browser screen area. It was partially covered by the stats also at the top left. The dat.gui was at the top right - outside the canvas. They would all need to go. I’ll follow the format you come up with.

Some of the material controls are there just for the links or structure’s sake, to add to or modify as desired. I was happy the dat.gui controls went so well (minus the pull-down), I was ready to try and control everything.

Changing pi(k) and pi(g) are something else. I thought the pi switch worked sufficiently well when I switched either the numerator or denominator pi switches once in a given track run; switch them twice and the tracks are unsynchronized.

Let me qualify that, the tracks are each in their own separate animation loops, they are synchronized or they aren’t. I don’t have any code to ensure the tracks are synchronized. I suppose I’ll try to correct that. I think I’ll try including boolean readyS, readyC, and readyG variables such that balls will not be advanced until all tracks are completed and again ready. Hopefully my current if/else structure will allow it.

Ask for a separate pi(g) track and ye shall receive. It’s a pig, not operating completely correctly – I haven’t converted all the spin animations and lerping yet. The tracks are ‘synchronized’ since the ball pi(g) track is allowed to overrun. All three begin new runs simultaneously, I’m not sure how. Maybe with ready variables the pi switches will work properly for the curved track; alternatively, since we now have a separate pi(g) track, it may make more sense to isolate the pi switches to just that track.  
.

Don't worry about trying to make the canvas smaller. That won't matter, although it is useful for you to test it, I guess. Basically, it is the contents of the scene that matter. The camera especially, as that sets the view. So make the scene work at whatever size you have, even full screen, but things might look a bit larger than you would actually have them at that size (assuming full screen). Make sure that the tracks take up almost all of the available space. The straight track should be about 90% of the width. Assume the height will be smaller than the width, probably in a 16:9 ratio (width:height). Set the track and ball diameter to use as much of that space as you can without it looking strange.

I would expect the tracks to be in the same animation loop and coordinated such that they stay in sync with each other. If some action causes a reset, then all tracks must be reset. They should be using the same time mechanism and a reset just changes that time. Then everything remains in sync no matter what happens. I assume that all tracks run through the same function that contains the if/else structure for motion (although they would be executed separately, so maybe that's what you meant by not running in the same animation loop). When you say animation loop I assume you mean the application loop, executed by the requestAnimationFrame function.

Can you make the PI=3.14 track a mirror of the PI=4 curved track, and place it on the other side of the straight track? I'd prefer the balls to start at the same X position (assuming X represents the width) so that you can see that they are moving at the same velocity during the straight section at the start. It will look a bit phallic, but the 6 year old boy inside of us can have a giggle and then get back to work.