Animate the PI = 4 experiment

.

Here we see the balls spinning about their forward, x direction. Note the spiraling marker path. The transparent tubes are completely transparent. Changing the balls' rollGroup from z rolls to x spins turned out to be extremely easy, just switch this.rollGroup.rotation.z to this.rollGroup.rotation.x in two places. I believe this would make a fine track alternative. Did you notice the rollGroup would allow alternate spins when you first coded it?


The other fine no track ball spinning through space direction would be either clockwise or counterclockwise y rotations. Unfortunately, the tracker is tracking the positions of the balls’ south poles. Instead of loop de loops we see single lines along the bottom of the balls’ paths. How can I change which ball marker intersection point the tracker tracks? I’ll see if I can find it out.


P.S. Ok, Here's the view from above which shows the three balls' z-rolls have been replaced with CCW y-axis spins.
.

.
I’m still playing with x and y ball spins.


Here’s another view of a y-axis ccw spin I showed last time. Note there is a 90 degree difference in the initial phase angles between the two images, you can see how the kinematic tracker path (yellow clover) has rotated ccw and geometric (blue diamond) patterns has rotated cw as viewed from above.


Here we see an initial phase angle difference between the curve and straight traveling x-spinning balls. I commented out the reset rotation angles to 0,0,0 in order to add some variety to the resulting spirals.


Spoiler alert. This image looks like z-rolling cycloids, it may take a moment or so before realizing the tracker is showing ccw x-spins.  
.

Airman wrote:Did you notice the rollGroup would allow alternate spins when you first coded it?

Yes, it's just a group, so it can apply any transform you want it to. It was intended for rotation, but you can rotate on any axis.

Airman wrote:How can I change which ball marker intersection point the tracker tracks?

I have started a new branch to change things to get this working a bit better. Currently, the Tracker class sets that point, but I am changing it so that it calls a method on the Ball that sets it. That way, the Ball class is responsible for its own rolling. Any changes required should only be needed in the Ball class. It really does come down to the roller being used, so the Ball class may end up passing that responsibility on to the roller function somehow.

.

Three images showing Balls with clockwise forward x spins and their marker tracks. Both curved track paths are created in opposite directions but they appear to be exactly the same. As I've mentioned previously, the geometric, ltBlue ball violates physics by traveling its curved track too fast - 4/Pi faster than the experimentally observed kinematic yellow ball.





I'm having fun, but I'm in limbo, anxiously awaiting any Ball Class changes you might come up with. I’m not going to make any new changes - including these ball spins while existing changes remain unprocessed. On the other hand, you haven’t indicated yea or nay on including forward x-spins or top y-spins. It's your decision, not mine, please pardon my enthusiasm.
.

.

Final positions for the balls traveling with clockwise y-spins on the geometric (ltBlue), and kinematic (yellow) tracks and their tracker paths. Although the ltBlue ball travels 4/pi too fast, the same path would be still be traveled with proper kinematic motion.

The cycloids need some explaining. When I first showed y-spin tracked patterns, I failed to point out the fairly obvious neon-like cycloid patterns formed by the ball track markers. We’d considered z-roll versions a week earlier. The clover loops are too long prolate cycloids and the stretched out diamond points are too short curtate cycloids. After some review and correction we obtained proper straight and curved track z-roll cycloids. The image above seems to throw all that into question. How does switching from a z-roll with proper cycloids to a y-spin result in either too long or too short cycloids? Does that make sense?

Luckily, it's not too complicated. As the ball travels through space about the curved track, there are two y-spin motions present, each will be either cw or ccw. The first is the ball’s y direction about the curved track and the other is the ball’s spin about its own y-axis. The two motions add, such that if the two spins are in the same direction, the prolate cycloid forms, and when the two spins are in opposite directions, we get the curtate cycloid.

It makes sense. The distance traveled by a point on the y-spinning ball about the y-axis track must will be either longer or shorter than the z-roll cycloid. Sound reasonable to you?
.

I have taken your branch and made everything work in a generic fashion so that the visual representation of the Sections can be swapped. It will even work while the scene is live, so we can hook up a UI control to choose which type of track to use. I accepted and merged the branch onto master, so you must not work on that branch anymore. I closed the branch when I merged it, but that is on the server (also known as remote in SourceTree) and you may still be able to work on your local branch. I suggest you delete that branch as it is no longer needed.

To do that, you select that branch in SourceTree in the left-hand panel:



Right-click on it and one of the options is 'Delete AmnMods'. Click that and follow the prompts.

It will only delete the branch from your local repo and all of the work is in master now, so it isn't needed. Nothing will be lost. The branch will remain on the server but it will be closed.

I haven't had a chance to get my head around this other stuff you are doing. I recommend you think about what makes sense for a PI=4 application, and what is just fun to play with. Nothing wrong with having some fun and changing things to see what happens or trying new things that may be unrelated to this app. In fact, I highly recommend that. However, we must leave those in the toy-box and keep the app focused on its intended purpose. I don't think we need X and Y spins. We just need a roll that makes sense for a ball moving along a track. The app also isn't about studying cycloids, although it could be used as such. You asked for a new app to work with this code base, well that may be it. Create a cycloid play-ground. You could take this project as-is and change things to fit whatever you wanted it to do. I can setup another project in GIT for it if you want. The first commit would be this code base and then you can run with it in any way you want to.

.

I see the Sourcetree change in status. I went to BitBucket and saw your additions to AmnMods and the Master branch. I went back to Sourcetree, Fetched and tried to Pull the 8 AmnMod changes first, with the‘Commit merged changes immediately’ Option selected.

I received the error shown – fatal: Couldn’t find remote ref AmnMods, … . And canceled the Pull.

Any detailed suggestions?

Next I saw your post. Are you telling me to right-click and delete AmnMods before Pulling the 8? After that I'll switch to Master to Fetch and Pull the 17 or 18? Please confirm.
.

You don't need to pull those changes onto the AmnMods branch. You don't need to do anything with that branch again. Just switch to the master branch, pull the changes, and delete the AmnMods branch from your local repo.

.

Everything looks good.
 

Nevyn wrote. You don't need to pull those changes onto the AmnMods branch. You don't need to do anything with that branch again. Just switch to the master branch, pull the changes, and delete the AmnMods branch from your local repo.

Amn. I ended up switching to the master branch, Fetched and Pulled those changes before attempting to delete AmnMods. Of course the branch is still in the commit history - turned green for some reason, I don’t know if it is still in my local repo or not. In any case, I’m supposed to make my changes on my own ‘branch’. Since I need more practice making branches than trying to stick with one and only one branch, I made myself a new working branch, amnM. I Pushed it to the remote repository.

Nevyn wrote. I have taken your branch and made everything work in a generic fashion so that the visual representation of the Sections can be swapped. It will even work while the scene is live, so we can hook up a UI control to choose which type of track to use.

And,

Nevyn wrote. Create a cycloid play-ground.

Amn. I said I had no idea how you would implement alternate tracks, now that you've shown me some new code, I need to see if I can hook up the UI control to select either tube tracks or flat tracks.

I wasn’t thinking about turning the PI=4 app into a cycloid playground, x-spin balls create spiral marker tracks. In either case I'm happy including them in a toy box. While I still haven't explained my thinking, I believe this app can create a fine orbital system of charged particles; where each particle emits dual torus shaped emission fields. I’d also like to stack spins using dual emission particles. I think this app offers several possibilities. 
.

Not all work has to be on a branch. Small changes are fine to go straight to master. A branch should be used when the changes are large or have large consequences or the work is going to effect other developers and you want to keep it isolated. A branch should also have a specific idea of what it is doing and it should be named appropriately. We don't want a branch called 'every-change-i-am-going-to-ever-make' because we have no idea of what that is doing. It can be difficult to come up with a name sometimes, especially if you don't know exactly what you are going to be changing exactly, but a little thought should come up with something.

For example, I have a current branch that is updating the Tracker to let the Ball handle more of its own data, and I did struggle to come up with a name until I decided to go with 'tracker-update'. It is small and just descriptive enough to let you know what it is about. Not the best name, but it is sufficient. I can always rename the branch if I come up with a better name, although that can be problematic if others are working on that branch. It is best to do the renaming before you push it to GIT.

.

The markers are created from cylinder material, the walls of which have zero thickness. They almost disappear when viewed along the cylinders’ main axis, including all the starting, zero/final, the kinematic circular track 4*trk radius marker and all the straight track markers in the image above. I’ve been trying to make them more visible without success. I’ll keep trying.

I was able to come up with a UI control for selecting either tube or flat tracks with a single checkbox called "TubeOrFlat track?" without too much difficulty. That solution works ok for two tracks but I don’t believe it would extend to a third track alternative. Is that an acceptable solution? Should I go ahead and submit the pull request?

I’ve checked out your tracker-update branch for review sake.

I’m running out of tasks. Can you think of anything I've missed?
.

A checkbox doesn't work for this type of option. Use a drop-down menu instead.

.

Compare this to my last posted image. The track markers are now clearer, the cylinders are replaced with toruses. As previously, the markers can be made brighter or dimmer with the user interface - UI, marker opacity slider control. In these two images the markers opacity equals 0.75.

Nevyn wrote. A checkbox doesn't work for this type of option. Use a drop-down menu instead.

I was afraid you were going to ask for that.

Done, the UI track type (tube or flat) selector checkbox is now a drop-down menu. Do you see any problems with it? I encountered no difficulties aside from my mental block. Unquestionably, the drop-down is the better solution; but, “doesn’t work”? I didn’t notice that.

I should mention our space-bar or [space] 'bug'. After making a track change, either to the track type (tube or flat) or tracks shown (including kinematic or geometric tracks), use of the spacebar continues the track change, i.e. after changing the track type, pressing [space] presents the drop-down list even when the controls are hidden. One must select Pause [space] from the controls before the [space] can behave properly.
.

.

Looking at flat tracks, markers, balls and cycloids from two opposite sides. With the standard three tracks, the center of the scene's (0,0,0) y plane is on the center of the long straight flat track. The flat track disappears when viewed from the side, zoom in as close as you like in order to see the ball/surface contact point.

For you consideration. For tube tracks, the center of the ball, the scene and the center at the middle of the long straight tubes all meet - zooming in closer lets you see where the center of the ball might be, but not the surface contact point. Switching between the tube and flat tracks caused a ball radius height displacement which was very distracting. I moved the tube group, including balls and tracks up one ball radius to eliminate the displacement. Now the balls in the tubes as well as the flats roll over the scene’s y=0 center ball/surface contact point. As an alternative I first tried moving the flat track down without success.  
.

Airman wrote:Unquestionably, the drop-down is the better solution; but, “doesn’t work”? I didn’t notice that.

Yeah you did:

Airman wrote:That solution works ok for two tracks but I don’t believe it would extend to a third track alternative.

The space bar bug is caused by the drop-down control having the focus, so it hears all key events before other parts of the app (and it may consume them so the rest never see them). You can fix that by giving the focus to the main scene element after updating the track type. That'll need some JQuery magic. I'll look into it shortly. You should be able to fix it manually by clicking anywhere else other than the UI controls.

I expected the balls to travel on the same path regardless of track type. Glad you fixed that.

.

Big change, small balls. The user may vary the balls’ radius between the previous fixed value of 0.25*the track radius to a tenth of that, 0.025*the track radius. Here, the ball radius equals 0.15*the track radius, note the curved tracks' six or so cycloid cycles.

You no doubt recall I complained that the balls were too large. I was anxious to make them smaller or user controlled, but the code wouldn’t allow it, and you weren’t happy with the idea either. Now, we can, changing the ball radius is easy. Move the slider and watch the balls and tracks change size ‘live’. One small adjustment is necessary, for a given scene brightness, as the balls get smaller, one needs to increase lighting.

.
P.S. Here the ball is 0.05*the track radius. 1/0.05 = 20. There are twenty ball z-rolls for the curved track.


P.P.S. Ten cycloid rolls about the curved track. The ball radius must be 1/10 = 0.1*the track radius.
.

.

The yellow ball’s tracker (one of the two red/green ball marker intersections) location is pointed straight up, in the +y direction. The magenta ball’s tracker location is pointed straight ahead, at the ball’s forward-most +x direction.

Sorry Bose, racking my brains, came up empty today. I believe the PI=4 app has got everything we need. I might have screwed around with toy box x and y spins but I’ll wait till you’ve made tracker-update changes first, chalk that up as another benefit of a good branch title.

You’d indicated a preference for textures, but haven’t included them yet. I realize I’m part of the problem, my Windows 10 system prevents me from using them. Was there some look you were hoping for? Some alternative to all the colors?

I like the fact that the colors of the markers and z cycloids convey position and motion information. On the other hand, the scene may be a bit too colorful/jarring for some sensibilities. We might let the app’s initial scene look more like Steven Oostijk’s PI=4 experiment with steel ball bearing and clear pvc tubing, with roughly the same ball/track dimensions. Let the user choose between ‘steel’, or colored and/or larger balls. Let the user choose ball/track markers, colored or monochrome.

If you think that idea is Ok, I’ll try to make the PI=4 app’s default scene look more like Steven O’s and maybe create more material/color options in the controls.

In any case, awaiting your further instructions.
.

You aren't the problem with using textures. They just present a security risk and have to be handled appropriately. Well, it isn't really about security, but ownership. Basically, a website has to allow other sites to use their images (and other media). So when a texture comes from somewhere that isn't the page that you are on (or where it came from), then it is not allowed unless the site containing the texture allows it. Local files are treated as coming from a different domain, so they aren't allowed (and there is nothing to allow it). To get around that you need to use a server (such as Apache Web Server) to serve your pages. Since setting up an Apache server is an advanced topic, I won't make you do it. It isn't really that hard (you can get a WAMP stack setup easily, for example) but there are other ways to get around it (such as using my website).

I haven't had much time to work on this lately. I'll try to get that tracker-update branch finished (it basically is, but I thought there might be some other things I could try). Then I'll have a look at using textures.

If you're looking for something to do, how about giving that dual rail track a go? You'll have to think a bit to get that working. Note that I don't want to change any motion, just render the rails in the right places.

.

Nevyn wrote. If you're looking for something to do, how about giving that dual rail track a go? You'll have to think a bit to get that working. Note that I don't want to change any motion, just render the rails in the right places.

Affirmative. Thank you Sir, that task has been completed. As shown in the image we’ve got rails in the right places. The rail option has been added to the UI drop-down list of track alternatives. There's no track ball y displacement when switching between tracks, and the rail tracks resize properly.

As I saw it, the problem was, Section-type returned a single mesh, be it a tube, flat box or ring; how do I return more than a single mesh (2 rails)? Reminded me of a similar problem you gave me long ago, then as now, the solution involved creating a new 3D object in which to add multiple meshes before returning the multimesh 3D object to the calling code. I wish I could have made the problem last longer.

With respect to making the motion 'correct', I believe we might still represent the rolling motion with a ‘single’  z-roll cycloid, but the z rotation for the rails must be recalculated with the smaller spherical subsection circumference of the ball above each rail contact position - call it the side contact point latitude circumference.

Copy, you're real world busy. I'll try cooling my jets, and stop being so pushy.
.

.

A couple more views of rail tracks. Here’s an underside showing how the rails 'puncture' the track markers.

Nevyn wrote. I won't make you do it. It isn't really that hard (you can get a WAMP stack setup easily, for example) but there are other ways to get around it (such as using my website).

Sorry I haven't volunteered to set up a "WAMP stack". My current system's getting old and the battery needs replacing. Why not build a new system? I have old working software I'll never be able to purchase again, for example, my old Autocad. Tech support suggests I might try a solid state Samsung device that would allow me to clone my current system. For the time being, I'm just trying to put off the inevitable.


Highlighting the problem of applying a flat track cycloid to rail tracks. The rails have been made extremely thin in order to show that the bottom most part of the ball - the usual surface contact point for tubes and flat tracks – lies 'below' the rail track balls' side rail contact points.

P.S. Replaced second image to include the cycloids.
.

.

Another inevitability, if we can make the balls’ radius smaller, why not larger?

Ok, in these two images the balls' radii are equal to half the track radius, as indicated by the two cycloid rolls per circular track.

Where I live it’s Mothers’ Day. Even if you don’t, here’s wishing everyone a Happy Mother’s Day.

.

.

The track markers are now a bit trimmer – the marker’s internal radius always matches the ball’s radius without overlap. The marker length, however, remains the same as the ball radius decreases, this allows the track marker to remain visible for the thinnest tracks. At the smallest ball size the track markers look more like old-fashioned ring-shaped life preservers or breath mints. Here the track markers are less opaque to draw less attention.

The default ball radius (bR) has been equal to 0.25 times the track radius (tR). Did I say that was too big? These two images show a larger default ball size, such that the straight track ball makes one z-roll every 2*tR marker. Solving for bR, using the ball circumference and track length. 2*PI*bR = 2*tR

bR = 2*tR/2*PI. Let tR =1. bR = 1/PI = 0.3183…  (geometric)

Solving for the number of z-rolls in the curved track. The denominator indicates the curved track’s kinematic distance. zRollsCirTk = 8*tR/(2*4*bR) = 8/(8*1/PI) = PI, z-rolls. (kinematic)


The ball makes 4 z-rolls on the straight 8*tR long track, while the same sized ball makes PI, 3.14… z-rolls about the curved 8*tR track. To the best of my understanding, these numbers apply to the tube and flat tracks. Rail track balls would need to be somewhat larger, please assume so for these images.
.

.

Back to the tubes, once again, the track radius is one and the ball radius is 1/PI.


Here’s the latest iteration of the PI=4 app Class Hierarchy. Feel free to point out improvements or errors.
.

Airman, you need to merge your branch onto master. I can't rebase my branch on top of those changes until you do. I know you tried to keep your stuff separate from my changes for safety, but you didn't need to. I had already done that by creating a branch for my stuff. I didn't think it would matter too much at the time, but now that I want to merge my branch on to master, your branch is getting in the way because if I did merge my stuff then it would leave you to rebase your branch on top of the new code from my branch. That might go well (and I actually expect it to), but if it didn't then you would have to fix up the problems. I created my branch so that I would be responsible for keeping it up to date with any changes that you make. I didn't want to get you into a tough spot trying to merge the code together when you don't understand my parts.

.
I just merged the amnM branch onto the Master; looks Ok to me.
.

.

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.


.