Animate the PI = 4 experiment

.

In this image, the ball’s markers have been added to each sphereGroup but the spheres have not.

Update. After taking a week off I decided to try making transparent balls a user controlled option, making it much easier to compare ball positions and observe cycloid creation. So far, I’ve tried a couple of ways without success: 1. By attempting to copy the current marker opacity control, and 2. copying the current ball velocity control. No joy. At best, any gui ‘ball opacity’ change gave the balls new random colors, another problem was the balls switched between transparent and opaque as they moved along portions of the tracks.  

Nix ball opacity control. My current attempt is to see if I can use the gui to add/subtract the ball’s mesh (new global variable ballMesh) from each sphereGroup, which should appear as in the image shown.  
.

.

This image shows 1/PI radius rollGroups (not sphereGroup) – with ball markers and without balls, showing a closeup view of the curved track finish lines. The darker green is shadow.

The third attempt worked. One can now ‘add’ or ‘not add’ the sphere to/from each rollGroup by using the dat gui checkbox or the letter ‘b’. There’s a little conflict when switching between the two mehods, repeated action works. The scene is reset if one changes the current setting.

.

.

A composite image showing a side view of the straight and curved rail tracks above and tube tracks below. The side rails are thin for extra clarity.

With respect to the rail track’s cycloid, as I’ve mentioned several times, it’s wrong. Still, since I would like to keep the rail tracks option, I’m compelled to correct its cycloid as much as possible; without, as you indicated - messing with the existing PI=4 app’s motion code.

While I can rationalize approximating the balls’ two side-by-side actual side rail contact points with a single equivalent central contact point ‘in the middle’. I fail to abide that single cycloid reaching lower than those two rail contact points.

I believe I ‘corrected’ that particular problem. The rails effectively shorten the ball’s radius by cos( PI/8 ); where PI/8 is the angle between the rails and the balls’ center. The tracker code currently includes a multiplier, currently 1, the ball radius, indicating a point on the ball’s surface. Multiplying the rail track multiplier by cos( PI/8 ) gives the rail track cycloids proper vertical extents. Note the top arch and bottom surface ‘contact points’ of the rail track cycloid do not reach as high or low as the tube track’s cycloids.

Of course the rail tracks’ cycloids are still wrong – note the last tracker surface contact point just to the bottom left of the balls’ (just the ball marker set is shown) central, final position. The rails’ contact point is too wide, a curtate cycloid. In order to correct that the app needs to recalculate the increased number of z-rolls and rolling increments.

I haven’t been able to figure out how I might make be able to make that change. I don’t believe it technically qualifies as messing with the app’s motion code. I hope you agree.
.

.

Today's two images were made with a perspective camera.

Last time I indicated I would attempt to change the rail tracks’ z-rolls. I did, but no joy. I also tried to give the user a camera option, to choose between perspective or orthogonal cameras. The camera is fixed during the init() function. reset() cannot change it, init() causes errors; again, no joy. Nevertheless, those two possibilities aren’t important.  

Nevyn, many, more than I can express, many thanks, for your cooperation, patience, support and guidance. I’m happy with the PI=4 app. I do hope you include it at the Lab. Unless you have any further tasks or directions for me, I don’t think I’ll be trying to make any more code changes.


.

.

We’ve got good rail track cycloids. The ballGroup is in its final position. Note the bottom edge of the ball marker is ‘well below’ the tracker cycloid surface contact position which is midway between and at the same height as the track rails.

Please pardon me, I must interrupt/delay my announced exit. I figured out how to correct the rail track cycloids without making any motion changes.  

The default is a tube track with ball radius = 1/PI, such that the ball will z-roll 5 times over the 10*track radius long, straight track, which produces the same cycloid pattern as shown for the curved track in the image. If the user selects a rail track, the ball radius, ball markers, and track markers must be increased in order to produce the same cycloid pattern. Motion is not changed, all rail track geometries/radii are increased.  
1. The ball radius is multiplied by cos( pi/8 )  // the ball’s effective radius for the same tube or flat track cycloid pattern.  
2. The tracks are reset(). // The track dimensions are a function of the radius times cos( pi/8 ).
3. The ball and ball marker radii are increased (/cos( pi/8 ))
4. The y and z rail positions, the straight and curved tracks, are lowered (widened) to accommodate the larger ballGroup mesh.
5. The marker radius is increased.
6. Selecting a different type track will restore the ballGroup mesh radius back to the ball radius.  

And undo previous rail track cycloid changes. I’m somewhere in that list, confident that this solution will work. The track markers aren’t included in the image since they still need to be increased, made more complicated by a Section.markerGeometry[key] that I haven’t grappled with yet.

Patience dear readers.   
.

.

Rail tracks, with thin rails showing proper cycloids. A close-view of the straight and curved tracks' zero markers.




This image shows three, ten*curved track radius long straight tracks: tube, flat and rail. The tube track default ball radius is 1/PI = .318, which results in five, total straight path z-rolls. Same for the flat track. For an equivalent rail track cycloid pattern, the rail track: ball radius, ball marker radius, track marker inside radius and track positions are expanded to 0.318/cos( PI/8 ) = 0.3442.

I believe the rail track cycloid pattern is now acceptable and accurate enough for government work.  

Once again Nevyn, many thanks. I might do some cleanup, but I'm out of tasks. Let me know if you think otherwise.

P.S. corrected 3.143 to 0.3143, and 3.442 to 0.3442.


P.P.S. the only constant in my life are my errors. Correcting 1/PI = 0.318 and added another image. Composite, flat tracks above rail tracks below.
.

.

White markers, Line tracks and Unmarked balls. As previously, the yellow and magenta balls (and their tube tracks) model Steven Oostijk’s PI=4 Experimental outcome. The optional blue ball and track models mainstream’s Pi=3.14… expectation, which violates the observed experimental Pi=4 outcome – by traveling too quickly, finishing its circular track as the other two track’s balls passing their 2*Pi markers.

Update. Reporting unscheduled positive changes. The image above shows three small Pi=4 main branch additions. 1. Line tracks, (made of very thin flat track box and ring geometries); 2. White markers (shown at 50% opacity); and 3. Unmarked balls.  

The amnTracker branch is intended for “toybox” changes, not a PI=4 user selectable item and therefore not Pi=4 app postworthy. I do not know how I might go about making one, let alone a cycloid toybox. For starters, I added a control to change the rolling ball’s z-axis phase angle. The app cannot display multiple paths. For the image below, I overlaid seven final marker position images including their cycloid tracks. The balls - just the ball markers, roll on rail tracks. Note that each yellow cycloid has a different initial z angle and there is a yellow cycloid path ‘behind’ the magenta straight path cycloid to the left of the center zero marker. I could have made it prettier if paint included masking.

Once again, I’m out of ideas. I’ll continue working with the code, thank you Nevyn. If I come up something, I’ll post it, but I don’t anticipate anything.

I keep up with the news. Family difficulties and real world events are taking up most of my time and attention. I heard a good summation yesterday. The US is facing its worst health crisis since 1918, worst economic crisis since 1933, and greatest civil unrest since 1968. There’s more, I’ll stop there. The PI=4 project has helped me focus and weather the constant stream of events.

Good luck to us all, or even better, try to make a positive change or two.

Adding a third image.


.