Possible Charged Particle Field

Page 9 of 29 Previous  1 ... 6 ... 8, 9, 10 ... 19 ... 29  Next

Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Aug 29, 2018 8:27 pm

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

////////////////////////////////////
Possible Charged Particle Field  - Page 9 Bitsta12
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.
.

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Aug 29, 2018 9:40 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Aug 29, 2018 10:19 pm

.
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.
Possible Charged Particle Field  - Page 9 Bitsta13
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?
.

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Aug 29, 2018 11:14 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Thu Aug 30, 2018 12:09 am

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Aug 30, 2018 10:21 pm

.
The center of the image is down, negative y.
Possible Charged Particle Field  - Page 9 Drop4n10
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.  
.

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Thu Aug 30, 2018 11:31 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Aug 30, 2018 11:33 pm

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

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Thu Aug 30, 2018 11:48 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Fri Aug 31, 2018 8:49 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Fri Aug 31, 2018 8:56 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Aug 31, 2018 11:46 pm

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

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sat Sep 01, 2018 4:41 am

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sat Sep 01, 2018 7:38 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Sep 01, 2018 10:17 pm

.
Check out that motion-engine branch and have a look at LatticeBody.initLatticeBody05 again. … . Let me know what you think.
Possible Charged Particle Field  - Page 9 Motion10

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

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sat Sep 01, 2018 10:21 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Sep 01, 2018 10:36 pm

.
Possible Charged Particle Field  - Page 9 Motion11
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.  
.

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 02, 2018 1:51 am

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 02, 2018 2:20 am

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 02, 2018 2:51 am

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Sep 02, 2018 1:04 pm

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

LongtimeAirman
Admin

Posts : 1240
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 02, 2018 9:28 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 02, 2018 11:33 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 02, 2018 11:37 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 03, 2018 6:56 pm

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

Posts : 1612
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 9 Empty Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 9 of 29 Previous  1 ... 6 ... 8, 9, 10 ... 19 ... 29  Next

Back to top


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