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.

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:

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

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.

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

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

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

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

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.

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

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

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

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

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

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?

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

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