Possible Charged Particle Field

Page 10 of 22 Previous  1 ... 6 ... 9, 10, 11 ... 16 ... 22  Next

Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Sep 03, 2018 6:59 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Sep 03, 2018 9:14 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 03, 2018 11:32 pm

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 04, 2018 12:08 am

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 04, 2018 3:59 am

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 04, 2018 8:54 am

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Sep 04, 2018 2:21 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Sep 04, 2018 5:05 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 04, 2018 7:18 pm

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 05, 2018 2:04 am

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
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 05, 2018 4:24 am

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 05, 2018 8:20 am

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. Smile
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 05, 2018 8:45 am

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

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Sep 05, 2018 11:21 am

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Sep 05, 2018 12:44 pm

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

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
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 05, 2018 6:26 pm

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.

avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 06, 2018 5:52 am

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Sep 06, 2018 2:05 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 06, 2018 6:18 pm

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. Very Happy
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Sep 06, 2018 10:17 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 06, 2018 11:09 pm

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 06, 2018 11:56 pm

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Jared Magneson on Fri Sep 07, 2018 2:31 am

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!

Jared Magneson

Posts : 442
Join date : 2016-10-11

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Sep 07, 2018 12:49 pm

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

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Sep 07, 2018 5:20 pm

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.
avatar
Nevyn
Admin

Posts : 1356
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 10 of 22 Previous  1 ... 6 ... 9, 10, 11 ... 16 ... 22  Next

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum