Possible Charged Particle Field

You don't add code to the addLinearMarker function, you call it with the node you want to add as a linear marker. You can call it as many times as you want, passing in different marker nodes to be added.

The reason you aren't seeing the marker is because the addLinearMarker method is not being called by anything. It is there for you to call, the system has no need to call it.

Code:


module.Particle.prototype.createNode = function( ... )
{
  ... // existing code
  
  this.armillaryNode = ... // create marker node
  // then add it to the markers, not to the grp parameter
  this.addLinearMarker( this.armillaryNode );
};


All of the code you put into addLinearMarker should be put into a new method called something like createArmillaryOverlay, which returns the created node. You then call that createArmillaryOverlay method from createNode, store it in a member variable (this.myVariable = ...)  and then call the addLinearMarker method to add them.

Code:


module.Particle.prototype.createNode = function( ... )
{
  ... // existing code
  
  this.armillaryNode = this.createArmillaryOverlay(); // create marker node
  // then add it to the markers, not to the grp parameter
  this.addLinearMarker( this.armillaryNode );
};

module.Particle.prototype.createArmillaryOverlay = function()
{
  var marker = new THREE.Group();
  ... // add nodes to marker group
  // this is where your code currently in addLinearMarker is added
  return marker;
};


If you have 2 types of armillary markers, then create 2 methods, one for each. See if you can do it in 1 though, but only if it makes sense. If they are not connected to each other, then create separate methods, but if they are related, then just do it in the 1 method. If my understanding is correct, then there are only 3 rings that are part of the armillary, and the other things you want to add a velocity markers, not armillaries. These should be separate methods as they are not related to each other.

.
Golly, I feel pretty dumb, it will take some time and effort to correct my thinking. By the way, those 2 armillary markers are the same, I gave them two different names in order to help me indicate the 'node' source - for troubleshooting my difficulties. Fat lot of good that did, I had no idea I was completely misunderstanding the functions and screwing up addLinearMarker.

Trying to wend my way backward through the changes I made I see I'm in a thicket. It's not pretty.

Please, if you'll be so kind, I beg you. Reject, reverse, undo or cancel my latest Commit changes in cdm.js and test.html and Push it back. That's the only way I think I'll be able to return to normal. The colliding - Spin 01 changes are OK, but I'll be happy to change them again if it's easier for you to just delete my last Push.  
.

Don't feel bad. I'm probably not explaining things clearly enough. It is easy to speak in terms that other developers will understand immediately, but I have to remember that you might not understand them as intimately as I do. It happens to me sometimes at work too. Trying to work in somebody else's code base can be difficult and what seems obvious to the author, is not always obvious to others. No matter how proficient they are.

I don't think I actually explained what to do with the add*Marker methods. I just expected you to know already. Not intentionally, but that doesn't change the outcome.

I can't rollback that commit until I get home. Probably about 3-4 hours from now. I tried to do it through the website, but it doesn't let me do that sort of thing, unfortunately.

Here's what you can do. Open SourceTree and look at the commit graph. You should see your latest commit at the top and my last commit, from 2 days ago, underneath that. Left click on my commit so that it is selected. Now right-click on it to show the popup menu. Then click on the menu item 'Reset current branch to this commit'. That will rollback all commits above the one that is selected.

That should leave you with my commit at the top of the graph. If that is what you see, then you can push those changes and it will remove your commit from the server too.

After that, click on my last commit again and then press the Branch button to create a new one that you can work in safely.

.

Given a choice and your directions, I couldn't wait, maybe I should have.

I followed your instructions, up to 'Reset current branch to this commit'. You said  "That will rollback all commits above the one that is selected". The screen doesn't seem to match your statement. I see a Pull is due, where did that come from? The uncommitted changes at the top, they are the no-longer-commits I want to get rid of from my last push.

What next boss?
.

It shows that a Pull is available because that is the commit you just rolled back. If you did pull that down, you would be back in your original position. So don't do that.

The next step could be tricky. Not difficult, but I'm not sure if you have the permission to do it, but let's give it a try.

Click the Push button and unselect all branches. Then select the master branch. It was probably already like that but I just want to make sure.

Now, at the bottom of the Push dialog box, you will see some checkboxes. Make sure that Force Push is selected and then press the Push button.

That will re-write the commit history on the GIT server. Effectively removing your last commit.

Don't worry about the warning SourceTree will show you when you try to force push. It can be a dangerous operation if other developers have those changes pulled to their own repository. I don't have them so you can safely force push.

.
One question. Please confirm that the master branch I should be on when I try to Force Push, is the red master associated with your commit, Fixed the SpatialIndex ... , (and not the blue origin/master just above it).
.

The red one represents your local repository, the blue one the server. But it doesn't matter. It doesn't care what you have selected, just what you have committed.

Note that the colors are not set in stone. Red does not always represent you and blue does not always represent the server. It just happens to in this case.

.

I wasn't allowed the Forced Push alternative, the box wouldn't take my check mark. The Push didn't work - for the old reasons. My screen remains the same. Should I go to terminal node - while on the master line - and try to Push from there?
.

No, you have to tell SourceTree that you want to be able to do Force Pushes.

Got to SourceTree -> Tools -> Options -> Git.

On that tab, you will see a checkbox about half way down the page that says Enable Force Push. Make sure that it checked and then try to force push again.

.
I changed my Force rights. I was able to select the Force Push, but the operation failed. The result was the exact same error message as my last post.
.

That is the same issue you were having a while ago. I think this is a SourceTree problem, not a GIT problem. You can try the command line if you feel up to it.

.

Rejected. Suggesting I Pull before Pushing.
.

That's why you have to force push. I don't know the command line but just search for it on the web.

.

git push --force. The terminal Forced Push worked. Hallelujah.

What's the best way to get rid of my changes? Just discard them?
.

Yes, just select them discard changes.

OR

You can select the top commit that you want to go back to, right-click and select revert to this commit. When that opens a dialog box, select Hard revert and it will delete all changes.

.
Thanks for a good night's sleep. I'll get back to work.
.

I had a look at the latest commit and it is set out correctly, but there are some small issues that can be addressed.

Code:


 module.Particle.prototype.createUniverseAxesOverlay  = function()
 {
 this.universeAxes = new THREE.Group();
 var aRadius = 1.2*PIM.RADIUS;


In this method, you are creating a new THREE.Group to contain all of the universe axes. That is good, but you don't want to set it as a property on this in this method.

You are calling that method in createNode and setting it to a different property:

Code:


this.armillaryNode = this.createUniverseAxesOverlay();


So in the end, you have the same object stored under 2 different names. While that will work, it is not the way it should be. Just change the assignment to a local variable in createUniverseAxesOverlay:

Code:


 module.Particle.prototype.createUniverseAxesOverlay  = function()
 {
 var universeAxes = new THREE.Group();
 var aRadius = 1.2*PIM.RADIUS;


Secondly, you are referring to the PIM module from within the PIM module. You should not reference it as PIM from within its own source code. It should be referenced as module. They are the same exact object, but you can't rely on PIM being set until after this code has been interpreted.

In this case it will work because you are referencing PIM from within a function that is only called after the module has been interpreted, but that may not always be the case. You can't rely on it all of the time, but you can rely on the module variable, because it is a local variable that is later set to the PIM global variable.

You have been working within the scenarios where PIM is already defined and that is how you should access it. Working in cdm.js is a bit different.

.
First things first. Thanks again for your patience, explanations, expertise, ... , and the do-over.


The Universe axes are there to be selected on their own, as valid a particle marker as the particle axes. It can be added to the graphics list. The same, I hope, will be true for velocity and spin vectors. The user may wish to see velocity and/or spin vectors without all the bells and whistles of the armillary.

To-do:
b. Spin axis.
c. Spin equator.
d. Velocity vector.
e. Spin vector.

The Plan. As I believe you’ve mentioned, lines that can change directions must be added to the rotational group. I suppose I’ll be creating additional modules for these items, their products will be added to the rotational group before being added to the armillary. That’s the plan.

So in the end, you have the same object stored under 2 different names. While that will work, it is not the way it should be. Just change the assignment to a local variable in createUniverseAxesOverlay

As usual, I need to give it some thought. True, I begin the armillary as a universeAxes, but I expect I'll be adding the four additional rotational products to the armillary as well. Does that change your interpretation/advice for correction? I'll clean-up the PIM reference next.

////////////////

P.S.
Correction. I misspoke. As you clearly stated, and I completely agree, the velocity and spin vectors will Not rotate. The spin axis and equator can rotate but they shouldn't. (How are things kept up to date?) I have no problems speaking in rash generalities, it's the details that get me in trouble.
.

I don't think you will want any of these to be rotating with the particle. Certainly not the velocity vectors. The b, c, d and e in your todo list should not be added to the armillary. They are separate markers of their own and should be treated just like you have the armillary. b and c can be put into the same marker, because they are 2 aspects of the same thing. You will need to keep the linear and spin velocities separate as well because they both need to be updated.

So you should end up with 4 markers: armillary, spin axis (which includes the equator), spin velocity and linear velocity.

I think that the spin axis and spin velocity can be put into the same marker eventually, but not yet. Once we have a better way to render the spin velocity, the spin axis marker will become redundant.

No, that doesn't change my interpretation/advice. No object should be referenced from the same place with different names (without some very good reason and we don't have one here).

You could put the spin axis (and equator) into the spin velocity marker and then connect the spin velocity vector to the equator ring.

To keep things up-to-date, refer to this post: https://milesmathis.forumotion.com/t476p425-possible-charged-particle-field#4550

.
I'm stuck in the Velocity Vector overlay module. It looks simple, but after two hours effort I can justify asking for your helpful comment. Extra lines were added over time. I know the rest of the code works correctly when I push the dummy vertex line endpoint instead.

Code:


module.Particle.prototype.createVelocityVectorOverlay  = function()
{
      var cVel = new THREE.Vector3();
      this.velocityVector = new THREE.Group();
      // this.velocityVector = new THREE.Vector3();
      var velocityVectorGeometry = new THREE.Geometry();
      var scalarM = 1000; // Multiplying the velocity by an estimated
      // time.delta as is done in module.update below.
      // cVel.copy( this.velocity ).multiplyScalar( scalarM );
      cVel.copy( this.velocity );
      cVel.multiplyScalar( scalarM );
      velocityVectorGeometry.vertices.push(
           new THREE.Vector3( 0, 0, 0 ),
           new THREE.Vector3( cVel.x, cVel.y, cVel.z ));// Not Working.
           //new THREE.Vector3( 3, 3, 3 ));// This dummy velocity distance works.
      var velMat = new THREE.Line( velocityVectorGeometry, MAT_LINE_CP );
      this.velocityVector.add(velMat);
      return ( this.velocityVector );
};


There is probably nothing wrong with it, the current velocity may just be zero.

The more important code is in the update method, as that will alter what you setup here before you ever see it on screen.

.

There is probably nothing wrong with it, the current velocity may just be zero.

The more important code is in the update method, as that will alter what you setup here before you ever see it on screen.

Thanks for the vote of confidence. The rest of your post sounds cryptic - a riddle. I’m believe I'm addressing this.velocity as the update module does.

In any case, I posted the Velocity Vector overlay module even though it doesn’t seem to be working. I'll probably be there until it does, since the next task - the spin velocity vector - seems similar although perhaps progressively more difficult.

createVelocityVectorOverlay module or bust.
.

The velocity vectors are showing, they just aren't being updated. You need to reset the geometry in the update method so that it shows the current velocity, not the initial velocity that it was created with. That is what my post above did, but that assumed you were using a THREE.BufferGeometry but you are using THREE.Geometry, so it will be different. The same thing has to happen, but the way you do it differs because of the Geometry object.

Don't scale the vector by time.delta. That will make it too small to see. I don't know what you will need to scale it by at the moment. Get it working and then find a nice scale constant that works for most situations.

In the update method, you are currently showing/hiding the velocity vector with this line:

Code:


this.velocityVectorNode.visible = module.SHOW_PARTICLE_VEL_VECTOR;


You want to add another section of code like this:

Code:


this.velocityVectorNode.visible = module.SHOW_PARTICLE_VEL_VECTOR;
if( module.SHOW_PARTICLE_VEL_VECTOR )
{
  this.updateVelocityVectorOverlay( time );
}


Then add a new method:

Code:


module.Particle.prototype.updateVelocityVectorOverlay = function( time )
{
  // update the velocity vector overlay geometry

  // set the first vertex to the surface of the particle
  this.velocityVectorNode.geometry.vertices[0].copy( this.velocity ).normalize().multiplyScalar( this.radius );
  // set the second vertex to the sum of surface and this.velocity
  this.velocityVectorNode.geometry.vertices[1].addVectors( this.velocityVectorNode.geometry.vertices[0], this.velocity );

  // mark the geometry as needing to be updated
  this.velocityVectorNode.geometry.verticesNeedUpdate = true;
};


.
That's surprising. I'm sure I might have figured that out in as little as a week or two, maybe.  I thought just calling this.velocity updated the velocity.

I transcribed verbatim, the change to the update module.
module.Particle.prototype.update = function( time )
and the module.Particle.prototype.updateVelocityVectorOverlay = function( time )
you recommended. It isn't cooperating. When one selects the Velocity vector Graphic, all motion stops - like using the spacebar.

The code breaks down on line 813.

Code:

this.velocityVectorNode.geometry.vertices[0].copy( this.velocity ).normalize().multiplyScalar( this.radius );

cannot read property of 'vertices' of undefined.
.

We aren't updating the velocity, we are updating the visual representation of that velocity. Since the velocity can change at any time, we must update the visual representation to match it. These objects aren't going to update themselves just because you used the particles velocity to create them. Once created, they are totally disconnected from the velocity or any other data used.

That error is occurring because this.velocityVectorNode is the wrong type of object. It is a THREE.Group, but I was expecting a THREE.Line.

Change this:

Code:


 module.Particle.prototype.createVelocityVectorOverlay  = function()
 {
 var cVel = new THREE.Vector3();
 this.velocityVector = new THREE.Group();
 //this.velocityVector = new THREE.Vector3();
 var velocityVectorGeometry = new THREE.Geometry();
 var scalarM = 1000; // Multiplying the velocity by an estimated
 // time.delta as is done in module.update below.
 //cVel.copy( this.velocity ).multiplyScalar( scalarM );
 cVel.copy( this.velocity );
 //cVel.normalize;
 cVel.multiplyScalar( scalarM );
 velocityVectorGeometry.vertices.push(
 new THREE.Vector3( 0, 0, 0 ),
 //new THREE.Vector3( cVel.x, cVel.y, cVel.z ));// Does not work.
 new THREE.Vector3( 3, 3, 3 ));// This dummy velocity distance works.
 var velMat = new THREE.Line( velocityVectorGeometry, MAT_LINE_CP );
 this.velocityVector.add(velMat);
 return ( this.velocityVector );
 };


into this:

Code:


 module.Particle.prototype.createVelocityVectorOverlay  = function()
 {
 var velocityVectorGeometry = new THREE.Geometry();
 velocityVectorGeometry.vertices.push(
 new THREE.Vector3( 0, 0, 0 ),
 new THREE.Vector3().copy( this.velocity )
 );
 return new THREE.Line( velocityVectorGeometry, MAT_LINE_CP );
 };


.

Thank you Sir, we have velocity vectors. They're large, but don't appear to need any other clean-up.  

I'll Push then study your changes, then attempt the spin vector/equator. I have plenty to work with.
.

.

Sorry, the 840KB gif I had posted was converted into this jpg file; no single image does it justice.

Velocity Vector review. The velocity vectors work very well – even if I do say so myself.

Looking at a field of particles, we can see at a glance the high speed express particles just passing through - occasionally colliding, from those particles that are interacting ‘locally’ at much lower velocities. Observing the knots of interacting neutral particles more closely, the velocity vectors provide a better understanding of each of the individual particle’s motions and paths. It is much easier to perceive the particles' curved 3D motion with the velocity vectors turned on.

The Velocity vectors make collision events much more obvious, so much so that collisions take some getting used to. When I see the abrupt flashes of post collision vector changes before I knew a collision took place.

The velocity vectors highlight overlap errors – yes, that bug still exists, over much longer intervals and in smaller numbers. The attached gif contains one. Each of the two particles involved in the overlap can develop what appear to be two forward velocities. Step ahead frame by frame and you can see each new velocity vector occurs with each post-collision particle repositioning/separation event. Unsuccessful attempts become easy to see as a dual forward velocity vector. Note, the velocity vector showed me something I hadn’t noticed before - the two overlapped particles have separated several seconds ago, yet the individual particles may each still show dual forward velocities - a shared schizoid particle velocity error.

I definitely appreciate/enjoy the addition of the velocity vector.

On to spin.   
.

Yeah, I saw that yesterday. I was working on getting collisions to include the spin of each particle and I was looking at the collision scenario I created a few weeks ago and stopped the model and stepped through the collision. I was very surprised to see that only 2 particles actually collided about 5 times before they separated. I could see the overlap code move them apart, but then they would move back together on the next frame, then apart, then back together, until eventually they did break apart.

If you watch the gravity scenarios, the velocity vectors show the sudden increases in motion from collisions between multiple particles.

Airman, a friend at work has been having trouble with SourceTree (not the same as you) and has started using a different GIT app called Fork. It is fairly similar to SourceTree, so I thought you might want to give it a go and see if you like it. I might start using it at home too.

.


Spin vectors. I think I’ve made a good start. I must admit, your code was so clean I just copied the create Velocity Vector module, etc. and replaced this.velocity with this.spin and - voila.

How to finish it? The spin axis is too diminutive as is, and since it extends radially outward from one side of the particle it’s easy to confuse with the velocity vector (color aside - I'll change that next).  

I’d like to turn it into what we would consider the spin axis by having it appear to pass completely through the particle. Perhaps by duplicating the same visible spin axis, and extending the negative(?) duplicate from the opposite side of the particle. The two together would then define our Graphic - "particle spin axis". Easy to differentiate from the velocity vector that extends from a single location on the particle surface. Note that two spin axes extending in both directions of the particles will extend in the appropriate magnitude (x2 poles).

Is that an acceptable spin vector? I think so. I‘d like to see what four of these same spin axes extending tangentially from four locations on the equator look like. Working with such rarefied spare code, it may take me a while. If you have any alternative ideas or suggestions, feel free to share.  

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

Thanks for the Fork suggestion. I'll probably try it after I get past this spin thing.
.

Nah, that won't work for spin. You are treating a THREE.Quaternion as if it were a THREE.Vector3. While that will do something, and not fail with an error, it isn't doing what you think it is. The X, Y and Z components of a quaternion are not a vector.

Here's how I would do this one:

Create the desired graphic in a known coordinate system. I usually use the Y dimension for this. So make a line to represent the spin axis that goes from -Y to +Y. Then create a circle that goes around the Y axis at Y=0 (the equator). Make that circle and line extend past the radius of the particle so they can be seen.

Now add some lines that are going to represent the angle of the spin. Add 1 line at each corner: (-X,0,0), (+X,0,0), (0,0,-Z), (0,0,+Z). Here's the tricky part, we want each of those 4 lines to share the same THREE.Geometry, so we need to create the geometry such that it is direction independent. Basically just create it so that the first vertex is (0,0,0) and the second vertex extends a certain distance into a known dimension, say +X. Now when you create each THREE.Line object, passing in the same geometry for all of them, you can now place each line at the 4 corners by using the properties of the Line and not the Geometry. e.g. line.position.set( +Z, 0, 0 ); line.rotation.y = Math.PI/2;

We need to store that geometry so that we can manipulate it later in the update method. This is a bit different to how the velocity was setup, so we are going to break the way these methods are supposed to be used a little bit. You will still return the top most node that contains all of these nodes, but we will also store the geometry in a member variable: this.spinNodeGeometry = ...

Once that is done, it is easier to manipulate it to represent the current spin of a particle in the update method.

Firstly, you convert the spin quaternion into an axis angle, which is a THREE.Vector3 to represent the axis, and a number to represent the angle. Take the axis and determine the necessary rotation to apply to the whole spin node so that its axis aligns with the actual spin axis. That sounds complicated but it is actually quite easy. You just find the cross product of the spin axis and the Y dimension to get the axis to rotate around. Then you calc the angle with the Vector3.angleTo method. We want the angle from the Y dimension to the spin axis. Now we have an axis angle and we can put it into a quaternion and set it on the spin node.

Secondly, we need to set the length of the 4 vectors that represent the amount of spin. To do that we just take the angle of the current spin and convert it into a length. We will probably want to make sure that this length matches the length of the velocity vector node (relatively speaking), but we will ignore that for now (this is where we apply that 8:1 relationship you mentioned earlier).

Since we shared the same geometry with all 4 lines, we only need to update that geometry to update them all. So just set the 2nd vertex of that geometry to have the length that we want in the dimension that you chose for this (+X in the above text).

See if you can make any sense of that.

.
Yikes. My misunderstandings are staggering. Thanks for all the timely, in-depth personal lessons, I feel greatly indebted to you.

Ok then, back to starters. Do the following lines of code come anywhere close to what you described as this.spinNodeGeometry? I know I don't understand what you meant by adding the axis angle lines; should I also be adding and rotating them here?

Code:


 module.Particle.prototype.createSpinVectorOverlay  = function()
 {
      this.ySpinAxisNodeGeometry = new THREE.Geometry();
       var aRadius = this.radius * 1.25;
       var segmentCount = 32);
       // add the Y spin axis.
       ySpinAxisLine = new THREE.Line();
       ySpinAxisLine.vertices.push(
             new THREE.Vector3( 0, -this.radius*1.25, 0 ),
             new THREE.Vector3( 0, this.radius*1.25, 0 )
       );
       var spinAxisLine = new THREE.Line( ySpinAxisLine, MAT_LINE_SA );
       this.ySpinAxisNodeGeometry.add( spinAxisLine );
 
       // add the Y spin axis equator.
       equatorY = new THREE.Line();
       for (var j = 0; j <= segmentCount; j++) {
             var theta = (j / segmentCount) * Math.PI * 2;
             equatorY.vertices.push(
                   new THREE.Vector3(
                         Math.cos(theta) * aRadius, 0, Math.sin(theta) * aRadius));            
       }
       this.ySpinAxisNodeGeometry.add(new THREE.Line(equatorY, MAT_LINE_SA));

       // add the spin angle line.
       ySpinAxisXAngleLine = new THREE.Line();
       ySpinAxisXAngleLine.vertices.push(
             new THREE.Vector3( 0, 0, 0 ),
             new THREE.Vector3( this.radius*1.25, 0, 0 )
       );
       var ySpinAxisPosXAngle= new THREE.Line( ySpinAxisXAngleLine, MAT_LINE_SA );
       this.ySpinAxisNodeGeometry.add( ySpinAxisPosXAngle );
       this.ySpinAxisNodeGeometry.visible = module.SHOW_PARTICLE_AXES;
       return new THREE.Line( ySpinAxisNodeGeometry, MAT_LINE_SA );
 };


That's pretty good, but a few things are incorrect. You had the axis and equator fairly close, but there is some mixup between Group and Geometry objects.

This should be close to what you need:

Code:


module.Particle.prototype.createSpinVectorOverlay  = function()
{
    var group = new THREE.Group();
    var aRadius = this.radius * 1.25;
    var segmentCount = 32;
    
    // create a line to represent the spin axis.
    var geom = new THREE.Geometry();
    geom.vertices.push(
        new THREE.Vector3( 0, -aRadius, 0 ),
        new THREE.Vector3( 0, aRadius, 0 )
    );
    group.add( new THREE.Line( geom, MAT_LINE_SA ) );
    
    // create a circle to represent the spin axis equator.
    geom = new THREE.Geometry();
    for (var j = 0; j <= segmentCount; j++)
    {
        var theta = (j / segmentCount) * Math.PI * 2;
        geom.vertices.push(
            new THREE.Vector3( Math.cos(theta) * aRadius, 0, Math.sin(theta) * aRadius )
        );            
    }
    group.add( new THREE.Line( geom, MAT_LINE_SA ) );
    
    // now we want to add some lines to represent the strength of the spin
    // this is encapsulated in the angle of the spin so we convert the angle
    // into a length and apply that length to 4 vectors positioned at the
    // cardinal positions of the spin axis equator
    
    // create the geometry to represent all lines
    // we will keep it pointed along the X dimension
    // and then transform it in each line
    geom = new THREE.Geometry();
    geom.vertices.push(
        new THREE.Vector3( 0, 0, 0 ),
        new THREE.Vector3( aRadius, 0, 0 )
    );
    
    // create the +X vector
    var line = new THREE.Line( geom, MAT_LINE_SA );
    line.position.x = aRadius;
    line.rotation.set( 0, Math.PI/2, 0 ); // this may need to be made negative
    group.add( line );
    // create the -X vector
    line = new THREE.Line( geom, MAT_LINE_SA );
    line.position.x = -aRadius;
    line.rotation.set( 0, 3*Math.PI/2, 0 ); // this may need to be made negative
    group.add( line );
    // create the +Z vector
    line = new THREE.Line( geom, MAT_LINE_SA );
    line.position.z = aRadius;
    group.add( line );
    // create the -Z vector
    line = new THREE.Line( geom, MAT_LINE_SA );
    line.position.z = -aRadius;
    line.rotation.set( 0, Math.PI, 0 ); // this may need to be made negative
    group.add( line );
    
    // we will need to update the geometry later, so store it in a member variable
    this.spinNodeGeometry = geom;
    
    group.visible = module.SHOW_PARTICLE_AXES; // change this to the correct constant
    
    return group;
};


.

Lattice 3 with un-updated spin axis nodes.

Firstly, you convert the spin quaternion into an axis angle, ...

Very good. I'll take another shot at the rest of your instructions tomorrow.
.

.

Firstly, you convert the spin quaternion into an axis angle, which is a THREE.Vector3 to represent the axis, and a number to represent the angle. Take the axis and determine the necessary rotation to apply to the whole spin node so that its axis aligns with the actual spin axis. That sounds complicated but it is actually quite easy. You just find the cross product of the spin axis and the Y dimension to get the axis to rotate around. Then you calc the angle with the Vector3.angleTo method. We want the angle from the Y dimension to the spin axis. Now we have an axis angle and we can put it into a quaternion and set it on the spin node.

Code:


 module.Particle.prototype.updateSpinVectorOverlay = function( time )
 {
      // convert the spin quaternion into an axis angle

       var spinAxis = new THREE.Vector3();
       var yAngleAxis = new THREE.Vector3();
       var q1 = new THREE.Quaternion();
       q1.copy(this.spin);
       if (q1.w > 1) {
             q1.normalise()
       };
       var angle = 2 * Math.acos(q1.w);
       var s = Math.sqrt(1-q1.w*q1.w);
       if (s < 0.001) {
             spinAxis.x = q1.x;
             spinAxis.y = q1.y;
             spinAxis.z = q1.z;
       } else {
             spinAxis.x = q1.x / s;
             spinAxis.y = q1.y / s;
             spinAxis.z = q1.z / s;
       }

       // find the cross product of the spin axis and the Y dimension to get the axis to rotate around.
       // Then you calc the angle with the Vector3.angleTo method.

       yAngleAxis = spinAxis.cross(0,1,0);
       var yAngle = yAngleAxis.angleTo(0,1,0);
 
      // Secondly, we need to set the length of the 4 vectors that represent the amount of spin.
      // take the angle of the current spin and convert it into a length

 };


As you can see, I didn't get too far - to Secondly and stopped there. Requesting a reality check.

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

My source for converting a spin quaternion into an axis angle. Maths - Quaternion to AxisAngle
http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToAngle/
.

That's a good start. You've converted the quat into an axis angle correctly. the next section is trying to do the right thing, but you are mis-using the Vector3.cross method. The cross method takes in a THREE.Vector3 as its argument and it does not return a value, but puts the result into the object that you are calling the method on (spinAxis in this case).

So it should become something like this:

Code:


spinAxis.cross( AXIS_Y ); // we use the AXIS_Y constant here instead of creating a new vector
var spinAngle = AXIS_Y.angleTo( spinAxis );

// now we just set that axis angle onto the spin node so that it is oriented the same as that spin
this.spinVectorNode.quaternion.setFromAxisAngle( spinAxis, spinAngle );

// now we need to convert the angle into a length to apply to the 4 vectors
this.spinNodeGeometry.vertices[1].x = module.Math.angleToSpinVelocity( this.radius, angle );
this.spinNodeGeometry.verticesNeedUpdate = true;


Note that I just pushed a new math equation to cdm.js to convert the radius and angle into a tangential velocity (the speed component anyway). You will need to get that before the above code works.

.
Noooooo.


The six piece (axis,equator and 4 quadrant tangent lines) spin axis node is too dominant. The spin nodes remains off till the particle's spin state changes, then it becomes hard to see anything else.

Looking at Lattice 03 again, the updated spin nodes are radically distorted; I don't see the distortion problem anywhere else.


The spin axes don't seem to match the particle spins. I'll take a closer look.  
.

.
The spin axes seem correct occasionally, but it seems the spin nodes are generally independent of the particle spin motions. There may be direction problems that have only become apparent with these new vector graphics.

Even the Unmovables had a surprise or two. They may be stuck in space, but their velocities continuously grow, and not necessarily in an expected direction, perhaps it's just counter my expectation.  

I now know I’m responsible for loading some scenarios with faulty non-quaternion spins.
For example, the Two Body group consists of: 01, 02, 02-s1, 02-s2, 03, 03-s1, and 04. The active Graphic ‘spin vector’ only appears for 03-s1 and 04, I suppose the particle spin states don’t change in any of the other scenarios in the group, even though the particles in 02-s1 and 02-s2 clearly do so. Within the Two Body group, the Spin Vector graphic is correct – matching the particle motion - in only Two Body 04.

I had a screen freeze during Spin 01- cdm line 926 q1.normalize is not a function.


I mentioned how the velocity vectors make overlap error collisions obvious, well you can see the spin node does way better than the velocity vectors.

I hope you’re not dismayed by the mess or disorder. I consider this progress.
.

I just pushed some changes to fix the spin visualization code. I had 2 function calls around the wrong way so it was changing the contents of a variable before I had used its previous value. They are now orienting themselves correctly.

There may still be problems. The directions don't seem to align with the rotation of the particles sometimes, but when I put them into a known state, they line up.

I fixed that bad function error, I'm guessing you copied the code from that example of axis angle extraction which had a different spelling of normalize/normalise because it was Java code using the Java3D API for vector math.

The unmoveable scenario does show some weird vectors, but they are perfectly explainable.

At first, I freaked out because I thought it was using attraction at the poles of the proton. So I turned on the Charge Profile to see that it is not. Then it clicked, it is gravity pulling on the top and bottom particles, while the protons emission pushes out the left and right ones.

.
I like the spin node color change, but especially the rotating tangent lines; the spin node is then easier to compare with the particle itself.


Two Body 04. The bottom particle is rotating end-over-end as shown by the CW rotation of the spin node.

Two Body group spin node display update.
Yesterday, in the wake of the spin node addition, I’d reported on the Two Body group; 03-s1 and 04 were the only two scenarios for which the spin node appeared. The Spin Vector graphic functioned correctly (displaying correct speed and direction) in only Two Body 04. Given the subsequent corrections, I need to follow-up with a current status description.
01 - No spin present, ok.
02 - No spin present, ok.
02 - s1 - Both neutrons particles spin in opposite directions CCW on the top, CW below. The top spin node spins in the correct direction at twice the particle spin speed. The bottom spin node spins opposite to the particles spin, also about 2x as fast as the particle.  
02 - s2 – the two neutrons particles spin in the same direction –CW from the top - but the two spin node graphics shows both neutrons particles spinning in the same CCW direction. Again, both neutrons particles spin about half the speed that the spin node graphics indicate.  
03 - No spin, ok.  
03 - s1 – The top particle is moving with y axis CCW spin. The spin node correctly shows both the particle’s spin direction and spin speed. The bottom particle’s spin is turned 90deg away from the Y axis (x direction) away from the vertical yet the spin node incorrectly shows the wrong spin plane, a y spin neutron spinning CCW from the top.  
04. The top particle is moving with a y axis spin in CCW direction; it’s spin node correctly shows the particle’s spin and spin speed. The bottom particle is spinning about it’s y axis, although that axis is oriented 90 deg away from y; it has a top level end-over-end spin that rotates CW in the plane of the image included above. The spin node seems to agree with the top level end-over-end spin although I believe the spin node is spinning slightly faster than the particle.  

Spins can add. What would the correct spin node display? A Y-spin particle may be tumbling end-over-end, shouldn’t the spin node be tumbling the same as the y-spin particle? How do extra spins complicate the spin nodes? Is there a practical limit or problem here?

I’ll look at and play with the Two Body group’s particle factory settings in order to see if I can find any errors and maybe get a better understanding of the spin node.
.

Please note that the rotation of the spin vectors has absolutely no relation to the amount of spin. It is just a constant rotation that I added because they felt a bit too static without it. Which I found amusing because I had previously told you that I thought that rotating them would be distracting. It may still turn out to be, but it definitely looked weird with them all being aligned to the same axes.

I haven't had a chance to look into it yet, but I think there may be a problem in the charge-to-spin calculations. It may not be re-orienting the spins based on the current orientation of the target particle. The collision based spins seem to be fine, it is just the charge based ones that cause issues, as far as I can see at the moment.

Airman wrote:Spins can add. What would the correct spin node display? A Y-spin particle may be tumbling end-over-end, shouldn’t the spin node be tumbling the same as the y-spin particle? How do extra spins complicate the spin nodes? Is there a practical limit or problem here?

I'm not sure what you mean. Are you talking about stacked spins?

.

Lattice 03 today. I corrected the extremely distorted spin nodes I showed on Saturday. They were entirely my mistake, as you say, treating quaternions as vectors. 'They looked so good at the time' is apparently no defense.

These neutrons all have the same y spin axis. Their spin speeds vary from zero – the left side bottom corner (the particle without the spin node) to one – located at the right side top corner. I believe the spin node magnitude line at that position is more than twice as large as the particle’s radius.

Thanks for pointing out that those tangential magnitude lines have no bearing on the particles’ spin; you added it to prevent distraction. The fact that the spin node rotation rate remains the same across the entire lattice even though the particles have varying spins is still distracting. The smallest tangent spin lines race ahead of the particle’s spin.

Can we detect and display a magnitude corresponding to the spin rate, and slow it down so it agrees with the particle spin rate?

Can we introduce additional variations within Lattice 03? Changing a particle's orientation seems to mis-align it's spin node.

I found a few more additional spin node distortions. They can occur for both protons and neutrons. A new collision bug, where their spin node remains elliptically elongated. One can find a few in Lattice 02.

Are you talking about stacked spins?

I'm talking about the spin node's ability to track the particles' different spin motions. Two Body 04 is a perfect example - the bottom particle is rotating end-over-end as shown by the CW rotation of the spin node. The spin node just shows a simple x or z rotation - with no indication of the protons primary y axis spin. Shouldn't we be able to show the real time orientation of the particle's y spin? We could watch it tumble with additional spins.
.