Possible Charged Particle Field

.

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

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

We could, but what is the point? Then it would just spin with the particle and we would not need the spin node at all.

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

Do you have a pic of that? Can you see any kind of relationship going on? For example, if you change the orientation by 90° about the X axis, does that change the spin node by a corresponding amount, and on what axis.

The orientation should not change the position of the spin node. Only changing the spin should change the spin node.

LongtimeAirman wrote: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.

Try to get some pics of the distortions. I thought that I saw the spin nodes shrinking within the particle sometimes, but I could not find any code that should be doing that. I'm not even convinced that that is what I saw, but it certainly looked like it. Sometimes angles can make things look different than they actually are.

LongtimeAirman wrote:

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

Each particle only has 1 spin motion. Not sure what you mean by particles' different spin motions.

The bottom particle in Two Body 04 does not have a Y spin. It has an X spin. An X spin rotates around the X axis. It also isn't an end-over-end spin, it is just an axial spin. That's why I thought you were talking about stacked spins, because they do have end-over-end spins.

.

Here's a picture of spin node distortion. That's funny, I thought I was seeing elongation expansion, but the spin node around the proton below ‘close controls’ has elongated by selective shrinking. I'll take another pic if I see anything different. It's harder to see the spin nodes penetrating the green colored neutrons.

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

Nevyn. We could, but what is the point? Then it would just spin with the particle and we would not need the spin node at all.

Airman. I see spin nodes as a component of the particle armillary, the spin node duplicates the particle and provides all relevant spin details which can be turned on or off by the user. We might still incorporate collisions into the armillary as well.

Nevyn. Each particle has 1 spin motion.

Airman. One spin motion? The particle at the bottom of Two Body 04 has a y spin, the source for the proton emissions, as well as an x spin; the spin node shows a single x spin without regard for the yspin emission field. A particle orbiting a body has the two orthogonal velocities of curved motion or spin, but what if the particle is also orbiting something else, like galactic central? Isn’t cubic motion (orthogonal x, y and z velocities) a logical extension of pi=4?

One spin? It mostly bothers me that the  spin nodes don't seem to be portraying the particle's apparent motions very well. The nodes need improvement, I do hope we end up keeping them. I don't know if you are arguing for or against them. Please let me know if you think I’m mistaken – i.e. they may not work out.
.

I'm not arguing against them. I just want to make sure they are working correctly and that the underlying spins are working correctly.

Airman wrote:Airman. One spin motion? The particle at the bottom of Two Body 04 has a y spin, the source for the proton emissions, as well as an x spin; the spin node shows a single x spin without regard for the yspin emission field. A particle orbiting a body has the two orthogonal velocities of curved motion or spin, but what if the particle is also orbiting something else, like galactic central? Isn’t cubic motion (orthogonal x, y and z velocities) a logical extension of pi=4?

The purpose of the spin node (and velocity node) is to show what the app is doing to these particles. It is not there to show underlying stacked spins. It isn't really there for the user at all, it is there for us as developers. They allow us to see what is going on underneath our code and make sure that it reflects our intentions.

It doesn't matter how many orbits you put the particles in, they still only have 1 linear velocity and 1 spin velocity. The orbit is created by external forces upon the particle (or apparent forces) that change those velocities over time.

No, cubic motion is not an outcome of PI=4. PI=4 is an outcome of circular motion. It is the result of looking at the actual forces, rather than just the position of things and ignoring how they got there.

.

Thanks Nevyn, you're right. I've mistakenly interpreted the proton emission field as proof that our particles could display more than a single spin motion at a time. I'll try not to do it again.

I was going to add random locations to the Four Body group, but decided against it for the time being. I see that a Four Body 01 collision is a reliable source for distorted spin nodes.
.

.

Here's a better picture from Four Body 01 showing both protons and the closest neutron all with spin node distortions.

Separate subject. Nagging me for several days. It takes two program reloads to select Boundary (one reload), and then the boundary radius (the second program reload). Could they be combined into one program reload?

I've been puzzled by the mysterious function code you added In cdm.js right above - var PI_RATIO = 4/Math.PI;. I haven't gone into solve or search mode, but I've been awful curious - I have a couple of ideas. Just letting you know it's caused me some speculation.
.

LongtimeAirman wrote:Separate subject. Nagging me for several days. It takes two program reloads to select Boundary (one reload), and then the boundary radius (the second program reload). Could they be combined into one program reload?

Yeah, I'm aware of it, but haven't put any time into trying to solve it. It is just a result of the way the menu was initially implemented. Since then I have introduced Bootstrap which I could use to show a dialog box to get all relevant parameters before reloading.

LongtimeAirman wrote:I've been puzzled by the mysterious function code you added In cdm.js right above - var PI_RATIO = 4/Math.PI;. I haven't gone into solve or search mode, but I've been awful curious - I have a couple of ideas. Just letting you know it's caused me some speculation.

It's called a Closure. I've used them quite a bit in this app. They are a bit difficult to understand without knowledge of how Javascript is interpreted and executed. It relies on the fact that functions in JS are just an object like any other, and also the way variables are searched for if they are not defined locally. You can think of it as a way to declare a scope and that is exactly what I am using it for.

Since a function is just an object, it has a lifespan. Some functions are created, used and then destroyed quite quickly, others exist for the entire time that the application is running. Some functions look like they will only exist temporarily, but actually they will stay around for some time. The way I am implementing Closures fits into the 'looks temporary, is actually not' category.

Without getting too complex, I am using it to create variables that will exist longer than the function execution that uses them. In this case, I am declaring PI_RATIO which is then used in the following function. If I declared it as a local variable in the function, then it would be calculated every time that function was called. The way I have done it, it will be calculated once and then used as a value from then on, whenever that function is invoked.

In other cases, I use it to create objects once and use them repeatedly (usually Vector3 and Quaternion objects). This saves the time it takes to create them. I do this when I know that the function will be called every frame so that I don't need to create 60 objects a second, multiplied by however many objects that are used per frame (a lot). It all adds up and slows down the rendering process. Note that I can only get away with this because JS is single-threaded. If it supported multi-threaded programming then I would need to handle it differently.

So, in essence, I am creating a scope that will exist for the life of the app, so that the objects declared in that scope can be used without creating them or calculating them over and over.

.
Thanks for the explanation. I understand the need for a single source for ready answers to expensive calculations, the commented out code /*  */ above var PI_RATIO had my interest, it looks like your angular speed calcs.

Bootstrap worked great for the Help section, I didn't realize it could allow the user to set program parameters too. I'm on the Bootstrap site, https://getbootstrap.com/. I also wondered about cloudflare, now I see where it came from.

I'd like to make a change to our UI, but I haven't done so yet. Let the user select the number of particles and the min/max speeds for the collision scenarios. It's good to know we have a choice in implementing such a change - our control panel or Bootstrap - I suppose it means more complicated maintenance. How do I go about making changes to the Bootstrap code? Should I download it or it's documentation? If you have special plans or wish to pre-coordinate any Bootstrap preferences, let's do so.
.

That commented out section above PI_RATIO is me transforming the velocity-to-angle equation into an angle-to-velocity equation. I left it in there in case I got something wrong and needed to refer to how I worked it out. So, yes, it is my angular velocity equation being transformed into a different form.

Bootstrap isn't doing anything for us specifically, it is just a library that provides useful user-interface related things. Generally, all it does is change the way they look, but sometimes it also changes the way they operate. We could do it all without Bootstrap, but it wouldn't look anywhere near as good or polished.

So Bootstrap won't be setting any program parameters, we will use Bootstrap to show a dialog box that lets the user enter those parameters, and then when they press the OK button, it will reload the page.

Similarly, if you want to let the user make some choices when the page loads, you would show a Bootstrap dialog from the scenario init function and then use the values entered to initialize that scenario.

There is a problem with that second approach. Generally, when you use a Bootstrap dialog box, you define it in the HTML. However, I would prefer that we don't do that, as it will tie the scenario to the HTML and I don't want that. Instead, we should build the dialog box in code (which Bootstrap usually supports). That way, the scenario is completely defined with its own JS file and does not link to any other files. I want them to be self-contained.

In saying that, it is generally easier to define the dialog box in HTML and then get your code working. Once it is, we can look into moving it to the code. Don't get held back by trying to do everything at once.

What I have been thinking about, is creating a new class that will take care of these types of things for us. It will have methods to get a value from the user given a message, or present a form containing multiple values, etc. Basically, this class will hide how that happens from the rest of the code. Then, if we later decide that we want it to work differently, we can change it in that class, and everywhere else is ready to go.

If you can work out what parameters you want and list them, then I can define the class and methods to get them from the user for you. Once we have that working, it will be so easy to add to other scenarios that we will probably redefine the whole user interface with it.

.
Does this sound ok? It applies to the Colliding group Direct 01 and Direct 02.

Three requested values. (The program variables). (The number constraints).
1. Minimum velocity. ( var startVel; ). ( 0 <= Minimum velocity <= Maximum velocity <= 60 ).
2. Maximum velocity. ( var stopVel; ). ( 0 <= Minimum velocity <= Maximum velocity <= 60 ).
3. Number of collision sets. ( var edgeZ; ). ( 1 =< collision sets <= 18).  

If there is just a single collision set selected, the moving particle(s) will travel at the Maximum velocity selected.

If there are two collision sets selected: one particle set would travel at the minimum velocity; and the other particle would travel at the maximum velocity.

The velocities of the collision sets greater than two and less than 18 ( the maximum) will be interpolated linearly between those two limits.

Negative values will be converted to positive(?).
.

.

Ok, I see you've created a new user interface (UI) for Gravity - Random 06. It starts with the above image.

The code:

Code:


 ui.createForm().title( 'Gravity Scenario' ).message( 'Various scenarios based on gravity.' )
 .control().message( 'Radius' ).value( 100 ).min( 10 ).max( 1000 ).step( 10 ).add()
 .control().message( 'Count' ).value( 300 ).min( 2 ).max( 500 ).step( 1 ).add()
 .success( success ).cancel( cancel )
 .show();
 return null;


Its a Good draft. Simple, straightforward, easy to use. I'm surprised I don't see the radius and count message labels.

It appears the same for Chrome or Firefox Developer.
.

I'm not sure why the labels aren't showing. They are put in there, and should show above the input control for it. I had a more important problem to fix though. The way the scenarios returned the ParticleArray object was a problem because to use a UI like this, you have to let the program continue on before it will show the dialog box. You use the values by implementing a function and attaching it by calling the success method (and a similar one for cancel that uses default values). so I had to change the way test.html was using the ParticleArray so that some scenarios could return a null value and the system would still operate without errors.

Ok, I just had a look and I can see why the labels aren't showing. The value of the message is not being set on the label. Doh! I'm at work, so I can't fix it until later today, but if you want to, just add this line at js/utils.js line 232:

Code:


d.html( params.msg );


I am thinking about changing the way the success and cancel functions work. They currently must find the values themselves, but I think I can extract those values, put them into an array or map, and then pass that to the success or cancel function. This will remove the need for 2 functions and you can just register 1. The UIManager will then call it with the appropriate values.

I will add support for drop-down lists and checkboxes soon. It currently supports text and numbers, which will be fine for most cases.

.
I quickly added js/utils.js line 232 because I'm right in the middle of it. Pardon me, I also changed msg to message because I also spent time looking for the label problem. Probably needs changing back. I never would have come up with your new line 232.

Good - get rid of the success/cancel alternatives; I'm having a devil of a time trying to re-define the new Colliding group scenario, Direct UI into success and cancel functions. I'd probably need two duplicate functions with either the: 1. selected values; or 2. preset values.

I'm thinking the first scenario of the group, should be designated Group UI to convey the fact that the user will receive additional information of the scenario group or allow user selectable variables. The rest of the group's scenarios, 01-07 provide our existing preset variables.
.

To implement the success/cancel callback functions, put the general code to setup the scenario into another function, much like we have in various scenarios. Then you call that function from the success/cancel functions with the appropriate parameters. We should be able to remove a lot of the scenario menu options by using dialogs.

Code:


(function( ScenarioJS, PIM, THREE )
{
   var initMyScenario = function ( p1, p2, ... )
   {
      ...
      return new PIM.ParticleArray( ... );
   };

   var init = function( factory, ui )
   {
      var success = function()
      {
         // TODO get values from ui
         // call init function
         var pArray = initMyScenario( p1, p2, ... );
         // set particles
         ui.setParticles( pArray );
      };
      // setup and show dialog
      ui.createForm().title( 'My Scenario' )
         .control().message( 'p1' ).value( 100 ).add()
         .control().message( 'p2' ).value( 300 ).add()
         .success( success )
         .show();
      return null;
   };

   var group = 'Gravity';

   ScenarioJS.addScenario( group, 'My Scenario', init );
}( ScenarioJS, PIM, THREE ));


Retrieving the values is currently up to you, and it sort-of requires knowledge of what the UIManager is doing, although there is a way to specify it yourself.

Essentially, the input controls have an ID attribute that can then be used to find that control. You can specify one yourself by using the id method in between a call to control() and add(). Like this:

Code:


      ui.createForm().title( 'My Scenario' )
         .control().id( 'p1' ).message( 'My Param 1' ).value( 100 ).add()
         .control().id( 'p2' ).message( 'My Param 2' ).value( 300 ).add()
         .success( success )
         .show();


Then you use JQuery to find that element like this:

Code:


      var success = function()
      {
         // get values from ui
         var p1 = $( '#p1' ).val();
         var p2 = $( '#p2' ).val();
         // call init function
         var pArray = initMyScenario( p1, p2, ... );
         // set particles
         ui.setParticles( pArray );
      };


If you don't specify an id, then it will use a generated id with the prefix value and the order number of the control as added to the form, starting at 1.

Code:


      var success = function()
      {
         // get values from ui
         var p1 = $( '#value1' ).val();
         var p2 = $( '#value2' ).val();
         // call init function
         var pArray = initMyScenario( p1, p2, ... );
         // set particles
         ui.setParticles( pArray );
      };


JQuery is a nice library to use and can simplify a lot of web development by homogenizing things that different browsers do differently. Here we are using it to select an element based on its ID, but you can do many other things with it. You don't need to use JQuery for this, but it is available because Bootstrap requires it and I generally use it if I am doing a lot of HTML manipulation.

To do it without JQuery, you would do this:

Code:


var element = document.getElementById( 'value1' );
var p1 = element.value; // this can be different depending on that actual element type which the JQuery val() method takes care of for us


But I want to change all of that anyway. I can do that in the UIManager and just pass in the values so these functions will become more streamlined. So I wouldn't go too far changing scenarios to use this just yet. By all means, have a play with it in one scenario, knowing that you will need to change it before too long.

.
It sounds like a plan.

It would be ideal if each of the Group’s scenario alternatives could be selected or selectable from the Group’s UI page. For example, until yesterday, the Gravity group had five scenarios whose only differences were general random settings. It makes good sense to replace them with a single UI. I can finally dial up my preferred number of Gravity particles – four. Of course the Group’s UI page should also include its own pared down scenario list to choose from.

I can almost follow the code. After my previous post I looked more closely at UI changes and was over my head. HTML 5? Suggesting I play around with it before you change it again is a bit more than I’m capable of – almost. Your use of normal developmental jargon throws me. Mention of JQuery lost me completely. Ok, JQuery is a nice library - of what? You don't have to explain everything; It just takes time. Form creation is a long way from charge fields but I’m grateful and happy for the opportunity to learn it in service to you and the charge field.
.

I use the jargon because it will allow you to search on it and get more information if I haven't written enough. If I water it down too much, it will make it very difficult to do any research, if needed.

I try to include code examples to show what needs to be done. It can be difficult to judge how much to explain sometimes.

A lib like JQuery is a huge thing. I just wanted to show what we would be using it for rather than get into what it could be used for. Same for Bootstrap, but at least with that I can just say it is a UI type of thing. JQuery covers UI stuff, element selection, style sheets, events, and a heap more that I can't remember or don't even know. Right now you can just think of it as a nice way to find things. It should be hidden from you soon enough.

At this stage, it is enough to be able to look at the examples, or the code itself, and see that a particular line is retrieving a value, say, even if you don't understand how it is doing that. A lot of development gets done that way. We all just copy/paste, get it working, then try to figure out why it works. Eventually you start to understand more and more and can decide when to use certain tools/techniques over others. But we all started without knowing much about anything and we all just toyed with it until we did.

The commits I pushed last night were fairly low level. It is dynamically generating a modal dialog box, and the controls it contains, based on information we supply. You don't really need to know much about that as long as you can use it effectively. I wanted to create the UIManager class just for that reason. It is there to hide the complexity of UI interaction and provide a common place for it, so that we don't need to implement all of that in every scenario. As a bonus, it allows us to make changes to the UI in one place and all scenarios will be updated without needing to be touched.

I fixed up the UIManager so that it passes the values into the success callback function. If the user cancels the dialog box, it will gather up the default values for each control and pass those into the callback function. You can still specify a different cancel callback, but if you don't, then it will use the success callback instead. This allows you to only use one callback function if you want to, and that is what is most useful to us for this app.

There are some requirements though. Each control must have a default value. You specify that by calling the value method when creating the control.

Code:


var initRandom = function( factory, ui )
{
   // we can use only the success callback because we have specified a default value on the control
   var success = function( values ) {
      // we can reference the values by their id specified on their control
      var radius = Number( values.radius );
      var count = Number( values.count );
      var particles = initRandomTest( radius, count, factory );
      var particleArray = new PIM.ParticleArray( particles );
      ui.setParticles( particleArray );
   };
   // create a form for user input
   ui.createForm().title( 'Gravity Scenario' ).message( 'Please enter some parameters for the model.' )
      // add a control to specify the radius to position the particles in
      .control().id( 'radius' ).message( 'Radius to place particles' )
         .value( 100 ).min( 10 ).max( 1000 ).step( 10 )
         .add()
      // add a control to specify the number of particles
      .control().id( 'count' ).message( 'Number of particles' )
         .value( 200 ).min( 2 ).max( 500 ).step( 1 )
         .add()
      // add the callback function
      .success( success )
      // show the dialog
      .show();
   return null;
};


Also note that you can specify an id for each control and then use that to reference the value in the parameter passed to the success function. If you don't set the id, it will be valueN where N is a positive integer > 0 and is the index of the control on the form.

What you might be finding difficult with this new stuff is the idea of a callback function. It takes a little while to get used to the concept.

Javascript is a single-threaded environment. There is mutli-threaded execution going on, but the developer can not control it and knows that their own code will be executed as if it is single-threaded. You can do some things as a result of that and I have made use of them in this app for performance improvements. However, a consequence of that is that the UI can not be updated unless your own code stops execution. There is no way to wait for the user to enter data or perform actions, etc.

So the concept of the callback function was used to allow you to hook into other code. In JS a function is just an object, so we can pass them around and store them and invoke them whenever we want to. Our current case is actually a good example, so we will go with that.

A dialog box is used to present the user with some controls to enter data, perform actions, etc. Ignoring the controls for now, think about just the dialog box. It really has 2 events: success and cancel. The user can press the Ok button or they can press the Cancel button (or escape or various other actions). The dialog box needs to provide a way to let its caller know that the user wants to proceed or cancel.

So the caller registers functions with the dialog box that it wants executed in those situations, or events. The calling code is saying 'Hey, call me back if the user presses Ok.'.

I used to see a function as something that is declared and something that is invoked. The idea of storage was non-existent. The idea of passing them around was totally foreign to me. You passed around objects and objects had functions, but now functions were objects and it took me a while to see the real power in it. Callback functions were probably the first way that helped me through that, but there are others.

.

Colliding - Direct UI in mid test. Here, two each, two particle collision sets were entered.

I’ve got the new user input scenario Colliding - Direct UI (Direct, as in ‘head-on’ collision with user interface – ow ) I requested, or well started, anyway. How could I not? You’ve provided plenty of code and guidance to go back to. Thanks.

I’m almost certain I’m learning, and enjoying it too. The idea this program is single threaded is amazing. Never having considered it before, I guess the hook you refer to is a mechanism to allow one to interrupt the program flow, and redirecting it depending on what functions are available from the UI’s ‘dialog box’. My idea of fun. The UI’s main negative I see is another page, the increased time or delay before executing a program requiring what? Cloudflare handshaking. What is that all about?

You mentioned including more Bootstrap UI functionality. Meanwhile I’ll add another UI or two. Oh no, I forgot to check number types, the variables edgeX and edgeY should be integers. I wouldn’t enter erroneous values unless I were testing or mistaken; but who knows what kids will do. Don’t we need a bunch of logical checks?

The bottom of the Scenario’s Gravity group is Random. The next group is Random. Suggest changing the first by adding UI, making it the Gravity Random UI. Or not, just trying to show I pay attention occasionally.

Thanks, plenty to do.
.

Cloudflare is a CDN (Content Delivery Network) and it is being used by this app to retrieve a Bootstrap plugin called popper.js. It is used to dynamically place dropdown menus. While we aren't currently using it, we will be shortly. I noticed that it would slow things down a bit too. We can pull it into our own code base and just serve it with our own JS files if it is a problem. It can also be a problem if your internet connection goes down because it will stop the page from loading.

Yes, you must make sure that the values retrieved from the user are valid and in a state that you can use them. In the gravity scenario, I used the Number function to make sure that they are a number, but I should have actually made sure that they are an integer, which can be done like this:

Code:


var myInt = parseInt( values.radius );


I wasn't thinking about the next scenario group when I made that change. Good call. It should be changed to something else. Maybe 'Randomized'. Feel free to make it something else or change the order of the scenarios, which you do at the top of test.html:

Code:


<script src="js/scenario/proton-stack.js"></script>
<script src="js/scenario/gravity.js"></script>
<script src="js/scenario/random.js"></script>


.

I can report some small progress, a second Colliding group scenario with user interface. Here’s a screen shot of Lattice UI, 4 neutrons colliding with a 2 by 2 by 2 proton Lattice.  

Thanks for the parstInt() command - I'd never crossed paths with it before. Googling parstInt() led to Mozilla and GeeksforGeeks, which has a math section I’ve been looking for - I'll go back again. I also gave jQuery a couple of looks, I think I understand what it is a little better. I cannot say I used parstInt() correctly, as my style seems to be more a sort of semi-appropriate crude force. It seems to work.

This business with the UI side-tracked me. There's still some Graphics work to be done. You mentioned post collision spots of some time duration on particles. I hope to be able to demonstrate pre and post collision spin and velocity vectors as additional markers, along with the armillary. Please excuse my enthusiasm.
.

.

More progress. The Offset Pair UI.

The scenario shows a collision between two offset particles (1.95 * the particle radius in the Y dimension). I just put a user interface on Colliding, Offset 02. The user can change the spin state of the ‘stationary’ target particle; its spin axis can be X,Y or Z, and its spin speed can vary between -10 to 10 (*Math.PI/2).

The goal here is to show how the program handles offset spin collisions, Offset Pair UI does that very well. We can add orientation. Of course, my programming is less than ideal; nevertheless, this scenario could develop into the full blown spin collision scenario I thought Spin 01 would become.

As is, Offset Pair UI might replace Colliding, Offset 01 and Colliding, Offset 02, but I didn’t want to do so without your approval. Given the two previous, Array and Lattice UIs, I could also eliminate Direct 02 and Direct 03.

I believe you’ve used Offset 02 to work the spin collision problem. With that in mind, I’ll share my impressions of the collision results for 6 number pairs: (spinAxis/+/-spinSpeed); 1,+/-1; 2,+/-1; 3,+/-1. Pre and post spin, for each; left arrow, left arrow again and again.  I’m far from certain, but here’s what I think I see:
1/1 looks ok
1/-1 looks wrong possible backwards y spin?
2/1 looks ok.
2/-1 looks ok.
3/1 looks like too much backward z-spin.
3/-1 looks good.
.

.

A new Random group scenario, Select UI.

The previous Gravity group’s Scenario with user interface features only neutrons - their number and distribution radius. The new Random scenario Select UI allows the user to specify the: number of particles and their distribution radius; but also the protonRatio; velocityRatio; and orientRatio.  

That bit of thickly occupied space above the UI are pTotal ( len sounds eh ) particles within the distribution radius times math.random for each dX, dY, and dZ. It doesn’t appear very random – more like an artifact when it’s so compact and full.

P.S. Sorry, the UI quantities for the number of particles and distribution doesn't agree with the image shown; I think it was 200 particles, 50:50, in a 100 radius.
.

I am happy for some scenario menu items to go, once they are replaced with a better alternative or they just aren't needed anymore.

Not so happy with the way you have handled the Spin Axis assignment in the screenshot above, but that is not your fault. I have yet to add support for dropdown lists or radio buttons, which would be the preferred ways to do what you are doing. I have had a look into that, but haven't put much time into it.

That is a lot of controls in the Random scenario UI, if we need any more than that on the one form, then I might look in to allowing tabs to be used in these forms.

I will also look into adding support for sliders.

I think we should have tabs with the first one being a description of the scenario and it will be showing by default. Then we can add other tabs for the user input. It forces a click to get to the controls, but I think it is better to give the user some idea of what they are about to see. The Ok and Cancel buttons will always be displayed, not part of a tab, so the user can always easily select the defaults.