Possible Charged Particle Field

.

EQP46 with the desired particle orientations - all n/s  axii (green) are aligned to the center of the configuration.

Thanks, Nevyn, as you see, that worked perfectly, much easier than I had expected. I believe this should be the default particle orientation for all the spherical configuration scenarios. I'll mess with it a bit before I Push it.
.

Being neutrons, I don't think the orientation should matter. It won't hurt either, but maybe add a check box to turn it on/off so it is easy to get back to axis alignment if it is necessary. It can sometimes be useful when working out how things are reacting to forces, collisions, etc.

.

The latest Poly Points interface.

I included the ‘Align to center of configuration’ (or ‘Align to the world axii’) pull-down choice in the remaining spherical configuration scenarios. Above is the latest Poly Points scenario interface, it’s the only one that includes a ‘Reverse particle types?’ checkbox.

Poly Points is also the only sphere configuration scenario with moveable – gravitationally attracted and charge repelling - particles. Below is a screen shot of the output. Having various alternatives including spherical aligned protons may make things more interesting.

The Unmoveable group scenarios 60 Neutrons and 130 Neutrons are redundant and should be removed. Please nod your head or say the word so I can delete them.

I like the Proton parameters tab of 60 and 130 Neutrons, so I may also include that in Poly Points as well. Or the unmoveable spherical scenarios could move into the Unmoveable group, but the Unmoveable group already has seven choices.

Next, I’ll try further consolidation by utilizing a single factory function call to place all spherical particles, rather than including the particle placement code within every scenario.
.

.
Ah, I see you nodding, very good, I’ll delete 60 and 130 Neutrons tomorrow, but that smile(?!). I’m quite code blind at the moment,  
making over a thousand changes last night and today, not counting the screw-ups. That must explain the smile. I think it needed doing, I knew what I was getting into and committed myself anyway. A day later I have a much greater appreciation of the extent of that simple change, mostly enjoying the revelation, having completed: Poly points(octa, cube, icosa, dodeca, hoso26 and icosa60), EQP, Golden, and Kogan algorithms. I'll give EQS and EQS Mods more thought - tomorrow.
.

.

Pretty Unmoveable velocity vector artifact.

Ok, Unmoveable scenarios 60 Neutrons and 130 Neutrons are deleted. EQS Points and EQS Mods are complete. Previous spherical arrays: xPts, yPts, and zPts were converted to the three vector3 points array, and all spherical configurations (not including Parallel Particles or Particle Ring scenarios) are handled by a single particle placement factory function. I’ll push the changes in a couple of hours.

This morning I noticed all the spherical configurations were imploding. I corrected my previous unmoveable code error so once again, only Poly Points particles are free to move.  Now it is a MUCH simpler matter to convert all the sphericals into a single scenario - with several tabs, or two scenarios to keep Poly Points separate.
.

.

Tetrahedron configuration.

I'm on a roll. Three changes. The first two in Poly Points:
1. Added a tetrahedron configuration. Given the improved modularity/organization of the sphericals, adding a tetrahedron points creator pPositionTetra( radius, points ) and the new option to the Poly Points’ pull-down list amounted to just 25 code lines. And almost no screw-ups!*
2. Added the option of the Proton parameters tab, relocated from prior spherical EQS factory code, then I cleaned up all the forms.
3. General cleanup. I Removed random additions from all the spherical point set calculations. I realized random should only be added during particle placement.

I should mention, I don’t think I’ve seen Kogan particles stuttering - rapidly changing spin directions several times; although I have seen high EQP particles stutter. It may be my imagination that the Kogan precision group reacts smoother. I’ll keep watching, I guess I need to come up with a good comparative performance measure.

*One of my unstated goals in coming up with the standard points array was the idea of performing configuration rotations. For example,
unfortunately, the tetrahedron is configured such that two neutrons are in the proton emission plane and the other two neutrons are above and below that plane. I want to be able to arbitrarily reorient the entire spherical configuration such that none or just one neutron is in that plane. Instead of recoding pPositionTetra, I could either reorient the proton’s emission axis or the spherical configuration (or both). I believe the algorithm reorienting the particles to the configuration center you provided a few days ago should suffice.
.

.

Configuration rotations are added to the sphericals. The top right image is the Octahedron configuration rotated 90 degrees about the z axis. The bottom right is the same (octahedron) configuration rotated 45 degrees about the z axis.

The user enters the axis and the amount of rotation. They can fine tune reconfigure as many times as they like. I didn't need anything more complicated than the three.js apply axis angle code.

Code:


     var vector = new THREE.Vector3().copy( points[i] );
     vector.applyAxisAngle( axisA, deg );
     points[i] = vector;


I'm out of ambitious ideas at present, I'll review and clean up the latest changes next.
.

.

The center particle can now be reoriented in the spherical configuration scenarios. The top left shows the cube configuration. The top middle results from rotating the cube configuration 45 degrees about the Z axis. The top right then includes reorienting the center proton 90 degrees about the X axis.  

I'm happy with the latest Poly points and the spherical algorithm changes. I'm done for this go round.
.

.
I found more to add to Poly Points.


The Rhombic Dodecahedron, Rhombic Triacontahedra and 120 Polyhedron.

Long before I discovered Miles and the Charge Field, before the bulk of my degree programs. I studied R. Buckminster Fuller’s Synergetics. I read through both volumes over a couple of years. To be completely honest, it took me many months to simply understand his jargon and ideas, or what I thought he was saying; but I studied his math because I could see how a world geometry based on the tetrahedron - a 60 degree coordinate system, would be better than the Euclidean ( x,y,z ). I’ve made several tensegrity balls and structures, including jitterbugs, but not much since then.

I recently ran across the work of Robert W. Gray, from 2000, Polyhedra Coordinates
http://www.rwgrayprojects.com/Lynn/Coordinates/coord01.html
http://www.rwgrayprojects.com/Lynn/NCH/whatpoly.pdf

Here are the 62 (x, y, z) coordinates for the 120 Polyhedron.

• 10 Tetrahedra
• 5 Cubes
• 5 Octahedra
• 5 rhombic Dodecahedra
• 1 Icosahedron
• 1 regular Dodecahedron
• 1 rhombic Triacontahedron
• many jitterbugs

There are edge and surface maps to go with the each set of vertices. Robert W. Gray is true to the spirit and intent of Synergetics. I easily imagine the 120 polyhedron swelling or diminishing volume along with surface vertex rotations – jitterbugging.

You may note that there are ten independent (overlapping) tetrahedrons within the 120 polyhedron, but I just needed one. Same goes for the 5 each: Cubes, Octahedra and rhombic Dodecahedra. I copied the list, and so added the Rhombic Triacontahedra and 120 Polyhedron to the alternatives in the Poly Points spherical scenario.

Poly points allows the user to vary the radius and/or reorient the configuration, that and the fact that the calculate statistics efficiency function isn’t needed for the polys, suggests I convert the calculate button into something useful, like outputting the current – resized and reoriented - points[] array.

The idea of using a single list of 62 coordinates to draw all the regular and rhombic polyhedral forms from seems good to me. That is, as long as the list is correct. I coded the table in an hour or two; and found and corrected my error after another two. I need to find the correct distance multiplier between what I used before and this new table. I’ll move from the several points[] list creations functions from the current – i.e. pPositionTetra – to the single new function, polyPositions62, before deleting the old.

Feel free to add.
.

.
Hey Nevyn, I hope you don't mind, I’m begging for help again.

Using Poly points’ Control tab I can output the unrotated configuration points array list, but I’ve had no success outputting the rotated configuration’s points list. All I get are NaNs. Such as this console output: axisA[0]: undefined,  axisA[1]: undefined,  axisA[2]: undefined,  axisA[3]: undefined.  radius: 10.  num: 8.

I can perform the configuration rotation in either the particle placement factory function or in the polyPositions62 function - after the points list is created, so I’ll probably put it in polyPositions62. In either case I’m unable to obtain the axisangle form values.

Code:

.control().id( 'axisangle' ).message( 'You may reorient the configuration by specifying an axis to rotate about, and the number of degrees to rotate it' ).axisAngle( -10, 10, 1 ).value( [ 0, 0, 0, 0 ] ).add()

Here’s one no joy Poly points’ event function variable list with qua instead of axisA, I've tried several variable combinations.

Code:

var num = $( '#nPoints' ).val();
 var radius = $( '#sphRad' ).val();
 var qua = new THREE.Quaternion();
 qua[0] = $( '#axisangle[0]' ).val();
 qua[1] = $( '#axisangle[1]' ).val();
 qua[2] = $( '#axisangle[2]' ).val();
 qua[3] = $( '#axisangle[3]' ).val();
 //var axisA = new THREE ( qua[0], )
 var axisA = new THREE.Vector3( qua[0], qua[1], qua[2] );
 var degA = qua[3];
 var points = [];
 var xPts = [];
 var yPts = [];
 var zPts = [];

How do I properly obtain/pass the four axisangle values?
.

Code:


 qua[0] = $( '#axisangle[0]' ).val();
 qua[1] = $( '#axisangle[1]' ).val();
 qua[2] = $( '#axisangle[2]' ).val();
 qua[3] = $( '#axisangle[3]' ).val();


This is the problem. You can't reference the array values from within the JQuery selector: $( '#axisangle[0]' ). You have to access each individual control for each value: X, Y, Z and A.

Code:


 qua[0] = $( '#axisangle_x' ).val();
 qua[1] = $( '#axisangle_y' ).val();
 qua[2] = $( '#axisangle_z' ).val();
 qua[3] = Math.PI * Number( $( '#axisangle_a' ).val() ) / 360.0; // convert angle to radians


Getting the individual values like that is kind-of a bit bad. It is reaching inside where it shouldn't. If you can do this stuff in the scenario success function, where the values have already been processed and put into appropriate variables (an array in this case), then that would be better.

Code:


 var qua = new THREE.Quaternion();
 qua[0] = $( '#axisangle[0]' ).val();
 qua[1] = $( '#axisangle[1]' ).val();
 qua[2] = $( '#axisangle[2]' ).val();
 qua[3] = $( '#axisangle[3]' ).val();


You shouldn't put those values into a Quaternion, because they are not quaternion values. Just put the first 3 into the axis vector and the last into an angle variable:

Code:


var axis = new THREE.Vector3(
  Number( $( '#axisangle_x' ).val() ),
  Number( $( '#axisangle_y' ).val() ),
  Number( $( '#axisangle_z' ).val() )
);
var angle = Math.PI * Number( $( '#axisangle_a' ).val() ) / 360.0; // convert angle to radians


.

Now with axisAngled output points lists.

Thanks Nevyn. I did what I set out to do, thank you very much. Separate subject, Hoso26 and icosa60 need fixing.  

JQuery sounds scary. I didn’t realize “[]” means to assign the value and, and “.” means to read the value(?).

Do you know of a format guide so I can clean up the output table.
 
Nevyn wrote. If you can do this stuff in the scenario success function, where the values have already been processed and put into appropriate variables (an array in this case), then that would be better.

Your comment has me wondering how to comply. My factory function – positionParticleSphere – also includes which polyPosition62 to choose the points sets from; I guess I need to break that part of the positionParticleSphere factory function off. The new function, the placing of the particles, will necessarily be the actual factory function.
.

JQuery isn't that scary. In the first instance, it's just a way to select HTML elements based on type, Id or CSS class. In the second instance, it provides a lot of common ways to do things that are often different in different browsers. There-by making a webpage usable across many different browser implementations using common code for all. Believe me, this was a serious pain for a lot of years and one of the reasons that I did not do much web development in the past. I like to know what my code is going to do, not what it might do.

The [] do not assign a value. They just don't belong in a JQuery selector. They don't mean anything in that context.

The . doesn't really mean 'read' either. It means 'access'. Once accessed, it can then be read from or written to. Same with [], they are just a way to reference a single value in an array (or a value in an object in Javascript). Both of these are just referencing syntax, they don't care what you do with that value after it is de-referenced.

In Javascript, they are almost interchangeable. Suppose we had the following object:

Code:


var object = { id: 1, name: 'One' };


That object has 2 properties: id and name. We can reference both of those like this:

Code:


object.id = 10;
object['id'] = 10;
object["id"] = 10;
var id = object.id;
var id = object['id'];
var id = object["id"];


However, we can't do the same with an array:

Code:


var array = [ 1, 'two', 3 ];
var val = array[0]; // 1
var val = array[1]; // 'two'
// but we can't do this:
var val = array.1; // syntax error


As for code formatting, there are a million guides with everyone having their own preferences. I suggest you look over the code that I have written and try to format in that fashion. I'm not too concerned about it. Formatting is something that you get a feel for as you learn and create more code. You pick up little bits from different people and incorporate it into your own style. Personally, there are some more modern formatting methods that I don't agree with and others that I don't really agree or disagree with, but tend to stick to my own style when I can. There has been a big push for all developers to use a common style lately, at least within an organisation or project (my employer has pushed this over the last few years, for good reasons), but I just care about readability. As long as the code is readable and understandable (such as using appropriate variable names), then it's fine.

I realised after I posted that you can't use the scenario success function because you need to show it on the scenario dialog. Don't worry about it.

.

The Poly Points Output tab (sized at 90%) provides an initial coordinate points list for a selected configuration at any desired radius and configuration rotation.

Given the theory there's never too many, I've added two new Poly Points. The 14 vertice Cubeoctahedron – adding the vertices of the cube plus octahedron, and the 30 vertice - Five Octahedrons – all 5 of the 120 polyhedron’s intersecting, interpenetrating octahedrons. Now there are a dozen Poly configurations to choose from:
4 - Tetrahedron
6 - Octahedron
8 - Cube
12 - Icosahedron
14 - Rhombic Dodecahedron
14 - Cubeoctahedron
20 - Dodecahedron
26 - Hosohedron
30 - Five Octahedrons
32 - Rhombic Triacontahedra
60 - Truncated Icosa
62 - 120 Polyhedron

Everything seems to be working. I cleaned up the tabs. I don’t have any additional Poly Points plans. Nor do I see any good reason to provide the same changes to the other spherical precision algorithms, where each of the three lists can be several hundred numbers.  

In the tab I wrote “Or use this tab as a sort of spherical calculator to find a desired configuration/radius”. For example, I used the output tab for finding the edge lengths of the 120 Polyhedron’s cube configuration with radius = 1 .

Code:

8 vertices. Min = 1.155. Radius = 1. AxisAngle, axisA.x = 0, axisA.y = 0, axisA.z = 0. degA = 0.  xPoints: 0.577,-0.577,-0.577,0.577,0.577,-0.577,-0.577,0.577.. yPoints: 0.577,0.577,-0.577,-0.577,0.577,0.577,-0.577,-0.577.. zPoints: 0.577,0.577,0.577,0.577,-0.577,-0.577,-0.577,-0.577.

Note that sqrt(3)/3 = 0.577. A radius of ten would have worked as well. A trial and error result slightly different from the pdf source.

Have I neglected any applicable spherical calculation or function you had in mind? Despite overstretching the possible definition and behavior of charge particles, is there anything you’d care to add or suggest? If not, I’ll try to break free – I haven’t seen any other new compound polys yet - before moving my go round to another scenario.

Nevyn, I'm just a worker bee, thanks again for your time, oversight and making it possible. It has, without a doubt, been a wonderful learning opportunity and experience. Agony and fun. Please feel free to redirect or task me otherwise.  
.

.

I believe I can finally check off an old wish list item of mine - making a Star Field. It’s hard to tell from the image, but that’s what it looks like, streams of particles are both approaching or receding depending on the amount pf anticharge selected. The particles are definitely slower than in the old screensaver tutorial I included below, but these charge particles can interact through charge and gravity, orbiting and colliding. I believe it qualifies as a new Possible Charge Field scenario, Particle Stream. I wanted to make it months ago, but for the fact that it relies on the particle engine’s Portal boundary; the Elastic boundary also makes continuous loops of a flipping charge stream and increasing side traffic. I don't believe that using Portal in any way diminishes the charge field aspects of the resulting particle interactions.


Three.js part 1 – make a star-field http://creativejs.com/tutorials/three-js-part-1-make-a-star-field/index.html

Tutorial
Time required : 30 minutes
Pre-requisites : Basic JavaScript and HTML. Some Canvas experience useful.
What is covered : The basics of three.js and using the Particle object.
Now updated for three.js revision 48

Sorry about the outdated three.js. The quote says it takes just 30 minutes to complete; good luck.

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

I added a thirteenth (making a baker's dozen) Poly Point configuration, 24 - Snub Cube 38F(6Sq+32Tri). I used a points list taken from,
Min-Energy Configurations of Electrons On A Sphere

https://www.mathpages.com/home/kmath005/kmath005.htm

/////////////////////////////Spoiler Alert\\\\\\\\\\\\\\\\\\\\\\\\\\\\


.

I'm not sure where to go from here. Any new scenarios you can think of? Maybe it's time to think about a new app. Look for some problem that interests you and see if you can wrap some code around it. Don't worry to much about the page itself, just try to code some math for it, figure out what data you might need, how you might structure it into an object, and see how they relate to each other. Basically, find something interesting and dive in.

.
I agree, all things must pass, or at least we need a break. I wonder what the readers think, all the available evidence seems to indicate they are bored to tears. Here's a quick feedback summary.

For starters, I like the Possible Charge Particle Field’s initial random scenario you made. It’s a one-of-a-kind view, this particle engine is unlike any other, as befits the Charge Field itself. Each initial random distribution is a kind of complex three dimensional character/opening credit/scene to divine as the interactions begin.

I regret not understanding the engine’s proton charge emission profile well enough to mess with it. As I stated previously, I would have liked to change the main emissions from the current equatorial to +/-30 degrees.

My main complaint - the engine needs other sized charged particles. On the other hand, we don’t really show the true nature of sub-atomic charged particles. We know photons generally enter the charged particle poles and are emitted in all directions. We should be see the gyrating motions of the topmost stacked spins Instead of the perfect ‘pool ball’ we now see, which leads to my main suggestion.

My main new app suggestion would be one that shows the charged particle as a charge engine. With two way charge current through the larger particle in accordance with charge recycling, nested stacked spins, angular spin velocities and gyroscopic motions. Unfortunately, we may have irreconcilable differences on the subject. We might brainstorm additional ideas, but I'd suggest we work on something you want.
 
In all sincerity, you’re the boss, and most of the brains. I’m at your service, delighted to work on the charge field project of your choice. But for all I know, I’m more a burden than a team mate, I hope not. I’d argue this is a great cause, and what do you expect from a retired public servant?
.

Definitely not a burden. My initial goals for this project were to create a framework that allowed you to play and learn as you go. To get you familiar with programming concepts and comfortably translating between math and code. I think we achieved those goals, and even more than that, we actually created something interesting and useful. Is this the end of it? No way! We may come back with fresh ideas at a later date.

I've been thinking about a new app recently, and I'm still figuring out how it fits together, but it might be on the same path that you mentioned. You want to show the charged nature of charged particles. What I've been thinking about is a scattering app. The user selects a target, which will be a particle in the first instance but it could be expanded to include atoms and molecules later, and they also select a type of gun and what sensors to use to record the data. When the model runs, the gun(s) fire bullets at the target, which may collide with the target and bounce off.

I imagine a bevy of gun types could be created. Single shot, multiple guns in different positions, spherical arrangements. We could even use your spherical algorithms to create points to shoot from. I definitely want some sort of random bullets from all directions kind of thing, as that will hopefully show the emission of a proton, for example.

To implement this, the charge photons (bullets) need to be real entities. I am playing with some ideas on how to handle lots and lots of bullets at the same time. I am using instancing at the moment, but I'm not convinced it will help as much as I thought it would because I have to update all of the bullets in the javascript code, not in a shader where it would be fast. Which is unfortunate, but unavoidable.

Each bullet has a color, so it can be updated to a different color for bullets that collided with the target. Each color also has an alpha channel, so we can make them transparent too. For example, the user might choose to make un-collided bullets transparent so they only see what actually collides.

I had some thoughts about creating sensors that would record the bullets in some way. For example, you might have a spherical sensor that wraps around the target at some radius and records the bullets that hit it, showing the charge profile of the target. A probe might have a position in the scene and record what hits it. A sheet might record what hits a 2D plane at a set position and orientation.

The target particle will have stacked spins which will be calculated each frame to determine if bullets hit the BPhoton, not the particle that the BPhoton creates. The current motion of the BPhoton will be used to determine the force it has at the point of collision. I'm still not sure how to go about that, but I'm thinking that I will record the last location (or calculate the next location) to compare to the current location. The difference between those points, and the time between their measurements, will be used to calculate the velocity used in the collision. This allows different spin levels to add to and remove from the velocity based on their relative motions.

A lot of it is still just ideas, but I have started to code up some of the main players, such as bullets, particles, the basis of a gun, and a range that represents the environment (as in a gun range, sometimes you get stuck in a metaphor). Not sure where it will go at the moment, but I think it could be an interesting app.

.


Sounds good to me. Let’s see if I understand correctly, please excuse the very inaccurate pieced together autocad/paint image, description and attempt at light hearted humor.

We see an equatorial circular firing squad of a full spherical photon cannon array. All the photon cannons (green with blue barrel) are aimed and have sequentially fired photons (small blue dots), toward the center of the magenta particle. All photons penetrate the particle and will continue unimpeded unless the photon collides with the magenta particle’s b-photon – not shown. In the notional image above, the first photon fired has almost reached (0,0,0) while the last photon has just existed the cannon barrel furthest to the right.

Looking at it now, I see simultaneous firing might have be better, but test photons shouldn’t be allowed to collide with other test photons – so cannons shouldn’t point directly at the cannon on the other side of the target particle.

The red wire frame, yellow colored sphere attempts to show a collision detector that can discern photon/b-photon collisions by the trajectory of the exiting photon. From which one may calculate the collision location and the position of the b-photon at the time of the collision. The calculations may require that the detector be a volume and not a surface area. Are the particles spinning? Heisenberg must be rolling in his grave. The full set of test photons amounts to incoming charge as far as the magenta colored particle is concerned. What is the particle’s resulting scatter or emission pattern?

Hot/cold? Am I close? If so, where to begin?
.

Yeah, something like that.

The bullets will not collide with each other. We don't have to aim any guns to avoid that, it just won't be calculated in the code so it can't happen. Bullets also won't collide with the guns. The only thing they can collide with is the target.

The detector needs to know that a particular bullet has reached the target or not, and not record those that have not, even if they have not collided. This is tricky. Maybe the detector will change the state of the bullets that pass by its boundary to mark them as Armed. Then it will only record Armed bullets. This only works when the detector is inside of the guns. Maybe it won't have anything to do with the detector. The system will just have some radius where it arms the bullets (should we call them missiles now?) set by the radius of the target particle, and expanded by a small amount. Maybe 50%, or even 100% of the targets radius.

I've made a small start, just trying to see how it fits together and looking into rendering options. The main thing to do at the moment is probably just thinking about things we can implement for it. Gun types and arrangements. Detectors. I initially thought that I would make the bullets have stacked spins too, but it may be quite inefficient. Might look into that once we have a working system and see how it goes. I'm not sure how many bullets to expect at the same time yet. If it is low, then we can give them stacked spins, but if it is high, then probably not.

.
Some additional comments.

Your suggested new App assumes that the particle is opaque, we cannot see past its surface. We can only see photons entering and exiting the particle. Ok.  

As such we might expect, especially with pole to pole alignment, that shortly after a photon enters the particle, a photon is seen exiting the opposite side of the particle with the same trajectory. At which time we can be fairly certain, even in the presence of many random ambient photons – that that photon passed through the particle without contact with the particle’s b-photon or ‘Target’. Much of the time, we might see photons entering, then quickly followed by a photon exiting in the reverse or in an apparent random direction - from which we may infer that the photon collided with the particle’s b-photon or target.  

The proposed app allows us to fire test photons into the particle void. We can control the time, location, direction and spin of test photons entering the particle. Or we might be able to fire test photons at any location and test direction we like, as long as we know its trajectory. The Detector is a tracking device. It measures the time, location, direction and spin of the test photons entering the particle, as well as those same parameters for photons exiting the particle. Given the difference between the entry and exit data, the detector can reasonably determine the exact location of the collision between the test photon and the particles’ target. Perhaps we can have a spinning b-photon actual target model versus the detector returns to compare side-by-side. inside the 'particle space'. There are various ways one might display the detector output.

You admit the possible charge particle field’s particle engine provided ample means by which I could become more comfortable with code and math; I agree, I certainly feel more comfortable, thank you very much. In fact, this latest application idea sounds as though it were entirely designed for provoking more such code modelling growth. On the other hand, Miles has given us the rough ideas but the details aren’t there yet. I know the stacked-spin b-photon is a subject of central interest and importance. Cutting edge/simulating Charge Field behavior.

Give the detector the test photon launch controls, and I expect it should be able to improve the percentage of photon/target collisions - no, wait, no A.I. here. I would say the app needs plenty of ambient photons, the sooner the better. I won’t insist, but I believe the target is simply a single b-photon. For example, we may notice that the radius of the target is critical. Too small and collisions almost never occur. Perhaps there should be a way to vary the target motions in order to result in emissions more in line with expectations. That may lead you to believe there must be more photons involved.

Gotta go.

P.S. Oh my, corrected a misspelled Miles.
.

The target particle does not need to be opaque. It could be rendered in any number of ways. An opaque sphere at the particle's radius is one, only showing the spinning BPhoton is another, showing a transparent particle radius sphere and a spinning BPhoton is another. I lean towards the last option, or the 2nd one. I don't see much need for an opaque sphere at the particle radius.

I want to show the state of a bullet with color. A fired but un-collided bullet might be white. A fired and collided bullet might be red. If we use a concept like Armed, then an armed bullet might be yellow, or something. That allows you to see directly what is going on, even without detectors. The detectors, I imagine, will be used for saving results. It might create an image of the points where bullets crossed the detector boundary, showing collided and un-collided with different colors and also leaving gaps where no bullets crossed. It could also save it as raw data.

You mention controlling time and I definitely want that. The user should be able to slow it down to see what is going on in detail, or speed it up to get results fast.

The user will be able to specify the stacked spins on the target particle. I may use SPL to do that, or it might just be a basic number of spin levels.

I don't want to be able to change things to reflect expectations. I want it to reflect the theory and see what it actually produces. Of course, we have to be very careful that we are following the theory, but I don't want to put the cart before the horse. This app is very much a virtual scattering experiment, and as such, we must accept the results, even if they don't match what we expect. If things don't match expectations, then we can look into what we have created and determine if it truly matches the theory. If not, we fix it as best we can. If it does match the theory, but not the results, then we have to face up to that and see what can be done. This is a simulator, not a demonstration.

Created a new topic for this scattering app: https://milesmathis.forumotion.com/t551-virtual-scattering-application