Possible Charged Particle Field

While the gravity math is in there, it has been disabled by default because it still needs work. You can now enable it in the scenarios just by including this line in the scenario function:

Code:


engine.applyGravity = true;


Or to turn it on for everything you can enable it in the ChargePointMotionEngine class constructor.

It still needs to be balanced with charge emission. I believe that charge emission should be the stronger force at the quantum level, but I'm not sure of the ratio.

Your new collision scenario had me all confused for a bit. I couldn't figure out why I couldn't see any of the particles until I rotated the camera and saw that they are a spiral coming in from the background. Looks pretty cool.

Your new collision scenario had me all confused for a bit. I couldn't figure out why I couldn't see any of the particles until I rotated the camera and saw that they are a spiral coming in from the background. Looks pretty cool.

A little confusion is good, turning things about is fair play. I was more concerned with someone losing patience and missing the action - the particles auguring in.

I suppose the main source of confusion is the ‘size’ of the particles. You were absolutely correct in ‘suggesting’ that I go back and link the separation of particle positions to a particle’s charge/emission/gravity radius. Our charge particles have a radius of 1 unit. The particle separation in the collision test configurations is now 22, each particle must be isolated by a volume of space over twenty cubed larger than the particle’s volume. The particles are thus further away and more difficult to see when they are surrounded by all that additional space. When the entire collision grid is visible, the particles appear very small. If the default Particle mesh is turned on, it’s especially difficult to observe neutrons from a pole position. For best viewing, one would turn on Charge axes and a higher Precision.
 
Do you have any particular directions with respect to changing the viewer’s Graphics and Precision settings, i.e. should we? Here, we may reduce user confusion by allowing the user to clearly see the neutrons coming. Of course one should allow the user to change it back.

Sorry the collision group struck you as ugly. Granted, my velocities were above that imposed by the frame rate; higher than one might expect during normal situations. I also seem to recall that not all collision bugs occurred at the higher speeds.

The collision test group now includes, (it still needs work): a lowest velocity – startVel, and highest velocity, stopVel. In Test 01, the range is broken into 10 incremental velocities. Eventually, a user would select the lowest and highest speeds using a control panel extension for this configuration.

You may not have noticed a single moving column colliding with a single stationary column in collision test 01. I believe there’s more difficulty in comparing final particle positions in the linear group when compared to the circular configuration.  

I would also like to portray the perfect collision’s final stationary position - two units away from the initial stationary particle’s position in the direction of the approaching particle - perhaps as a target strike zone box with gradation marks to allow measurements, deviations from the ideal.

Will we see electrons? I realize the frame rate for electrons is not the same as our charged particles.

Give some thought to whether a new configuration might be used to compare gravity and charge. Can we not compare those accelerations directly. Can we compare them with enabling/disabling alone?  

Please feel free to redirect or task me if I get too single minded.

Posting in a rush, the next wave is here.
.

LongtimeAirman wrote:A little confusion is good, turning things about is fair play.

Touche!

LongtimeAirman wrote:Do you have any particular directions with respect to changing the viewer’s Graphics and Precision settings, i.e. should we? Here, we may reduce user confusion by allowing the user to clearly see the neutrons coming. Of course one should allow the user to change it back.

Right now there are a lot of options, because I want to test them all and see the differences. I also want you, and anyone else, to find those differences and figure out why they are different. I actually spent some time yesterday thinking about a new way to show the charge points. Since I have been working with THREE.BufferedGeometry objects and per-vertex colors lately, I saw that I might be able to create a new particle sphere that contained the charge point locations directly on that sphere, rather than using lines that are external to it. So most of the particle would be the primary color of it (red for protons, green for neutrons) but where there is a charge point, it would be another color, maybe black since it goes with any other color.

What I soon realised is that it won't work for any arbitrary locations of charge points. I had to combine the precision of the sphere with the precision of the charge points in such a way that there were more sphere vertices than charge point locations, otherwise the charge point color would cover the sphere. They also had to be an integer multiple of each other. That is, if the precision of the charge points was 8, then the sphere would need N*8 vertices. This made it difficult to implement and I didn't get it correct, so I rolled it all back.

The main problem I had was that I would need to remove all of the different charge point precision options except for the Hosohedron ones. I could create the vertex colors I wanted with a Hosohedron because of the way it has been implemented with math, where-as a lot of the others use set vertices according to some pattern. I wasn't quite ready to remove them all. I am tempted though. The Hosohedron algorithm can be used to create the original NSEWFB positions and it increases in precision in a nice, even manner. I think that is the charge point location algorithm to use.

I think we can remove all of the precision options and just leave Cardinal, Low, Medium and High options.  If you are happy with that, then I will look further into it. Simplifying these options will provide more room for other features to be implemented, such as the per-vertex colors to show charge points.

LongtimeAirman wrote:Sorry the collision group struck you as ugly. Granted, my velocities were above that imposed by the frame rate; higher than one might expect during normal situations. I also seem to recall that not all collision bugs occurred at the higher speeds.

It wasn't the collision group that was ugly, just the collision errors.

LongtimeAirman wrote:You may not have noticed a single moving column colliding with a single stationary column in collision test 01. I believe there’s more difficulty in comparing final particle positions in the linear group when compared to the circular configuration.  

I would also like to portray the perfect collision’s final stationary position - two units away from the initial stationary particle’s position in the direction of the approaching particle - perhaps as a target strike zone box with gradation marks to allow measurements, deviations from the ideal.

Yeah, I've noticed those ending positions being out of place. Not sure why yet, but it only seems to happen with very fast velocities, so I guess some sort of math error. Maybe the initial collision is producing NaN numbers, which then get zero'd out to avoid everything collapsing, but then it works on the next frame. This allows it to proceed with its initial velocity for a bit farther than it should.

LongtimeAirman wrote:Will we see electrons? I realize the frame rate for electrons is not the same as our charged particles.

Electrons bring in a few problems. Yes, the frame rate is a problem but so is size (which are actually the same problem, really). The code is not quite setup to handle them at the moment. I have been slowly moving towards it, but haven't quite reached the point that it needs to be at to handle different radius and mass values.

LongtimeAirman wrote:Give some thought to whether a new configuration might be used to compare gravity and charge. Can we not compare those accelerations directly. Can we compare them with enabling/disabling alone?

Yes, that would be good, and necessary. We need to find the balance point, which should be done through theory, and we need a scenario to make sure that it works as we think that it should. Some of the existing scenarios should do the trick. The Two Body scenarios in particular should be able to show the repulsion of a proton being balanced by the attraction of gravity. Still, if you can think of something else, then just post it and we can work out the details, or just give it a go and see what you come up with.

Being able to enable/disable some forces is just a convenience. Some scenarios may not want to use all forces because they want to show some special behavior of one force. Like the collision tests. We just want to look at the problems with collisions, not be distracted by gravity or the ambient field.

.

I think we can remove all of the precision options and just leave Cardinal, Low, Medium and High options.  If you are happy with that, then I will look further into it. Simplifying these options will provide more room for other features to be implemented, such as the per-vertex colors to show charge points.

The current nine Precision options, with no clear differences or rationale for selecting one over another except more or less pink Charge lines are too many. Limiting them to Cardinal, Low, Medium and High would be better.

Oh, I failed to mention earlier, I definitely prefer the lat/long particle mesh, they look neater. The previous triangles mesh was slick enough, but they drew more attention to themselves and were probably a larger graphic load.

Today, I  looked at one of the Lattice configurations, 01. ‘Unbroken’? Sort of, it's now a slow motion breakdown. The configuration consists entirely of neutrons with particle separations greater than the particle interaction zones (2.2*PIM .EMISSION_RADIUS). An extra neutron is added to the grid’s center, within the interaction zones of the central-most, closest eight neutrons. (I noticed the p = null; statement for the first time). The result is some surprising motions, I’ll call it cube dancing. After a minute or two, the central neutron is cast out, and the 8 other neutrons go a bit slower in the opposite direction. The action appeared a little smoother on my machine, with more motions before the eventual ejection of the central neutron and the breakdown of the entire lattice.


LatticeBody 01 variations can cause reliable Overlap bug collision errors.

The results described in the previous paragraph apply to a lattice with grid dimensions: edgeX, edgeY, and edgeZ, of 6x4x6. The same applies to 2,2,2 or 4,4,4 or any even#,even#,even#. If the grid dimensions are changed, and the central neutron is placed within four closest neighbors - mid face - Overlap bug collision errors occur. For example, changing the grid from 6,4,6 to  7,4,6, or 6,5,6, or 6,4,7; the center of the grid would then be positioned between four closest at the center of the lattice; all 5 neutrons become ‘fused’ in in an overlap error - in the example’s x,y and z planes respectively. The overlapped particles usually burst apart after some time – up to several minutes – all the while getting closer and closer to each other –overlapping more and more. Likewise, placing the lone center neutron between two closest neutrons - an odd#,odd#,even# grid configuration will result in three overlapped neutrons at the grid’s center.  

It appears that the initial 9 central neutrons for say, a 2,2,2 grid and new neutron center seem to be frozen for a moment in their own overlap error before the action begins.
.

I don't think I mentioned the change to the particle mesh. Those spirals bothered me a bit, so I created a line geometry to represent them instead. Previously, it was just using the geometry for a sphere and rendering it as wireframe, hence you saw the triangles. Now it is its own geometry and uses a THREE.LineSegments object to render them. That Hosohedron algorithm just keeps giving and giving!

I've seen overlapping problems in Lattice 02 (which I like to use every now and again to gauge performance with a lot of particles). Sometimes a couple of neutrons would attach to each other and spin around that bond point. The ambient field, and gravity if enabled, cause all particles to group together, which causes a lot of collisions at the same time. Some of the Three Body scenarios do the same, but with less force and less particles.

There are a few problems at work here.

Looking at the Three Body problem as it is simpler. We have 3 particles in a line and the top and bottom particles are pushed towards the central one by the ambient field. Gravity would do the same thing as the central particle is pulled towards the other 2, but they are equal and opposite forces, so they offset each other and it doesn't move. Once they all collide, both the top and bottom particles hit the central one at the same time and with the same, but opposite, force. This causes the central particle to take the velocity from one and then the other, which cancels out and we end up with no motion.

That makes sense.

However, the influence of gravity and/or the ambient field (or even the attraction from the protons if that is being used) do not disappear. They keep wanting to push all of those particles together. Since the particles have no velocity, even though they are colliding, they do not change each others velocities. So the ambient field or gravity push them together and they start to overlap.

I have actually caused this by reversing a change I made a while ago. In the main processing code of the MotionEngine implementation, it decides which forces to apply to the particle that it is looking at. Now, in theory, there is no reason to stop a charge interaction just because there is a collision at the same time. However, in practice (or virtual practice), there is. I recently reversed that code so that it allowed charge (and possibly ambient field) interactions even if there is a collision in the same frame. I wanted to see if it would work with that after some other changes. It didn't. It can be changed back to avoid some of these issues, but I don't like it. It should be able to process both forces on the same frame, but I'm not sure how to at the moment.

I have been toying with an idea for a few weeks that might help, but again, I don't really like it. It feels wrong. Anyway, my need for purity aside (that sounds a bit racist , but is not meant to, pure principles , not pure genes or race ), we need a way to reverse these overlaps. I can't find a nice way to do it, so may have to revert to something ugly.

One idea was to have a way for the collision code to be able to apply a once-only velocity. Since velocity stays with a particle, there is no way to say 'move back a bit, you've gone too far', but that is what we need. This may mean that we have to process collisions separately from all other forces. Before all other forces so that these little adjustments can be applied before the other forces calculate their numbers. A little bit of a performance hit, but shouldn't be too bad and I choose precision over performance for this type of code.

That won't fix problems that are caused by multiple particles colliding simultaneously though. That is a hard one to fix. I may need to rethink the way forces are calculated to deal with that one. For example, it currently calculates the changes in velocity for all particles, and then it applies all of those changes. We may need to make the changes as we go so that when multiple particles collide at the same time, the forces can transfer across the particles.

Take the Three Body problem above, if we make the changes as we calculate the collisions, then either the top or the bottom particle will be considered to collide with the central particle first. The velocity changes will be calculated and applied. Then the other particle will collide and it will now see the new velocity for the central particle and calculate accordingly.

This would cause the second particle to collide to bounce off first, then on the next frame, the other particle would bounce off. It doesn't feel right, but it may be necessary.

.
Thanks for explaining the collision status in detail.

Granted, collisions, gravity, charge emission and charge reception should all be occurring at the same time. It surprised me when you first said it, but sure, I believe it. It’s only natural to expect that the best solution should involve the single motion engine spherical index interaction zone .

For review, unless I’m mistaken, collisions are detected when the emission and target particles overlap.
charge-point-engine.js, line 720.

Code:

If( info.distance <= module.DIAMETER ) {
engine.collisionForce.interactWith( info.particle );
}

You've explained our main constraint - we may not change a particle’s position. The collision response to the overlapped particle is to calculate a change in velocity or spin in the target particle. Simple-collision-force.js, line 118,

Code:

velocity.add( vel );

Unfortunately, we do not know whether the new velocity or spin will clear the collision or not.

Gravity or charge can compound the problem by working against separating the particles. I suppose that’s part of what you meant by the practical reason to disregard all additional interactions during a collision.
 
How about a collision counter? If a collision extends over some dt or small number of iterations a particle should be able to recover the penetration distance by some anti-overlap re-position response – like an additional drift velocity or deformation away from the emission particle. If motion is prevented by another particle – then a 3body situation may be necessary. But that would be ‘reverting to something ugly’.

Sorry, I keep thinking about it, but I’m not much help here.
.

Well, we are going to have to change their positions, during processing of a single frame. I can't see any other way around it. I just need make sure that it doesn't effect the other calculations. It does raise more problems though. How do you know where to move them to? In a single collision between 2 particles it is easy, but what if there are multiple particles? What if we move a particle inside of another? It all gets complicated, very quickly.

I was thinking of adding a third parameter to the collision force that would allow it to specify a once-off position adjustment. It won't be remembered on the next frame the way a velocity would. That will fix the 2 particle collisions, but not the multiple, or at least, not all of the time. It may work sometimes, maybe even a lot of the time, but not always. Maybe it will fix itself over the next few frames though. We won't really know until we try it.

Maybe I can come up with another spatial index, or add to the existing one, so that we can find all of the collisions on a given particle and make adjustments accordingly. Rather than treating every particle in isolation, we know in advance that we have multiple and can use them all to find the right motions to add.

Airman wrote:Gravity or charge can compound the problem by working against separating the particles. I suppose that’s part of what you meant by the practical reason to disregard all additional interactions during a collision.

Yes, exactly. Directly after the distance to diameter check you posted above it did have an else, but I commented that out recently and it needs to be put back in to avoid some of these overlapping issues. Long term, we need to fix it in a better way, but that is the short term solution.

.
For the record. A few days ago I saw Lattice 01, a previous version by now, creating far more overlap errors. I didn’t mention it at the time as I was trying to figure out how best to show it. As it turned out, I haven’t seen anything like it since. Anyway, many more overlapped pairs were created. So many that overlapped pairs occurred in sets in the grid’s remote particles on opposite sides of the blasted grid; the simultaneous overlapped pairs could burst free at the same time, then, somehow, two of the four speeding neutrons - from opposite bursts - collided on an axis of symmetry. The dual mirror, fourfold symmetry was well neigh perfect. A Matrix moment. I haven’t noticed that particular extreme since then.

Lattice 02 (which I like to use every now and again to gauge performance with a lot of particles).

Lattice 02 starts with a fine crush of particles. I especially enjoyed the slightly overlapped spinning neutron pairs, the closest we have to resembling end-over-end spins. I increased the other lattices’ separation distances, but left 02’s alone. Opps, I should still change the separation distance from 10 to Er, with no change in the action.

Directly after the distance to diameter check you posted above it did have an else, but I commented that out recently and it needs to be put back in to avoid some of these overlapping issues. Long term, we need to fix it in a better way, but that is the short term solution.

I like to note significant interactions. That's part of the reason we create scenarios - to highlight details, not to request or imply they be immediately changed or corrected. Those behaviors good and bad, are a part of developing the program. My mentioning that varying Lattice 01’s grid dimensions can create long term overlapped collision errors with 5 or 3 neutrons is a notable distinction, and not meant as critique.
 
Ok, I un-commented out - or restored the else statement on line 729. In my working system, not GIT.

Furthermore, I’ve subsequently run many iterations of both Lattice 01 and 02; with both the ‘else’ version running beside the ‘commented out else’ version. When else is included, I see no – wait, there’s still an occasional overlap error; although far fewer. The trade-off, or downside to less overlapped particles is a slower system. Including 'else' slows the system down – I might guess by half. If that's true, I’d prefer faster with more obvious errors myself. I wouldn't necessarily want to reduce errors by taking such a big a big performance hit.  

I trust your judgement. There are plenty of problems need solving. If you don’t mind my saying, you’ve made great progress. I’m happy to help.
.

I don't understand why the 'else' version would be slower. If anything, it should be faster, because it is not doing charge (and I think ambient) interactions on a collision. But that shouldn't even be enough to see a difference. Maybe try opening them up in the reverse order. Maybe one of them is getting more of the graphics card than the other. I have noticed that happen when I leave my dev version open and test my website version after an update and the website version runs slower. If I close down the dev browser (I check them in different browsers) then it is fine. Doesn't happen every time though, but often enough that I try to shut down my dev browser before testing. It is usually just the start of the app that seems to slow down to maybe 30 fps for a while. It can clear itself even with both browsers running.

We need to discuss where this app is going. What do we want out of it? What do we want it to do? How will a general user make use of it? Everyone else can chime in here too. I'm not sure if they are listening anymore, we have gotten fairly low-level and it would be difficult for anyone else to understand.

I don't really have good answers for those questions. In one way, I see it as a Particle Interaction Engine. Just an API that can then be used to build other apps with a more focused angle on some problem or solution. I don't mean to make that sound like it is something small and inconsequential, because it is not. In fact, it is a great thing to have in your toolbox. I just don't see what our end-goal is at the moment. Not that that is a problem right now, there is plenty still left to do, but having an end-point can be beneficial too.

.
Bad News. I intend to keep quiet for a while, and let someone else have a say, but fate would have it otherwise. My GIT isn’t working today. I tried Fetching three times - morning, noon and a little while ago. The timer keeps going round and round and I re-entered my Atlassian password at least twice for each attempt; no joy, so I canceled those Fetches. I’ve made changes today (adding post collision target grids in collision tests 01 and 02) that I’ve saved as a Commit.

I will not Push the Commit until I successfully Fetch and Pull (if necessary) first. If I have the same problem tomorrow, I may mention it again.
 
/////\\\\\/////\\\\\/////\\\\\

Good news. Meanwhile, does anyone out there have any comments, questions or suggestions concerning the Charged Particle Interaction Model?
.

I haven't made any changes this week (i've been reading a few Jack Reacher novels and loving it) so there shouldn't be any changes to pull. I've received emails saying that you have pushed changes, so your local repository should be up-to-date.

Have you restarted SourceTree? I have had issues in the past where I leave it open and my machine goes to sleep, but when it wakes up, SourceTree won't work properly and the timer just keeps going round and round but nothing ever happens. A restart of the app usually fixes it. Although, I haven't had that problem in a few months, so maybe they fixed it in an update.

.

We need to discuss where this app is going. What do we want out of it? What do we want it to do? How will a general user make use of it? Everyone else can chime in here too. I'm not sure if they are listening anymore, we have gotten fairly low-level and it would be difficult for anyone else to understand.

Particle engines are wonderful things. I believe I may have a few thoughts about where we might go.
 
First, I haven’t seen the lattice 04 and 05 spin jitter bugs lately, how did you fix them? Was it a spatial index charge point sign error?

Without a doubt, our single biggest collision error is overlapped particles. It seems worst when particles drift together.

Have I overlooked any specific changes you requested or suggested to any of the scenarios?

I need to look at spin collisions.

We don’t have neutron charge channeling yet. Or slightly differing particle radii, let alone a separate size class like electrons.

Have you ever tried whitespace instead of black? Can we create streams of particles? Or a particle shooter?

Given the charge sampler/profiler and how it allowed you to find a good equatorial emission solution, can you, or we, re-look the possibility of maximum proton emissions at +/-30 degree latitudes?

The Matrix moment still exists. As Lattice 01 breaks down, one might see four simultaneous overlapping pairs bursting apart at the same time with new collisions among the outcomes. How can that degree of symmetry exist between the distant corners of the expanding/disintegrating lattice?

Neutrons alone are comparable to photons. Is it possible to bring in a staked spin object and see if we can corral ‘photons’ with it?

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

Thanks for the continued GIT/ Sourcetree advice and support. I usually turn Sourcetree on in order to copy from my working version to the Git folder before commiting a change, Fetch and/or Pull or Push, then I turn it off. I never 'leave it on' unless I'm reviewing the commit changes. I don't know what resolved my latest BitBucket problem, it just started working again. It may have been due to the fact that I don't always have internet access. Or not all Fetches, Pulls and Pushes work.  
.

LongtimeAirman wrote:First, I haven’t seen the lattice 04 and 05 spin jitter bugs lately, how did you fix them? Was it a spatial index charge point sign error?

Not sure. I did play around with that sort of stuff last week, but can't remember anything specific that I changed. I still see them in the Unmovable scenarios. It seems like the particle bounces (spin-wise) between 2 points.

LongtimeAirman wrote:Without a doubt, our single biggest collision error is overlapped particles. It seems worst when particles drift together.

Yep, that needs a serious change to fix and I'm still trying to figure out a nice way to do it. It seems like I will need to take all collisions into account, on a given frame. Somehow keep the particles outside of each others boundaries while satisfying all of their velocity changes.

LongtimeAirman wrote:Have I overlooked any specific changes you requested or suggested to any of the scenarios?

I can't think of any at the moment.

LongtimeAirman wrote:I need to look at spin collisions.

Yes, I had a quick attempt at it, without looking into any current theory on the issue and it worked some times but not all the time. I think I need to take relative position into account. Not just look at the spin of the particle, but transform it so that we get the spin from the perspective of the line between the colliding particles.

LongtimeAirman wrote:We don’t have neutron charge channeling yet. Or slightly differing particle radii, let alone a separate size class like electrons.

I am hesitant to add in electrons just yet. We need to deal with the collision issues before we introduce a smaller particle.

Not sure how to handle charge channeling at the moment. My first attempt, for the proton, was to use an attraction, but that is incorrect. It is not an attraction but an absence of repulsion or even a reduction of the received emission. I am starting to think of it as a charge point issue. Effectively, we need a way for each ChargePoint object to know if it is at the poles and to reduce the received charge accordingly. Basically it will act like a reversed charge point.

LongtimeAirman wrote:Have you ever tried whitespace instead of black?

Not in this app, but I tried it in AtomicViewer and it sucks. Too bright and everything looks washed-out.

Are you thinking of a printer friendly version?

LongtimeAirman wrote:Can we create streams of particles? Or a particle shooter?

Not in this app. That is a different type of engine.

LongtimeAirman wrote:Given the charge sampler/profiler and how it allowed you to find a good equatorial emission solution, can you, or we, re-look the possibility of maximum proton emissions at +/-30 degree latitudes?

A few weeks ago I changed the creation of the CHARGE_DENSITY array so that it could be generated from an equation. I really like that and settled on an algorithm that uses the sine function. So we need a way to use that, but the maximum is not at the equator but just before it. I think we should be able to do that by providing an offset to the angles used in the sine function. Right now the equator is represented by sin( 90° ) and the poles are represented by sin( 0° ) (actually, it is a bit more complicated than that, but close enough). so if we give it an offset of 15°, say, then the equator will be represented by sin( 105° ), which is a smaller value than at 90°. 15° away from the equator will be 100% strength. 30° seems too large, but it will be easy to change the offset to see how it turns out.

LongtimeAirman wrote:The Matrix moment still exists. As Lattice 01 breaks down, one might see four simultaneous overlapping pairs bursting apart at the same time with new collisions among the outcomes. How can that degree of symmetry exist between the distant corners of the expanding/disintegrating lattice?

Because they are all the same distances from the other particles. You have created a scenario based on symmetry, so it is going to have symmetry.

LongtimeAirman wrote:Neutrons alone are comparable to photons. Is it possible to bring in a staked spin object and see if we can corral ‘photons’ with it?

I don't think this is the app for that. That requires a more formal representation of charge. This app is about particles, and uses charge for that, but it doesn't represent charge itself.

LongtimeAirman wrote:Thanks for the continued GIT/ Sourcetree advice and support. I usually turn Sourcetree on in order to copy from my working version to the Git folder before commiting a change, Fetch and/or Pull or Push, then I turn it off. I never 'leave it on' unless I'm reviewing the commit changes. I don't know what resolved my latest BitBucket problem, it just started working again. It may have been due to the fact that I don't always have internet access. Or not all Fetches, Pulls and Pushes work.

Probably just the BitBucket servers then. It happens.

.
Here's a quick followup.
///////////////////


Airman. A collision test 01 view. The moving particle - approaching from the right - will push or overlap the stationary particle slightly forward (toward the left), before it ends up in a slightly further than the 'ideal' position, not quite visible in frame 51. Sorry, the gifs are almost always too large to post.  
///////////////////

Nevyn. I am hesitant to add in electrons just yet. We need to deal with the collision issues before we introduce a smaller particle.
Airman. Actually, I was thinking of bigger particles. Our particles of radius one define the top velocity; call it 60, or what if we call it lightspeed(?). Our radius equals 1 particles are the simulation’s smallest particles ; charge interactions are calculated. We could just as easily call the particles nectrons and electrons. The proton would then have a radius of about 10. Our sim should allow us some range of particle dimensions. Including large, slow moving bodies needn’t complicate the present collision situation.
///////////////////
(Whitespace).
Nevyn. Are you thinking of a printer friendly version?
Airman. I hadn’t taken that into consideration.
///////////////////

Airman wrote. Can we create streams of particles? Or a particle shooter?
Nevyn. Not in this app. That is a different type of engine.
Airman. Can we create any other object? Nothing else exists in this simulation? Sure, I like to draw lattice line grids to mark positions, but the lines cannot interact with the particles in any way. We need something besides just the lines or particles. How about a particle chamber? Start with a huge hollow particle that could fit a dozen or so of our particles inside. Any collisions with the large and smaller particles would bounce the small particles back inside the larger particle’s boundary again. Or boundary walls could be treated as the surfaces of very large particles. Or is that wishful thinking?
///////////////////

Nevyn. A few weeks ago I changed the creation of the CHARGE_DENSITY array so that it could be generated from an equation. I really like that …
… but it will be easy to change the offset to see how it turns out.
Airman. That sounds easy enough, the sine maps directly to a particle’s latitudes. Please consider, one may modify the sine argument. In my D function diagram I multiply the angle by 2, so that 2 sine peaks (magnitude) occur, one for each hemisphere (different polarities) at +/- 45, for starters(?). I was thinking about the possible source for a charged particle's dual polarity magnetic field.
///////////////////

(Matrix moment).
Nevyn. Because they are all the same distances from the other particles. You have created a scenario based on symmetry, so it is going to have symmetry.
Airman. I’ll be more than happy to put a little randomizer at every new location velocity or spin. That has the added advantage of making things a little more interesting for the viewer. Probably help slow things down though.
.

LongtimeAirman wrote:Actually, I was thinking of bigger particles. Our particles of radius one define the top velocity; call it 60, or what if we call it lightspeed(?). Our radius equals 1 particles are the simulation’s smallest particles ; charge interactions are calculated. We could just as easily call the particles nectrons and electrons. The proton would then have a radius of about 10. Our sim should allow us some range of particle dimensions. Including large, slow moving bodies needn’t complicate the present collision situation.

OK, I hadn't thought about that, but it still falls to the same problem. The model needs to keep velocities below what the smallest particle can handle, so the larger particles will be a lot slower than they currently are. How slow depends on the difference between the smallest and the largest.

LongtimeAirman wrote:Can we create any other object? Nothing else exists in this simulation? Sure, I like to draw lattice line grids to mark positions, but the lines cannot interact with the particles in any way. We need something besides just the lines or particles. How about a particle chamber? Start with a huge hollow particle that could fit a dozen or so of our particles inside. Any collisions with the large and smaller particles would bounce the small particles back inside the larger particle’s boundary again. Or boundary walls could be treated as the surfaces of very large particles. Or is that wishful thinking?

Some sort of virtual boundary would be a good thing to add. I'll see if I can come up with an interface for it and plug it in to the MotionEngine class. I want to be able to use different geometry for the boundary. We could then use a rectangular boundary in some scenarios or a spherical boundary in others. Can't really see any need for other shapes, but you never know what the future holds.

LongtimeAirman wrote:I’ll be more than happy to put a little randomizer at every new location velocity or spin. That has the added advantage of making things a little more interesting for the viewer. Probably help slow things down though.

It will only slow down the initialization. Not the runtime execution of the model. That is, it will take slightly longer to load the page, but it should run the same. And it won't even slow it down noticeably.

See if you can made the randomization configurable. Pass in the max amount of randomness (for the position) and then work out the actual randomness for each particle (actually, each dimension for each particle). Don't forget that you want positive and negative values.

See if you can made the randomization configurable. Pass in the max amount of randomness (for the position) and then work out the actual randomness for each particle (actually, each dimension for each particle). Don't forget that you want positive and negative values.

I included the following code in Lattice 01. It works fine, but I’m not real clear on how to make the “randomization configurable”. I believe the boolean variable ‘randomPosition’ may be a PIM variable; it may be selectable from the GUI. When true, the code adds small randomDX, randomDY, and randomDZ values to the particles’ lattice positions that Lattice 01 calculates. I don’t see how to make a new function call to create new random positions, am I missing something?

Code:


particles.push( new PIM.Neutron() );
 for( var i=0; i < vol  ; i++ )
 {
 ...
 if(randomPosition === true){
 var MaxRandomDX = 0.2;
 var MaxRandomDY = 0.2;
 var MaxRandomDZ = 0.2;
 var randomDX =  MaxRandomDX * 2 * ( Math.random() - 0.5 );
 var randomDY =  MaxRandomDY * 2 * ( Math.random() - 0.5 );
 var randomDZ =  MaxRandomDZ * 2 * ( Math.random() - 0.5 );
 p.object3D.position.set( countX * dX - offsetX + randomDX, countY * dY - offsetY + randomDY, countZ * dZ - offsetZ + randomDZ );
 }
 else {
 p.object3D.position.set( countX * dX - offsetX, countY * dY - offsetY, countZ * dZ - offsetZ );
 }
 particles.push( p );
 }
 var particleArray = new PIM.ParticleArray( particles );
 return particleArray;


.


Dodeca Motion Error. I noticed a problem that needs reporting. Easily seen in Colliding Test 03. Moving neutrons approach a stationary grid of protons. In the image above, I changed the camera position to look in the positive x direction, the same direction as the approaching neutrons.

Observing the scenario in each of the Precision levels – except Dodecahedron – we see the neutrons will collide with the either the proton emission field; or the proton and the proton’s emission field. In all cases the neutron will end up going back in the direction it came from, with a negative x velocity. Likewise, protons that are actually hit will be given a positive x velocity, which they may pass to the next proton.  

The image shows Dodecahedron Precision. I removed the proton emissions for clarity. The bottom row of 4 neutrons is still advancing (+X); the three rebounded rows of neutrons have a component of negative Z. The second row of neutrons received the most neg Z.  We can also see the resulting proton motions have a lot of resulting +/-Z component as well.

You indicated your thinking about reducing the Precision list, but it’d be nice to know what the error is.
.

LongtimeAirman wrote:I included the following code in Lattice 01. It works fine, but I’m not real clear on how to make the “randomization configurable”. I believe the boolean variable ‘randomPosition’ may be a PIM variable; it may be selectable from the GUI. When true, the code adds small randomDX, randomDY, and randomDZ values to the particles’ lattice positions that Lattice 01 calculates. I don’t see how to make a new function call to create new random positions,  am I missing something?

All you need to do is pass in a parameter for the max values (which you have called MaxRandomDX, etc). I don't think you need 3 of them, 1 will do for all of them. So it might look like this:

Code:


function initLattice01( ... /* your current parameters */, maxRandomPos )
{
 var randomDX =  maxRandomPos * 2 * ( Math.random() - 0.5 );
 var randomDY =  maxRandomPos * 2 * ( Math.random() - 0.5 );
 var randomDZ =  maxRandomPos * 2 * ( Math.random() - 0.5 );
 ...
}


If you want to get a bit smarter, then we can make that parameter optional like this:

Code:


function initLattice01( ... /* your current parameters */, maxRandomPos )
{
 if( typeof maxRandomPos !== 'number' )
 {
  maxRandomPos = 0; // no randomness if not specified
 }
 ...
 for ...
 {
  var randomDX =  maxRandomPos * 2 * ( Math.random() - 0.5 );
  var randomDY =  maxRandomPos * 2 * ( Math.random() - 0.5 );
  var randomDZ =  maxRandomPos * 2 * ( Math.random() - 0.5 );
  ...
 }
 ...
}


That allows you to not pass in a value for maxRandomPos, or even an invalid value, and it will still work.

With respect to dodecahedrons, I suspect that the problem is that they do not have a ChargePoint at the poles and/or that they are not exactly symmetrical.

By the way, the general consensus is to use a lower case letter to start a variable name or function/method name. Start with an upper case letter for class names. Use all upper case for constants. It makes it easy to see what a particular name refers to.

Variable and function names use what is called Camel-case. It starts with a lower case letter and every word after the first starts with an upper case letter: myVariableName.

Different people have different styles, but that is very common.

.
Sorry, Nevyn, I'm trying to follow instructions and I'm stuck. The code is easy enough, my problem is, I do not know how to use a function call here. In calling the function (randomizingPosition), I will pass maxRandomPos (or not, if, as you say, one includes code for substituting zeros when a numerical value is not included). The function then generates values for randomDX, randomDY or randomDZ, but how do I get those random numbers back to lattice 01 in order to add them to the particle positions? The calling function doesn't recognize them. I've also tried initializing the variables in Lattice01, and overwriting them with the function call with no luck. Please excuse my frustration, your patience is appreciated.  
.

Nah, my bad. You can't use parameters to the scenario init functions. You could copy the current initLatticeBody01 into a new local and private function that does take parameters, and then call it from initLatticeBody01, but it is not worth the effort unless you wanted to create multiple scenarios with differing randomness.

.
Thanks, that's a relief. I'll stick with your corrections to my previous code, then add randomized positions to a few more scenarios, using the boolean variable randomPosition.
.

I have removed all of the precision options, leaving only 4: Low, Medium, High and Overdrive. All of these are based on the Hosohedron algorithm, so I will be able to take advantage of that for visualization of the charge points.

I created a new ChargeProfile implementation that will randomize another one. It uses the other profile to calculate the standard value, then it alters the length of that vector by calculating a random number between 0 and 1, if the number is below the threshold then it is clamped at that threshold, otherwise it is used as is. This creates a variation in the force strength between the threshold and 100%.

To visualize that, I have added some code to recreate the charge profile geometry every 60 frames. That should make it update every second. I randomize the initial update count for each particle so that they do not all update on the same frame as that causes stuttering. Note that the profile that you see does not represent the values that are being used in force calculations. It is just a sample taken every second or so.



This represents a randomness in the ambient charge field feeding the proton emitting the charge and/or the randomness of collisions with charge photons. It provides a variation in the model that leads to unique situations as the model runs.

I have added a new menu that allows you to specify how much randomness you want in the charge profiles of charged particles.

I updated my site with all of the latest changes.

https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=100&scenario=Unmoveable.Arrange%20about%20Z&graphics=y,n,y,n,n,n

.
Looking good Nevyn,

The charge profiler makes interesting patterns. Random charge emission makes sense. It makes even more sense with respect to the ambient field. Currently, the neutron has no emission field, if we put a charge profiler about a neutron shouldn’t it show the ambient field the neutron is receiving?

I finally got around to coding a hosohedron, copying your charge point engine example in order to make the 26 point spherical. Then I cleaned up the rest. I’m sure you agree, they are better without the previous surface edge lines.

I tried adding random positions to Lattice 02. The results were a faster and cleaner dispersal of particles, with nowhere near the number of collisions the non-randomized version exhibits – so I did NOT add randomization to Lattice 02’s positions after all.  

Please consider adding a Reload or Refresh button (next to the Restart button). The Restart button replays the exact same scenario, particle parameters and viewing position from last time. What if I want to reload the same scenario without the exact same parameters? I must open the category Scenarios, then the category Group then find and select the scenario (that I’m currently running). That works, but I usually re-load the browser page, knowing the program defaults to the last scenario viewed. Unfortunately, not all the particle settings default to my previous settings, so I’ve become adept at making all my desired particle properties every time I reload the page. Please consider adding a Reload or Refresh button (next to the Restart button) - although I think it would be nice if the Reload button replays a refreshed version of the current scenario from the current viewing location. I haven’t looked at the details, but if you agree, I’ll try to implement this change by copying what you’ve done with the Restart button.

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

I see this post jumps us to the top of page 15. I'll repost your updated link with all of the latest changes here too.

https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=100&scenario=Unmoveable.Arrange%20about%20Z&graphics=y,n,y,n,n,n
.

LongtimeAirman wrote:The charge profiler makes interesting patterns. Random charge emission makes sense. It makes even more sense with respect to the ambient field. Currently, the neutron has no emission field, if we put a charge profiler about a neutron shouldn’t it show the ambient field the neutron is receiving?

The ChargeProfile sampler doesn't work like that, so it won't show the received charge.

LongtimeAirman wrote:I finally got around to coding a hosohedron, copying your charge point engine example in order to make the 26 point spherical. Then I cleaned up the rest. I’m sure you agree, they are better without the previous surface edge lines.

Yep, more clean, but I didn't want to distract you while you were having fun (and more importantly, learning).

LongtimeAirman wrote:Please consider adding a Reload or Refresh button (next to the Restart button). The Restart button replays the exact same scenario, particle parameters and viewing position from last time. What if I want to reload the same scenario without the exact same parameters? I must open the category Scenarios, then the category Group then find and select the scenario (that I’m currently running). That works, but I usually re-load the browser page, knowing the program defaults to the last scenario viewed. Unfortunately, not all the particle settings default to my previous settings, so I’ve become adept at making all my desired particle properties every time I reload the page. Please consider adding a Reload or Refresh button (next to the Restart button) - although I think it would be nice if the Reload button replays a refreshed version of the current scenario from the current viewing location. I haven’t looked at the details, but if you agree, I’ll try to implement this change by copying what you’ve done with the Restart button.

Yeah, that would be good. You just need to add in the new menu item, there is already code for it. You should only need to change the initGUI function. You will find this code at the bottom:

Code:


gui.add( { fct: function() {
   resetState();
} }, 'fct' ).name( 'Restart' );


Just copy and paste that beneath the existing one, rename the action and instead of calling resetState(), call restart().

Maybe call the new action Reload. It is a bit weird that the Restart actions actually resets everything while the Reload action actually calls restart. Maybe we should change Restart to Reset and make the new one Reload.

I had a go at using the Hosohedron algorithm to render the particle geometry with the charge points marked on it using vertex colors. It works, but they don't look very good at the moment. I need to change the way it creates the geometry to make them look better. It is a bit tricky and I won't have time to look at it today, but there is one new addition that I wanted to mention because it will make things a bit easier to code in the scenarios. I haven't pushed any of this yet, but I will soon enough.

I needed a way to alter the geometry used for each particle, but only the MotionEngine had the intelligence to do it. The MotionEngines have had nothing to do with particle geometry (and I didn't think that they ever would) but I suddenly needed them to. So, I defined a new class called ParticleFactory that is used to create Particle instances. The standard factory will just create the same particles that we have been doing up until now. However, the ChargePointMotionEngine has its own ParticleFactory that will create particles that use the geometry that renders the charge points in the vertex colors.

I went a little bit further than just creating the particles though. I added methods that would set the position, orientation, velocity and spin. This makes it easier to set those properties and we don't need to remember that some are on the object3D property and some are directly on the Particle object itself.

The down side is that we need to change all of the scenarios to use it. The ParticleFactory instance is passed in to the init function of all scenarios. Everything will still work if they don't use it, but they won't get the new per-vertex geometry.

Here is an example of how to use it, it is from the Unmoveable scenarios:

Code:


 var ZERO = new THREE.Vector3( 0, 0, 0 );

 var initSpin01 = function( factory )
 {
  var particles = [];
  var p;
  p = factory.createProton().place( ZERO ).get();
  p.moveable = false;
  particles.push( p );
  p = factory.createNeutron().place( new THREE.Vector3( 5, 0, 0 ) ).get();
  p.moveable = false;
  particles.push( p );
  var particleArray = new PIM.ParticleArray( particles );
  return particleArray;
 };


To set all possible properties, you could do something like this:

Code:


var pos = new THREE.Vector3( 5, 0, 5 );
var o = new THREE.Quaternion().setFromAxisAngle( new THREE.Vector3( 0, 1, 0 ), Math.PI/2 );
var vel = new THREE.Vector3( 5, 0, 5 );
var spin = new THREE.Quaternion().setFromAxisAngle( new THREE.Vector3( 1, 1, 0 ), Math.PI/8 );
var p = factory.createProton().place( pos ).orient( o ).velocity( vel ).spin( spin ).get();


Notice that is uses function chaining which means you have to call the get method last, which will return the actual particle.

I just created a new branch (feature/charge-point-vertex-colors) for it and pushed it to GIT. You can have a look at what I have done so far.

.

Neutrons gather round a proton to keep warm and tell stories.

I checked out the Charge Point Particle Factory, (Dr. Howl’s moving castle has a new wing!).

- Ok, I’ll see about changing Restart to Reset and adding Reload.  

- After thinking about it, yes, I still need to install random positions in Lattice 02 even if I just set the degree of random to zero.  

- Another GUI change request, please replace the current 6 button Charge Emission % Random selection with a single 0-100 slider.

While your wish is my command, I am loathe to make any changes to the GUI or anything else – expecting a changeover to the Charge Point Particle Factory at any time. Once again, I’ll be more than happy to modify the scenarios – all of them if you like, you’ve shown us the Unmoveable example above - while you work on other things. Revisiting the scenarios has been steady work and every go round has been worth it, learning a bit more while finding additional things to mess with.

So, knowing a change is coming, the sooner it hits, the better, if you ask me. Ready when you are.  
.

I just merged that new branch onto master and deleted it. You can update the scenarios to use the factory now.

I initially intended to create the randomness setting as a slider, but it was easier to create a few buttons for testing, so I did. I'll have a look into it at some stage.

I changed the ParticleFactory methods place and velocity so that they can accept either a THREE.Vector3 object, or X, Y, Z values as numbers. So you can do either of these:

Code:

var p = factory.createProton().place( 0, 5, 3 ).get();

or

Code:


var v = new THREE.Vector3( 0, 5, 3 );
var p = factory.createProton().place( v ).get();


The same for the velocity method.

For the orient and spin methods, I have used a different approach. It is not convenient to set a quaternion by its 4 values. So I have allowed these methods to accept an axis angle (as X, Y, Z, A) or a quaternion object.

Code:

var p = factory.createProton().orient( 0, 0, 1, Math.PI/4 ).get();

or

Code:


var q = new THREE.Quaternion().setFromAxisAngle( new THREE.Vector3( 0, 0, 1 ), Math.PI/4 );
var p = factory.createProton().orient( q ).get();


The same for the spin method.

This makes it more convenient to set these values quickly without having to create vectors and quaternions all the time.

.
Status Update. Making the updates went smoothly enough. Only the Random group is left. I don’t think I can update this group without additional instructions.

For example, I must have all my variables ready to declare p in a single assignment, as in.
p = factory.createNeutron().place( 0, -5*PIM.EMISSION_RADIUS/10, 0 ).get();
particles.push( p );
With the previous p.object3D. setup, one could address each p.parameter separately. How can we do that with the factory .get? Like when you began a new Config 03 by calling Config 02, with the intent of addressing p[i] to change one or two parameters. I wasn’t able to do it. Having such directions may allow me to do the Random group, but that may still be wishful thinking.

Please note that updating to the factory seems to have eliminated spin reversal errors previously shown by the bottom protons in two scenarios: Two Body 03 S1, and Two Body 04.

Four of the five (6, 8, 12, and 20 point) Sphericals have no initial velocities!? How do the Neutrons drift in to collide with the proton? Ambient gravity? The factory must enable you to balance charge and gravity.
.

LongtimeAirman wrote:
Status Update. Making the updates went smoothly enough. Only the Random group is left. I don’t think I can update this group without additional instructions.

For example, I must have all my variables ready to declare p in a single assignment, as in.
p = factory.createNeutron().place( 0, -5*PIM.EMISSION_RADIUS/10, 0 ).get();
particles.push( p );
With the previous p.object3D. setup, one could address each p.parameter separately. How can we do that with the factory .get? Like when you began a new Config 03 by calling Config 02, with the intent of addressing p[i] to change one or two parameters. I wasn’t able to do it. Having such directions may allow me to do the Random group, but that may still be wishful thinking.

You don't need to do everything in 1 line, as my examples have shown. You could replace that code above with this:

Code:


factory.createNeutron();
factory.place( 0, -5*PIM.EMISSION_RADIUS/10, 0 );
p = factory.get();


LongtimeAirman wrote:
Please note that updating to the factory seems to have eliminated spin reversal errors previously shown by the bottom protons in two scenarios: Two Body 03 S1, and Two Body 04.

It shouldn't have anything to do with that. Unless it was a bug in the way the orientations or spins were being set and the factory fixed them by using axis angles. I haven't seen that myself, so I will have a look tonight.

LongtimeAirman wrote:
Four of the five (6, 8, 12, and 20 point) Sphericals have no initial velocities!? How do the Neutrons drift in to collide with the proton? Ambient gravity? The factory must enable you to balance charge and gravity.
.

Yes, gravity and the ambient field will push them in. The factory has nothing to do with any of the forces. It is only responsible for creating particles.

I did make a small change where I found something I had done for testing made its way into a commit without me noticing. The gravity force was only being applied from the closest particles to the target, when it should be (and now is) working with all particles. Maybe that has something to do with it. Are those particle supposed to have no initial velocity?

I made some changes to the way charge points are rendered. The lines are gone and each charge point is now represented by a small cone. This has been created with some custom geometry for efficiency and so that I can use per-vertex-colors.



I also used some custom geometry on the particles themselves which gives the same effect as the charge profile with some randomness. You don't really need the particle mesh now.

Random Gnarly particles.

Those are some gnarly particles dude. My only criticism – they are too dark to see without Graphics markers. They need to be brighter. Please consider losing the background two color random pattern and go with a single color green or red.  The addition of charge points, axes or another new marker may be necessary to distinguish a single color particle.

Did you check how the factory settings update cleared those two Two Body group spin reversal errors? We’ve been talking about that specific bug. I looked at it twice and made a separate commit – a sign correction - because of it. On the other hand, I no longer assume I can observe objective reality, I don't know whether I want confirmation or not.   

I updated the Random group today, with one problem. I couldn’t make the group’s internal function, initRandomBody accept “factory” settings; so I commented out the function, and placed the function code into each Random 01, 02, and 03. Take a quick look and see what I mean. If you’ll be so kind as to provide the fix, I’ll restore the group function and eliminate the redundant code at my first opportunity.

Your “closest particles” gravity error/correction could explain my Spherical initial velocities. I remember your previous mention of finding and correcting that closest gravity error, but I never attributed any of my observations to your comment. My recollection is that I needed to give all the Spherical neutrons within the proton emission field - except over the pole positions - some degree of inward velocity (toward the central proton at (0,0,0)) in order to allow for an occasional neutron/proton collision. Now, I just position the neutrons, and they will begin to approach the proton before they are repelled by it. Since there’s no hope of a proton equatorial collision without them, I’ll keep the 06 point Cardinal initial velocities. I also see that I still need to fix the 6 point Cardinal random positions too.

And the GUI stuff, my to-do list is getting longer.
.

Do you mean the actual particle color is too dark? Not the charge point markers? I can look into that. Easy enough to change the colors as I picked them based on the complete sphere being the one color. I don't really want them to be one color though, as that removes the depth from them. You can't tell if they are spinning, for example, because you can't tell one part of it from another. I can make it better though, so I will do that and we can see how it works and find another solution if not.

I did check those scenarios, and found no spin reversals. I can't remember what they were like before though, so I can't comment on the difference.

Airman wrote:On the other hand, I no longer assume I can observe objective reality, I don't know whether I want confirmation or not.

It sounds like you might have over-saturated yourself. It is easy to get so bogged down in little differences that your brain starts to go a bit numb. You can't really tell if something is better or worse anymore. The only way to avoid it is to take breaks fairly often. Once you are in it, drop what you are doing and don't go back to it until you have forgotten about it for a while (maybe hours, maybe days). It is a horrible state to be in and so easy to get there. I've spent all day working on things before, and late in the night I think I've done something that I am happy with, so I finally go to bed. The next day I look at it and wonder what the hell I was thinking. That's over-saturation.

My best guess about your problems with the factory in the Random scenario, without seeing the code, is that you have not passed the factory in to the local function. You probably added the parameter to the function declaration, but have not passed it in when calling that function.

So you may have done something like this:

Code:


(function( ScenarioJS, PIM, THREE )
{
 
 var initRandomBody01 = function( factory )
 {
 camera.position.z = 100;
 return initRandomBody( 10, 200, 20, 70, 0.66, 0, 0.25 );
 };
 
 var initRandomBody02 = function( factory )
 {
 camera.position.z = 100;
 return initRandomBody( 10, 200, 20, 70, 0.66, 0.25, 0.5 );
 };
 
 var initRandomBody03 = function( factory )
 {
 camera.position.z = 100;
 return initRandomBody( 10, 200, 20, 70, 0.66, 0.5, 0.75 );
 };
 
 var initRandomBody = function( minCount, maxCount, minSize, maxSize, protonRatio, velRatio, orientRatio, factory )
 {
            ...
 };

 // Set the group name you want them under in the menu
 // You can change this as you go to use multiple groups
 var group = 'Random';
 
 // Register each scenario function
 ScenarioJS.addScenario( group, 'Random 01', initRandomBody01 );
 ScenarioJS.addScenario( group, 'Random 02', initRandomBody02 );
 ScenarioJS.addScenario( group, 'Random 03', initRandomBody03 );
 
}( ScenarioJS, PIM, THREE ));


But you need to pass in the factory to initRandomBody whenever you call it:

Code:


(function( ScenarioJS, PIM, THREE )
{
 
 var initRandomBody01 = function( factory )
 {
 camera.position.z = 100;
 return initRandomBody( 10, 200, 20, 70, 0.66, 0, 0.25, factory );
 };
 
 var initRandomBody02 = function( factory )
 {
 camera.position.z = 100;
 return initRandomBody( 10, 200, 20, 70, 0.66, 0.25, 0.5, factory );
 };
 
 var initRandomBody03 = function( factory )
 {
 camera.position.z = 100;
 return initRandomBody( 10, 200, 20, 70, 0.66, 0.5, 0.75, factory );
 };
 
 var initRandomBody = function( minCount, maxCount, minSize, maxSize, protonRatio, velRatio, orientRatio, factory )
 {
            ...
 };

 // Set the group name you want them under in the menu
 // You can change this as you go to use multiple groups
 var group = 'Random';
 
 // Register each scenario function
 ScenarioJS.addScenario( group, 'Random 01', initRandomBody01 );
 ScenarioJS.addScenario( group, 'Random 02', initRandomBody02 );
 ScenarioJS.addScenario( group, 'Random 03', initRandomBody03 );
 
}( ScenarioJS, PIM, THREE ));


Or it could be the opposite. You might have passed it in in the function calls, but not declared it as a parameter in the function declaration.

That's my best guess at the moment.

I've been thinking about the precision options lately, and I don't think we can use them. The original cardinal points are good, but anything with a higher precision causes the poles to be over-represented. Look at the image above and you can see that the ring of charge points just off the pole is so tight that they touch each other. The charge points at the equator have space between them. I think the Icosahedron algorithm worked quite well too. Maybe even the Dodecahedron. The Hosohedron algorithm, while nice and easy to work with, does not provide an even representation across the surface of the sphere.

My latest change to render the charge points still relies on the Hosohedron algorithm, but it can be changed to use the actual ChargePoint objects, if I can make that happen. The problem is that the code that has the ChargePoint objects is not very accessible when creating the particles. Maybe I can find a way around that though.

Right now, I just want to open a discussion about the precision options and what we want out of them.

Here’s a picture of protons and neutrons without any Graphics markers. Plenty of black has been added to both the red and green colors, they are too dark to see. If you lit them up like the incandescent charge profiler with 0% random Charge Emission, then, say, a bright broad single equatorial band of green or red (darkening toward the poles would be fine), would be much easier to see.  

Your suggestion that I include ‘factory’ in both the random function call and function source sounds like just what I was asking for.

Right now, I just want to open a discussion about the precision options and what we want out of them.

With respect to charge precision, we want charge detection to be as accurate and balanced as possible. If we achieve that, why would we wish to increase precision? Particles don’t change precision. It seems that increasing precision is a way of increasing charge detection by particles. Charge detection should be a function of the relative sizes and distances between the particles, an angular aspect between the 2 particles and NOT a function of the particles themselves. I don’t see any rationale or advantage in being able to change precision levels, nor do I see any physical basis for changing precision. Thanks for asking.

I may be a bit over-saturated, but I'm enjoying every bit of this project.
.

It's not about being able to change precision, but finding the right precision. The options are only there to see how the precision differs in a given scenario so that we can select one and go with that. We need to be able to determine the performance using a given precision but also, more importantly, to see how it handles the forces that it receives.

A real particle does not change its precision, but it also has an infinite precision. To be more precise, it doesn't have a precision, because it has a real surface (assuming we are talking about a BPhoton). That surface is continuous (at least to the things that could collide with it). It doesn't have certain spots that will receive charge. But we have to work that way because of the limitations of the medium we are working in.

I introduced the concept of charge points in order to implement spin from charge interactions. I wanted a way for the particle to feel a difference in charge across its surface. I wanted to see what that would do to the linear and spin velocities. A real particle would feel that difference and act accordingly. It is one of the small things that cause the universe to look chaotic.

We are trying to represent the surface of a sphere, so the more charge points we use the closer we get to that. However, we have to be careful about how those charge points are arranged. It is very important that all charge points be equally apart form all of their immediate neighbors. We need a very even spacing. There should be no way to tell where the poles are just from the charge points.

I became a bit attached to the Hosohedron algorithm because I could do so much with it. I actually really liked the Icosahedron arrangement as far as interactions were concerned. It has a very even spacing to the charge point locations. But it is a bit of a pain to work with. It doesn't have a nice algorithm to create it. In the end, that didn't matter as much as I thought it was going to and I could probably bring the others back if I wanted to.

At the moment with any precision above cardinal points, I feel like the particles are weighted at the poles because they have so many charge points so close together.

.
I think I understand the problem, there's too much sampling at the hosohedron poles.  We want to find a charge point distribution with equal areas. I appreciate the simplicity of the hosohedron, but I can see that the resulting hoso charge point distribution isn’t uniform or of equal areas. Overall, the icosahedron or dodecahedron provide the best equal area subdivision solutions. We want a larger number than 12 or 20 charge points in order to give the particle a more natural charge response.

I tried a Google search. partition sphere into equal areas. The following two hits look promising.

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

A new method to subdivide a spherical surface into equal-area cells Zinovy Malkin. https://arxiv.org/ftp/arxiv/papers/1612/1612.03467.pdf
Abstract. A new method is proposed to divide a spherical surface into equal-area cells. The method is based on dividing a sphere into several latitudinal bands of near-constant span with further division of each band into equal-area cells. It is simple in construction and provides more uniform latitude step between latitudinal bands than other methods of isolatitudinal equal-area tessellation of a spherical surface.

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

https://www.mathworks.com/matlabcentral/fileexchange/13356-eqsp-recursive-zonal-sphere-partitioning-toolbox
EQSP: Recursive Zonal Sphere Partitioning Toolbox
A suite of Matlab functions intended for use in exploring equal area sphere partitioning.
.

Yeah, that's the kind of algorithm I was thinking about. I wasn't convinced that I could make them equidistant at the poles though, so I hadn't put any time into developing an algorithm. I'll have a look over those links and see if they are of use.

I looked at the first link and it was easy enough to implement, so I created a new arrangement for the charge point locations based on it. It works pretty well,



but you can still see the poles.



Good enough though, so I have made things work with it and set the Medium, High and Overdrive precision settings to use it. Low still uses the hosohedron algorithm, but it is only creating the cardinal points.

I adjusted the colors and made them brighter. Changed the tip of each charge point marker to be black instead of white, which I think works quite well. I also toned down the randomness to the particle texture.

My site has been updated with the latest of everything and I changed a few default settings while I was there so that the particle mesh is disabled, but the charge point markers are on by default.

https://www.nevyns-lab.com/mathis/app/cpim/test.html

I embedded the charge point markers a bit so that they blend in with the particle better.

.
Wow Nevyn. The particles are lighter – brighter and more responsive - than ever. In Overdrive Precision each particle is sampling charge at 406 points! That’s a lot of particle 'surface'; the model is operating at a lower FPS than for Low, Medium, or High Precision, sure, but it doesn’t lower it much nor does overdrive appear to slow the action down. Particle appearance is much improved, very nice; but then to have implemented the charge point configuration changes so quickly is quite impressive. Oh, and then post your changes so everyone can see for themselves, gosh.

but you can still see the poles

We see the three charge points are closely packed together at the poles, but that’s misleading, an artifact of the choice of a cone of a given size to represent the charge point. The actual computational charge points are much smaller and those near-polar points more equally separate then when they are represented by the much larger cone. I believe the equi-area math is as accurate as we like. I think it’s a plus to easily see the poles.

I was a bit side tracked by spherical tessellations yesterday, I'm not sure what I'm supposed to look at next.

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

Please excuse a downside. My Bitbucket difficulties have continued, I haven’t been able to Fetch (etc.) today. The problem occurs about half the time, I do better in the off-hours, I figure that’s life at the bottom of the priority list. You may have noticed I posted a query with the Atlassian community a week or two ago. I’ve been ‘advised’ to update to Git 2.19 and switching Sourcetree to use it as a System Git install. I might have done that by now except that the second half of the instruction confuses me.
.

I thought you had fixed your GIT issues? You've been pushing commits over the last few days so everything seemed OK.

I had the same problems at work last week. One day everything was fine and the next it wouldn't access the GIT server saying that I didn't have permission to access the repository. After a lot of pain, I found that I was using an 'Embedded GIT' but I had to change it to use a 'System GIT'. That requires you to install a version of GIT yourself and SourceTree will use it rather than the one it has built-in. That was caused by SourceTree failing to update the Embedded GIT and after I restarted the app, it would not work again.

While it is good to be able to see where the poles are, it is not good for the calculations. If you ignore the cones representing the charge points, and just think about the point that they are at and look at the area between points that are near each other, then the poles have less area than the rest of the sphere. No where near as bad as the hosohedron algorithm and I am happy with it, but it's not perfect. Of course, there is no perfect way to to do it, so this is close enough. I'm glad you found it. I'm not sure I would have reached the same algorithm if I tried to develop it myself.

Then again, maybe it won't be as much of a problem when I get around to implementing a charge input profile. We currently have a charge output profile but I want a similar thing for reception. This will allow the poles to act like they allow charge to flow through them, providing very little resistance. It would be good if that charge flowing through the middle of a particle could actually cause forces on that particle, which would allow 1 proton to send charge down into another proton at a right-angle to it (proton-stack bonding) and align the proton to that charge flow. I'm not sure how to go about that at the moment though. Maybe something will come to me once I get started.

.
Sorry, I was hoping these GIT moments would pass.

I installed 2.19. How do I make it my system GIT?

Here’s the Sourcetree Tools/Options/Git tab . It looks like the System Git version has been updated to 2.19.1. Note that I have the “Allow Sourcetree to manage my credentials via the Credential Manager" checked. I have the credential manager open elsewhere, but I have no existing or new Bitbucket credentials. Do I need to select anything else? When I try to Fetch I get this:

Bitbucket hasn’t asked for my password, so I unchecked that box and tried again, no difference. Now I think I'm stuck.
.

It looks like you are already using a System GIT, otherwise the System button would be enabled and the Embedded button would not. You should not have lost your credentials. I don't know anything about using a Credential Manager, haven't needed one, so I guess I'm just using what SourceTree has. On my work machine, I don't have that option checked and I would assume the same for my home setup.

To test if your System GIT is working, press the Terminal button on the top right on the main SourceTree window. That will open a shell (so it is Unix, not Windows). You can type GIT commands directly here. Just try executing 'git fetch' and see what happens.

.

.