Possible Charged Particle Field

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

.

.

Something else I did last night was an attempt to reduce the horrible converging triangles at the poles of the particle geometry. You can see it clearly in the pic of a proton above (red particle), where-as the green neutron has less variance near the poles as that pic was taken after I made the change. I think it looks a lot better. At least it doesn't look like a gaping butt-hole after dinner at Taco Bell.

So that looks like the command-line GIT is working fine. You didn't have to enter in your username/password either by the look of it. Restart SourceTree and try again from in there.

.
Nonsense, those particles are beautiful. The first thing I thought when I saw your images above was - those particles look like that fruit that smells like gym socks, the Darian fruit. Or like the seed of the American Sycamore - as a kid I called them itchy balls, and if you hit someone hard enough the seed ball would explode. It bothers the heck out of me that I haven't named them yet - like little Mourning Stars.
.

A fruit that smells like gym socks? How did anyone find out it was edible? Starvation, not even once!

.

The console Fetch worked. I see that there are 7 Commits to Pull. When I tried to Pull, I received the above.
.

I think you probably should just delete the local repository and clone it from GIT again. It looks like it has got its knickers in a knot and I'm not sure how to get out of it.

.

It won't let me clone. I never entered a password until I tried to comply with the message and log into bitbucket.
.

Are your credentials still in SourceTree. Check the Authentication tab in the Options. Maybe reset your passwords in there, if you have anything in there, that is. There are a few sections for Saved Passwords, if you open them up and press the Edit link, it should prompt you to enter the password again.

On the Options -> General tab, the first checkbox is for a setting with the label 'Allow Sourcetree to modify your global Git and Mercurial config file', Mine is checked, so make sure yours is too. Maybe that is stopping Sourcetree from being able to save the passwords or something. I don't know. It's a bit of a stretch.

Maybe switch back to the Embedded GIT, shutdown Sourcetree, restart and switch to System GIT and restart Sourcetree again.

.

- I edited/checked my password.
- I verified the checkbox "Allow Sourcetree to modify your global Git and Mercurial config file', is checked.
- I don't know how to switch between the System or embedded GIT.
- I've restarted and rebooted several times.
- I suppose the above shows the CPIM clones that I've 'lost' over time. The master 151 is my first peep. Might one of those be an item with the same key?
- I guess I can always rename the GIT folder back - to the 7 pull behind.
- I added to my question at the community, now I have more to share if a support guy answers.
- Thanks Nevyn. I'm about burnt out, Let's call it a day.
.

.

I renamed/restored my GIT folder and pulled your latest commits with the terminal. The windows GUI still provides all the status and staging information, and may still work for commits - I'll find out soon enough. Sorry for the interruption, with your help I'm sure I'll get this all straightened out eventually, for the time being I'll be performing all Fetches, Pulls, and Pushes with the terminal.
.

What a pain.

You mentioned earlier that there was part of the System GIT install that you didn't understand. What was that? Maybe it has something to do with your problems.

I just pushed a small change that adds in a check for overlapping particles and moves them. This is done before any calculations are made for that frame. It isn't perfect, but it seems to be working okay.

.

Nevyn. I just pushed a small change that adds in a check for overlapping particles and moves them.
Airman. Good, can’t wait. Now we need to be able to study collisions more carefully. It goes in line with my latest thinking – offset collisions. I spent time earlier today formalizing a collision set that should result in predictable, post collision trajectories.

Nevyn. You mentioned earlier that there was part of the System GIT install that you didn't understand. What was that? Maybe it has something to do with your problems.
Airman. The 2.19 install was straightforward. I just went with the defaults, including the configuration mgr settings. I don't know the difference between System GIT or embedded GIT – or how to change between them.

Nevyn. Maybe switch back to the Embedded GIT, shutdown Sourcetree, restart and switch to System GIT and restart Sourcetree again.
Airman. I don't understand your "maybe switch" directions. The first time I read it - put me into a comatose state. Strange reaction reaction eh? I'm happy to follow your suggestions - when I understand them.
.

Airman wrote:I don't understand your "maybe switch" directions. The first time I read it - put me into a comatose state. Strange reaction reaction eh? I'm happy to follow your suggestions - when I understand them.

The 'maybe' just means 'I don't know if this will work, but it is something to try'.

To switch between Embedded and System GIT, you just press the button with the appropriate label (in Options -> GIT). If the Embedded button is enabled, then you are using a System GIT, so press it and it will change back to the internal GIT that comes as a part of SourceTree. Then they will change so that Embedded is disabled and System is enabled, so you can press System and it will change back to the installed GIT separate from SourceTree. I think restarting SourceTree after each change is a good idea to know that it has loaded up with whichever one is selected.

More collision scenarios sounds good. You might want to disable Gravity and the Ambient Field to ensure that the collisions are predictable.

I've been thinking about some Gravity scenarios too. Setting up some neutrons that will all fall in towards each other and see how that works out. I'm not convinced the current collision math will work as I expect it to.

Added a Gravity scenario group containing 3 scenarios that differ by the distance that the particles start at. It is based on a hosohedron algorithm, but includes some randomness so that the particles do not form nice even circles. This avoids multiple simultaneous collisions which can cause large velocities.

The math did work mostly as I expected. I wanted all of the particles, well most of them, to form a ball. The forces are a bit large, so the particles bounce around a lot. If I reduced the force of gravity then they should be able to come to rest on each others surfaces and they will arrange themselves into the smallest possible shape. I've scene that before when I first built an app to mimic expansion. So I was hoping we would get to something similar.

I have even seen some particles that seem to orbit the others. It isn't a nice clean orbit, but close enough. Doesn't always happen though.

.
No, no, maybe is fine, it's going between Embedded and System GIT that was my main mental hangup. Now your instructions make sense, thank you. There may be a delay at my end due to etcetera, etcetra.

Please remain on the main for the time being. When I last used my terminal, I Fetched, and Pulled what were the last 4 of your commits ending with Code cleanup. This time however, exceptions were encountered and the requests were cancelled.  I was asked for my user and password info for each request (a single session of two actions). After good waits, each requests was completed. The information age.


Since there are no other surfaces in the universe, we are forced into banging particles together. Can an Unmoveable be a stationary target? How do you propose to demonstrate gravity? I know, I'll do another Fetch and Pull and see for myself.

Unless I'm mistaken, the new collision separation step is currently in effect - the view on top, and NO collision separation is shown in the bottom image. The charge points are left off to prevent cheating. It appears that if the top view (current model) shows an improvement, it's an incomplete one. Is it a fair test? Maybe something a little more creative, like parallel trajectory collisions (or otherwise) aimed at a particle's target map set - the collision analog of the charge point configuration. Just thinking.
.

I'm not sure what I'm supposed to be seeing in those images. There aren't any collisions. Are they taken after the collisions have occurred and I should be looking at the position of the sphere relative to the box that it is in?

The algorithm I wrote is too simple and in the wrong place to be effective. This should be done in the collision code, but I have done it outside of all interaction code so that I can do it before any interaction code is executed so that they see the updated positions and not the old, overlapped, positions. I will make it a bit smarter, which will involve copying some of the collision code, so that it applies the position adjustments correctly.

What it is currently doing, is looking for an overlap, and if it finds one, it just moves both particles back by half the distance that they are overlapped.

What it should do, is look at the relative velocity of each particle, and move them back along that trajectory, and only as far as their own velocity dictates. It should determine the relative strength of each velocity so that the larger velocity moves back the furthest. Effectively rewinding time.

I checked those collision scenarios and they didn't change as a result of the overlap fix. That is because you already fixed them a week of so ago when we went over the maximum velocity math. You might want to revisit that code and see if you can raise the max velocity limit now. If so, how far?

The new gravity scenarios are great. You can just sit and watch them for ages. The neutrons form into a ball and it gains spin (the ball, not the neutrons) and it bubbles up like a pool of lava.

https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=0&scenario=Gravity.Close&graphics=n,n,n,y,y,n

Nevyn. I'm not sure what I'm supposed to be seeing in those images. There aren't any collisions. Are they taken after the collisions have occurred and I should be looking at the position of the sphere relative to the box that it is in?
Airman. Yes, the target grid shows the 'perfect' post collision position, 2*pRadius away - in the direction of the expected oncoming head-on collision.

You may recall my collision code originally contained separating overlapping particles. There's a diagram on the Boid string that goes along with it.

Code:

if( distance < sumRadii ){
 // Interpolating the collision contact point using the
 // boid's velocityVector. Use y = mx + b

 var velocityVector = new THREE.Vector3();
 velocityVector.copy(boid.velocity);
 
 var boidPositionTwo = new THREE.Vector3();
 boidPositionTwo.copy(boid.position);
 
 var boidPositionOne = new THREE.Vector3();
 boidPositionOne.copy(boid.position);
 boidPositionOne.sub(velocityVector);
 
 var velocityVectorLength = velocityVector.length();
 
 var posOneDist = boidPositionOne.distanceTo(this.position);
 var posTwoDist = boidPositionTwo.distanceTo(this.position);
 
 //var slope = deltaY/deltaX;
 //var deltaY = posTwoDist-posOneDist;
 //var deltaX = velocityVector.length();
 var slope = (posTwoDist-posOneDist)/(velocityVector.length());

 var newVelVecLength = (sumRadii-posOneDist)/slope;
 
 // This next part is pulled from this.move, with slight differences
 ///////////////////////////////////////////////////////////////
 
 // var mag2 = moveVecToContact.length();
 var frameBreak = newVelVecLength/velocityVectorLength;
 velocityVector.multiplyScalar(frameBreak);
 
 var collisionPoint = new THREE.Vector3();
 collisionPoint.copy(boidPositionOne);
 collisionPoint.add(velocityVector);
 boid.position.copy(collisionPoint);
 //boid should be in position.
 
 var thisHereVelocity = new THREE.Vector3();
 thisHereVelocity.copy(this.velocity);
 //thisHereVelocity.normalize;
 //thisHereVelocity.multiplyScalar(frameBreak);
 this.position.sub(this.velocity);
 this.position.add(thisHereVelocity);
 //this particle should be in position.


This talk about gravity - I won't be able to work on any new scenario configurations till I review your latest.
.

.

I usually like to deliberate and carefully consider what I say next, otherwise I may be incoherent. Your gravity scenario configurations are gobsmacking. They do indeed move about in a most fascinating manner.

Most incredible, I see NO overlapping particles! The mass of neutrons remain in motion while remaining clustered close together.

My only criticism – we know the hoso configuration’s poles naturally form large pockets of particles even before the sphere of neutrons falls together. Gravity quickly pulls lattice 01 together nicely too. Does this gravity have unlimited range? All scenarios must be checked.

Repeat! I see NO overlapped particles!
.

I hesitated for about 3 seconds before deciding to go with the hosohedron arrangement. Only because I can code it up quickly. Your Sphere scenarios can be copied into the Gravity group and altered to work with only neutrons. I'll get it working with the new equidistant algorithm soon.

Yes, gravity does not discriminate. All particles feel gravity from all others. I changed that this morning. I thought it already worked like that, but I found that it was being limited to the particles within the ambient charge field limit. Probably something I was experimenting with and left in there by accident.

I changed the anti-overlap code to take the velocity of the particles into consideration and it is working beautifully. It is a difficult thing to test, but the gravity scenarios cause lots of collisions in tight spaces, so I think it's working correctly.

Site updated too.

Added a new CollisionForce that adds the spin caused by the collision. It does not currently take the existing spin into consideration. I basically treat the collision point like a charge point and calculate the spin in the same way. The force calculation is not quite right at the moment. Works well enough though.

Created a new class called Boundary that defines an interface for redirecting particles back inside of a sphere. There are 3 implementations of it that create a Soft, Hard and a Portal boundary.

The HardBoundary will bounce a particle off of the sphere.

The SoftBoundary will apply a force towards the center of the sphere, the further outside of the boundary the higher the force.

The PortalBoundary will leave the particles velocity as-is, but transport the particle to the opposite side of the sphere.

You can enable/disable a visualization of the boundary, if one is being used.

I have not created a way for the user to set the boundary type or if one is to be used. The scenarios will define that. To do so, you just set the applyBoundary property of the MotionEngine class like this:

Code:


engine.applyBoundary = true;


You can also set the radius of the boundary like this:

Code:


engine.boundaryRadius = 1000;


It is currently turned on by default, but that will change soon. The default radius is 100.

You can set the type of the boundary like this:

Code:


PIM.BoundaryType = PIM.BOUNDARY_TYPE_SOFT;
or
PIM.BoundaryType = PIM.BOUNDARY_TYPE_HARD;
or
PIM.BoundaryType = PIM.BOUNDARY_TYPE_PORTAL;


I might change that to be a property on the engine.

.
Quick review.

Gravity's effect on Lattice 01, the model's 'large scale'.

Gravity? Well, I’d heard that before. You recently corrected the “fail to apply gravity to other than the closest nearby particle” error. Surprise, I didn’t expect such a fine display of gravity; and orbital motion. The neutron clustering was (I say was because you've already improved them further) very interesting and stable. Noticing my attention, my wife looked, was duly amazed, and said they needed spin. You quickly obliged with spins and spin collisions. I spent plenty of time wondering how charge interaction gives way to collision then back to charge interaction, adding a rudimentary spin helps tremendously. The clusters are much more natural.

Previously, in the Randoms and Lattice 02, etc., all neutrons would eventually leave, often overlapping, then bursting apart at velocity to depart our local volume of space. In my opinion, the ‘overlapping particle’ error was our Bug 01; I’m looking hard, and the particles do seem a bit little sticky at times, but I must say, congratulations for getting rid of the problem.
 

Gravity's effect on 6 point Spherical 01, the 'small scale'.

Your Gravity scenario group involves large numbers of particles. Gravity can easily be demonstrated with as little as 2, 3, or 4 particles. For example, I believe there is an ‘understanding’ that the 3-body orbital problem is unstable and unsolvable; but not for the charge field, where we know it can be easily demonstrated. 4 particles can be widely separated or close together. Each particle is exchanging positions with its opposite, swinging past each other as the partners slowly change over time. I thought I might find a four group if I launched the 6 point spherical, the only difficulty is the need for a totally separate proton trajectory – the proton just blows the neutrons apart when it comes close. A couple of tries, and there it was. Give the four particles some common velocity and they begin to interact. Even with the proton present, the Sphericals make good gravity demos.  

Thanks for making the particle chamber – the boundary. No more evaporation deaths for our scenarios; on the other hand, all particles with escape velocities keep coming back. I suppose it’s arguable whether it’s justified on any physical grounds, but I think it will be more appreciated over time. I see that if the chamber is too small, it becomes part of the scenario. For example, given the boundary, the Collision group is wonderfully broken – 03 especially, including constantly increasing energy. Please don’t fix it just yet, let me mess with it first. I noticed you added Offset Collision Tests (with and without spin) 05 and 06. I want to work on collisions later today, but I'm nowhere near caught up. I feel obliged to review a bit more and maybe stare for hours.

*  

Please excuse the effusive praise, you deserve it. Great work. You’ve advanced the program quite a bit in the last day or two. Please try to sit back and appreciate the view. How difficult would it be to make a 3D version of this program?

P.S. *. And plenty of time tech supporting my sorry problems.
.

I have made a few more changes. I added a new property to the Particle class, called isAlive, that provides a way to effectively destroy a particle. The Particle itself will remain, as there is no way to remove it from the ParticleArray since the MotionEngine never sees the array. However, it will not take part in any calculations and will be made invisible.

The reason for that: I created a new Boundary, called DestructionBoundary, that will destroy any particle that reaches the sphere.

Also created another Boundary, called StickyBoundary, that stops the particle at the edge of the sphere. This lets gravity take control of the particle and move it back towards the other particles.

I also moved all Boundary related code out of the ChargePointMotionEngine class and put it into the base class, MotionEngine. This allows all MotionEngine implementations to make use of boundaries.


I think the reason some particles appear to stick together is because of gravity and/or the ambient field. Note that I have turned off the ambient field in the gravity scenarios.

There is no physical justification for using a Boundary, but it can be beneficial at times. I will set the size of the boundary to be much larger by default, but I wanted to show them off before I relegate them to the background.

It is actually very easy to get a 3D version of the app running. That statement did make my head spin at first. It is already a 3D application, but then I realised you meant like a 3D movie. ThreeJS has a special camera, called StereoCamera, that can be used to create a 3D Anaglyph rendering. That uses the old Red and Blue (now Cyan) glasses you might remember from the 80's.

In order to use more modern 3D techniques, such as that used for Virtual Reality, you need 2 cameras, one for each eye, and you just render the scene through each camera and send them to the appropriate device. Not sure how to get that working in ThreeJS, but I think it is possible. I can deal with the rendering, but not sure how to send the frames to the device for each eye.