Possible Charged Particle Field

.
Sorry for the grief Nevyn,

be on master and revert to the commit with the tag origin/master; or be on the feature/precalculate branch and revert to the commit with the tag origin/feature/precalculate.

When I attempt a reverse commit from the master (or the  branch), I get errors.
///////////////////////////////////////git header .....

error: commit 6983...91660 is a merge but no -m option was given.
fatal: revert failed

Completed with errors, see above.

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

Now I'm 4 Pushes behind, but at least the Revert list is longer. I thought Git made these things simple.

Alternatively, you can definitively fix it by deleting your source tree and pulling it from GIT again.

How do I delete my source tree? Like in? How do I do a full uninstall?
https://community.atlassian.com/t5/Sourcetree-questions/How-do-I-do-a-full-uninstall/qaq-p/122267, (not a pretty discussion).

I've already shared correspondence with the Atlassian Support Group. I suppose I should ask them whether there's a more graceful solution.
.

You don't need to uninstall anything, you just need to delete (or even just rename) the directory on your file system that GIT is pointing to for that repository. Then clone the repo again and it will pull everything down as it exists on the BitBucket server.

.

you just need to delete (or even just rename) the directory on your file system that GIT is pointing to for that repository

I was hoping you were going to say that.

A quick check shows collisions and spins are as they were.
////////////////////////////////////////////
Thanks Nevyn. Re-cloning is a perfectly elegant solution.

Where were we - what did you think of the spin reversal gif?
.

It is worth looking deeper into. If I only watched one of those proton/neutron pairs then I would say that is within the limits of the algorithms. But the second one does act quite differently (the far one in the GIF above). Much more smoothly. The front one does seem to move over to the right a bit, and that might account for some differences, but not all of it. Also, both neutrons reverse their spin at the very start. They both appear to spin 1 way and then almost instantly spin the other way.

A good test would be to have a motionless proton with a neutron above it, maybe about 20 units above it, and a slow velocity towards the top of the proton. This should allow the neutron to slowly move into the area that it will interact with the proton. Might give some more info about that transition into the interactions. Also try that with the neutron having an initial spin to see how the proton effects that spin.

I have just had a thought regarding how the spin is applied. The spin for each Particle object is left as-is and this keeps getting added to by other spins (standard spin velocity addition). However, when this is used to actually rotate the Particle, the used quaternion is normalized. Normalizing a quaternion means to make sure that it is between 0° and 360°, but still equivalent to the original rotation as far as the final orientation goes. So if the spin says to rotate by 380°, then the normalized spin will just be 20°.

What I am worried about is what happens with a negative spin? Does -380° normalize to -20° or does it go to 340°? That would be a problem for us. That would reverse the direction, although that value is never used in the calculations, only to apply the final rotation, so it may not be a problem.

Another weird thing in your GIF is that the front neutron is all fidgety, but then when it gets close to the proton, it smooths out. The forces should be getting stronger as it gets closer, so why does it get smoother? We really need to see the numbers going in to and out of the calculations, but it is such a pain to extract them when it is executing 60 times a second. It can lock up the browser because it is writing so much to the console.

.
The center of the image is down, negative y.

Four Neutrons approaching 4 protons. As requested, neutrons are given a downward forward velocity toward N/S oriented protons. The protons are not spinning, they are located at the 4 furthermost (toward the image center) - red, green, blue (x,y,z) grid intersections. We are looking toward the proton poles, a direction from which protons appear darker, and harder to see at this small gif image size. This gif file size is 493KB. Each neutron is also given a small (0.2) spin velocity, in one of 4 different spin axis directions, +/-X, and +/-Z, each of which are orthogonal to the neutron’s forward velocity, -Y. As previously, all radii = 1, particles are given NSEWFB lines for reference. The front/back, left/right distances between neutron/proton pairs: dX and dZ both = 12 (outside the proton emission range). The vertical distance between the grid lines is 10.6 (just within the one unit thick surface volume added to the proton emission range). The neutrons were initially positioned at the near ends of the green lines, at about z=20, outside the 4 corners of the image.

The spins look to me to be - I admit I'm confused by the top spin:
Top left. The N/S oriented Neutron is given a positive x-spin.
Bottom left. The N/S oriented Neutron is given a negative x-spin.
Top right. The N/S oriented Neutron is given a negative z-spin.
Bott0m right. The N/S oriented Neutron is given a positive z-spin.
Agreed?

All neutron motions are smooth until they reach the top of the proton’s emission field, when they usually experience many spin reversals. Note that the neutrons also seem to gain speed when they enter the proton emission field. The only neutron that looks natural and doesn’t experience any spin reversals is at the bottom right; however, when I allowed random velocities and spin speeds, I saw that any or all of the neutron orientations are subject to spin reversals. Apparently there isn’t a specific bug, I suppose there’s a variable or two that reduces the neutron’s apparent angular momentum to roughly equal to the momentum delivered by the sampled proton emissions.  

A photon is 6 billion times smaller than the proton. It is unreasonable to allow a single peripheral charge ‘sampling’ of photons could reverse a proton’s angular momentum, let alone causing stuttering reversals about the proton's spin axis. There seems to be another logical inconsistency in that if the approaching neutrons have little to no spins, then there are no spin jerks, starts or motions comparable to the stuttering spin reversals.

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

As I’ve implemented it, to add the rgb colored NSEWFB cross markers, one must uncomment the group adds, around lines 121, 128, and 135 in cdm.js. If one simply leaves the NSEWFB crosses in place, they add a computational load which slows performance when many particles are present. The crosses are good for the odd scenario or two, but I don’t see how someone can turn them on or off from test.

Given my Sourcetree difficulties yesterday, I'm glad to say I already Pushed the above changes to BitBucket. With all these lattices, I see I need to make the grids a separate function, then I'll clear out all its replicas used in all the LatticeBody and CollisionTest scenarios. On the other hand, every time I've made a grid, I've tried to improve it.   

Nevyn, I can see why branches are necessary, but feature/precalculate is like the twilight zone; while I was there, spins weren’t and collisions caused either energy multiplying, screen freezing or intersecting phantoms. There was no initial particle attraction – such as seems present when the neutron starts around 10 above a non-spinning proton. I saw and reversed every one of those code changes in my back-up mode, to no avail. I saw but didn't figure out that code source for attraction, it’s a start.  
.

Notice that when they stutter, it always has one of the charge points pointing down at the proton? That is a key part of this problem. If the neutron had no spin of its own, then its southern charge point is going to enter the interaction zone of the proton first. For a small amount of time, it will be the only charge point that receives any attraction. In this case, no neutron spin, the force will be perfectly on the Y axis. Therefore, there will be no spin component. It will start to accelerate as a result of that force and eventually the 4 side charge points will enter the interaction zone. All of the side points are equally distant from the proton though, so they all receive equal amounts of charge, although in different directions. Each opposite pair of charge points will negate each other, so we end up with no spin and more downward acceleration.

Now we add some spin to the neutron and see how that changes the interactions. Let's assume that when the southern most charge point first intersects the interaction zone that it is as a 10° angle to the line between the center of the neutron and proton (and there has not been any sideways movement). Now that southern charge point is receiving a small amount of spin as well as the attraction to the proton. It is the same attraction causing both. So the charge point starts to spin back towards 0°. Since there is no spin at 0°, any remaining spin will continue to rotate the neutron past that point. Once past it, the spin component of the attraction is negative as compared to the existing spin. So it tamps it down and will start to spin it the opposite way. If that was the only charge point, then it would keep spinning between those angles.

But it isn't the only charge point, so once the side charge points enter into the interaction zone, they start to apply spin as well (and attraction, but more spin). The side charge points are almost at 90° to the center line, so nearly all of their force is applied to spin and not much to motion. If they are at equal distances from the charge source, they will perfectly offset each other and no net spin is the result. But when the neutron is already spinning, they are not at equal distances, so they will not offset each other and there will be some residual spin. But that spin causes the southern charge point to move away from 0° so it starts to spin against the spin from the side charge points and since it is closer to the proton, it will receive more force. Eventually, it will spin back enough that the other sides side charge point will be attracted and the stuttering begins.

It is all a balance of distance of each charge point from the proton and its angle to it.

Another thing to consider is that I added some code to decide which charge points should be used for a given interaction. This was designed to omit 1 charge point from each pair (X, Y and Z pairs or NS, EW, FB). Maybe that code is not working correctly when both charge points are equally distant from the proton. Or maybe it is working correctly and the stuttering is just a result of using only 6 charge points to represent a full sphere.

That leaves us with the bottom right neutron/proton pair in your image. Why does that not stutter? Because it rotates differently to the others so that it doesn't have a single downward facing charge point, and is more centrally aligned between a few charge points. See how it starts spinning about the Z axis, but then, once in the interaction zone, it gains a bit of X spin. That changes all of the interactions and balance and seems to avoid the stuttering.

I am leaning towards this just being a resolution problem. It is a result of using only 6 charge points. I might have a go at using a dodecohedron. It will be a lot worse for performance, but should be a lot better for precision. I'll try to make it so that we can swap them easily and we can compare the two.

.
My quick relaxed review.

It looks like the neutrons displaying the spin reversals appear to be aligning in 4 of their 6 cardinal points orthogonal to the forward direction, they square themselves orthogonal to the proton before falling in. The neutrons that avoid spin reversals are the ones that seem to slip into or ‘dive’ into the emission volume. If the particle’s N/S, E/W, F/B points meet the emission volume at a sufficiently flat (ortho) direction, like hands claping, spin reversals occur. If the N/S, E/W, F/B points hit at a sufficient different direction, the particle has performed a dive into the emission volume instead of a belly flop.
.

Something like that.

I might create an intermediate version before going full dodecohedron. I will try to add another 6 charge points which are at the diagonals to the current ones. That will give us 12 charge points and more of them will be interacting at any given time in these scenarios.

One good thing about introducing more charge points is that the algorithm will actually become simpler. The code will look simpler, but it will be less efficient because I will have to use the dot product operator on some vectors. I am currently transforming the points to avoid that as it allows me to split along the X, Y and Z dimensions directly. Oh well, you win some, you lose some.

I have made a start on refactoring the calculations into a new class. I have created a new branch for this to keep it separate from anything you want to work on. I will keep it up-to-date with any changes you commit to master. The new branch is called 'feature/motion-engine'.

I have created an abstract class called MotionEngine (abstract means you don't instantiate any objects of that class but you extend the class with implementations that you do instantiate, called concrete classes). That class just defines the methods that need to be implemented by sub-classes. Another name for it is an Interface, although there are differences between an abstract class and an interface, and you can think of it as a contract that sub-classes must adhere to.

I have created one sub-class at the moment called SixPointMotionEngine and that contains all of the calculation code that we had before, but it was part of the ParticleArray class.

I have also removed all of the code that I thought was going to lead into a shader implementation. I have realised that we can't do that, so I have changed the methods to use the Particle objects directly instead of copying all of their data into buffers, calculating off of the buffers, writing into the buffers and then having to copy it back into the Particles. Two buffers do remain as that is what the new changes in velocity and spin are written into so that we don't overwrite the current values for the rest of the calculations during a frame.

My next move is to create a second MotionEngine that will be the same as the first, but it will use a more generic algorithm (using those dot products I mentioned earlier). This will make it easier to transition into a more complex MotionEngine that uses more charge points.

One problem with the current version of MotionEngine that I want to address at some point is that it contains all of the calculations in one class (actually sub-classes of it). I actually want to separate out the various forces into their own classes so that different implementations can be used without having to change the calling code. That is, the MotionEngine will have an object for each force that performs the calculations for that force, and the engine will combine them all together. This will probably mean that MotionEngine will become a concrete class and the force classes will have an abstract parent class.

.
Thanks for the explanations and update Nevyn. Abstract parent class Concrete Motion Engines eh? Just so you know, I usually need to re-read^ your posts, the last few have been no exceptions.

Early today, I was pleasantly surprised to find your changes, making the N/S, E/W, F/B cross markers a Boolean selectable particle effect. I guess now it could be selected from the control panel. You also improved their construction. I believe I took the straight forward approach – by pushing three lines. I see you started with a single x-line, then copied and rotated it to create the y, then copied and rotated again to make the x into a z-line. I guess your method creates less independent objects. Even with your improvements the markers are a large additional load; although they make up for it by making spin behavior much easier to identify from a distance. If we aren’t going the shader route, I suggest we consider reducing the marker line load even further by replacing the lines with sprites.

Given your current effort, I don’t see how I can be very much help. I'm committed to my small task - to try and figure out how to make grid lines a function callable from any of the Scenarios. It's a good housekeeping/clean-up detail, enough to keep me occupied for the time being.
.

There's nothing wrong with the straight forward approach. It works and is usually a good place to start. It's easier to optimize a working algorithm than it is to create a complex one from scratch. I just made it more efficient by sharing data where possible. I don't expect you to know about that, but it was a good opportunity to show you the differences.

The idea is that you don't create unnecessary data. Especially large data. In this case it was just lines, so they aren't very big at all. Let's assume that it was the sphere of each particle instead. The geometry of a sphere will contain a lot of points that represent the surface of that sphere. The more points the more spherical it will be. Let's say there are 100 points in the geometry of a sphere.

If we create that geometry for every particle that we create, then we are creating N * 100 points to represent them. Each point contains 3 values and each value is a 32/64 bit floating point number. So we end up with N * 100 * 3 * 64/8 = N * 2400 bytes.

However, if we realise that every one of those geometries contains the exact same data, then we share it. We create 1 geometry with 100 points and use it for every particle we want. No matter how many particles we create, we will only use 2400 bytes of data to represent them. It isn't only about memory consumption either, that geometry will need to be copied onto the graphics card memory, not necessarily every frame but possibly, so the less we have to copy the better.

Any time you are doing something per item or per iteration, try to get rid of it. You can't always do that, but it is worth thinking about for these types of applications.

Similar to the geometry, you can share the materials used to define the appearance of that geometry. This is where you tell it to be red or wireframe or shaded with a gradient, etc. You can share the material between objects which means you can change the appearance of any of those objects just by changing the 1 material. Materials are also used to setup the graphics hardware for rendering. They literally apply the settings like color, fill method, textures, etc. So all objects that use the same material can be rendered together (where feasible) to save time setting up the hardware.

Working with 3D systems is pretty low level stuff. You are just a whisker away from the hardware and you need to make it sing to get good results. We aren't writing the next AAA titled game here though, so don't worry about this sort of stuff, except as a learning experience if you think you are ready to delve into that sort of thing. I'm just trying to mention things that I've picked up along the way. You might read this in a years time and see more than you do right now.

The most important thing is just to experiment. You've been doing that. You wanted to show the collision discrepancies so you figured out how to create a grid and show it clearly. I mentioned axis markers and you figured out how to show it. You put something new into your toolbox every time you do that. Next project you won't have to think about how to create a grid, you'll just do it.

Airman wrote:I suggest we consider reducing the marker line load even further by replacing the lines with sprites.

We can't use sprites for axis markers because a sprite is not exactly 3D. The defining quality of a sprite is that it always faces the camera. It is a 2D rendering into a 3D world. The distance from the camera may be taken into account to reduce the size of the sprite, but it can not show you depth.

We need depth to show the rotation of the markers so we have to use 3D lines. It currently uses 1 line geometry, which contains 2 points, to represent all axis markers. It uses 3 materials to render them since we want different colors for X, Y and Z markers. All X markers share the same material, all Y markers another and the Z markers yet another. No matter how many particles we create, that is all it will use for geometry and materials. It is efficient enough.

I just pulled your changes to master and rebased feature/motion-engine on top of it and pushed that back onto GIT (so it now includes your changes while still remaining a branch of its own). Check out that motion-engine branch and have a look at LatticeBody.initLatticeBody05 again. I didn't do anything specifically to help with the spin problems, but it does seem to be working better. There is still some stuttering, but it doesn't seem to be as bad. Let me know what you think.

.

Check out that motion-engine branch and have a look at LatticeBody.initLatticeBody05 again. … . Let me know what you think.

Latest Pull. I’m confused, where is the feature/motion-engine branch? After reading your previous post I Pulled the latest changes, and saw what we see in this image. I reviewed the changes, but without much understanding, I'll need to review them a few more times. Then, with no small trepidation, I tried requesting a checkout of the branch, but saw no change; a title of a branch but no separate branch. How am I supposed to avoid that? Do I need to go to the origin/master line before Pushing any additional changes? What am I missing? What have I bollixed this time?

So, with that ‘understanding’, I’m running what I believe is the latest test and cdm files. I’ve viewed LatticeBody.initLatticeBody05 a few dozen times; sorry, I don’t see any less stuttering. I also removed some incorrect, arbitrary initial spins in CollisionTest 01 and 02 hoping well oriented N/S neutrons might behave better, but I saw no change in the overlapping particle collision bug either.

Having at least succeeded in making a gridLattice function and replacing my grids with calls to that function, I’m ready to clean up my particle lattices next.
.

Open the BRANCHES item on the left side. There should be 3 branches with 2 under a folder called 'feature'. Double click the 'feature/motion-engine' branch to change all of your source files to that code branch. The current branch will be in bold.

.

Ok, now I see motion-engine and master under the left side under "feature", but with motion engine selected I still don't see a 'separate' branch. Selecting master bluelights the origin/master line five lines below the top.  
.

It won't change the graph, it will only change your file system. Which-ever branch is bold is the one your file system contains.

Now I see what you mean. If you open the REMOTES item, it will show all branches that are on the server. The BRANCHES only show the branches that you use (maybe).

Do you use the Fetch feature at all? Maybe that is the difference. The Fetch operation is used to peek at the server and see what is new. It does not change your file system or your local repository, it just looks at what the server has and shows it in the graph (where you see all of the commits). You can then choose to pull them if you want to.

It is highly recommended to perform a Fetch operation just before you push any commits of your own. This tells you the current state of the server (or me in this case) so you can decide how your changes will fit in with other peoples changes.

If you find that changes have been made, then you can Pull them down to your local repo and make sure everything is working with your changes before you push them.

SourceTree does show you when it needs to Pull, but it does not show you unknown branches that may exist on the server. A Fetch will get those too.

.
I've slept on it, I don't think there's a problem. After each of my Pulls – no I haven’t used Fetches, don’t know why, I'll try it – I begin by verifying all the changes with notepad++, an inventory step that’s probably a waste of time since that’s what Sourcetree does. When I double click the motion-engine or the origin/master lines, the GIT folder’s test and cdm files are changed to that line - as in the last image I posted. I also make all my changes in notepad++ and it 'asks' me to acknowledge/confirm those file changes. This may be a commotion over nothing, I called attention to the fact that I see no separate branch. That may change after the origin/master adds a commit – just guessing.  

Having seen and verified the motion-engine Commit changes, I've run the scenarios. I see no differences in the particle behaviors between the branch and main (motion-engine and the origin/master). Having not observed any changes I’ll double click on origin/master next; unless directed otherwise, I'll make sure I’m on origin/master before making any changes to the program.
.

OK. I thought they worked a little bit better, as in the motions were a bit smoother, although there was still some stuttering going on. I have noticed that it doesn't always have stuttering problems, or some will and some won't (of the four neutron/proton pairs), so maybe I just got lucky a few times.

I have made some progress on a more generic idea of a ChargePoint. I have formalized it into a class of its own, but I haven't committed anything to GIT yet. Each ChargePoint object takes in a vector which is a point on the sphere (so the vector is based at the center of the sphere). Each ChargePoint then works out its own axes for the velocity components that the force will be split into. One for linear velocity, which points back to the center of the sphere, and two spin components which are orthogonal to the linear velocity and each other. The class provides a calculate method that uses those axes to find the resultant linear velocity and spin given a vector representing the force applied at that ChargePoint.

This allows an arbitrary number of ChargePoints to be used, since they don't need to be in pairs (although they nearly always will be for balance). The previous (current) implementation pairs them up into NS, EW and FB so that they can be combined back together correctly. I performed the calculations in a different way this time, so they don't need to know about each other. Each ChargePoint does create a virtual charge point (not to be confused with a ChargePoint object) on the opposite side of itself so that it can determine if it should be used to calculate the velocities or not. This represents the code I added to the existing implementation to determine when to exclude charge points based on how close they are to the emitter. Basically excluding the furthest point so only the face closest to the emitter receives charge.

I then created a new MotionEngine that uses ChargePoint objects (imaginatively called ChargePointMotionEngine), created a function to create ChargePoints in the cardinal directions (just as we have now), and fired up the application. They mostly worked, but not totally correctly. It was late, so I stopped there, but I think the problem is the spin axes are not always in the right direction, which makes some of the spin go the wrong way, some of the time. I need to figure out when they need to be reversed and how to determine that given the information I have at the time. I am more reliant on math this time. In the last implementation, I knew when I was working with a N or S, E or W, etc, so I could take appropriate actions. This time, I need to calculate that kind of information just from the location of the ChargePoint.

Once I have that working, we can try all sorts of ChargePoint configurations. All you need is a way to calculate the points on a sphere that you want represented as ChargePoints. You can also hard-code them, which is what I have done for the cardinal points, but more complicated ones will require math or at least it will be easier to do with math. That will allow us to specify the amount of precision we want very easily. Have a look at the THREE.SphereGeometry class for an example of this. You can specify the number of divisions you want in longitude and latitude.

The ChargePoint class is implemented in such a way that it is not tied to a particular particle, but is shared among all of them (all with the same radius, anyway). Therefore, we only create ChargePoints for one sphere and use them for all particles. I also created a method on the ChargePoint class that will create some visual representation of its velocity axes, much like you already did with the markers, but more fine grained than that. Rather than 1 line representing 2 charge points on opposite sides, each ChargePoint contains 3 lines that are rendered at that charge point. One of them will point towards the center of the sphere, and the others will be at a tangent to the sphere. It is those tangents that are causing problems at the moment and I will use these markers to visualize that. Ironically, those changes I made to your markers to make them more efficient have been lost and we are back to individual geometry, but the materials are still shared (in fact they use the exact same materials as your markers). I did it this way because I need to know exactly where those velocity axes are, and not some idea of where they should be. They won't be used normally, only for debugging, so we don't need to worry about the performance hit. I think we should keep the existing markers though, as they provide some context for spin. While they won't always represent the actual charge points anymore, I think they are still useful.

Nevyn wrote:One problem with the current version of MotionEngine that I want to address at some point is that it contains all of the calculations in one class (actually sub-classes of it). I actually want to separate out the various forces into their own classes so that different implementations can be used without having to change the calling code. That is, the MotionEngine will have an object for each force that performs the calculations for that force, and the engine will combine them all together. This will probably mean that MotionEngine will become a concrete class and the force classes will have an abstract parent class.

I have addressed this earlier than I thought. As I looked over the code seeing how to implement some things, I realised that it would be better to split things apart earlier rather than later. I went through a few iterations, but ended up with a Force class, which is abstract, that defines the methods needed to implement a force. It has the following methods:

target( particle ) - initializes the object with a Particle object that will be the receiver of the calculated force.
interactWith( particle ) - calculates the interaction of the given Particle with the target Particle.
apply( velocity, spin ) - adds the changes in velocity and spin into the given Vector3 and Quaternion objects.

You call the target method once per frame per Particle, to setup calculations for the Particle given to it. For all other Particles, the MotionEngine determines if an interaction should be made, and if so, calls the interactWith method. Then, when all interactions have been calculated, the apply method is called to add the resultant change in velocity and spin to the respective variables passed in to that method.

For example:

Code:


var force = ...
for( var i=0; i<particles.length; i++ )
{
  force.target( particles[i] );
  for( var j=0; j<particles.length; j++ )
  {
     if( i != j )
     {
         force.interactWith( particles[j] );
     }
  }
  force.apply( vel, spin );
  // add forces to particle
  particles[i].velocity.add( vel );
  particles[i].spin.multiply( spin );
}


Some forces require all of those methods, others don't. The charge interactions certainly do, but not the collisions, although they can still work within that framework.

I have created some Force implementations to contain the existing code, called SimpleCollisionForce and SixPointChargeForce. I have now created a third Force that works with ChargePoint objects and it is called ChargePointForce. We will soon create a new Force for gravity. This keeps them all separate from each other, as a matter of code, and allows us to interchange various implementations easily. The MotionEngine class will just become a holder of Force objects and a small amount of code to determine which forces to use for the current frame and particle combinations. I actually don't like that choice being made by the MotionEngine, it would be better to do it in the Force itself, since only it should know where its boundaries are. I am keeping it in the MotionEngine because it is more efficient to do so. Otherwise, each Force would need to calculate the distance between particles to determine if they are close enough for an interaction. I may find some other way to share that knowledge.

I probably should call it a Field, rather than a Force. Although a collision is a force and not a field. I guess their is no correct term for them if we want to keep the collision code as part of the same framework.

I didn't have much time to look into the ChargePoint problem last night, but I think I have found a better way to do it. You see, I was still thinking in terms of how I had originally implemented charge points where I split them into linear velocity and two spin components. I did it that way so that I could combine X's with Xs and Y's with Y's, etc, to find the total resultant spin. However, I don't need to do that anymore.

As part of writing the ChargePoint class, I found a way to convert a vector into an axis angle and then into a quaternion. The key part was finding the axis to rotate around. I was still doing that for the ChargePoint itself and finding 2 of them to represent the 2 spin components I had previously. But I don't need to do that. I can just take the charge vector (force) and find the component of that that is on the plane that is tangential to the location of the ChargePoint. And it is easier than I thought it would be.

It is so easy that I feel like I should have seen it myself, but I didn't. I went looking for how to calculate a plane from the normal to that plane, and then how to calculate the projection of a vector on a plane.

Let me paint a picture of this algorithm and see if you see it before you get to the end.

We have the location of our ChargePoint which is a point on the surface of a sphere. That vector is the negative of the normal to the plane that is tangential to that point on the sphere (actually, it is also a normal to the plane, but we want the opposite direction). So we just negate it and normalize it to find the normal of the plane (note that normalizing a vector has nothing to do with being a normal, although a normal is always normalized). We use that normal to find the linear velocity component because that normal points back towards the center of the sphere and that is the direction that linear velocity will follow.

So that gives us the linear velocity, how do we now find the spin component? Have a think about it before you read on and don't over complicate it!

We now have the original charge vector, containing both linear velocity and spin components, and we have the linear velocity component in another vector. So how do we extract that spin component? We just subtract the linear velocity component from the original charge vector! So obvious and simple, but I didn't see it until it was shoved right in my face.

From there, we just need to find the axis angle from the spin component. To do that, we need to find a vector that is orthogonal to the spin component vector and the normal to the plane. The cross product of those 2 vectors will give us that. Then we convert the length of the spin component vector into an angle (through my spin velocity equation) and we have an axis angle which is easy to convert into a quaternion.

That's the theory I am working with at the moment. I should have some time tonight to code it up and see how it works. It should be simpler, and hopefully more efficient, than the current code. There is a bit more math but we only need to work out 1 spin vector, not 2, so maybe that will offset the differences. I'm not worried about efficiency though. Much more concerned with precision.

.
Sounds like you’ll have that machine level singing in no time Nevyn.

Each ChargePoint then works out its own axes for the velocity components that the force will be split into. One for linear velocity, which points back to the center of the sphere, and two spin components which are orthogonal to the linear velocity and each other.

The six cardinal points ( N, S, E, W, F, B ) are unique in that each point is at a radius distance from the particle’s center ( 0, 0, 0 ) along each coordinate axis ( +/-X, +/-Y, +/-Z ). I’m still not convinced that six point cardinal set is an insufficient number for charge sampling, I can see that expanding the ChargePoints class beyond the six must increase the sampling precision, and improve the particle’s responsiveness.

The only thing that bothers me in your description is knowing that every particle surface point beyond the six cardinal points will no longer align with the three axii. Even worse, there are any number of orthogonal pairs orthogonal to the line to the particle’s center. There need to be rules governing orthogonal decomposition. As you said, mistakes in rotation spin are more difficult to recognize in any expanded ChargePoints set. Building surface ChargePoints sets sounds like fun. I’ll check the sphere geometry, have you used or considered using polar coordinates? (Oh, oh, you just posted on this subject, I'll quick post this too).

My more menial efforts have been mixed. I put together a LatticeParticles function ( edgeX, edgeY, edgeZ, dX, dY, dZ ) that works much like the gridLattice function. Perfect for making simple, single type particle lattices. However, any complications - such as different particle type mixes, or setting up unique new positions or initial velocities or spins reintroduces complexity, cancelling any utility in calling the LatticeParticles function in the first place. I’ve been stuck there for hours – how to allow for small variations.

For example, in a collision scenario, the left (x=0) surface, is repositioned to the left and given a positive x velocity into the rest of the lattice. Working within the scenarios’ code, I know that once a particle’s position has been set, I can always re-set it to a new location. What I haven’t been able to do is simply move a particle. I tried adding and subtracting 3Vectors (-50,0,0) without success. Am I allowed? Should I keep trying to move the particle, or am I not allowed? I hope you don’t mind my asking.

.
Alrighty, I’ve had a chance to read and consider your plan. When you asked me to give it thought, I was convinced that projections were involved – all those sines and cosines, what an extra load. But you’re right, the charge point brings along it’s own charge point plane, equivalent to the collision plane centered on the charge point. You’re right, the way to find the components orthogonal to the normal is by subtracting the components parallel to the normal – subtracting the linear component, (just like a collision), leaving only the spin component (the angular component) remaining. Maybe your subtraction method can play a part in determining the spin components? In any case, your simplification is a perfect solution and your plan makes perfect sense.  
.

It is much easier to visualize the charge points when dealing only with the cardinal directions. I would not have found this solution without thinking along those lines. My initial solution always had them in pairs. Now I have found a way to make them isolated. They don't need an opposing charge point to figure out their own velocity changes. Each charge point only needs to know about itself.

The need for more charge points has been made clear by the stuttering that we have found. More sampling points should help with that because for any given configuration between emitter and receiver, there will be more charge points taking samples and influencing the velocity components. In reality, every point on the surface of the sphere is receiving charge, so we should attempt to get close to that. We can't really reach it because it would require infinite time to compute, but we can divide the surface up into smaller and smaller sections until we are happy with it and get decent performance.

Think of it this way, what if we treated collisions in the same way? What if we only allowed collisions at the six cardinal points? Would you expect to see realistic collisions? The code for collisions handles a collision at any point on the surface of either sphere. We need to approach that for charge but are constrained by the fact that charge effects a surface where-as a collision effects a point on the surface. Well it effects the whole sphere, but it happens at a point. We are implementing a charge field, not a collision with individual charge photons. We are trying to mimic that, but we know that we really can't.

There are going to be problems with introducing more charge points. The first one being that the amount of force is going to increase. Let's say we currently have 2 charge points receiving charge, if we introduce a new charge point between them, then we are adding more force to the resultant velocity because that new charge point is adding its little bit to it. We may need to reduce the force to accommodate that.

With respect to the gridLattice function, well done for identifying the need to make it a function so that it can be shared and getting it done. Your starting to think like a programmer. It might not seem like much, but it is an important stepping stone. You're starting to see some things in more generic terms and identifying when to use them and how.

Trying to do the same thing with the particles may not be the right way to go. Making things into functions is good, but not at the expense of functionality. Placing particles and giving them initial velocity and rotation is rather specific to each case we are creating. That doesn't mean you can't use a function, but it might make it a bit difficult at times.

I will give you some ideas on how to go about it though, and you can see if they work for you or not.

Javascript functions are just objects like any other. Most languages treat functions as a special thing. Not Javascript. They are just an object that you can invoke. As a result of this, you can pass around functions. So you have a gridLattice function that creates a grid, now you want to add particles into that grid. You can create a special function signature to do that, and pass implementations of that into your grid function.

What do I mean by a function signature? Well, the definition of a function is dictated by the arguments to that function and the return type of it. Javascript is also pretty loose with this as well and you can do some pretty cool stuff as a result of that, but what I am trying to get to is that your grid function needs to be able to call the function given to it, and to do so, it must know what arguments to give it and what output to expect from it, if any. It is the grid function that defines what those arguments are and what return type it wants.

Let's write some code to see it in action:

Code:


function gridLattice( width, height, depth, dx, dy, dz )
{
   // create lattice from arguments
}


Now we want to create a function that will create some Particle to add to the grid, as we are creating the grid. It might look like this:

Code:


function gridLattice( width, height, depth, dx, dy, dz, createParticleFct )
{
   // create lattice from arguments
   for Z ...
   {
      for Y ...
      {
         for X ...
         {
            // create some lines
            ...
            // add a Particle
            var p = createParticleFct();
            ...
         }
      }
   }
}


If you wanted all neutrons,  then we could implement a function to pass in to that function like this:

Code:


function createNeutron()
{
   var n = new Neutron();
   // maybe randomize some properties
   return n;
}


Then we would call the grid function like this:

Code:


gridLattice( 10, 5, 1, 20, 30, 10, createNeutron );


That shows you how to pass in the function and how to call it, but it isn't very useful in that case because the function is not given any information to make any decisions about what particle to return. The function signature is not good enough to support that kind of behavior. So let's give it some more information.

Code:


function gridLattice( width, height, depth, dx, dy, dz, createParticleFct )
{
   // create lattice from arguments
   for Z ...
   {
      for Y ...
      {
         for X ...
         {
            // create some lines
            ...
            // add a Particle
            var p = createParticleFct( X, Y, Z );
            ...
         }
      }
   }
}


We pass in the current X, Y and Z indexes so that the createParticleFct function knows what cell it is creating a particle for.

Code:


function createNeutronOrProton( x, y, z )
{
   var p;
   if( ( y % 2 ) == 0 ) // even rows in the Y dimension
   {
      p = new Neutron();
   }
   else
   {
      p = new Proton();
   }
   // maybe randomize some properties
   return p;
}


Of course, you can pass any information you want to into that function and use it in any way you need. You might use the X index to multiply the velocity of the particle or give them more spin. As long as the calling function (gridLattice in this case) can supply the data, you can pass it in to the given function.

This type of approach works when the index values allow you to make the decisions that you need to make. So creating particles with a velocity that is a function of the X dimension would be fine. But it doesn't work for all cases. Sometimes you just need a bit more information that the calling function can not supply, so you can do something like this:

Code:


function gridLattice( width, height, depth, dx, dy, dz, createParticleFct, globalFctArgs )
{
   // create lattice from arguments
   for Z ...
   {
      for Y ...
      {
         for X ...
         {
            // create some lines
            ...
            // add a Particle
            var p = createParticleFct( X, Y, Z, globalFctArgs );
            ...
         }
      }
   }
}


The calling function does not use the globalFctArgs data (which could be a simple value or it might be an object with much more data in it, it could even be another function if that suits your purposes), but passes it along to all invocations of the createParticleFct function so that it can use it. In this case, you might pass in the ParticleArray object that you then get a Particle from and manipulate it based on the X, Y and Z values. You can also save data back to that object (if it is an object) for other invocations to see and use. For example, suppose it was an object that contained the ParticleArray and an index into that ParticleArray. Then each invocation of the createParticleFct function would get the Particle at the current index and then increment that index value so that the next invocation gets the next Particle.

Am I going too far? It is probably best to keep it simple at this point. Creating the gridLattice function is great, since it allows many other functions to use it. However, creating and placing the Particles is probably easier to do directly in each scenario function. But by all means, have a play if you think the above method works for a given case.

Airman wrote:For example, in a collision scenario, the left (x=0) surface, is repositioned to the left and given a positive x velocity into the rest of the lattice. Working within the scenarios’ code, I know that once a particle’s position has been set, I can always re-set it to a new location. What I haven’t been able to do is simply move a particle. I tried adding and subtracting 3Vectors (-50,0,0) without success. Am I allowed? Should I keep trying to move the particle, or am I not allowed? I hope you don’t mind my asking.

I'm not sure what you mean here. What do you mean by move? Setting the location (or position as it is called in the Particle class), will move that particle. It will put it exactly at the point that you specify in the Particle.object3D.position vector.

something I found a while ago with ThreeJS, is that you should not change the position, rotation, scale or quaternion objects that are on an Object3D object. You should manipulate them instead. So you can move it like this:

Code:


particle.object3D.position.set( 10, 0, -5 );
or
particle.object3D.position.copy( myVector );
or
particle.object3D.position.add( myVector );
etc


But you should not replace that object:

Code:


particle.object3D.position = new Three.Vector3( 10, 0, -5 );


I don't know why that is, but I have had problems in the past where I was trying to replace it and everything failed.

Airman wrote:When you asked me to give it thought, I was convinced that projections were involved – all those sines and cosines, what an extra load.

Yep, I was thinking the same thing. Glad it was much easier than anticipated.

I have pushed the new implementation to GIT on the motion-engine branch. The spins are working a lot better. I think I accidentally found the cause of the stuttering too. The original charge point algorithm had some troubles with attractions, so I extracted it out and applied it separately, but only to the linear velocity. When I started thinking about this new version, I saw that I should be able to fix that and just make the force point the other way for attraction. And I was right, but I haven't completely fixed that yet, just negated it, because I have to remove all of the old code to do that. Which I am about to do.

Check out the motion-engine branch and have a look over the scenarios, especially lattice 5.

I will do some clean up and remove old code and I will be ready to merge that branch back on to master. To do that, it is best that you have any changes you want kept, pushed to GIT and wait until I have merged. Let me know when you are ready.

I have created 2 new ChargePoint configurations. The first is based on an Icosahedron and contains 12 points. This works well. The second is based on a Dodecahedron and contains 20 points. This is a bit over-powered at the moment. As I mentioned earlier, because there are more charge points, there is more force being applied.

I changed the markers to show the ChargePoints such that it handles however many of them there are. They are colored purple now as it can't differentiate based on dimension anymore.

I then created a new menu item called 'Precision' that allows you to select the desired ChargePoint configuration. It currently contains the options: Cardinal Points, Icosahedron and Dodecahedron.

.
Please don’t delay any GIT actions my account. I work in a separate folder, ready for main changes at any time. I decide how to update my working files after each Pull. Now that I think about it, after this post, I'll go back to the origin/master line and sit tight.

Looking at the latest motion-engine, I’m startled by the spiny particles – with all the additional charge point samples the particle motions are certainly more responsive.

Lattice 05. I do see something odd. While at times there seems to be less stuttering (I keep going back for half dozen bursts of scenario repeats), it’s still there, but also an apparent reason why. The neutron is interrupting it’s own spin in order to align it’s North/South axis with the N/S proton axis below. The neutron is behaving most strongly when in contact with the proton's interaction zone. Slow rotations and velocities are least affected. Once inside the proton’s emission field the neutron appears to ‘settle down’ – no more spin reversals. It almost appears as though you provided a preferential path of least resistance through the neutron that would account for the alignment. Despite the additional buoyancy, the interaction zone shouldn't provide such an abrupt change, as though the particle appeared close by. Interactions with real particles begin slowly over a greater range, instead of abruptly as through a nearby boundary layer. I'm just throwing stuff out there.

Can you add an option to save the current initial values for replay later? Or repeat play button option?

Thanks for explaining the function options – capturing all my questions and considerations, showing me more choices than I’d thought. It’ll take me some time to digest.
.

.
I forgot to mention that the icosa and dodeca particles seem to fall more directly, cleanly, along the constant y-lines.

I also had to share a thought about being able to vary the number of charge points based on the size (angular aspect) of the emitter. I realise this idea isn't feasible, we are sampling in the direction of the emitter's center, and not the particle's 'angular extent'. We can sample charge from all distant - smallest - relative single point objects - through the single cardinal point chargePoints set since charge received by objects at long distances will cancel at opposite sides of the target. The particle will know as other particles approach, as the emitter gets closer, and the cancelling diminishes due to the increasing angular aspect of the emitter, as felt by the target. More charge points are on the target will point point toward the emitter. The 'orthogonal surface area' on the target due to the emitter (smaller is further, bigger is closer) increases, to wrap around the target, in the case of very large emitters. Our equi-sized particles will to reach a maximum angle size, just before a collision. Size or proximity sampling. Monitoring the spread in angle between the chargePoints set of linear directions per emitter. Leave the Dodecas until the emitter is closer.
.

I have noticed that the attraction seems to be stronger at the outer boundary of the interaction zone, which is backwards. The stuttering happens in that outer zone and tamps down once about half way through it. I think the charge force algorithm has something wrong in it. I need to change that anyway. I will probably work on that next, I think. These recent changes help with that because I have been able to revert it back to calculating the correct charge vector without extracting the attraction/repulsion from it.

I can't explain that Y alignment. I've seen it, but can't explain it. Even when using the original 6 cardinal points it still prefers the Y and not the X or Z, even though they should be equivalent.

Airman wrote:Can you add an option to save the current initial values for replay later? Or repeat play button option?

I've often wanted something like that myself. You find an interesting interaction but can't replay it to see more detail or watch a different particle. What we need is save and load methods on a Particle which store the current state of it and load it back in. A pause feature would be good too. I thought it had one because my other apps usually use the space bar to pause/resume rendering but I tried it last night and it didn't work. I'm pretty sure the code is still in there, but the key mapping has not been setup to use it.

Airman wrote:I also had to share a thought about being able to vary the number of charge points based on the size (angular aspect) of the emitter.

This idea is like mipmaps, which are used to change the geometry and materials used by an object based on the distance to the camera. The closer it is, the more quality it has. However, I don't think this is feasible for an interaction because it would need to calculate the distance from each particle that it interacts with. Possible, and not even expensive, but I don't think that it is worth it. I haven't noticed any slowing down as a result of using more charge points, so far. I think it will just make it more confusing since you would have to know how many charge points are in use for a particular pair of interacting particles to figure out any problems with it.

I will create one more ChargePoint configuration which will be very flexible. It will be based on the THREE.SphereGeometry class I mentioned earlier. Well, not based on the class itself but the way that it generates the points for a sphere. Basically you provide the number of divisions in longitude and latitude. This is converted into an angle for each direction. Those angles are then used to calculate the locations of the ChargePoints. It is close to the concept of a Hosohedron. Think of a beach-ball where the lines go from pole to pole.

There are problems with this approach. There is always 1 point at the top (Y axis) and one at the bottom, but the X and Z dimensions are very different. This creates an unbalanced sphere. If we were using this now, then it might help explain the attraction of the Y dimension noted above. I still think it is worth implementing though. The differences between dimensions may not be as much of a problem as they look. If nothing else, it will allow us to see where the boundary is for the number of charge points. That boundary is the point where it becomes too much to calculate. Of course, that is dependent on the system running the app, not some absolute value, but we should be able to find a nice compromise.

The icosahedron and dodecahedron are very well balanced. If the particles didn't have the wireframe mesh over them, it would be difficult to tell where the top of the sphere is. The icosahedron seems to be the nice compromise at the moment. When I looked at the shape of it, I didn't think it would work very well because it doesn't look that balanced (in some regards) but it worked well. I actually wasn't even thinking about icosahedrons, I went looking for some old code I had in Java that created a dodecahedron, but it turns out that I didn't implement a dodecahedron but did implement the icosahedron. So I took it and then implemented the dodecahedron as well since they are actually pretty similar in how you create them.

I am interested in finding some other shapes like them. Feel free to look over some yourself (or anyone else) and make recommendations. The important thing to look for is equal distances between points. It would be really good to find one that still has the cardinal points, but with more in between them. I think an octohedron might be useful but haven't looked too closely at it.

I have merged the branch back onto master and also updated the version on my site for everyone else to play with.

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

Added the Hosohedron ChargePoint configuration. Added 3 new choices in the Precision menu that use a different number of divisions to break up the sphere: 8, 16 and 32. 32 ChargePoints per Particle is a lot of calculations and if you load up the Lattice 02 scenario you will get slow-down.

I also implemented a way to reduce the calculated charge forces based on the number of ChargePoints being used (actually, only half of them because only 1 half receives charge from any given interaction). This should bring all of the different precision options to a common ground and remain comparable.

Sorry, I misspoke. It is not 32 ChargePoints per particle, it is 32 divisions in 2 dimensions, so somewhere near 32^2 = 1024 ChargePoints per Particle. A bit over-the-top.

Added a menu item to restart the model with the original settings.

.
I’ve been playing with CPIM for over an hour, the fact that anyone can do the same and judge for themselves is a fine testament, you do good work.

The reset button works better than I’d hoped, resetting the scenario from the viewer’s last viewing location for a new perspective of the same event is a definite improvement.

I’m surprised at the variations in particle behavior with the different chargePoints sets. Now we need a control panel button to turn off the charge point markers.

I’ll look at the chargePoints configurations today, but I want to come up with an expanded lattice 05. You had requested better control of neutron particle orientations when entering the Interaction Zone, I’ll try to do that, and maybe also add some off-proton center negative-y neutron collision velocities.
.

.
Given your implementation of spherical geometry, the new charge point markers strongly suggest scenarios that resemble those markers.

I'll try to match the method you used for constructing them, so I'll study that first.

Anyone is free to make requests, comment, or add to the discussion.

Implosion. Start with a proton at ( 0, 0, 0 ). A ridiculously high number of neutrons are placed in a dandelion configuration at some distance around the proton. All neutrons are given collision velocities toward the proton .

Given that configuration, one can greatly vary the outcomes with initial proton variations; such as moving the proton a radius distance from ( 0, 0, 0 ).
.

LongtimeAirman wrote:The reset button works better than I’d hoped, resetting the scenario from the viewer’s last viewing location for a new perspective of the same event is a definite improvement.

That actually wasn't planned, but a welcome oversight. I often look at Lattice 05 and sometimes move the camera down to look from the side and it was a pain if I wanted to restart and it would reset the viewing position. But I still didn't think of doing that when I implemented the restart function, I just forgot all about the camera and only saved the state of all Particles. Sometimes less is more!

LongtimeAirman wrote:Given your implementation of spherical geometry, the new charge point markers strongly suggest scenarios that resemble those markers.

That's a good idea. Place some neutrons at equal distances from the central proton, but make sure they are within interaction distance, and see how the charge field effects them all. It should show the gradient of the charge field (from equator to pole) and might help us to see if something is wrong with it. It would work better if we had some smaller particles. You won't be able to get many neutrons around a proton. Maybe it is time to formalize the radius of a Particle (and mass) rather than using constants. Then we can look into implementing electrons but I also want some particles in between that and the proton/neutron for these kind of testing procedures.

I will add in a GravityForce class, but not an algorithm for it, and hook it up so that it will work once implemented. You can have a play with it if you want. I'll be working on the charge force calculations which will require a bit of theory before I can get into the code for it. Most of it has been worked out (see previous posts) but the actual charge calculation still needs work.

I have some pretty big changes for you. Firstly, I created a new sub-class of Force called GravityForce and plugged it in to the ChargePointMotionEngine class so it is ready to be implemented. Secondly, I started to give each Particle its own radius and mass properties and this led to a huge refactoring of the code.

Instead of just having the Particle class, I made Particle abstract and created a few sub-classes. Directly from Particle we have Neutron and ChargedParticle. Descending from ChargedParticle we have Proton. ChargedParticle is abstract but takes care of setting up and maintaining the charge field shaders. So you don't create Particle objects anymore, you create a Proton or Neutron. This led to...

... the ParticleArray class being changed because I had to give the caller the power to create their own particle objects. I never liked the way that worked anyway, it was just a hack to get something else working and I never fixed it because it meant changing so many other things. But now I had to fix it, which led to...

... the calling code in test.html. All of those scenarios needed to be dramatically changed. It took a while, but I got them all working again.

.
Nevyn, well done, you’ve been very busy – making many changes. Take a break!



Six neutrons headed toward a proton. I had to Push something to make it seem like I'm keeping up. As promised – for starters, a new configuration resembling the cardinal points. Six neutrons, at a distance: above, below, left, right, behind and in front of a proton positioned at 0, 0, 0. The neutrons are moving toward the proton at a small velocity, with proper orientations and spins. This new view is intended to show the extent of the proton’s emission field (in those 6 directions) while exhibiting spin reversal problems.

Of course, we don’t necessarily need to create new scenarios in order to study problems, although we are looking for fresh insights. The Restart button allows us to zero-in and study any problems we may happen to notice. One slight limitation, restarts don't necessarily repeat the collision error - overlapping particles.

For example, the spin reversal problems in latticeBody04. View the three left-most neutron/proton pairs from a negative x direction. Of course we noticed the problem earlier, it was the reason for making lattice 05. Given the new charge point particles, the problem appears slightly different. Those three left edge neutrons spin about their y, z and x-axes (respectively, from the left), all exhibit the same two spin reversal spin problems – inversely. 1. Isolated single spin reversals or 2. Constant rotational bouncing between two close angular positions about the particle’s spin axis. The effect is least present using cardinal points, when the y-axis spinner may only reverse spins once (twice or thrice), while the neutrons spinning about the z and x-axes exhibit constant spin jitters. Using icosa - hosos charge points sets – we have a reversal of problems, the back left neutron has y-axis jitters, but the other two left side z and x spinning neutrons may reverse their spins just once or twice.

By the way, my wife thanks you for keeping me busy, she thinks it’s all very interesting.
.

Airman wrote:One slight limitation, restarts don't necessarily repeat the collision error - overlapping particles.

That is because it is not just a function of the starting conditions, it is also a function of the time between frames, which is some-what random. It converges to an average of 1/60th of a second (assuming you are reaching that frame rate), but there are always little differences between actual frames. This is caused by what your computer is doing at the same time, and is out of our control as far as programming goes. There's just nothing you can do about it. I believe that a large part of those collision problems are caused by velocities that are too large. It can still happen even with small velocities, but I don't tend to see it when the velocity is only dictated by the other forces in the model.

What I think is happening is that the velocity is so large that the particles slightly pass each other during the frame transition. The collision is calculated and they move back a bit, but not enough to not overlap. So they are basically in the same position, but from opposite sides, as they were in the last collision and they just rock back and forth until they gain enough extra velocity to actual fly apart.

Airman wrote:By the way, my wife thanks you for keeping me busy, she thinks it’s all very interesting.

My pleasure. Let her know that if she wants you back then I'll come up with an excuse for why you can't work on it for a few days.

.
Thanks Nevyn, we’ll be happy to take you up on that offer in a few weeks. Till then, chive on.

6Neutrons configuration. I added lines and made a spin direction correction - unless of course I’m setting them all up incorrectly: by looking at three CW particle rotations, from +X, +Y, and +Z and looking toward 0, 0, 0; and 3 CCW rotations from the -X, -Y, and -Z directions while looking toward 0, 0, 0. I’ll wait till I make more progress before I make another change before I Push again.


I’m in the middle of the icosa configuration – quite a bit more difficult than cardinal points.

I especially like this code line -

Code:

v.set( -1, t, 0 ).normalize().multiplyScalar( s );

I’ll see if it also applies to positions.

If you don't mind my asking - Have you had any CPIM hits at the Lab?
.

I don't have tracking on that page, since it is still in development. You can't find it on my site either, you have to know where it is and this forum is the only place you can find that URL.

Code:


v.set( -1, t, 0 ).normalize().multiplyScalar( s );


Yes, v is just a standard THREE.Vector3, and those methods are available. This is a good way to create a new vector that is the same direction as another. You set it, this is setting the values directly but you could also use the copy( vector ) method, and then normalize so that the length of the new version is equal to 1, then you just multiply it by the length that you want.

In this case, I think that s = 1, so the multiplication is unnecessary, but it will become necessary when we have different sized particles. I actually added that for a different reason. The coordinates to create a dodecahedron will produce a sphere with a radius of sqrt( 3 ). I wanted a radius of 1, so I multiplied the resultant vector by 1/sqrt(3). Then I realised that I was normalizing, so it already had a length of 1 before the multiplication. I thought the code would be useful later on, so I left it in.

That line also highlights what is called 'Function Chaining'. Not all functions can do this, but a lot of programmers setup their functions with this in mind these days. I'm a bit mixed on it, to be honest, it can make the code more streamlined, but it can also make it a real pain to debug.

So what is Function Chaining and how does one do it?  You can only use this if the function does not return a value already. You can only use it on methods of a class. Normal functions can not be chained (in this way, at least) because they don't have anything to chain them together. It is the object that is being chained, really, not the functions. Let's look at an example:

Code:


module.Vector3 = function()
{
  this.x = 0;
  this.y = 0;
  this.z = 0;
};

module.Vector3.prototype = ...

module.Vector3.prototype.set = function( x, y, z )
{
  this.x = x;
  this.y = y;
  this.z = z;
};

module.Vector3.prototype.multiplyScalar = function( k )
{
  this.x *= k;
  this.y *= k;
  this.z *= k;
};


That is a basic Vector3 class but it does not use Function Chaining. To use that, we would need to invoke each method individually, like this:

Code:


var v = new module.Vector3();
v.set( 3, 2, 1 );
v.multiplyScalar( 5 );


To implement Function Chaining we just make the methods return this (the object that is invoking the function).

Code:


module.Vector3 = function()
{
  this.x = 0;
  this.y = 0;
  this.z = 0;
};

module.Vector3.prototype = ...

module.Vector3.prototype.set = function( x, y, z )
{
  this.x = x;
  this.y = y;
  this.z = z;
  return this;
};

module.Vector3.prototype.multiplyScalar = function( k )
{
  this.x *= k;
  this.y *= k;
  this.z *= k;
  return this;
};


Since each function now returns the calling object, which is the same object called v in the above example, you can just call another function on that object.

Code:


var v = new module.Vector3();
v.set( 3, 2, 1 ).multiplyScalar( 5 );


We can even put that all into 1 line like this:

Code:


var v = new module.Vector3().set( 3, 2, 1 ).multiplyScalar( 5 );


The functions are evaluated from left to right. So the first thing is the call to the Vector3 constructor. This obviously returns the new object. Then, on that object, we call the set method, which also returns the same object, so we call the multiplyScalar method. Since this also returns the object, it is then stored in the variable called v.

So what is the problem with Function Chaining? When you use a Debugger, you step through the code one instruction at a time. You can think of it as a video that you pause and then advance frame by frame. So what happens when you come to that line and want to step into the multiplyScalar method? When you press the Step Into button of the debugger, it will step into the next function invoked, which is the constructor. That's not what you wanted though, so you step out of that function and press Step Into again and this time it goes into the set method, which you also didn't want. Finally, after stepping out of the set method, you can actually step into the function you want. If each function call was on a line of its own and only made through a reference to the object (v), then you could just step into the function you actually want to step into. It might not sound like much of a problem, but when working on a particularly nasty piece of code and struggling to get it working, you might be stepping through it a lot.

This just keeps getting cooler and cooler as you guys get further in! I can't keep up with the code at all, but it's driven me in my other direction a bit harder myself, towards actually scripting stacked spins instead of just animating them. Hopefully I can make some progress and share some results soon there too.

I'm curious about the spikes though - they look great and can be a useful tool I'll likely import to my video style if that's okay. But could they be made to match the charge profiles of the proton and neutron? I don't know much about that. It looks like they're pretty uniform currently.

Also, what about transparency in the shaders? Would it be useful or possibly to turn the charge transparency down a bit, say 75% or something, as a visual reference? To emulate the field instead of implying (perhaps) discrete particles? Just an idea!

Hi Jared. Of course we can dial down the emissions effect in the code – have you seen it? I usually do so in order to decrease a gif size. The spikes mark the particle charge point locations, I would turn them off, but since they are a precision reminder, I leave them alone. I object to the idea of leaving them on for appearances sake, making what appears to be a spiny particle; unless there’s a good reason, view particles without the spikes.  

Nevyn, thanks for the programming lessons. I could see that code line combining three actions, I'll be very careful using it.

 
Sorry, I have a small problem. I noticed you had made changes about three hours ago, so I collected my changes - mainly adding an icosa configuration - and committed them without a push. I then pulled your changes and they appeared as a branch. I tried to push my changes but get errors. BitBucket does Not show my commit or push. I’ve got my changes copied so I’ll try backing out if that’s what you suggest I should do.  

Reopening Sourcetree I see the graph has changed slightly, the uncommitted changes are yours(?). I'll wait for directions.
.

That looks really bad, but it isn't. I freaked out the first time I did this but it should be easy to fix. It has not created a branch. It looks like it, but it isn't.

What the graph is telling you is that there are 2 commits (1 mine, 1 yours) that are out of order. You had made a commit, but not a push, and that is represented by the blue line. But the GIT server has my commit, which was pushed, and that is showing as the red line. My commit happened before yours did, so the red dot is lower than the blue dot.

To fix this, you just need to pull my commit, but when you do a dialog box with show up on screen and it has several checkboxes on it. The bottom one says 'Rebase instead of merge'. Check that and then press the OK button.



That should pull down my commit and then rebase yours on top of it. Effectively slotting my commit in between your last 2.

If that doesn't clean it up, let me know.