// The single collision 3D dynamic reduces to a 2D known // solution. In the reference, movevec is the moving circle// velocity vector used to determine the collision contact // point with a stationary circle.

// Here, movevec - the next this.velocity - won’t be // calculated until totalAcceleration is known. // For clarity: this.velocity resulted from adding // the previous totalAcceleration to the previous // this.velocity. The next this.velocity is created// outside this i-loop and its host function // this.gravAndChargeRepulsion(). Instead, movevec, // or each new this.velocity, is created in the // function this.move().

// The particle's current velocity, this.velocity, is a // close approximation, good enough for escape tests.

// The particle pairs that fail the escape tests here// will be collision candidates.

// I'll keep the source instructions, but change the // names slightly so the differences with this // implementation will be easier to follow.

// First my small addition, a benchmark test.// create a reasonable closing frame separation distance // threshold or things can slow down quickly. Current // maximum particle speed appears to be about 3units/frame. var VectorC = new THREE.Vector3();// VectorC, the vector from the center of the moving circle // A to the center of B. A length of 7.5 units amounts to more // than twice the observed maximum velocity. The target is too // far away and collision cannot occur within that frame. VectorC.subVectors( boid.position, this.position );if(VectorC.length ()> 7.5){ continue; }

var VectorN = new THREE.Vector3();// Normalize the approxMoveVecVectorN.copy(approxMoveVec);VectorN.normalize();// D = N . C = ||C|| * cos(angle between N and C)var D = VectorN.dot(VectorC);// Another early escape: Make sure that A is moving // towards B! If the dot product between the // approxMoveVec and B.center - A.center is less that // or equal to 0, A isn't isn't moving towards Bif(D <= 0){continue; }

var F = (VectorC.length * VectorC.length) - (D * D);// Escape test: if the closest that A will get to B // more than the sum of their radii, there's no // way they are going collideif(F >= sumRadiiSquared){continue; }

// We now have F and sumRadii, two sides of a right triangle. // Use these to find the third side, sqrt(T)var T = sumRadiiSquared - F;// If there is no such right triangle with sides length of // sumRadii and sqrt(f), T will probably be less than 0. // Better to check now than perform a square root of a // negative number. if(T < 0){continue; }

// Therefore the distance the circle has to travel along // approxMoveVec is D - sqrt(T)var dist2;dist2 = D - Math.sqrt(T);// Get the magnitude of the movement vectorvar mag = approxMoveVec.length();// Finally, make sure that the distance A has to move // to touch B is not greater than the magnitude of the // movement vector. if(mag < dist2){continue; }

// And the final set of reference lines:// Set the length of the movevec so that the circles will just touch.// approxMoveVec.normalize();// approxMoveVec.times(dist2); // return true; // OK, just me now. Going further is a waste of time // without knowing the particle’s actual velocity.

system.out.println("dist2 is " + dist2);// The system doesn't print anything, but the animation // consistently freezes here with the collision visible. // All I need to do is refresh to start it back up again. // By the way, this is the most sophisticated stopping // point test I've ever handled.

// So far, there's been no real penalty. With 256 particles, // fps has held at 24, since adding the first test. Without it, // 128 particles were clocking in at 29 fps.

// Still present at this point, we have this.position, aka // boid = boids[ i ] from the function render(), and// boid = boids[ i ] from this.gravAndChargeRepulsion()// in a photo-finish.

// How would I pass them to this.moveCollisonBounceEtc// or even to the return totalAcceleration level???

I admited being somewhat of a clod last week using the java cmd system.out.println as a programming tool. It reflected a certain desperation at the time. Then after a bout with an if-statement (testing equivalence - not making an assignment) I also realized that while I had studied Java, I had not yet studied JavaScript. So in my normal fashion, I went back to start, by beginning two new books: 1) http://eloquentjavascript.net/index.html; and 2) JavaScript: The Definitive guide. I loaded three.js Inspector but don’t see any utility to it yet. I also loaded Firebug on my Firefox. I am now using what I believe is a JavaScript console, to use the mini API cmd console.log(“doh”); to allow running javascript snippets or all the text examples on my browser. Also, an alert with variables listed has replaced system.out.println. Please forgive my loose use of the subject matter. Your patience is appreciated.

In any case, with less than a week left to this year, my best wishes to all for the next.

The collisions look OK. Most have the periapsis wiggle to some degree introduced by the charge field’s tanAcceleration. The wildest “collision” occurs when two boids roll around each other at high speed, a quirk or feature of SO2 caused when two bids are too close ( < 1. 0) to each other. It's hard to tell, but there's an example the image above, halfway up at 12 o'clock. I’ve seen them since last month, so, nothing special. Only now, they usually break free of each other, and are sometimes hit in collisions too. There are a few other wierdities, like occasional long range collisions.

Overall, stability is improved. The boids are now "tangible". The radii act as margins preventing the production of high accelerations. I tended to use radii between 1 and 10 in working the bounces. Size makes for poor differentiation in this simulation. I haven't tried a very large single central object yet. I have increased velocity, and gravity, because of the improved stability.

I apologise for the awful code I posted on the 18th. The reference source used thus far is the same as I identified then, but of course the errors were mine. My first test worked by hiding many errors, identifying collisions by fluke. Well, with effort (and //misery too!), I finally saw as the console.creator intended: Beginning with the revelation - a multitude of NaN's caused by vector.length; (answer. it needs() after length).

ToDoHere: 1)Create a separate collide function _collide(). Move citation. In this.gravAndChargeRepulsion, a new _collide() would be used for collision detection; maybe it can be as simple as a flag or two. From this.move, _collide() would be the same as here, used to confirm collisions, and if true, calculate reactions. Presently, the Alerts below identify: a) the rare set (< the number of boids) of collide===true which occurred for me on two startups. b) Negative distances also occurred during view position changes. In my observation - after running many hours in the background, just a few sqSideT and sqSideF fails. As should be expected. They don't affect the simulation, it's just an observation. approxMoveVec and moveVec are almost the same. Easy enough to find out; 2) Find out; 3) Everything is still in debug over-expanded form; Too many variables. 4) All the errors still waiting. Like the occasional collision and one, two move, separated by many units, (50 or more). 4) Need collision sounds, great for monitoring the rate of collisions. And a counter(?). 5) This too is just a start. A vital and necessary one to move forward.6) Spins. Will need to also transfer angular momentum.

// refQ: Set the length of the movevec so that the circles // refQ: will just touch. var moveVecToContact = new THREE.Vector3(); moveVecToContact.copy(moveVec); // Keep the velocity vector intact moveVecToContact.normalize(); moveVecToContact.multiplyScalar(dist2Touch); var mag2 = moveVecToContact.length(); var frameBreak = mag2/mag; // frameBreak is a number between 0 and 1. This // represents the point in time (as a fraction // of moveVec's possible extension as well as the // current frame) the circles touched. var thisHereVelocity = new THREE.Vector3(); thisHereVelocity.copy(this.velocity); thisHereVelocity.multiplyScalar(frameBreak); this.position.add(thisHereVelocity); //this particle should be in position.

var copyBoidVelocity = new THREE.Vector3(); copyBoidVelocity.copy(boid.velocity); copyBoidVelocity.multiplyScalar(frameBreak); boid.position.add(copyBoidVelocity); // boid should also be in position.

// Determine collision reaction. Still mainly // as described in the source document. // refQ: First, find the normalized vector n from the // refQ: center of circle 1 to the center of circle2 var vectorCNC = new THREE.Vector3(); vectorCNC.copy(this.position); vectorCNC.sub(boid.position); vectorCNC.normalize();

I’m still working the collision stuff. Like eliminating penetrations. As you can see, I’m close to mastering the line-slope-intercept! Yes, implementing perfectly elastic 3d spherical collisions has been fairly straightforward: 1) Find the collision point, (use interpolation);2) Move the two spheres along their velocity vectors to just "touch"; 3) Find the contact plane and the normal between the two spheres;4) Exchange linear momentum. Velocities parallel to the contact plane are unaffected, while velocities perpendicular to the plane are basically exchanged;5) Move boids along their new velocities to their post collision positions.

The missing step - Exchange angular momentum.

Up to now, I've stuck to vectors. Points, positions, velocities, and accelerations are all vectors, although (of course) not all vectors are mathematically equal. (Miles has extensively described many of mainstream’s misuse of vectors). Angular momentum is directly analogous to linear momentum, with angular: mass, inertia, velocity and acceleration. The two momentums are entirely separate – though I’m on the record looking for where they can interact, beside any off-center collision. Solving the rotational system involves additional complexity, like following the correct ‘order of rotations’. Suffice to say, all the math used to exchange angular momentum that I’ve come across thus far is exceedingly difficult. If I knew what I was doing, I would say, “buck up, start enjoying matrix algebra”.

Please, there’s got to be a simpler way.

Both linear and angular momenta transfer forces through a contact point. Well, actually the contact area. Infinitesimal points do not exist and real objects deform; and friction... I’ll try again.

Observe the expected contact areas of two spheres just before they collide. I’ll list what I think are the few cases: 1.a. No spins. Head-on collision. Both contact areas approach each other without changing their angular position. The contact areas just clap together at the difference velocity of both spheres (like velocities of 1 and -1 meet with a difference velocity of 2). While all linear momenta may be transferred, there is no angular momenta present.1.b. No spins. Off-center collision. The contact areas of the two spheres come together with equal and opposite translational surface velocities parallel to and not greater than the difference velocity of both spheres. Again there is no angular momenta (? I don't believe this. I 'll doublecheck, since off-center hits cause angular rotations). 2.a. Spins. Head-on collision. Both contact areas approach each other without changing their relative angular position. The contact areas just clap together. This is only possible if the contact area includes a pair of equal and opposite spin-axis anti-poles. Note that the rotational velocity is independent of the spheres’ forward velocity.2.b. Spins. Head-on collision. When the same spin-axis poles come together, the contact areas come together with a contact plane rotation equal to the combined rotations of both spheres. 2.c. All other collisions between spinning spheres involve both the addition of parallel, forward translational parallel velocities; and another spin based surface velocity set that also varies velocities from zero to two. A zero differential surface velocity can occur during a glancing surface collision – actually more like a gentle rolling contact between two side-by-side anti-parallel spin-axis spheres on a plane containing both equators. The maximum velocity differential occurs between two side-by-side parallel spin-axis, the translational velocity in that opposite extreme case can reach four. A large variation.

The point I’m trying to make is that each surface point has a unique set of surface velocity variations that can define any sphere moving and spinning through space. I believe those additional vectors will allow a complete vector solution to collisions involving both linear and angular momenta.

Spin collisions are very difficult. I've reached the point you are at now and thought about the next step of introducing spin but haven't actually done it. I didn't need it for that particular project but have always had the idea of building a spin collision framework.

My suggestion is to keep it simple and add one thing at a time. Never work in angular units, always tangential velocities. Ignore inner spins, if you are heading towards stacked spins, until you need them (and you may not). A collision happens at a point, evaluate your spin values from that perspective. That point is the start of any velocity vectors you use whether they be linear or angular.

Your going to get into calculating angles between vectors and using some trig to figure out the resultant vector given 2 rotations. Compare the rotation axes of the particles: are they parallel or orthogonal or somewhere in between? Given the plane that the 2 axes are in, are they at equal levels (hitting at the equator of each particle) or are they at differing levels (hitting more at the top/bottom of the particles). These things effect how the collision happens.

You've posted some good diagrams already, keep working with those and just try to see the motions you are trying to work with. Look for any vectors or lines you can use to figure out things.

Nevyn, Thanks for the sanity check, and especially the constraint (no radians)!

In order to find actual collision points, I’m afraid one would need initial conditions and an axis rotation function – what I believe you recommended I avoid – and I agree.

I do have the boid object properties spin axis and rotation velocity (well, no rotVel yet actually, (say v=x at r=1)). We can estimate the spin tangential velocities through the relation, velAtLatitude = velAtEquator(cos(latitude)).

I think you have misunderstood my statement. You can't avoid radians (and don't want to). All I meant is to avoid angular velocity values and stick to tangential velocity values. Keep everything straight as a good vector should be. Radians often give you horrible numbers but you can avoid that sometimes by working in units of PI. PI=180 degrees, PI/2=90, PI/4=45, etc, is much better than seeing 3.14, 1.57 or 0.707 although you will get used to reading radians if you keep at it long enough.

In your earlier posts, you had a picture of 2 spheres that were touching. The line between their centers is your baseline. Think of that line as being flat (along the X axis, say, but all I mean is that you consider the points to be the same in 2 dimensions and differ in the other). The collision point (assuming spheres of the same size, else divide accordingly) is half way along that line. Think of the collision point as being 0, 0, 0 and the baseline extends to either side of it in some dimension (X, say). Effectively, we have just created a translated and rotated coordinate system. This is just to think about, you won't need to create it in the math, it just helps to talk about the math by moving things to nice round numbers.

Now you need to figure out the direction of the spin axis of each particle with respect to the baseline. Find the angle between the baseline and the spin axis (the dot product, I think). If they are both perpendicular, ie 90deg, then you have an equator to equator collision. If an angle is less than 90 deg, then you are colliding near the top of that particle (but double check what a +ve rotation is in your 3D API as a <90 (actually it would be in radians, not degrees) value may mean you are colliding near the bottom rather than the top, I find it extremely helpful to create the points in the 3D scene so that you can see them and make sure they are where you expect).

Knowing the angle of attack allows you to calculate the tangential velocity from the collision point which allows you to determine the resultant velocity vectors. In the first instance, I would be tempted to just apply the resultant linear velocity vector to the existing linear velocity vectors and apply the resultant spin vector to the existing spin vectors. This will not lead to stacked spins but that is quite complicated and we don't really know how they work at this level. But it will allow you to fine tune the math and make sure you have that close to correct before complicating things.

That should get you thinking along the right lines. I haven't implemented anything this far along, but have thought about it a few times. Reading this thread makes me want to get back into the GPU code I wrote along these lines and extend it into a spin collision system.

Before simulating convincing spin collisions, or laying claim to a charge field demo, one must see spinning!

This image shows seven boi”particles”ds (previously manifest as single spheres, spots, and flapping birds), each comprised of 6 spheres. All the individual particles have the same radius; larger means closer to the viewer. Each of the seven clusters contains a red and blue pair of spheres - the north/south spin axis, randomly generated. The other 4 colors are also random, and positioned at +/- : eWAxis and fBAxis. These two axii are duplicates and rotations of spinAxis around its z and x axii, not true orthogonal rotations. That results in the small mix of shapes shown. Just a little interest. Again, I want to see spinning.

As yet, there is none. Each particle orientation is fixed as it travels and bounces about.

I’m happy to say that tribute to Miles and the rest of you now includes a fine set of marbles, built from circles, spheres and sprites. Several images are superimposed above, involving many hours of object/parent/child lessons; clearly the child in me won – BIG!

Thanks Cr6, I think they work like majic. Each is clearly visible, and when they're swarming they're every-which-way pretty. Of course their appearance doesn't make any difference in their behavior, but I'm not sure. The ortho shape is present in three of the four marbles, and it makes perfect sense. Each makes distinct visual spinwaves. Two spinrolling marbles make a case for spin stacking. I can easily see replacing them with all sorts of micro or macro objects.

I’d like to call attention to a gem from The American Journal of Physics, vol. 37, no. 1, January 1969, Kinematics of an Ultraelastic Rough Ball. http://www.rpi.edu/dept/phys/courses/PHYS1150/GarwinSuperBall.pdf. The math is turning out to be a favorite - translational and angular momentum exchanges in collisions between a superball and stationary surfaces – well, maybe someday. The analysis is clear and leads to an Ultraelastic Rough collision matrix.

The paper’s biggest surprise, I think it’s fair to say, is oscillation between translational and angular velocities from one collision to the next. The first bounce converts translational velocity to angular velocity, which is converted back to translational velocity after the next bounce. In effect, superballs take extra - almost vertical - bounces to get to wherever they’re going - translationally, compared with ‘normal’ balls. I guess that accounts for the “Ultra” in the paper’s title. If I understand correctly, the difference isn’t due to ‘slip’, it’s due to asynchronous energy reaction periods relating to the mass density distribution within the sphere … ? I’ll keep it in mind.

OK, Pop Quiz.

Inspector Clouseau leans on a globe, in which direction will he go?

The trick answer is - east. We all travel east as the world turns below us. The answer I’m looking for is east or west, as the globe, fixed on its N-S axis is free to turn only in the E-W ‘directions’. The globe’s resulting angular velocity is due to the tangential acceleration provided by Clouseau’s elbow.

When two spheres collide, the primary sources of angular momentum are the two collision latitude tangential velocities. I’ll assert that these two velocities are the primary directions, even though they don’t usually align and I don’t understand how they interact yet.

We also have the translational velocity vectors that are ignored in the linear energy exchange, since they are in the contact plane. These must be replaced with new projections parallel or perpendicular to the tangential velocities. They remain within the contact plane to add or subtract from the main tangential vectors.

I think I'll begin by exchanging these velocity vectors within the existing spin axii. If there is not enough existing angular momenta to cover the exchange, then I guess the spin axis orientation should somehow make up the difference.

Note. I’m coming full circle. How does a sphere respond to the charge field? Does it get slowed down to the point where the spin axis begins to change? I see now how a charge differential front to back may speed-up or slow–down transverse tangential velocities. I can also see the same differential turning the spin axis. In my optimistic viewpoint, the charge field differential mechanism flows seamlessly to these collisions.

There are many ways to use or improve it. With just randomly placed spinning marbles and linear collisions it looks and works better than I'd hoped. Of course there are still plenty of bugs. Maybe I should clean it up as is and upload it to GitHub as thanks for Birds. I could also change it to pursue my own game ideas; believe it or not, my goal (25 years ago) was to program a 3D pool game, but for lack of a compiler (s/w) I changed my hobby to stained glass/metal sculpture instead.

I wouldn’t consider SO2 finished until Nevyn or you told me it was. On the practical side, I’ll see if the angular collisions are working or not. I also believe the continuum - charge differential to tangential velocity to collisions – should be elegant. And stacking spins, I’m nowhere near stacking spins yet, except maybe I am. How many discreet spins should a marble have anyway?

Thanks for reminding me that rational trigonometry should be part of the solution. While I declare that the latitudinal velocity is the mainline, what happens if the spin velocity is low, or the latitude is close to the spin Axis pole? At what ‘rate’ will the translational velocity become the mainline. Will conversion to quaternions enable me to directly add the two?

I jumped into the blue with a good deal of math trepidation and joy. Did you throw a jet pack at me? Are you working on Library ideas?

LTAM, I just have always found Sine, Cosine, Tangent, etc. as "lookup book values" that maybe Rational Trig could give a more simplified approach in some cases? It would be a lot of work to make a new Javascript library that could imitate something like three.js with Rational Trig but down the road it might provide flexibility for matrix math (hits/direction/rotation/speed), etc. If I'm rambling, I blame the Whiskey.

This book has a few indications of classical "QT" electron matrix math with eigenvalues. The math is "waaayy tooo deeep" for my humble abilities. C. Graaf and R. Broer, Magnetic Interactions in Molecules and Solids Theoretical Chemistry and Computational Modelling

Can't say that I've ever made a practical "kitchen sink" from these random ideas.

While I declare that the latitudinal velocity is the mainline, what happens if the spin velocity is low, or the latitude is close to the spin Axis pole? At what ‘rate’ will the translational velocity become the mainline. Will conversion to quaternions enable me to directly add the two?

Good questions, and is the program built for the viewer or just the objects without a viewer?

Nevyn, I'm happy with the results of this project so far. I’ve presented bits and pieces of Simple Orbiter as evidence of progress, certain you or someone at home could reassemble them, and, with half a mind, do better.

Have you or Cr6 seen this thing? I’d hate it if some danged old newby died hogging a Charge Field simulation waiting for angular inspiration.

I’d like to post a first draft. Maybe organize it a bit. As you know, this project is far from finished. I intend to do as good a job as I’m able and turn it over to you. I’d appreciate any instructions you may have for me toward that end.

For the last month I’ve been in virtual orbit. I’m better prepared to share discussion and interpretations on the subject of the interaction of charged particles..

Cr6,Nevyn PMed me to zip and send Simple Orbiter to him, so I did. I would have sent it to you but MM the Site won’t let me attach zip files. Worse, my mail server doesn’t have any messages from you. I word searched your name in my files and hit on compendium, but no further. I’ve been whiling away time going through your 15MB monster – how do you navigate through it? Lots of additional stuff, and I do love the pictures. Send me a gmail message so I can send SO2 to you too. Then be amazed!

LongtimeAirman wrote:Cr6,Nevyn PMed me to zip and send Simple Orbiter to him, so I did. I would have sent it to you but MM the Site won’t let me attach zip files. Worse, my mail server doesn’t have any messages from you. I word searched your name in my files and hit on compendium, but no further. I’ve been whiling away time going through your 15MB monster – how do you navigate through it? Lots of additional stuff, and I do love the pictures. Send me a gmail message so I can send SO2 to you too. Then be amazed!

Okay LTAM,

Let me send you all my personal email in a PM. I don't know if I'll be much help with three.js issues. I'll have to defer to Neyvn's powers with that one.

I did look over mrdoob's github entries and noticed he makes fairly frequent updates. There's always a potential situation where you might stumble on to a bug in one of the libraries -- a lot of it looks taken from good 3-D C++ libraries built in the past. I should have looked at this closer before posting my prior post. Looks like three.js is using Quaternions/Slerp/etc. routines. I guess I better shut my mouth.

The only question is, do we have everything needed in three.js to represent Mathis' spin mechanics/collisions?

By the way, I'm fully cognizant of the time and effort it takes to "create" an original work programming this. Nevyn's work and your work here just simply impresses.

Cr6 wrote:The only question is, do we have everything needed in three.js to represent Mathis' spin mechanics/collisions?

Yes, everything required is in ThreeJS. Most of it is just math and decisions based on the mechanics. ThreeJS allows us to visualize it and also provides some handy things like vectors, matrices, quaternions, etc to help with the calculations.

My main question at the moment is what kind of system I want to build. You can look at it from really close up where you are watching a limited number of particles collide to get that fine detail of the collisions and how spins are gained/lost. On the other hand, you can look at it from afar where you have lots of particles colliding and you want to look at the field rather than the particles.

I want both but I think, at the moment, we all need a closer look at spin mechanics in action to get a better understanding of the quantum world. So I am leaning towards the former but I feel that the latter will kind of fall out of it. Once I have that spin mechanics behavior, I can apply it to other systems and it should be relatively easier to create the field model once I have the collision model. The difference is more to do with performance than anything else.

The particles already show a surprising range of spin behavior, including a slingshot effect. Two or more particles can whip around each other in constant contact for several ‘orbits’ before disappearing in some wild acceleration. I’ve tried to slow it down, but this is first draft. I thought I could somehow mirror or extend the action to the collisions.

“I’ll Try This!” immediately resulted in very high equatorial velocities. Translational velocities are easily converted to spin, while I have no mechanism to shed spin except through collision. To paraphrase a colleague, spins are hard.

I took a break from Boids. A non-stop politics binge. I want to be sick.

So, back to subject. I’ll put a couple of thoughts out there.

Pretty as it is, Boids is still mostly charged points. The unexpected spin behavior is not real.

Starting where I'm at, I think I can model close particle interaction as pre-e/m strength changes along quadrature lines (30N/30S/30E/30W), radially expanding, where the time or charge density is also dependent on the equatorial velocity, etc.

That drives the total number of particles down but I’d rather see a few as accurately as possible at this point.

The sum of spin on the charge photons can sum to zero. The tangential force vector would then be zero and provide no tangential velocity to any orbiting bodies. Our solar system has a 2:1 ratio of photons to anti-photons so it does not sum to zero. Are there solar systems that do not orbit but just sort of sit there as deep into the charge field of their star as possible? Would all of the planets cause each other to move based on their charge interactions?

If the tangential force is caused by an imbalance of charge to anti-charge, then the force is applied at either the top or the bottom of the orbiting body, not over its complete shell. This is not a nice clean push sideways. I think it would cause spin to a stationary orbiter. Therefore, the existing axial spin of the orbiter resists that spin and applies it as a torque to the whole body. That is, part of the force is used up working against the axial spin and the other part is allowed to express itself so the result is a sideways force.

The axial spin must be driven or it would soon stop. I think the axial spin is caused by the charge flowing through the orbiting body (north/south through-charge). Therefore the charge is working against itself (not the exact same photon but the mass of charge effecting the orbiter at a given time). This may result as heat and help explain the internal and external heat of planets.

Nevyn, Thanks for your previous post. You shared several points that beg consideration and discussion. Let me get back to that when I include spin.

I hope you don't mind the delay. I’ve put a great deal of thought into the matter.

The sum of spin on the charge photons can sum to zero.

Sure, in a given system, the number of photons compared to the number of anti-photons can be equal. Or say, far enough away, the total charges in a volume sums to zero. But that’s not correct. It ignores matter, or even net charge flow. The energy present, high or low, may be independent of that sum.

The tangential force vector would then be zero and provide no tangential velocity to any orbiting bodies.

Disagree. Consider Miles’ diagram. The one where photons enter the south pole and leave at some small positive latitude - up to 30 deg, and anti-photons enter the north pole and exit the earth south of the equator. (The image service is gone. Or it isn't working for me).

It really doesn’t matter whether the total number of photons equal antiphotons or not. The earth is structuring charge flow such that photon and antiphoton tangential velocities complement when delivering forces about the equatorial plane. They reinforce, not cancel, tangential velocities for bodies orbiting the spin axis.

Would all of the planets cause each other to move based on their charge interactions?

And gravity too. I think so – absolutely. It’s a main premise of my model. If the sun were somehow plucked from the sky, our dominant objects, the gas giants would immediately begin to re-order the system.

The axial spin must be driven or it would soon stop.

I do not see this. Why would spin stop? Up or down photons entering their respective poles cause the same overall rotation direction. Granted, the spin is somehow tied to the energy level of the local charge field, but what determines a limit?

I think the axial spin is caused by the charge flowing through the orbiting body (north/south through-charge).

I believe that the axial spin of the dominant body, our sun, is caused by charge recycling. The Earth’s axial spin depends mainly on the sun’s tangential forces.

At any temperature above zero, charge will create structure, both in itself and in any material, even a gas. To start with, the gas will align its poles to the applied field, to allow for better channeling at the atomic level.

What is the mechanism that aligns the spin axis to maximize direct polar channeling? It seems to be present at all scales, from electrons to galaxies.

I have a quick response for you but I may need to flesh out these answers a bit later when I have more time.

LongtimeAirman wrote:

Nevyn wrote:The sum of spin on the charge photons can sum to zero.

Sure, in a given system, the number of photons compared to the number of anti-photons can be equal. Or say, far enough away, the total charges in a volume sums to zero. But that’s not correct. It ignores matter, or even net charge flow. The energy present, high or low, may be independent of that sum.

Yes, it ignores matter because I was looking at the effects of charge on matter. If we wanted to find the total energy content then we would need to look at the matter present and factor that in but I was trying to look at what charge would do to the matter. I was only looking at the cause of the tangential vector, not what the vector is applied to. In that way, the sum of the spin on the charge photons can sum to zero and therefore there is no tangential force to cause a circular orbit.

LongtimeAirman wrote:

Nevyn wrote:The tangential force vector would then be zero and provide no tangential velocity to any orbiting bodies.

Disagree. Consider Miles’ diagram. The one where photons enter the south pole and leave at some small positive latitude - up to 30 deg, and anti-photons enter the north pole and exit the earth south of the equator. (The image service is gone. Or it isn't working for me).

It really doesn’t matter whether the total number of photons equal antiphotons or not. The earth is structuring charge flow such that photon and antiphoton tangential velocities complement when delivering forces about the equatorial plane. They reinforce, not cancel, tangential velocities for bodies orbiting the spin axis.

But I was not looking at the equatorial force. That is (mostly) irrelevant to the orbital motion of the body itself and only applies to bodies that orbit it. I say mostly irrelevant because the equatorial charge emission does interact with the incoming charge (from the body we are orbiting) to cause magnetospheres, charge pauses, etc, which may limit the amount or direction of charge that actually reaches the orbiting body.

I was suggesting that the through-charge, and the equatorial emission to a lesser extent, causes the spin of the body not its tangential motion to that which it is orbiting. It is the action upon the body, by the charge passing through it, that causes the axial rotation of that body because each individual photon has some spin.

LongtimeAirman wrote:

Nevyn wrote:Would all of the planets cause each other to move based on their charge interactions?

And gravity too. I think so – absolutely. It’s a main premise of my model. If the sun were somehow plucked from the sky, our dominant objects, the gas giants would immediately begin to re-order the system.

Yes, if we removed the sun then everything would adjust to orbit about jupiter (or possibly a jupiter and saturn binary system) but that isn't what I meant. I was thinking that an equal charge field (photons to anti-photons) would lead to no tangential forces for the orbiting bodies so they would find some equilibrium with all other bodies. This would leave them at a set distance from the central body but not circling around it.

LongtimeAirman wrote:

Nevyn wrote:The axial spin must be driven or it would soon stop.

I do not see this. Why would spin stop? Up or down photons entering their respective poles cause the same overall rotation direction. Granted, the spin is somehow tied to the energy level of the local charge field, but what determines a limit?

In a vacumm, the spin would not stop, but these bodies are not in a vacumm. They are constantly bombarded with charge from the central body and each other. This would reduce the spin component over time. Since we do not see a reduction in the spin of orbiting bodies then it must be driven by something.

LongtimeAirman wrote:

Nevyn wrote:I think the axial spin is caused by the charge flowing through the orbiting body (north/south through-charge).

I believe that the axial spin of the dominant body, our sun, is caused by charge recycling. The Earth’s axial spin depends mainly on the sun’s tangential forces.

If it causes spin on the main body then it must cause spin on orbiting bodies as well. I don't see why it would only work for the larger body but not the smaller ones.

As I understand it, Miles has suggested that the suns tangential forces (from its emission) cause the circular motion (in conjunction with gravity and charge emission pushing it away) not the axial rotation, although it may be a factor in it.

Mathis wrote:At any temperature above zero, charge will create structure, both in itself and in any material, even a gas. To start with, the gas will align its poles to the applied field, to allow for better channeling at the atomic level.

What is the mechanism that aligns the spin axis to maximize direct polar channeling? It seems to be present at all scales, from electrons to galaxies.

I'm not sure of this mechanism myself. I probably need to read this paper again and see if I still agree with my speculation.

If the tangential force is caused by an imbalance of charge to anti-charge, then the force is applied at either the top or the bottom of the orbiting body, not over its complete shell. This is not a nice clean push sideways. I think it would cause spin to a stationary orbiter. Therefore, the existing axial spin of the orbiter resists that spin and applies it as a torque to the whole body. That is, part of the force is used up working against the axial spin and the other part is allowed to express itself so the result is a sideways force.

It’s exactly what I was asking for. A differentiation along the 30N/30S lines based upon relative resistance of a pole, as opposed to the general surface of the object. Miles also said that a pole provides a natural field “resistance”, paraphrasing again.

I think that’s close, aside from the first sentence conditional - I don’t believe an imbalance of up/down photons is necessary to generate pre-m tangential accelerations to a body in orbit. Also, I guess you’re talking gyroscopic torque.

Aligning spin poles to the charge field provides minimum resistance to the charge field lines. Minimum resistance makes more physical sense to me than "allow for better channeling", even though that is the result.

Definite aha moment!

Last edited by LongtimeAirman on Fri Mar 18, 2016 10:30 pm; edited 2 times in total (Reason for editing : Cleaned up sentence begining: I think that's close; and Minimum resistance)