# Possible Charged Particle Field

Page **20** of **23** • 1 ... 11 ... 19, **20**, 21, 22, 23

## Re: Possible Charged Particle Field

.

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.

.

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.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.

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..

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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:

You want to add another section of code like this:

Then add a new method:

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;

};

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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.

cannot read property of 'vertices' of undefined.

.

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.

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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:

into this:

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 );

};

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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.

.

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.

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

.

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

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.

.

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.

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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.

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

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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.

.

**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.

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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.

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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?

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 );

};

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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:

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;

};

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

Lattice 3 with un-updated spin axis nodes.

.

Lattice 3 with un-updated spin axis nodes.

Very good. I'll take another shot at the rest of your instructions tomorrow.Firstly, you convert the spin quaternion into an axis angle, ...

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

.

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.

http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToAngle/

.

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/

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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:

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;

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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.

.

**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.

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

.

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.

.

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.

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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.

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

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.

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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.

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.

~~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.

~~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.

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.

.

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**02 - s2**– the two**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.

.

Last edited by LongtimeAirman on Sun Nov 04, 2018 1:23 pm; edited 1 time in total (Reason for editing : [strike]neutrons[/strike] particles)

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

## Re: Possible Charged Particle Field

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.

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.

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

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?

**Nevyn**- Admin
- Posts : 1360

Join date : 2014-09-11

## Re: Possible Charged Particle Field

.

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.

.

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.

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.Are you talking about stacked spins?

.

**LongtimeAirman**- Admin
- Posts : 1044

Join date : 2014-08-10

Page **20** of **23** • 1 ... 11 ... 19, **20**, 21, 22, 23

Page

**20**of**23****Permissions in this forum:**

**cannot**reply to topics in this forum