Possible Charged Particle Field

.
Sounds like you’ll have that machine level singing in no time Nevyn.

Each ChargePoint then works out its own axes for the velocity components that the force will be split into. One for linear velocity, which points back to the center of the sphere, and two spin components which are orthogonal to the linear velocity and each other.

The six cardinal points ( N, S, E, W, F, B ) are unique in that each point is at a radius distance from the particle’s center ( 0, 0, 0 ) along each coordinate axis ( +/-X, +/-Y, +/-Z ). I’m still not convinced that six point cardinal set is an insufficient number for charge sampling, I can see that expanding the ChargePoints class beyond the six must increase the sampling precision, and improve the particle’s responsiveness.

The only thing that bothers me in your description is knowing that every particle surface point beyond the six cardinal points will no longer align with the three axii. Even worse, there are any number of orthogonal pairs orthogonal to the line to the particle’s center. There need to be rules governing orthogonal decomposition. As you said, mistakes in rotation spin are more difficult to recognize in any expanded ChargePoints set. Building surface ChargePoints sets sounds like fun. I’ll check the sphere geometry, have you used or considered using polar coordinates? (Oh, oh, you just posted on this subject, I'll quick post this too).

My more menial efforts have been mixed. I put together a LatticeParticles function ( edgeX, edgeY, edgeZ, dX, dY, dZ ) that works much like the gridLattice function. Perfect for making simple, single type particle lattices. However, any complications - such as different particle type mixes, or setting up unique new positions or initial velocities or spins reintroduces complexity, cancelling any utility in calling the LatticeParticles function in the first place. I’ve been stuck there for hours – how to allow for small variations.

For example, in a collision scenario, the left (x=0) surface, is repositioned to the left and given a positive x velocity into the rest of the lattice. Working within the scenarios’ code, I know that once a particle’s position has been set, I can always re-set it to a new location. What I haven’t been able to do is simply move a particle. I tried adding and subtracting 3Vectors (-50,0,0) without success. Am I allowed? Should I keep trying to move the particle, or am I not allowed? I hope you don’t mind my asking.

.
Alrighty, I’ve had a chance to read and consider your plan. When you asked me to give it thought, I was convinced that projections were involved – all those sines and cosines, what an extra load. But you’re right, the charge point brings along it’s own charge point plane, equivalent to the collision plane centered on the charge point. You’re right, the way to find the components orthogonal to the normal is by subtracting the components parallel to the normal – subtracting the linear component, (just like a collision), leaving only the spin component (the angular component) remaining. Maybe your subtraction method can play a part in determining the spin components? In any case, your simplification is a perfect solution and your plan makes perfect sense.  
.

It is much easier to visualize the charge points when dealing only with the cardinal directions. I would not have found this solution without thinking along those lines. My initial solution always had them in pairs. Now I have found a way to make them isolated. They don't need an opposing charge point to figure out their own velocity changes. Each charge point only needs to know about itself.

The need for more charge points has been made clear by the stuttering that we have found. More sampling points should help with that because for any given configuration between emitter and receiver, there will be more charge points taking samples and influencing the velocity components. In reality, every point on the surface of the sphere is receiving charge, so we should attempt to get close to that. We can't really reach it because it would require infinite time to compute, but we can divide the surface up into smaller and smaller sections until we are happy with it and get decent performance.

Think of it this way, what if we treated collisions in the same way? What if we only allowed collisions at the six cardinal points? Would you expect to see realistic collisions? The code for collisions handles a collision at any point on the surface of either sphere. We need to approach that for charge but are constrained by the fact that charge effects a surface where-as a collision effects a point on the surface. Well it effects the whole sphere, but it happens at a point. We are implementing a charge field, not a collision with individual charge photons. We are trying to mimic that, but we know that we really can't.

There are going to be problems with introducing more charge points. The first one being that the amount of force is going to increase. Let's say we currently have 2 charge points receiving charge, if we introduce a new charge point between them, then we are adding more force to the resultant velocity because that new charge point is adding its little bit to it. We may need to reduce the force to accommodate that.

With respect to the gridLattice function, well done for identifying the need to make it a function so that it can be shared and getting it done. Your starting to think like a programmer. It might not seem like much, but it is an important stepping stone. You're starting to see some things in more generic terms and identifying when to use them and how.

Trying to do the same thing with the particles may not be the right way to go. Making things into functions is good, but not at the expense of functionality. Placing particles and giving them initial velocity and rotation is rather specific to each case we are creating. That doesn't mean you can't use a function, but it might make it a bit difficult at times.

I will give you some ideas on how to go about it though, and you can see if they work for you or not.

Javascript functions are just objects like any other. Most languages treat functions as a special thing. Not Javascript. They are just an object that you can invoke. As a result of this, you can pass around functions. So you have a gridLattice function that creates a grid, now you want to add particles into that grid. You can create a special function signature to do that, and pass implementations of that into your grid function.

What do I mean by a function signature? Well, the definition of a function is dictated by the arguments to that function and the return type of it. Javascript is also pretty loose with this as well and you can do some pretty cool stuff as a result of that, but what I am trying to get to is that your grid function needs to be able to call the function given to it, and to do so, it must know what arguments to give it and what output to expect from it, if any. It is the grid function that defines what those arguments are and what return type it wants.

Let's write some code to see it in action:

Code:


function gridLattice( width, height, depth, dx, dy, dz )
{
   // create lattice from arguments
}


Now we want to create a function that will create some Particle to add to the grid, as we are creating the grid. It might look like this:

Code:


function gridLattice( width, height, depth, dx, dy, dz, createParticleFct )
{
   // create lattice from arguments
   for Z ...
   {
      for Y ...
      {
         for X ...
         {
            // create some lines
            ...
            // add a Particle
            var p = createParticleFct();
            ...
         }
      }
   }
}


If you wanted all neutrons,  then we could implement a function to pass in to that function like this:

Code:


function createNeutron()
{
   var n = new Neutron();
   // maybe randomize some properties
   return n;
}


Then we would call the grid function like this:

Code:


gridLattice( 10, 5, 1, 20, 30, 10, createNeutron );


That shows you how to pass in the function and how to call it, but it isn't very useful in that case because the function is not given any information to make any decisions about what particle to return. The function signature is not good enough to support that kind of behavior. So let's give it some more information.

Code:


function gridLattice( width, height, depth, dx, dy, dz, createParticleFct )
{
   // create lattice from arguments
   for Z ...
   {
      for Y ...
      {
         for X ...
         {
            // create some lines
            ...
            // add a Particle
            var p = createParticleFct( X, Y, Z );
            ...
         }
      }
   }
}


We pass in the current X, Y and Z indexes so that the createParticleFct function knows what cell it is creating a particle for.

Code:


function createNeutronOrProton( x, y, z )
{
   var p;
   if( ( y % 2 ) == 0 ) // even rows in the Y dimension
   {
      p = new Neutron();
   }
   else
   {
      p = new Proton();
   }
   // maybe randomize some properties
   return p;
}


Of course, you can pass any information you want to into that function and use it in any way you need. You might use the X index to multiply the velocity of the particle or give them more spin. As long as the calling function (gridLattice in this case) can supply the data, you can pass it in to the given function.

This type of approach works when the index values allow you to make the decisions that you need to make. So creating particles with a velocity that is a function of the X dimension would be fine. But it doesn't work for all cases. Sometimes you just need a bit more information that the calling function can not supply, so you can do something like this:

Code:


function gridLattice( width, height, depth, dx, dy, dz, createParticleFct, globalFctArgs )
{
   // create lattice from arguments
   for Z ...
   {
      for Y ...
      {
         for X ...
         {
            // create some lines
            ...
            // add a Particle
            var p = createParticleFct( X, Y, Z, globalFctArgs );
            ...
         }
      }
   }
}


The calling function does not use the globalFctArgs data (which could be a simple value or it might be an object with much more data in it, it could even be another function if that suits your purposes), but passes it along to all invocations of the createParticleFct function so that it can use it. In this case, you might pass in the ParticleArray object that you then get a Particle from and manipulate it based on the X, Y and Z values. You can also save data back to that object (if it is an object) for other invocations to see and use. For example, suppose it was an object that contained the ParticleArray and an index into that ParticleArray. Then each invocation of the createParticleFct function would get the Particle at the current index and then increment that index value so that the next invocation gets the next Particle.

Am I going too far? It is probably best to keep it simple at this point. Creating the gridLattice function is great, since it allows many other functions to use it. However, creating and placing the Particles is probably easier to do directly in each scenario function. But by all means, have a play if you think the above method works for a given case.

Airman wrote:For example, in a collision scenario, the left (x=0) surface, is repositioned to the left and given a positive x velocity into the rest of the lattice. Working within the scenarios’ code, I know that once a particle’s position has been set, I can always re-set it to a new location. What I haven’t been able to do is simply move a particle. I tried adding and subtracting 3Vectors (-50,0,0) without success. Am I allowed? Should I keep trying to move the particle, or am I not allowed? I hope you don’t mind my asking.

I'm not sure what you mean here. What do you mean by move? Setting the location (or position as it is called in the Particle class), will move that particle. It will put it exactly at the point that you specify in the Particle.object3D.position vector.

something I found a while ago with ThreeJS, is that you should not change the position, rotation, scale or quaternion objects that are on an Object3D object. You should manipulate them instead. So you can move it like this:

Code:


particle.object3D.position.set( 10, 0, -5 );
or
particle.object3D.position.copy( myVector );
or
particle.object3D.position.add( myVector );
etc


But you should not replace that object:

Code:


particle.object3D.position = new Three.Vector3( 10, 0, -5 );


I don't know why that is, but I have had problems in the past where I was trying to replace it and everything failed.

Airman wrote:When you asked me to give it thought, I was convinced that projections were involved – all those sines and cosines, what an extra load.

Yep, I was thinking the same thing. Glad it was much easier than anticipated.

I have pushed the new implementation to GIT on the motion-engine branch. The spins are working a lot better. I think I accidentally found the cause of the stuttering too. The original charge point algorithm had some troubles with attractions, so I extracted it out and applied it separately, but only to the linear velocity. When I started thinking about this new version, I saw that I should be able to fix that and just make the force point the other way for attraction. And I was right, but I haven't completely fixed that yet, just negated it, because I have to remove all of the old code to do that. Which I am about to do.

Check out the motion-engine branch and have a look over the scenarios, especially lattice 5.

I will do some clean up and remove old code and I will be ready to merge that branch back on to master. To do that, it is best that you have any changes you want kept, pushed to GIT and wait until I have merged. Let me know when you are ready.

I have created 2 new ChargePoint configurations. The first is based on an Icosahedron and contains 12 points. This works well. The second is based on a Dodecahedron and contains 20 points. This is a bit over-powered at the moment. As I mentioned earlier, because there are more charge points, there is more force being applied.

I changed the markers to show the ChargePoints such that it handles however many of them there are. They are colored purple now as it can't differentiate based on dimension anymore.

I then created a new menu item called 'Precision' that allows you to select the desired ChargePoint configuration. It currently contains the options: Cardinal Points, Icosahedron and Dodecahedron.

.
Please don’t delay any GIT actions my account. I work in a separate folder, ready for main changes at any time. I decide how to update my working files after each Pull. Now that I think about it, after this post, I'll go back to the origin/master line and sit tight.

Looking at the latest motion-engine, I’m startled by the spiny particles – with all the additional charge point samples the particle motions are certainly more responsive.

Lattice 05. I do see something odd. While at times there seems to be less stuttering (I keep going back for half dozen bursts of scenario repeats), it’s still there, but also an apparent reason why. The neutron is interrupting it’s own spin in order to align it’s North/South axis with the N/S proton axis below. The neutron is behaving most strongly when in contact with the proton's interaction zone. Slow rotations and velocities are least affected. Once inside the proton’s emission field the neutron appears to ‘settle down’ – no more spin reversals. It almost appears as though you provided a preferential path of least resistance through the neutron that would account for the alignment. Despite the additional buoyancy, the interaction zone shouldn't provide such an abrupt change, as though the particle appeared close by. Interactions with real particles begin slowly over a greater range, instead of abruptly as through a nearby boundary layer. I'm just throwing stuff out there.

Can you add an option to save the current initial values for replay later? Or repeat play button option?

Thanks for explaining the function options – capturing all my questions and considerations, showing me more choices than I’d thought. It’ll take me some time to digest.
.

.
I forgot to mention that the icosa and dodeca particles seem to fall more directly, cleanly, along the constant y-lines.

I also had to share a thought about being able to vary the number of charge points based on the size (angular aspect) of the emitter. I realise this idea isn't feasible, we are sampling in the direction of the emitter's center, and not the particle's 'angular extent'. We can sample charge from all distant - smallest - relative single point objects - through the single cardinal point chargePoints set since charge received by objects at long distances will cancel at opposite sides of the target. The particle will know as other particles approach, as the emitter gets closer, and the cancelling diminishes due to the increasing angular aspect of the emitter, as felt by the target. More charge points are on the target will point point toward the emitter. The 'orthogonal surface area' on the target due to the emitter (smaller is further, bigger is closer) increases, to wrap around the target, in the case of very large emitters. Our equi-sized particles will to reach a maximum angle size, just before a collision. Size or proximity sampling. Monitoring the spread in angle between the chargePoints set of linear directions per emitter. Leave the Dodecas until the emitter is closer.
.

I have noticed that the attraction seems to be stronger at the outer boundary of the interaction zone, which is backwards. The stuttering happens in that outer zone and tamps down once about half way through it. I think the charge force algorithm has something wrong in it. I need to change that anyway. I will probably work on that next, I think. These recent changes help with that because I have been able to revert it back to calculating the correct charge vector without extracting the attraction/repulsion from it.

I can't explain that Y alignment. I've seen it, but can't explain it. Even when using the original 6 cardinal points it still prefers the Y and not the X or Z, even though they should be equivalent.

Airman wrote:Can you add an option to save the current initial values for replay later? Or repeat play button option?

I've often wanted something like that myself. You find an interesting interaction but can't replay it to see more detail or watch a different particle. What we need is save and load methods on a Particle which store the current state of it and load it back in. A pause feature would be good too. I thought it had one because my other apps usually use the space bar to pause/resume rendering but I tried it last night and it didn't work. I'm pretty sure the code is still in there, but the key mapping has not been setup to use it.

Airman wrote:I also had to share a thought about being able to vary the number of charge points based on the size (angular aspect) of the emitter.

This idea is like mipmaps, which are used to change the geometry and materials used by an object based on the distance to the camera. The closer it is, the more quality it has. However, I don't think this is feasible for an interaction because it would need to calculate the distance from each particle that it interacts with. Possible, and not even expensive, but I don't think that it is worth it. I haven't noticed any slowing down as a result of using more charge points, so far. I think it will just make it more confusing since you would have to know how many charge points are in use for a particular pair of interacting particles to figure out any problems with it.

I will create one more ChargePoint configuration which will be very flexible. It will be based on the THREE.SphereGeometry class I mentioned earlier. Well, not based on the class itself but the way that it generates the points for a sphere. Basically you provide the number of divisions in longitude and latitude. This is converted into an angle for each direction. Those angles are then used to calculate the locations of the ChargePoints. It is close to the concept of a Hosohedron. Think of a beach-ball where the lines go from pole to pole.

There are problems with this approach. There is always 1 point at the top (Y axis) and one at the bottom, but the X and Z dimensions are very different. This creates an unbalanced sphere. If we were using this now, then it might help explain the attraction of the Y dimension noted above. I still think it is worth implementing though. The differences between dimensions may not be as much of a problem as they look. If nothing else, it will allow us to see where the boundary is for the number of charge points. That boundary is the point where it becomes too much to calculate. Of course, that is dependent on the system running the app, not some absolute value, but we should be able to find a nice compromise.

The icosahedron and dodecahedron are very well balanced. If the particles didn't have the wireframe mesh over them, it would be difficult to tell where the top of the sphere is. The icosahedron seems to be the nice compromise at the moment. When I looked at the shape of it, I didn't think it would work very well because it doesn't look that balanced (in some regards) but it worked well. I actually wasn't even thinking about icosahedrons, I went looking for some old code I had in Java that created a dodecahedron, but it turns out that I didn't implement a dodecahedron but did implement the icosahedron. So I took it and then implemented the dodecahedron as well since they are actually pretty similar in how you create them.

I am interested in finding some other shapes like them. Feel free to look over some yourself (or anyone else) and make recommendations. The important thing to look for is equal distances between points. It would be really good to find one that still has the cardinal points, but with more in between them. I think an octohedron might be useful but haven't looked too closely at it.

I have merged the branch back onto master and also updated the version on my site for everyone else to play with.

https://www.nevyns-lab.com/mathis/app/cpim/test.html

Added the Hosohedron ChargePoint configuration. Added 3 new choices in the Precision menu that use a different number of divisions to break up the sphere: 8, 16 and 32. 32 ChargePoints per Particle is a lot of calculations and if you load up the Lattice 02 scenario you will get slow-down.

I also implemented a way to reduce the calculated charge forces based on the number of ChargePoints being used (actually, only half of them because only 1 half receives charge from any given interaction). This should bring all of the different precision options to a common ground and remain comparable.

Sorry, I misspoke. It is not 32 ChargePoints per particle, it is 32 divisions in 2 dimensions, so somewhere near 32^2 = 1024 ChargePoints per Particle. A bit over-the-top.

Added a menu item to restart the model with the original settings.

.
I’ve been playing with CPIM for over an hour, the fact that anyone can do the same and judge for themselves is a fine testament, you do good work.

The reset button works better than I’d hoped, resetting the scenario from the viewer’s last viewing location for a new perspective of the same event is a definite improvement.

I’m surprised at the variations in particle behavior with the different chargePoints sets. Now we need a control panel button to turn off the charge point markers.

I’ll look at the chargePoints configurations today, but I want to come up with an expanded lattice 05. You had requested better control of neutron particle orientations when entering the Interaction Zone, I’ll try to do that, and maybe also add some off-proton center negative-y neutron collision velocities.
.

.
Given your implementation of spherical geometry, the new charge point markers strongly suggest scenarios that resemble those markers.

I'll try to match the method you used for constructing them, so I'll study that first.

Anyone is free to make requests, comment, or add to the discussion.

Implosion. Start with a proton at ( 0, 0, 0 ). A ridiculously high number of neutrons are placed in a dandelion configuration at some distance around the proton. All neutrons are given collision velocities toward the proton .

Given that configuration, one can greatly vary the outcomes with initial proton variations; such as moving the proton a radius distance from ( 0, 0, 0 ).
.

LongtimeAirman wrote:The reset button works better than I’d hoped, resetting the scenario from the viewer’s last viewing location for a new perspective of the same event is a definite improvement.

That actually wasn't planned, but a welcome oversight. I often look at Lattice 05 and sometimes move the camera down to look from the side and it was a pain if I wanted to restart and it would reset the viewing position. But I still didn't think of doing that when I implemented the restart function, I just forgot all about the camera and only saved the state of all Particles. Sometimes less is more!

LongtimeAirman wrote:Given your implementation of spherical geometry, the new charge point markers strongly suggest scenarios that resemble those markers.

That's a good idea. Place some neutrons at equal distances from the central proton, but make sure they are within interaction distance, and see how the charge field effects them all. It should show the gradient of the charge field (from equator to pole) and might help us to see if something is wrong with it. It would work better if we had some smaller particles. You won't be able to get many neutrons around a proton. Maybe it is time to formalize the radius of a Particle (and mass) rather than using constants. Then we can look into implementing electrons but I also want some particles in between that and the proton/neutron for these kind of testing procedures.

I will add in a GravityForce class, but not an algorithm for it, and hook it up so that it will work once implemented. You can have a play with it if you want. I'll be working on the charge force calculations which will require a bit of theory before I can get into the code for it. Most of it has been worked out (see previous posts) but the actual charge calculation still needs work.

I have some pretty big changes for you. Firstly, I created a new sub-class of Force called GravityForce and plugged it in to the ChargePointMotionEngine class so it is ready to be implemented. Secondly, I started to give each Particle its own radius and mass properties and this led to a huge refactoring of the code.

Instead of just having the Particle class, I made Particle abstract and created a few sub-classes. Directly from Particle we have Neutron and ChargedParticle. Descending from ChargedParticle we have Proton. ChargedParticle is abstract but takes care of setting up and maintaining the charge field shaders. So you don't create Particle objects anymore, you create a Proton or Neutron. This led to...

... the ParticleArray class being changed because I had to give the caller the power to create their own particle objects. I never liked the way that worked anyway, it was just a hack to get something else working and I never fixed it because it meant changing so many other things. But now I had to fix it, which led to...

... the calling code in test.html. All of those scenarios needed to be dramatically changed. It took a while, but I got them all working again.

.
Nevyn, well done, you’ve been very busy – making many changes. Take a break!



Six neutrons headed toward a proton. I had to Push something to make it seem like I'm keeping up. As promised – for starters, a new configuration resembling the cardinal points. Six neutrons, at a distance: above, below, left, right, behind and in front of a proton positioned at 0, 0, 0. The neutrons are moving toward the proton at a small velocity, with proper orientations and spins. This new view is intended to show the extent of the proton’s emission field (in those 6 directions) while exhibiting spin reversal problems.

Of course, we don’t necessarily need to create new scenarios in order to study problems, although we are looking for fresh insights. The Restart button allows us to zero-in and study any problems we may happen to notice. One slight limitation, restarts don't necessarily repeat the collision error - overlapping particles.

For example, the spin reversal problems in latticeBody04. View the three left-most neutron/proton pairs from a negative x direction. Of course we noticed the problem earlier, it was the reason for making lattice 05. Given the new charge point particles, the problem appears slightly different. Those three left edge neutrons spin about their y, z and x-axes (respectively, from the left), all exhibit the same two spin reversal spin problems – inversely. 1. Isolated single spin reversals or 2. Constant rotational bouncing between two close angular positions about the particle’s spin axis. The effect is least present using cardinal points, when the y-axis spinner may only reverse spins once (twice or thrice), while the neutrons spinning about the z and x-axes exhibit constant spin jitters. Using icosa - hosos charge points sets – we have a reversal of problems, the back left neutron has y-axis jitters, but the other two left side z and x spinning neutrons may reverse their spins just once or twice.

By the way, my wife thanks you for keeping me busy, she thinks it’s all very interesting.
.

Airman wrote:One slight limitation, restarts don't necessarily repeat the collision error - overlapping particles.

That is because it is not just a function of the starting conditions, it is also a function of the time between frames, which is some-what random. It converges to an average of 1/60th of a second (assuming you are reaching that frame rate), but there are always little differences between actual frames. This is caused by what your computer is doing at the same time, and is out of our control as far as programming goes. There's just nothing you can do about it. I believe that a large part of those collision problems are caused by velocities that are too large. It can still happen even with small velocities, but I don't tend to see it when the velocity is only dictated by the other forces in the model.

What I think is happening is that the velocity is so large that the particles slightly pass each other during the frame transition. The collision is calculated and they move back a bit, but not enough to not overlap. So they are basically in the same position, but from opposite sides, as they were in the last collision and they just rock back and forth until they gain enough extra velocity to actual fly apart.

Airman wrote:By the way, my wife thanks you for keeping me busy, she thinks it’s all very interesting.

My pleasure. Let her know that if she wants you back then I'll come up with an excuse for why you can't work on it for a few days.

.
Thanks Nevyn, we’ll be happy to take you up on that offer in a few weeks. Till then, chive on.

6Neutrons configuration. I added lines and made a spin direction correction - unless of course I’m setting them all up incorrectly: by looking at three CW particle rotations, from +X, +Y, and +Z and looking toward 0, 0, 0; and 3 CCW rotations from the -X, -Y, and -Z directions while looking toward 0, 0, 0. I’ll wait till I make more progress before I make another change before I Push again.


I’m in the middle of the icosa configuration – quite a bit more difficult than cardinal points.

I especially like this code line -

Code:

v.set( -1, t, 0 ).normalize().multiplyScalar( s );

I’ll see if it also applies to positions.

If you don't mind my asking - Have you had any CPIM hits at the Lab?
.

I don't have tracking on that page, since it is still in development. You can't find it on my site either, you have to know where it is and this forum is the only place you can find that URL.

Code:


v.set( -1, t, 0 ).normalize().multiplyScalar( s );


Yes, v is just a standard THREE.Vector3, and those methods are available. This is a good way to create a new vector that is the same direction as another. You set it, this is setting the values directly but you could also use the copy( vector ) method, and then normalize so that the length of the new version is equal to 1, then you just multiply it by the length that you want.

In this case, I think that s = 1, so the multiplication is unnecessary, but it will become necessary when we have different sized particles. I actually added that for a different reason. The coordinates to create a dodecahedron will produce a sphere with a radius of sqrt( 3 ). I wanted a radius of 1, so I multiplied the resultant vector by 1/sqrt(3). Then I realised that I was normalizing, so it already had a length of 1 before the multiplication. I thought the code would be useful later on, so I left it in.

That line also highlights what is called 'Function Chaining'. Not all functions can do this, but a lot of programmers setup their functions with this in mind these days. I'm a bit mixed on it, to be honest, it can make the code more streamlined, but it can also make it a real pain to debug.

So what is Function Chaining and how does one do it?  You can only use this if the function does not return a value already. You can only use it on methods of a class. Normal functions can not be chained (in this way, at least) because they don't have anything to chain them together. It is the object that is being chained, really, not the functions. Let's look at an example:

Code:


module.Vector3 = function()
{
  this.x = 0;
  this.y = 0;
  this.z = 0;
};

module.Vector3.prototype = ...

module.Vector3.prototype.set = function( x, y, z )
{
  this.x = x;
  this.y = y;
  this.z = z;
};

module.Vector3.prototype.multiplyScalar = function( k )
{
  this.x *= k;
  this.y *= k;
  this.z *= k;
};


That is a basic Vector3 class but it does not use Function Chaining. To use that, we would need to invoke each method individually, like this:

Code:


var v = new module.Vector3();
v.set( 3, 2, 1 );
v.multiplyScalar( 5 );


To implement Function Chaining we just make the methods return this (the object that is invoking the function).

Code:


module.Vector3 = function()
{
  this.x = 0;
  this.y = 0;
  this.z = 0;
};

module.Vector3.prototype = ...

module.Vector3.prototype.set = function( x, y, z )
{
  this.x = x;
  this.y = y;
  this.z = z;
  return this;
};

module.Vector3.prototype.multiplyScalar = function( k )
{
  this.x *= k;
  this.y *= k;
  this.z *= k;
  return this;
};


Since each function now returns the calling object, which is the same object called v in the above example, you can just call another function on that object.

Code:


var v = new module.Vector3();
v.set( 3, 2, 1 ).multiplyScalar( 5 );


We can even put that all into 1 line like this:

Code:


var v = new module.Vector3().set( 3, 2, 1 ).multiplyScalar( 5 );


The functions are evaluated from left to right. So the first thing is the call to the Vector3 constructor. This obviously returns the new object. Then, on that object, we call the set method, which also returns the same object, so we call the multiplyScalar method. Since this also returns the object, it is then stored in the variable called v.

So what is the problem with Function Chaining? When you use a Debugger, you step through the code one instruction at a time. You can think of it as a video that you pause and then advance frame by frame. So what happens when you come to that line and want to step into the multiplyScalar method? When you press the Step Into button of the debugger, it will step into the next function invoked, which is the constructor. That's not what you wanted though, so you step out of that function and press Step Into again and this time it goes into the set method, which you also didn't want. Finally, after stepping out of the set method, you can actually step into the function you want. If each function call was on a line of its own and only made through a reference to the object (v), then you could just step into the function you actually want to step into. It might not sound like much of a problem, but when working on a particularly nasty piece of code and struggling to get it working, you might be stepping through it a lot.

This just keeps getting cooler and cooler as you guys get further in! I can't keep up with the code at all, but it's driven me in my other direction a bit harder myself, towards actually scripting stacked spins instead of just animating them. Hopefully I can make some progress and share some results soon there too.

I'm curious about the spikes though - they look great and can be a useful tool I'll likely import to my video style if that's okay. But could they be made to match the charge profiles of the proton and neutron? I don't know much about that. It looks like they're pretty uniform currently.

Also, what about transparency in the shaders? Would it be useful or possibly to turn the charge transparency down a bit, say 75% or something, as a visual reference? To emulate the field instead of implying (perhaps) discrete particles? Just an idea!

Hi Jared. Of course we can dial down the emissions effect in the code – have you seen it? I usually do so in order to decrease a gif size. The spikes mark the particle charge point locations, I would turn them off, but since they are a precision reminder, I leave them alone. I object to the idea of leaving them on for appearances sake, making what appears to be a spiny particle; unless there’s a good reason, view particles without the spikes.  

Nevyn, thanks for the programming lessons. I could see that code line combining three actions, I'll be very careful using it.

 
Sorry, I have a small problem. I noticed you had made changes about three hours ago, so I collected my changes - mainly adding an icosa configuration - and committed them without a push. I then pulled your changes and they appeared as a branch. I tried to push my changes but get errors. BitBucket does Not show my commit or push. I’ve got my changes copied so I’ll try backing out if that’s what you suggest I should do.  

Reopening Sourcetree I see the graph has changed slightly, the uncommitted changes are yours(?). I'll wait for directions.
.

That looks really bad, but it isn't. I freaked out the first time I did this but it should be easy to fix. It has not created a branch. It looks like it, but it isn't.

What the graph is telling you is that there are 2 commits (1 mine, 1 yours) that are out of order. You had made a commit, but not a push, and that is represented by the blue line. But the GIT server has my commit, which was pushed, and that is showing as the red line. My commit happened before yours did, so the red dot is lower than the blue dot.

To fix this, you just need to pull my commit, but when you do a dialog box with show up on screen and it has several checkboxes on it. The bottom one says 'Rebase instead of merge'. Check that and then press the OK button.



That should pull down my commit and then rebase yours on top of it. Effectively slotting my commit in between your last 2.

If that doesn't clean it up, let me know.

This is why it is a good idea to do a Fetch before you commit. That will show you what is on the GIT server but won't actually Pull them down. Then you can decide if you want to pull them down or not (but you usually should, I can't think of any reason not too, but there might be one).

.
No Joy.
Requesting a pull from your line, with the 'Rebase instead of merge' checkbox checked, I received the following error.

The graph is unchanged.
.

You may need to Abort the Rebase before you do anything else. Go to the Action menu and near the bottom there is an item to Abort rebase, if that is enabled (not grayed out) then select it and let it do its thing. This should put you back to where you were before that pull and rebase.

The error has occurred because you still have changes that are not committed. Either commit them (but don't push) or stash them (this removes them from the files but you can add them back when you want to). Then try to pull and rebase again.

.
'Abort the Rebase' is greyed out, and not a option.

I haven't made any additional changes that I'm aware of. The uncommitted changes at the top seem to refer to your octahedron changes, not mine.
.

Nah, it definitely refers to your changes. Click on the Unsaved changes item in the graph to see if there are any. If so, then stash them (or deal with them however you want) and try the Pull and rebase again.

If all else fails, you can always clone from GIT again.

.
Thanks again Nevyn, I re-cloned, committed and pushed my changes. I must learn to do a better job with Git, I'll try a few tutorials.  

Jared, Sorry to step on your post and cause a ruckus.  
.

Cool. That is often the easiest way to get out of a bind.

I just wanted to mention that I don't want you to feel obligated to work on this app. You can take a break any time you want. Sometimes I just don't feel like working on my apps, so I don't. If I feel like watching a movie, but know that I should be fixing some bug, then I'll just watch a movie and maybe get to that bug afterwords, or maybe not at all. I might not get back to it for a week or more, sometimes months. We don't have any deadlines or any pressure that we don't put on ourselves. I certainly don't want to put any pressure on anyone. If you have the desire to work on it, then go ahead, but if you don't, then don't force it. We'll get it done eventually. No rush.

.
Aside from a few small embarrassments like today, everything's great, thank you very much. Knowing one can re-clone is a real relief, but it's also a pretty crude tool to rely on.

This project is perfect, something I've always wanted. I intend to devote a great deal of time to it in the future - but you're the boss. I'm extremely happy to be working with you, but at present I'm a bit of a burden, a cross between Sancho Panza and the Sorcerer's apprentice (Mickey Mouse). Eventually I'll get out of the learning mode and make some real contributions.
.

Found a bug in the charge force calculations that caused some serious issues. Nothing has been working very well since the start and I was dismissing it as equatorial interactions when an attracted particle got close. Turns out it was just crappy math.

.
Correcting bad math is good progress. Can't wait to see it.

I received a new Windows 10 update last night and nothing is working well. I was ready to commit my own changes (I'm still on the icosa but I'd like to cover all the configurations before playing with gravity), checked BitBucket and found you had changed -1 back to 1. I committed my changes without a push. I tried Fetching and Pulling for minutes on end with no outcome. Ok, something new, I'm receiving an atlassian log-in request every minute I'm in Scourcetree, I may need to go back to them for another bug fix.

Now I'm taking a break.
.

I have added the ability to stop a Particle from moving and/or spinning. This allows you to remove one of them to focus on the other. You can set it on a per particle basis. There are some new scenarios that make use of it by stopping the neutrons from moving so that we can see the spin effects from the charge emission of a proton.

It sounds like you need to reset your credentials in SourceTree. Goto the Tool menu, select Options and then click on the Authentication tab. From there you can edit your account or remove some saved passwords. If you edit the account don't change anything except for the password. The rest has been working so it should not need to be changed.

.
The Good/Bad Status Update.

Good Status. Thanks. My SourceTree (Bitbucket) is working again. I checked the SourceTree Authentication tab - it was empty. There were no Bitbucket credentials in my Windows Credential Manager either (a previous problem). I cleared the desktop of everything except SourceTree, did a Fetch, caught and replied to the first Atlassian log-in request. I think I’m back to normal.

Bad Status. We have a conflict. My next step would be to pull your changes – carefully unselecting the ‘commit merged changes immediately’ option, followed by a Push. I haven’t tried it yet, because I don’t think it would be pretty. I noticed your latest change is adding the new Scenario group Unmoveable, beginning at line 356 in Test.html. In my commit I’ve added the function drawIcosaSurface at the same location. If I Pull your changes now, then I will need to resolve the conflict. Unless I'm mistaken, I believe that involves a Source Tree resolution tool, something new. Or I can re-clone again, and Commit my changes to Test.html when Unmoveable is already in Test, with no conflict.  

Thanks for your continued attention and patience. I’ll await your direction.
.

A merge conflict can be difficult to fix. It can be very easy too, and it should be in this case, but it will be made difficult because I can't see anything.

What you need is an application that shows you the differences between 2 files and allows you to select what you want to merge. The one I use at work is a professional product and so it costs money. There are free ones available though. I have asked around the office and you can try to use one called KDiff3 (http://kdiff3.sourceforge.net/). You have to tell SourceTree to use it. Open the Action menu, select Options and go to the Diff tab. On there you will see the lower section called 'External Diff / Merge'. On that part, there is an option to select an 'External Diff Tool'. Drop that down and select KDiff3. I'm not sure what else you will need to do. Maybe tell it where the executable is or it might be able to figure that out on its own.




Once that is done, you can right-click on files that have a merge conflict and hover over 'Resolve Conflicts' and then select 'Launch External Merge Tool'. This will open up KDiff3 with the 2 files.

KDiff3 will present you with 3 panes. The right and left panes will contain the 2 files (which one is which I don't know, you should be able to figure that out by looking at the content of them as one will contain my changes and one will contain yours). The center pane is where you merge things together. You can select the sections that are different in the 2 files and move them into the center version. In this case, you want both of our changes. Once you have the center file looking correct, save it and close KDiff3. Then SourceTree will pick up the changes and you should be able to continue with the merge (Action menu). If not, you might need to select the file, right-click, hover over 'Resolve Conflict' and then select 'Mark Resolved'. Then continue with the merge.

Alternatively, you could create a new branch and commit your stuff to that and then create a Pull Request so that I can merge them together. I think you can only create a Pull Request from the BitBucket website. If you can't see where to do that, then just let me know and I will merge them without it. A Pull Request is just a formal way of asking someone to merge your work. Since it is just the 2 of us, we can forego the formality.

I think I have misunderstood. I thought you had pulled my changes, but on a re-read of your post above, it doesn't seem like you have. In that case, this isn't really a problem. You should be able to Pull with the rebase option checked (if your changes have been committed but not pushed). Don't worry about line numbers. The apps work all that out by comparing content, not lines. It should be able to figure out how to put those 2 together because we have not changed the same section of that file. In fact, we have added new content rather than change existing code. Things get difficult when we both change the same thing. Then you, or I, have to decide which one to keep or which parts of each to keep.

.

Alternatively, you could create a new branch and commit your stuff to that and then create a Pull Request so that I can merge them together…

What can I say? if there’s a way to screw something up, I will. Starting with the fact that I missed your most recent excellent direction, 'pull with a rebase'.

Insead, I put myself on the commit and made it into a branch, origin/featureIcosaSurface. I went to Bitbucket and made a pull request for the branch - I hope it went to you. I went back to sourcetree and tried to reposition myself at origin/master at the top and found I was merging my new "branch" and your subsequent work. Luckily, just this morning I had downloaded and viewed a couple of kdiff3 tutorials. You'll be happy to hear I was able to resolve the conflicts, as you said, our work was separate content. Unfortunately, no joy; Pulls and Pushes resulted in errors. Now I’m a push and 6 pulls behind, realizing that the feature is now the master. My head is lost somewhere.


The status looks grim. I think I need a detailed map with instructions on how to get out.
.

.

If it's any help, here are the staged files. I understand that I would delete the orig file.
.

I can't see why you have 1 push. The branch starts from the 'Corrected phi calculation' commit, which I pulled a few days ago. All commits on the blue branch (master) are mine and make up the 6 pulls. I can't see anything for you to push. I am a bit concerned about the top red commit, which has a tag for master on it. I guess that is the 1 push, but that should be on a new branch (which the other 2 tags show). I got 2 emails this morning: one for a commit and another for a pull request. I'll have a look tonight and see if I can merge them together.

By the way, you forgot to add a / to the branch name in between 'feature' and 'icosahedraSurface' so it became one word. No big deal. I will try to merge these branches such that that branch will disappear (unlike how I merged my previous branch which kept it as part of the history). It doesn't matter either way, but this is more of an accidental branch rather than a separate piece of work.

I have fixed up that merge conflict and put your changes on to master. Everything seems to be working, but check your stuff in case I missed something.

KDiff3 was a bit different to what I am used to. I might try another one if I need a merge tool again.

.
Current status. Hallelujah. Thank you Nevyn. Given my previous standing of one Push, 6 Pulls, and two uncommitted files (the products of my kdiff3 conflict resolution) – I re-cloned. One small problem (?), it appears the origin/featureIcosahedraSurface is the current main branch.


Should I try to delete the branch - featureIcosahedraSurface branch; or leave it alone?

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

There was mention of a charge interaction math correction. I delayed posting until I had something better to discuss, happy to review the scenarios.

There are significant changes visible in LatticeBodies 02, 04, and 05. I described the 3 vertical neutron proton pairs on the left edge of lattice 04 recently. The neutrons above those protons are given initial spins but not an initial velocity. Now, as before, the neutrons begin to approach the protons’ north poles in a downward z direction. There’s no change in the neutron’s x, y, and z spin reversal errors: single changes, or bouncing between spin angles while the neutrons descend. Something new, the protons’ emissions do not stop the neutrons from colliding into the protons. Half the lattice’s particles exit, stage down. Lattice 05 also blows out the bottom. Lattice 02 now makes a more vertical blast pattern.
 
Unmoveables. You create particle arrays so neatly, in three lines given initSpinTest - more to study. I see that you didn’t add the Unmoveables to the default list //initFct = Scenarios, was that intentional?

Unmoveable 01. A proton at (0,0,0) and unmoveable neutron at (5,0,0). I saw no neutron motion.


Unmoveable 02. After having looked at the three unmoveable scenarios: arrange about Y, Z, and X; this scenario makes better sense, it's shown above. Three neutrons in near equatorial positions, spinning in response to the uneven charge they receive due to their latitude positions – very difficult to achieve. The emission strength is off course highest at the equator. The emission field strength felt by the neutrons at lattitudes above or below the equator will fall off at some rate. That difference in field strength received should cause the unmoveable neutrons to spin. Unfortunately, we will note that using a fixed number of charge point samples involves a mathematical certainty, sampling can cause undesirable side effects and/or artifacts. As I understand it, the higher precision particles were created specifically to minimize such artifacts.

Unmoveable, arrange about Y. A proton at (0, 0, 0) is surrounded in the Y plane by a ring of 16 unmoveable neutrons 5 units away. The neutrons are within the proton’s emission field; the neutrons start rocking, then tumbling. The tumbling looks quite natural.

With CP precision selected, every other neutron in the ring: front, back, left, right and the four positions directly between them remain stationary - they do not react to the emission field. With CP precision selected, the stationary neutrons are receiving ‘balanced’ charge. The other neutrons are spinning in reaction to the spin imbalance caused by the particle’s precision selected. Since none of the unmoveable neutrons can be pushed out of their positions, I would expect all the neutrons would remain stationary until small differences begin to accrue to new stable positions at varied spin angles, or slow random spins. After a while, more than a minute or two, the neutrons begins experiencing spin reversals - bouncing between spin positions. The reversals last for a while, then stop as the neutrons resume their natural looking tumbling. Infrequent, intermittent spin reversal errors.

With Icosa precision selected, only the four particles in the F,B, L, R positions remain stationary. After some time, the tumbling icosa particles also display intermittent spin reversal errors. With the other higher precision selected, the particles’ spin motions appear lifelike. The same intermittent spin reversal errors are present, although they are harder to see.

Unmoveable, arrange about Z. 16 neutrons in a z-plane ring (16 at the top) around the proton at ( 0, 0, 0 ). With CP selected– Above (16 ), right (4), below(, and left (12), positions remain stationary. The 4 particles directly between them (2, 6, 10, 14) move very slowly, even stopping in new positions for long periods of time – just what I would expect.

On the other hand, why would particles 2,6,10,14 move very slowly or not at all? Also, positions: 1, 3, 5, … , 13, 15 all spin at the pretty much the same rate, that doesn’t seem to make sense, so I check the charge density values.
CHARGE_DENSITY = [100, 90, 75, 50, 30, 10, 5, 2, -5, -15, -30];
I believe the charge density shown is a vertical (latitude) profile. The pole emission value of -30 is a third the magnitude of the equator’s 100. The greatest differential (-30)-(-15) = -15 occurs near the pole, so that complicates things like a faster spin near the pole. I would expect to see particles 1,7,9,15 (near the pole) spin at one rate while particles 3,5,11,13 (near the equator) will spin at a higher rate, but I’m not certain. Or that particles 2,6,10,14 would move more vigorously, not less. That logic makes me believe the neutrons are not properly representing the vertical profile you’ve created.

Unmoveable, arrange about X. Same as Z. 1,3,5,7,9,11,13,15 appear to me to be spinning at the same basic rate (I’ll experiment with those values later); 2,6,10,14 are spinning more slowly, or stationary at new spin positions; 4,8,12,and 16 are perfectly stationary. The higher precision particles are the most responsive.

Those negative charge field values could use some discussion. If I understand things, the particle's emission profile needs tweeking. Aside from the infrequent intermittent spin reversals, the motions look good. Any agreement? Or am I seeing things?

P.S. I received notification of the completed Pull request yesterday, but didn't notice it till just an hour ago.
.

SourceTree looks correct to me. The tags are just saying that the featureIcosahedraSurface branch is at the same position as master, which is just what we should expect from a merge of those two branches. Yes, you can delete that branch. It is not needed anymore. I'm not sure if I deleted it from GIT (which would be under the REMOTES section of the left hand panel, the BRANCHES section represents only the branches that you have checked out). If you don't want it anymore, then it can be deleted from both. Everything is on master now, so there is no danger in deleting them.

Airman wrote:You create particle arrays so neatly, in three lines given initSpinTest - more to study.

Definitely look over initSpinTest, which is the guts of setting up these scenarios. It takes advantage of the ThreeJS classes that we are working with to place all of the particles. Essentially, it creates a Vector3 to represent the first position (this can be anywhere on the circle that it creates, but it is easiest to put it on 1 dimension only) and then creates a Quaternion that is a rotation about the axis we want the circle to be around. Then, for each Particle to be created, it sets the position using the current value in the Vector3 and then rotates that vector to the next position. Simple and effective.

What that function doesn't do, by design, is change the orientation of those Particles so that they point towards the center. I didn't want that for these tests, but it would be good to create another version that does. It isn't quite as simple as rotating a vector, but pretty close. Give it a try if you want to.

Airman wrote:Something new, the protons’ emissions do not stop the neutrons from colliding into the protons.

Yes, that was the problem that I fixed and had previously thought was the protons equatorial emission pushing the particle away once it got close. Now the attraction holds right up to the collision. It has broken a few scenarios, or at least, they don't behave the same way they did before. Broken is probably not the right word, but it is what I thought when I ran over all of the scenarios for testing and saw that a lot of them don't work the way we are used to. Sometimes, we have to change our expectations and not fall into the trap that it must look the way it did when we created the scenarios. It can be a difficult thing to do sometimes.

Airman wrote:I see that you didn’t add the Unmoveables to the default list //initFct = Scenarios, was that intentional?

A bit of both, really. I did see all of those commented out functions to set the initial one to be used, and wondered if I would bother adding the new ones to it and was leaning towards not doing so. In the end, I just forgot about it. Now that we have the menu, those lines are not really needed anymore.

Airman wrote:Unmoveable 01. A proton at (0,0,0) and unmoveable neutron at (5,0,0). I saw no neutron motion.

That is the intended outcome. Since the neutron is right on the equator of the proton, it should receive equal amounts of charge on both sides which cancel each other out.

The rest of the scenarios currently show problems. Not in the scenarios themselves, but in the way the neutrons react to the protons charge field. I think you have covered it quite well. I placed neutrons just above the equator line expecting them to keep gaining spin, but they don't. There are still problems in the spin algorithms and these tests were designed to help see what that might be. I haven't spent anymore time with it though.

For a bit of fun, temporarily change those neutrons into protons and watch how they all push on the center proton.

Yes, the charge density values can certainly be discussed. I played with them a bit after creating these new scenarios and ended up with the reduced attraction that you have shown above. I even tried removing the attraction as I think that is part of the problems that we are trying to fix.

It has pushed me towards the idea of creating a new Force to represent the ambient charge field. I am thinking that it will create some virtual boundary that represents the volume of space around a particle that ambient charge can come from. For all other particles that are within that boundary, it will calculate how much of that boundary they block and create a vector to represent that. The vector will be the opposite of what the ambient field would do, that is, it will point outwards, not inwards, because the ambient field represents a constant force from all directions. Other particles block that, so it is the same as an attraction towards those particles that is equal and opposite to the force of the ambient field.

It also shows the need for gravity. I will be very happy to remove those attractions from the charge density array once we can do so.

CHARGE_DENSITY = [100, 90, 75, 50, 30, 10, 5, 2, -5, -15, -30];

Something else I did was to reduce the number of items that represent an attraction. This pushes the change-over point from equatorial emission to polar attraction further towards the poles.

There are 11 items in the array and only 3 of them represent an attraction, therefore, the polar attractions only represent 11/3 of the 90° angle between equator and pole.

I also removed the 0 sections. There used to be a small section between equator and pole that had no repulsion or attraction. I was trying to get the repulsion back when the attracted particles gets close, but it was a lost cause.

Before we get too far into a discussion about that charge density array, I probably should mention that I am trying to get rid of it. I want an equation that does the same job and I think I have found some good leads for finding one. However, a discussion would still be good, because I need to find the right equation and it might help me to see what it needs to do a bit better.

How would we find the correct equation for that? Ideally, we would pull it out of some sort of experiment, something like a scattering experiment. It might be worth looking over Miles papers on scattering and any others we might be able to find from the mainstream to get a feel for what the charge profile might look like and what equations are being used to describe them.

...about that charge density array ...

Nevyn, I just saw your comment. Here's my quick reply.
The maximum emissions in our charge profile currently occur at the equator, that's a mistake.

These pictures show that maximum missions occur at +/30. That's the profile we should match.
When there are two profile peaks instead of one, there is a stable region between the two peaks - like the rings of Saturn. That's something I had to immediately throw out there.

Ambient space will be comprised of particles and antiparticles. Does our space include antiparticles?
.

I did model that +-30° at first, but soon dropped it because we are dealing with particles, not composite bodies. When moving through a planet, charge has time to create the profile you see above. It is caused by lots and lots of collisions. But a particle doesn't have any of that. It has 1 collision to redirect an incoming charge photon, so there is no time and no reason for it to create the +-30° peaks. Those charge profiles are created by streams of particles, not single photons like we have.

However, I have an abstract class called ChargeProfile, with one sub-class called SimpleChargeProfile (that I want to change the name of to reflect that it is a charged particle profile). So we can create multiple ChargeProfile implementations to reflect different scenarios. I don't want +-30° peaks for a particle, but I do for a planet, so we create a version for planets and moons and stars, etc (composite bodies).

No, we don't have anti-particles because we don't have any spin on the charge photons. The code can support spin from charge, but it isn't being used right now.

.
I apologize for many typos.

I would hope this sim could demonstrate orbital behavior, aka the relationship between charge and gravity. I know that gravity operates over vast distances, that is, with respect to the size of the particle. Maybe the sim can provide better understanding. In my opinion, equatorial emissions wreck orbits. Your explanation "1 collision to redirect an incoming charge photon" doesn't necessarily suggest that the resulting  emissions are primarily equatorial. It seems to me that single collision, redirected matter, is more likely redirected from somewhere between the pole and the equator, when arriving from above or below, similar to the +/- 30 deg lats. You may say particulate matter doesn't orbit or that gravity is useless at the Particulate matter level. What a killjoy.

Thanks for the +/- charge profile alternative - for the sake of a general class.

I looked at the the rest of the scenarios. Not to inventory them, I was mainly looking for changes and to re-familiarize myself with them. I'll be starting on the dodecahedron configuration next. 

Two body 02, two protons with an initial vertical separation of 10. This is included as the gold standard. The 2 protons can bounce every ten seconds for several minutes without errors.

Two body 02-s1 and Two body 02-s2 are not stable. After a single collision, the two vertical (and y-spinning) protons cannot maintain their common spin axes. The top neutron goes through series of constant spin reversal errors which make these two scenarios difficult to watch.

Two body 03. Two protons with an initial vertical separation of 10, the bottom proton is rotated 90 degrees about the x-axis. I don’t recall the bottom proton also picking up an x-spin before.

Two body 03-s1. Same as 03, but the the bottom proton has a y-spin. This scenario seems to run the same as previously. As in 02-s1 and 02-s2 the top neutron goes through series of constant spin reversal errors.

Three body 01, and Three body 02, three protons in a column, with slightly different yet similar symmetrical spacing are both broken as with Proton Stack 03 below.  

Three body 03, protons above and below, with a neutron in the middle – closer to the top proton. The neutron gently collides with the top neutron, and then follows the proton off the top

Three body 04, and Three body 04-02 Two protons, above and below an offset neutron. The neutron begins by moving more in line with the proton poles. Interesting collision variations, including vertigo - It doesn’t last long,

Three body 05, top and bottom protons, a middle neutron is given a horizontal offset, and Three body 06, top and bottom neutrons, a middle proton is given a horizontal offset. Both scenarios are changed, but don’t seem broken.

Four Body 01-04 are all interesting.

Proton Stack 03 - three protons in a vertical column, is definitely ‘broken. Involving the overlap collision error. The column of three cannot maintain separation, followed by a three-way collision, where they seem to come to rest for a while. Up close you can see how the particles are overlapped and getting closer to each other – more and more, until the collision ‘ends’, usually sending one proton up or down at a good speed, and the other two – which may still be locked together in collision, go the other way.

Proton Stack 04 is better behaved than 03, but it too suffers from the overlap collision error. The vertical column of 4 protons go through series of bounces – maintaining their average separations for about a minute or two before a collision overlap (or two) error occurs, a short build-up time, then break apart from overlap error collision with enough energy for the particles to usually exit the screen up and down.

Proton Stack 05. This scenario suffers from the same problem as 03. All 5 of the initial protons collapse together and sit there – overlapping more and more - till the collision error ends, with higher velocity separations.  

Proton Stack 06. This configuration can also last for a minute or two – a fine executive’s toy – before it needs a reload or restart.

All in all, the 3 and 5 proton stacks (and three body 01 and 02) appeared the most 'broken'. The top or bottom ends quickly blow off. The larger stack splits with greater energy. These two scenarios can last longer if they are slightly modified - by moving the middle proton away from the exact center and unsynchronizing the collisions.  
.