# Possible Charged Particle Field

Page 4 of 29 ## Re: Possible Charged Particle Field

I think I misunderstood you question about that proton in the center of the lattice. I thought you meant it wasn't supposed to be there and went into debug mode. Now I think you are asking why, as a matter of Physics, does it stay in the center. Which is actually easier to answer.

There is nothing to move it. No protons are close enough to impose any attraction or repulsion. Neutrons don't attract or repulse, so they won't move it either. You may also be asking why it doesn't move those neutrons that are close to it, and that is because they are at a 45° angle to the proton and are in a zero influence zone. That is, the proton neither attracts nor repulses anything in that area.

The lattice arrangements are interesting. Didn't expect them to move quite the way they did.

I have made those changes to get the collision code in there and working. You only need to implement the actual math in the calculateCollision method of ParticleArray. It already contains the data, read in from the appropriate buffers, and the writing to the appropriate output variables. I have included the spin values as well as the linear velocity, but you don't have to use them. I'm not sure if they should be used or not, but they could be used to impart spin between the particles. Don't worry about them at first, just get a standard collision working and then it can be altered to include spin later.

I have split the original ParticleArray.calculate method into 2 methods now. The charge calculations now have their own method so that they could be separated from the collision code. This allows neutrons to be included in collisions while excluded from charge calculations which it didn't do before.

I wouldn't reset the orientation, I would determine the change in spin based on the current spin of both particles and apply that change. Collisions will not always stop the spin because they may have spins that match and therefore do not change the spin of either particle. If they are equal and opposite then they would cancel each others spins, just like Miles talks about with magnetism.

We don't need to move either particle because they have penetrated each other. Normally I would agree with you, but in this case it doesn't apply because we don't have solid particles. We have little spinning BPhotons acting like particles and they allow overlapping.

The collision calculations must be performed for one particle only. All of these calculations are for one particle only. Everything is setup for such math. They all work out the same things, so it all calculates correctly, it is just a bit less efficient than it could be. But if we made it efficient in that way, it would be less efficient in other ways that matter a lot more.

I'll give you an example to illustrate it. Suppose we have 10 particles and we are calculating through them and come to the 4th particle and determine that it collides with the 6th particle. If we decide to move the 6th particle during that calculation, then all particles before the 4th will have worked with a differently positioned 6th particle. While there are ways to deal with this stuff, we don't need it here because the physics allows us to ignore it.

## Re: Possible Charged Particle Field

.
CPIM Bug report. No changes. Running particleArray = initLatticeBody02() in order to observe plenty of close particles.
The screen appears to freeze at the moment when two neutrons make contact.

The following error outputs.
//499cdm.js:731 Uncaught ReferenceError: q1 is not defined
//    at module.ParticleArray.calculateCollision (cdm.js:731)
//    at module.ParticleArray.calculate (cdm.js:483)
//    at render (test.html:562)
//    at animate (test.html:555)
.

## Re: Possible Charged Particle Field

Sorry about that, looks like I called them s1 and s2 but copied the code from elsewhere where they were called q1 and q2.

This is the code block:

Code:
` (function() // calculate direct collision between particles { var v = new THREE.Vector3(); var q = new THREE.Vector3(); var v1 = new THREE.Vector3(); var s1 = new THREE.Quaternion(); var v2 = new THREE.Vector3(); var s2 = new THREE.Quaternion();  module.ParticleArray.prototype.calculateCollision = function( index1, point1, orient1, index2, point2, orient2, vel, spin ) { var vi = index1 * 3; var qi = index1 * 4; // read in current velocities and spins for each particle v1.x = this.velocities[vi]; v1.y = this.velocities[vi+1]; v1.z = this.velocities[vi+2]; q1.x = this.spins[qi]; q1.y = this.spins[qi+1]; q1.z = this.spins[qi+2]; vi = index2 * 3; qi = index2 * 4; v2.x = this.velocities[vi]; v2.y = this.velocities[vi+1]; v2.z = this.velocities[vi+2]; q2.x = this.spins[qi]; q2.y = this.spins[qi+1]; q2.z = this.spins[qi+2];  // TODO calculate change in velocity for point1 caused by point2 // place change in velocity into v v.set( 0, 0, 0 ); // place change in spin into q q.set( 0, 0, 0, 1 );  // add change to velocity and spin vel.add( v ); spin.multiply( q ); }; }());`

Change
Code:
`var s1 = new THREE.Quaternion();`
to
Code:
`var q1 = new THREE.Quaternion();`
and do the same for s2 to q2.

I have just found another bug in that code. It is not reading the full quaternions because it is missing the w value.

Directly after

Code:
`q1.z = this.spins[qi+2];`

add

Code:
`q1.w = this.spins[qi+3];`

and do the same for q2.

## Re: Possible Charged Particle Field

.
Ok, progress. I’ve made the four changes as directed. I suppose I should feel guilty for not finding and correcting them myself – almost.

CPIM Bug 2. Particles disappearing.

Now, we have a slightly new problem. When particles touch, they blink out of existence. Are their buffer contents overwritten with zeros -  v.set( 0, 0, 0 )? I would have hoped the particles passed thru each, like before, unless the collision code was provided.

I understand I’m supposed plug in the appropriate change in velocity of this.particle or v1, due to the other.particle, v2, and to not make any changes to the other particle, v2. Given the current problem it looks like I must set both v1 and v2.

Hep me please. Your continued guidance and patience is appreciated.
.

## Re: Possible Charged Particle Field

You just need to replace this code:

Code:
` // TODO calculate change in velocity for point1 caused by point2 // place change in velocity into v v.set( 0, 0, 0 ); // place change in spin into q q.set( 0, 0, 0, 1 );`

with the implementation. Place the change in velocity in the v variable (a vector) and the change in spin in the q variable (a quaternion). The rest of the code takes care of adding it to where it needs to go.

Not sure why they would disappear though. There is nothing in that code to do that. Do they ever re-appear? If not, then they are being given a bad velocity and have shot away off screen. I had some particles do that when I was getting the major charge algorithm operational. I also found that sometimes the math would calculate invalid values. That is, the numbers are in a state that is 'Not a Number' (yes, that is a possible state of a floating point value). You can check for this by using the isNaN function like this:

Code:
`if( isNaN( v.x ) ){   // take action for a non-valid number}`

You could zero out the vector (and spin) if you detect invalid numbers. The charge calculations are already doing that. However, spend a bit of time making sure that the math is correct before that. Bad math may give you bad results and should always be the first thing to check. If the math is fine, then it just may be that the numbers are getting too large to store in the 53 bits a JS floating point number has to work with (it is 64 bits but the other bits are used for something else).

## Re: Possible Charged Particle Field

To be clear and completely honest, I did not test that collision code, even without the implementation. I ran through a few tests to make sure that the page still worked, but did not look for a test configuration that actually made particles collide. I should have done that. There may be problems higher up in the call stack. Just make sure that your math is correct and if it still has problems, then I will have a look at it. I might have a little bit of time later today to have a look, but can't promise anything.

## Re: Possible Charged Particle Field

.
The particles blink out and do not return.

"Just make sure that your math is correct and if it still has problems".

I made no changes beyond as you directed me earlier. I have not generated any change vectors, my math is not at issue. I believe it "still has problems".
.

## Re: Possible Charged Particle Field

Ok. Show me the changes that you did make. Post the whole code block as I did above.

I had a quick look at the calling code and it looks fine, but that is the problem with little bugs, they look fine until you look really closely. I am not at home, so I can't test anything. I'm just looking at the code on BitBucket.

## Re: Possible Charged Particle Field

.
If you're not at home don't worry about this now.

I pushed the small changes to BitBucket.
Code:
` module.ParticleArray.prototype.calculateCollision = function( index1, point1, orient1, index2, point2, orient2, vel, spin ) { var vi = index1 * 3; var qi = index1 * 4; // read in current velocities and spins for each particle v1.x = this.velocities[vi]; v1.y = this.velocities[vi+1]; v1.z = this.velocities[vi+2]; q1.x = this.spins[qi]; q1.y = this.spins[qi+1]; q1.z = this.spins[qi+2]; q1.w = this.spins[qi+3];  vi = index2 * 3; qi = index2 * 4; v2.x = this.velocities[vi]; v2.y = this.velocities[vi+1]; v2.z = this.velocities[vi+2]; q2.x = this.spins[qi]; q2.y = this.spins[qi+1]; q2.z = this.spins[qi+2]; q2.w = this.spins[qi+3];  // TODO calculate change in velocity for point1 caused by point2 // place change in velocity into v v.set( 0, 0, 0 ); // place change in spin into q q.set( 0, 0, 0, 1 );  // add change to velocity and spin vel.add( v ); spin.multiply( q ); };`

I'll continue playing with it on a separate copy.
.

## Re: Possible Charged Particle Field

Yeah, that looks fine.

That should not change anything. Both v and q are set to an identity value (ie, they do nothing) so it may be vel and/or spin that are the problem. They were being used in a different way before my recent changes, so it may that they are being used somewhere that I don't want them to be anymore. I thought I caught them all, but may have missed one. Or it is something else entirely. I'll have a look when I can.

## Re: Possible Charged Particle Field

Fixed it. The spin component of the collision was causing invalid numbers. I have commented it out. I thought I was multiplying by an identity quaternion, so it should do nothing, but I'm not so sure that I was, now.

## Re: Possible Charged Particle Field

I have had a look over the Gravity at the Quantum Level paper and found these values that I think should be able to help us implement gravity and make sure that the gravity and charge fields are in the correct proportions.

Gravity of the Proton = Gp = 6.29 x 10^-20 m/s^2
Electrical field of the Proton = Ep = 1.48 x 10^18 m/s^2

Let's look at their ratios:

Ep/Gp = 1480000000000000000 / 0.0000000000000000000629
= 2.35e+37
Gp/Ep = 4.25e-38

This means that the gravitational field is extremely small compared to the charge field. We are currently using a charge field strength of 0.1, so the gravity strength would be 4.25e-39 to keep it proportional. It doesn't look like it will make much difference.

Everyone, please chime in if you have any info about gravity at this level. Any links to papers that might be relevant. Anything, really. I remember reading about gravity being 22 orders of magnitude larger than we thought at the quantum level, but haven't found it in my searches yet. I'm probably skimming over it. Those numbers might already contain it but I'm not sure. I think they must, but would prefer it was spelled out for me.

## Re: Possible Charged Particle Field

From "The Third Wave Pt. 5":

Mathis wrote:As the basic motion in the universe, it intersects the E/M field and all other known and unknown fields. Only in this way can it be unified with other interactions. I have already shown in this series of papers that at the quantum level it combines with the E/M field to create the orbit. In subsequent papers I have shown that the strong force can be replaced by gravity at the quantum level, and that the acceleration of gravity at the quantum level can be calculated from known numbers, giving us a field that is actually 1022 more powerful than now thought.

In fact, let us now calculate the force due to acceleration of mass, and see if it is of a proper size to fit the strong force. Here is the value I calculated for the proton:

a = 6.06 x 10-13m/s2
F = ma = 1 x 10-39v4

http://milesmathis.com/third5.html

That's really all I could find myself, after scanning about half a dozen papers. I feel like we know it better as a concept but since most of Miles' work is charge equations, there's not much to work with on gravity equations. Hope it helps though.

## Re: Possible Charged Particle Field

.
I implemented a simple collision, a transfer of linear energy alone.

The algorithm I used can be found at the end of the Gamasutra reference  Pool Hall Lessons: Fast, Accurate Collision Detection Between Circles or Spheres, page 3. http://www.gamasutra.com/view/feature/131424/pool_hall_lessons_fast_accurate_.php?page=3

Code:
` module.ParticleArray.prototype.calculateCollision = function( index1, point1, orient1, index2, point2, orient2, vel, spin ) { var vi = index1 * 3; var qi = index1 * 4; // read in current velocities and spins for each particle v1.x = this.velocities[vi]; v1.y = this.velocities[vi+1]; v1.z = this.velocities[vi+2]; q1.x = this.spins[qi]; q1.y = this.spins[qi+1]; q1.z = this.spins[qi+2]; q1.w = this.spins[qi+3];  vi = index2 * 3; qi = index2 * 4; v2.x = this.velocities[vi]; v2.y = this.velocities[vi+1]; v2.z = this.velocities[vi+2]; q2.x = this.spins[qi]; q2.y = this.spins[qi+1]; q2.z = this.spins[qi+2]; q2.w = this.spins[qi+3];  // Determine collision reaction. // Calculate the velocity and spin changes  // felt by the receiving charged particle only.  // The linear momentum velocity exchange is implemented               // below. See Gamasutra's Pool Hall Lessons // Find the normalized vector between the centers of the  // overlapping receiver and emitter particles. var vectorCPA = new THREE.Vector3();// CPA, collision point axis. vectorCPA.copy(point1); vectorCPA.sub(point2); vectorCPA.normalize();// In the ref, vectorCPA is called n.  // Find the length of each particle's motion along the linear  // component CPA. var a1 = v1.dot(vectorCPA);  var a2 = v2.dot(vectorCPA);   // Using the optimized version,  // optimizedPA =  2(a1 - a2)  //               -----------  //                 m1 + m2  // float optimizedPA = (2.0 * (a1 - a2)) / (circle1.mass +  // circle2.mass);  var m1 = 1.0;// receiver's mass or this.mass. var m2 = 1.0;// emitter's mass or this.mass. var optimizedPA = (2.0 * (a1 - a2))/(m1 + m2);  // Calculate v1', the new movement vector of the receiver  // v1' = v1 - optimizedPA * m2 * n  var vectorV1Bounce = new THREE.Vector3(); vectorV1Bounce.copy(vectorCPA); vectorV1Bounce.multiplyScalar(optimizedPA*m2); var v1Prime = new THREE.Vector3(); v1Prime.copy(v1); v1Prime.sub(vectorV1Bounce); // TODO calculate change in velocity for point1 caused by point2 // place change in velocity into v v.set( 0, 0, 0 ); // place change in spin into q q.set( 0, 0, 0, 1 );  // add change to velocity and spin vel.copy( v1Prime );// Transfer of linear momentum only. //spin.multiply( q ); };`

The coding is direct and straight forward. The resulting collision velocities seem a bit too energetic, I've reviewed it several times. Please give it a look.

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

I can't think of anything to add on the subject of gravity at the proton scale.

Thanks for that reference Jared. In our discussions we always seem to assume the nucleus is held together by charge channeling, but I personally believe gravity does hold the nucleus together. Gravity may not bring nuclei together, although it may help hold it together. Planetary scale charged particles might be more fun.
.

## Re: Possible Charged Particle Field

Replace m1 and m2 with MASS. This is a constant created at the top of the file and is set to the value 1.
Remove v1Prime and use v for that purpose instead.
Remove the v.set(0, 0, 0); line (since you are doing that in the above code when setting v1Prime).
Change vel.copy( v1Prime ); back to vel.add( v );.

By using copy instead of add, you are overriding all collisions other than the last one (for this particle). We need to sum all collisions, not just use one of them.

We may find that the value of MASS needs to be reduced in order to balance it with the charge strength and gravity, once that is in. Feel free to reduce it until the collisions look right to you.

## Re: Possible Charged Particle Field

.
Thanks Nevyn, I made the changes you identified, with a little more cleanup and pushed them to bitbucket.

A couple of notes.
1. I tried varying MASS from MASS=0.0001 to MASS=10000 with no change in collision outcomes.
2. When line 788 spin.multiply( q ) is uncommented, particles disappear.

Code:
` // float optimizedPA = (2.0 * (a1 - a2)) / (m1 + m2); // var optimizedPA = (2.0 * (a1 - a2))/(MASS + MASS); // Calculate v, our desired receiver velocity change // v = v1 - optimizedPA * m2 * n  var vectorV1Bounce = new THREE.Vector3(); vectorV1Bounce.copy(vectorCPA); vectorV1Bounce.multiplyScalar(optimizedPA*MASS); v.copy(v1); v.sub(vectorV1Bounce);  // TODO calculate change in velocity for point1 caused by point2 // place change in velocity into v //v.set( 0, 0, 0 );  // place change in spin into q q.set( 0, 0, 0, 1 );  // add change to velocity and spin vel.add( v ); //spin.multiply( q ); };`
.

## Re: Possible Charged Particle Field

Yeah, I tested that mass change myself and it didn't work. The collision math is the wrong algorithm to be using. I think it is an elastic collision, but we want an inelastic collision. There is definitely too much bounce going on.

## Re: Possible Charged Particle Field

.
I pushed a "correction" to the bounce’s energy efficiency by changing the multiplier from 2.0 to 4.0 in the momentum transfer equation for optimizedPA. I can't explain why but it seems to work fine.

//var optimizedPA = (2.0 * (a1 - a2))/(MASS + MASS);
var optimizedPA = (4.0*(a1 - a2))/(MASS + MASS);

You can see the difference between the two values most clearly when running particleArray = initThreeBody04(). With the 2.0 multiplier  the results are inexplicably radical, but with 4.0 the result looks perfectly natural, including the slight sideways motion imparted to the protons.

I believe changing the MASS value had no effect because both particles were equivalent masses no matter what MASS value was actually selected.
.

## Re: Possible Charged Particle Field

. Here's a gif of particleArray = initThreeBody04_03(), a slight numerical change not pushed, made just for discussion. I believe it shows a perfectly valid collision. The –y value for the bottom proton has been changed from -5 to -4.9 so that both protons don’t impact the neutron at the same time as in initThreeBody04(). The change has resulted in a single collision, between the bottom proton and the neutron. What appears to be a second collision is not, it is due to charge repulsion primarily between the top proton and the neutron. Note, I minimized the emission field for clarity.
.

## Re: Possible Charged Particle Field

It still doesn't look quite right to me, and I'm not comfortable with 'it looks close enough'. Yes, we can do that temporarily, but we need to know that the math is correct if we want to extract any useful information from this app. I'd suggest removing the charge field interactions for testing, as you can't tell what is causing the forces when there are multiple being expressed. Use some neutrons with initial velocities that make them collide.

Also, create a scenario with 3 neutrons in a line and the outside 2 have equal but opposite velocities that will collide with the center one at the same time. Make sure that the center neutron doesn't move, but the outside ones receive the forces. That will test the summing of all forces received through collision.

## Re: Possible Charged Particle Field

.
As requested.

Collision testing. Changing the optimizedPA coefficient value.

In the simple linear collision implemented, the transfer of linear momentum is described by optimizedPA = (2.0 * (a1 - a2)) / (m1 + m2). a1 and a2 are each particle motion’s dot projections onto the collision axis between the two particles - the two linear components of the collision; m1 and m2 = MASS, a given; the value of 2.0 in the expression is appropriate for a perfectly elastic collision. We’re free to change it, doing so results in a variety of responses.

Code:
` // Using the optimized version,  // optimizedPA =  2(a1 - a2)  //               -----------  //                 m1 + m2  // float optimizedPA = (2.0 * (a1 - a2)) / (m1 + m2); // // optimizedPA value testing. //var optimizedPA = (2.0 * (a1 - a2))/(MASS + MASS); //var optimizedPA = (3.0 * (a1 - a2))/(MASS + MASS); //var optimizedPA = (3.5 * (a1 - a2))/(MASS + MASS); //var optimizedPA = (3.9 * (a1 - a2))/(MASS + MASS); //var optimizedPA = (4.0 * (a1 - a2))/(MASS + MASS); //var optimizedPA = (4.1 * (a1 - a2))/(MASS + MASS); var optimizedPA = (5.0 * (a1 - a2))/(MASS + MASS);` Consecutive columns. This gif shows a configuration created for collision testing. Consisting of 7 columns and 5 rows for a total of 35 Neutrons. The distance between columns is 25. The distance between rows is 10. Each neutron is given three, (x,y,z) random orientations. The leftmost column is given an initial velocity of 7.5. There are four consecutive sequences shown, corresponding to the linear collision’s optimizedPA values:

a. optimizedPA = 2.0. The leftmost column collides with the second column, then those two columns quickly bug out the right side of the screen without any additional collisions.

b. optimizedPA = 3.0. After each column collides and transfers momentum to the next, each column still has a forward velocity, faster for each consecutive column to the right.

c. optimizedPA = 4.0. Each column transfers all momentum as shown by the post collision stationary neutron columns. If all energy is transferred, how would the collisions increase in energy?

d. optimizedPA = 5.0. After each column transfers momentum they begin traveling in reverse, repeated collisions bug the columns off both the right and left sides of the image.

In all cases, the total particle system’s energy increases with each collision.

I also checked optimizedPA values of 3.9 and 4.1. At 3.9, after collisions, the particles continued with a slight forward velocity. At 4.1 after collisions, the particles continued with a slight reverse velocity. The optimized value of 4,0 resulted in the best transfer of momentum. Three in a row. Here the configuration is changed to 3 columns and 5 rows for a total of 15 Neutrons. The separation distances are the same as before. The leftmost column is given an initial velocity of 7.5 and the rightmost column a velocity of -7.5.

All optimizedPA values below 5.0 resulted in the three neutrons in each row clumped together, with the most overlapped and clumped trios occurring for optimizedPA = 2.0. This gif shows optimizedPA = 5.0, with two outcomes. Somewhat less than half the time the particles would clump together, more often, the neutrons would rebound apart somewhat slower then they converged together in the first place. I don’t know what would cause such a change. I believe the three in a row test is a bust. I don’t see how a simultaneous three way collision is a fair test.

The biggest problem I’ve observed is increasing energy with consecutive collisions. I believe the results I’ve described above support an optimizedPA with a coefficient of 4.0. However, I do not see how any value would result in increasing the total energy of the particle system. The collision calculation alone may not be causing the total system energy increase.
.

## Re: Possible Charged Particle Field

.
Status update. You’ll recall I implemented the collision algorithm while the particles were overlapped, that may be the reason for the total particle system energy increase.

The ‘charge density received’ calculation adds together (N/S,E/W,F/B) all the charge p1 receives from nearby particles. The received charge causes a change velocity – an acceleration - that will be added to p1’s current velocity.  In the middle of the calculation, while checking for p2’s possible contribution to p1’s change accelerations, the distance between p1 and p2 is found to be less than the sum r1 and r2. The particles are overlapped - go to the collision calculation!

As with the ‘charge density received’ calculation, the collision calculation is only intended to return a change velocity (and change spin) for particle 1. I knew I implemented the collision algorithm while the particles were overlapped, that may account for the total particle system energy increase. The change velocity calculated for overlapping particles is a greater magnitude than the change velocity that is calculated for particles at first contact.

It’s true, we’re constrained in that we cannot change the actual position of any particle, but that doesn’t prevent us from moving both particles to where they might have first touched for the purposes of calculation only. Other than obtaining the required velocity change, any position changes made for the collision calculation does not affect the particle at all.

I implemented repositioning the two particles in the collision calculation with positive results.  The top gif shows the increasing energy problem I reported last post. The bottom gif shows the results of repositioning the colliding particle centers. Watch them long enough and you'll see when they begin at the same time, making the energy change obvious. Using the gif maker and paint I made images of individual gif frames (approximations), showing:

Total time between collisions between column pairs 1/2 and 5/6:
Overlapping particles (top gif) - approx. 1.05 seconds.
Touching particles (bottom gif) - approx. 2.244 seconds.

Positive results. I reduced the amount of energy being added with each collision, clearly there's more being added somewhere. A problem or few remain.

Feel free to chime in.
.

## Re: Possible Charged Particle Field

Airman wrote:The change velocity calculated for overlapping particles is a greater magnitude than the change velocity that is calculated for particles at first contact.

It can't do that because neither the center points of the particles, nor the vector pointing from one center to the other are actually used in the equation. The vector from one to the other is used to find the component of the existing velocity that is along that line, but that is it. The length of that vector is never used, so it can't effect the result. In fact, that vector is normalized, so its length will always be 1.

What I think is happening is that when the particles are overlapped, the resultant velocity does not change their positions enough to put them outside of each others boundaries, so when the next frame is calculated, they are still overlapping and go through the collision code again. This keeps happening until they are no longer overlapping or touching. This is why the original code you got this from would move the particles so that they were not overlapping. That avoids this problem.

Not sure how to handle it at the moment.

## Re: Possible Charged Particle Field

.
It can't do that because neither the center points of the particles, nor the vector pointing from one center to the other are actually used in the equation. The vector from one to the other is used to find the component of the existing velocity that is along that line, but that is it.

I respectfully disagree, the dot projections, a1 and a2 use the normalized center to center collision axis; a1 and a2 are longer when the normalized axis is overlapped.

Code:
`812           ///vectorCPA.copy(point1);813           vectorCPA.copy(collisionPoint1);814           ///vectorCPA.sub(point2);815           vectorCPA.sub(collisionPoint2);`

Make the changes between point1 and collisionPoint1 and see for yourself.

Can you console those points to clear up any ambiguity?

The site insists on adding http before the slash slash even in the code block. You understand.
.

## Re: Possible Charged Particle Field

I agree that the length of those 2 vectors will be different. With the overlapping vector being shorter than the touching vector. However, it is irrelevant, because the very next line normalizes the vector which ensures that it keeps the same direction and that its length is equal to 1. So any difference is lost after that function call.

816 vectorCPA.normalize();// In the ref, vectorCPA is called n.

The reason a1 and a2 are larger when overlapping is because they already contain some velocity from the last collision, which is really the same collision, and are amplifying that velocity. At least, that is my theory at the moment. See if you can determine if the collision is occurring multiple times. Use console.log( 'my message' ) to write debug messages to the console to see what is happening. Use the debugger to step through the algorithm and watch the variables as you do.

## Re: Possible Charged Particle Field

Sponsored content

Page 4 of 29 Permissions in this forum:
You cannot reply to topics in this forum