Possible Charged Particle Field

Page 1 of 23 1, 2, 3 ... 12 ... 23  Next

Go down

Possible Charged Particle Field

Post by LongtimeAirman on Fri Jun 15, 2018 12:05 pm

.
I believe I’ve found an excellent threejs program for conversion to the charge field. webgl_gpgpu_protoplanet - https://threejs.org/examples/#webgl_gpgpu_protoplanet.



The image shows that the program uses some sort of a particle system. When particles collide, they join, all coalescing into a protoplanet. Controls, with physics parameters is included.

I would like to reprogram the particles with charge and collisions - a charged particle field would make a great simulation/animation. I’ll be happy to do the majority of the work; if anyone else is interested, a team would be ideal. I’ll probably need some help before it’s done. Is this agreeable to everyone?

Nevyn, do you think this is doable? Are the protoplanet's particles robust enough to add spin and charge? Do you see any problem with this approach, teamwork possibility or simply managing this? It is my sincerest wish to end up with something you would be happy to own; otherwise I'd prefer not to waste our time again.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Jun 15, 2018 7:58 pm

It is more aimed at gravity than charge. You could change it to reflect charge interactions, but all of the work will be in the shaders, so you will need to learn GLSL (OpenGL Shader Language), which is pretty much a variant of C. The problem with developing shaders is that you don't have any sort of debugging framework. You just have to change the code, run it, and see what happens. If it doesn't do what you want, then you just have to figure out where the code is wrong. You don't get to write debug statements to a console to tell you what is happening in your code as it runs. It can be extremely frustrating until you get a feel for the way shaders work and what you can do inside of them.

I think it would be beneficial to come up with a project outline. What is the aim of the project? What is it trying to achieve? What do you want it to show? Very broad ideas of what you want it to be. With that, it will be easier to see what is the best way to accomplish those goals.

It doesn't have to be pages of documentation. A lot of my own projects just start out with the goal of learning something. If I want to learn how to develop 3D systems, then I find some interesting problem to implement in a 3D system and keep going until I have something that works, or I have learnt enough, or I just get sick of it. Another project might start with the goal of being able to easily build molecules. As I think over what I want it to look and act like, I see different ways of accomplishing that. I may change my mind on how it operates or what it looks like as I go along. MBL is not what I set out to achieve, but along the way I saw that it was the best way to go and I am really happy that I did. If I had stuck to my original ideas then it would not even be operable yet. At least, no where near what it is capable of now.

I don't want to discourage you. This example could certainly be a good starting point for something. I can help along the way, which that project guide also helps with as it gives me an idea of what you are doing. At this point, I don't have a good picture of what this app will do. See if you can paint me a better picture.
avatar
Nevyn
Admin

Posts : 1360
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 Sat Jun 16, 2018 12:40 am

After a bit more thought, I'm starting to see some possibilities. I've had a project in the back of my mind for some time and this might be a good way to bring it to life. Essentially it is a charged particle interaction model. Protons and electrons, maybe neutrons, and some rules to govern their behavior based on charge. I have never started this project because I couldn't see how to model the charge field of a particle in an efficient manner.

I think I have found a way. I'm working on some math to calculate the effective charge vector of a particle at some point. It takes into account how far away the point is and how close it is to the poles or equator. The charge field sets the length of the vector and the position of the point determines the direction. The vector is always a repulsion, never an attraction. It can be zero length, but it will always point away from the charged particle. I have an outline for the algorithm, but I haven't coded it and tested it yet.

Does that fit in with what you had in mind? I wasn't sure if you were thinking of charge photon interactions or of larger particles.

avatar
Nevyn
Admin

Posts : 1360
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 Sun Jun 17, 2018 1:16 am

.
Yes, the particles are larger, recycling particles. I'm glad you're seeing some possibilities as well as the difficulties. I'm psyched.

This program contains three strong pluses: a particle engine, a control panel, and an orbital/interactive camera.  I’d failed to mention the orbital camera previously. The fact that they all work together after so many of my own previous difficulties makes this program especially noteworthy.

The proto-planet program seems to meet the basic requirements of a mainstream planetary formation model. All particulate matter within a distributed gravitational field of a so-called proto-planet is described by each particle’s: radius, density, gravity, position and velocity.

I don’t know how gravity is handled by the program just yet – it doesn’t look complicated. The controls include a dynamic variable, which you can change as the program is running – gravityConstant. The single value seems to be applied equally to all particles and aggregate particles at the same time. Increased gravity increases particle accelerations, velocities and mergers. Decreased gravity slows things down greatly, too slow and most particles won’t merge. Acceleration is a change in the particle’s velocity in reaction to the field it encounters – such as large nearby particles; all accelerations are currently due to gravity only.

We must add the charge field. This involves two changes to the parameter list.

The Goal. Changing the particle parameter list to include charge repulsion and spin.

First, in accordance with the charge field, as long as we know a particle’s radius, we know its gravity. Gravity increases as the inverse – or inverse squared – distance between particles. If gravity is treated as a field in the program’s calculations then we must compound the acceleration calculation by adding repulsive charge to the same calculation. Note that charge repulsion is not as simple as gravity, since particle emission is a function of a charged particle’s latitude – most repulsion is felt over the equator, and the least repulsion is felt approaching a particle’s pole.

Second. We must include each particle’s spin - the tangential velocity at the particle’s equator. Spin is thus both a position and a velocity. There are alternative possibilities in implementing spin, the best scheme I’ve come up with is monitoring the particles two pole positions – north and south, (with the particle’s position directly in-between). The two poles would then define the particles’ spin-axis. Once again, we need the spin axis of each particle to determine how much charge repulsion each particle feels.

I'll need to study the program first, but that’s my suggested game plan. If we get to the first goal, we’ll discuss further plans then. I think the essentials will be in place. The proto particles will continue to merge, but I believe the observed behavior of the particle field will change greatly. The major drawback is the fact that adding spin adds a great deal more computational load, efficiencies must be sought.

I don’t see that we would need to mess with the shaders yet – except for maybe adding north and south poles.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Jun 17, 2018 9:26 pm

Nevyn wrote. The charge field sets the length of the vector and the position of the point determines the direction. The vector is always a repulsion, never an attraction. It can be zero length, but it will always point away from the charged particle. I have an outline for the algorithm, but I haven't coded it and tested it yet
Airman. As we know, charge repulsion – bombardment by photons from the earth or from a charged particle - is more than a just a push. The vector you described sounds like the forward push, we also need a spin component. We cannot simulate magnetism without it.

Emission is a function of the particle's latitude, and it will have two components, Vf and Vs. I'm guessing we can determine the magnitudes of the forward and spin components of a particle's emission radiation by directly comparing the two source velocities. Or perhaps some vector addition is in order? We don't need this resolved yet, but we do need to allow for radiative spin.

Anyone?

P.S. Aside from a direct collision, radiative spin is the only mechanism available that can slowly turn the spin axis of the bombarded particle over time. The radiative spin will align all charged particles to the dominant charge source.
.


Last edited by LongtimeAirman on Sun Jun 17, 2018 9:58 pm; edited 1 time in total

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Jun 17, 2018 11:36 pm

Most of the work will be in the shaders, as that is where the current gravity math is. But it isn't that bad. Shaders are a pain to debug, but they also represent a smaller world, where math is more significant and easy to use. Once we know what data we need for the calculations, I will find a way to get it into the shader. This will be a little difficult as it needs to be passed as image data (a texture) but don't worry about that for now.

The way I see it, there are 2 parts to an interaction with a charged particle: the effects of the charge field; and the collision with the real particle if the other can get through the charge field. I am working on some math to handle the first and it will not need any spin information. It should be quite quick to calculate. The collision, on the other hand, may need at least some spin calculations, if we want to go to that length. In the first stages, I think we should just model a standard collision. Most of the time will be spent in the charge field calculations (as in the particle needs to overcome that long before it ever reaches a point of collision) and that will be the main driver of the system. That actually may be all we need for collisions. We don't really need to look into spin stacking or any of that.

Having looked over the code for this example, I see that it is based on set time intervals (1/60th of a second) rather than using the actual amount of time that has passed since the last frame. I usually work with the latter, and we may change it at some point, but for now I think it best to just leave it as-is. It does reduce the complexity of the math a bit, which can be beneficial until we get something working.

So what do we need to do to get started? Setup a project in BitBucket so that we can share the code and work on it separately. I'll do that later today, or maybe tomorrow and invite you to the project. While I do that, you can download the source code for the example and get familiar with it (which you probably already have). Once I have the project created, I'll put the original source code in and commit it so that we have the original example as the start of the project. Then you can clone it to your system and make some UI changes such as making the page title reflect this app, remove any unnecessary parts, etc. Just get it ready for the bulk of the work, which will be in the shader math and I still have some things to consider for that.

You might like to get a bit more familiar with shaders and their math. How to use vectors. How to access the position. How attributes and uniforms work and why you would need them. Just keep in mind that in this app, we will be using them for math, not really what they are meant for (which is geometry and color manipulation). We will be using them more like OpenCL, rather than a graphics based thing (which they really are). It's a fudge, but a useful one.

While I could happily take care of the shader parts, that will end up being most of the project and I want it to be your project more than mine. So I might give you the algorithm so that you can implement it in the shader and we can work together to get it running. It will be frustrating and painful and you will tear your hair out, but when it works the way you want, it feels pretty good. I love that feeling.

In response to your recent post, which was added while I was writing this one:

Yes, spin is needed, and I hadn't thought of the magnetic effects. I don't think we need them at first. They can be added in later. I'll see if it can be added in to my math easily. It could just be a boolean value: is it spinning left or right. Maybe a floating point value between -1 and 1 as it will be a sort of spin density, rather than the spin of a single photon. This would mean that at the edge of the charge field the value will be 0 and close to the BPhoton of that particle it will be 1. That should be fairly easy to implement in the math. The result of it will be a quad with the fist 3 items being the emission vector and the 4th item being the spin component.

Airman wrote:Aside from a direct collision, radiative spin is the only mechanism available that can slowly turn the spin axis of the bombarded particle over time. The radiative spin will align all charged particles to the dominant charge source.

Off-center hits from the electrical component of the charge field can induce rotation as well. It gets complicated, quickly.

I have always assumed it was the straight bombardment of charge that aligned entities to it rather than the spin. The spin doesn't turn off once something is aligned, but the linear velocities of the charge can become balanced for that entity. That is, if the same amount of charge is hitting it on both sides, then it will not rotate. But if one side is getting more hits, or a more dense field, then it will rotate until they are balanced.
avatar
Nevyn
Admin

Posts : 1360
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 Mon Jun 18, 2018 2:35 am

I have created the project and invited you as a developer. Clone the repo and get familiar with it. I copied it from Boids so you should understand the file structure. The readme file explains how to build and deploy, if you want to do it that way but you can just double click the HTML file to run it. I don't see the need for textures (which can create cross site scripting issues) so that shouldn't change.
avatar
Nevyn
Admin

Posts : 1360
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 Mon Jun 18, 2018 1:47 pm

.
Gentle reader, if the above seems a bit overwhelming, join the team. It's almost impossible for me to follow directions until I ask for them. I hit a quick bump to prove it wasn't easy.  

I've cloned the repository and made my first change to the html file. Using Sourcetree, I've committed the first change; I see the change was made to the origin/master (not to origin/head). Should I have created a new branch for myself? So I stopped there, I haven't 'Pushed' the 'Commit' yet. I see no change in BitBucket. I expect I should delete and re-clone the repository, then make my own branch?

I've sent a separate message to Nevyn and am awaiting his further instructions.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Jun 18, 2018 6:01 pm

I did not create any branches for this project. You are free to create one if you want to isolate what you are working on, which is a good idea unless doing small edits, but it is not a big deal if you don't. We can work on master and if we need to remove any commits we will just roll it back to where we want it to be.

You didn't do anything wrong. The origin/master tag shows where your local repository is currently at. The origin/head tag shows where the remote repository is at. I can see the remote but I can't see your local repo. If you had pushed that commit then the origin/head tag would move to the same commit as the origin/master tag to show that they are at the same place.

Just remember that you work in your own private repo and that is what you commit to. When you push, then those commits go to the remote repo (BitBucket server) and become public. Commit to save. Push to share.
avatar
Nevyn
Admin

Posts : 1360
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 Jun 20, 2018 1:32 am

.
The Push worked, good; I'm grateful for the progress.

I finally looked a bit closer at the threejs proto-planet program and I could clearly hear Nevyn say - "you need to learn GLSL".

OK. They start by assuming you know OpenGL. Then, in order to learn OpenGL, you must be familiar with - say, C++.

So, I picked a random Beginner’s OpenGL tutorial.
http://www.opengl-tutorial.org/assets/pdf/opengl_tutorial_2017_06_07.pdf.

It's been a long day, but I'll claim more progress. I’ve updated my drivers, firefox browser, and installed: Visual Studio, CMake and the OpenGLtutorial package. My screen is a bit different, at least the names are the same.



As soon as I find them, I’ll open and play with each of the examples.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Jun 20, 2018 2:37 am

It's great to learn OpenGL, but totally not necessary! GLSL is a language within a language. Or it's a language within a framework within a language. Anyway, you won't be seeing any OpenGL stuff in ThreeJS because the point of ThreeJS is to hide all of that from you (which is called WebGL for browsers). Well, you can see it a bit, but not enough to worry about. However, you will, and have, come across GLSL in ThreeJS. You will need to write it directly, but all of the OpenGL stuff is hidden behind the objects that you are using from ThreeJS.

While it is critical to understand the syntax of GLSL, it is also extremely important to understand the execution environment. Where it is executed. How it is executed. What it is executed with respect to. When it will be executed. It will all become apparent by reading a few tutorials on it. Try to find ones that are ThreeJS specific as things can be slightly different in an OpenGL environment. Not enough to stop you from reading them if it is all you can find or just want more info.

Read through a tutorial and then look back at this project. See if you notice any more than you did before. Try another tutorial and see if you understand more. It looks daunting, but once you can answer those questions above it isn't that difficult. And it gives me time to work on the math a bit more.
avatar
Nevyn
Admin

Posts : 1360
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 Fri Jun 22, 2018 11:02 pm

.
Nevyn wrote. Read through a tutorial and then look back at this project. See if you notice any more than you did before. Try another tutorial and see if you understand more. It looks daunting, but once you can answer those questions above it isn't that difficult. And it gives me time to work on the math a bit more.

Thanks for the timely directions Nevyn. I’ve tried concentrating more on GLSL and three.js, and am currently in part two of A Beginner's Guide to Coding Graphics Shaders by Omar Shehata. https://gamedevelopment.tutsplus.com/series/a-beginners-guide-to-coding-graphics-shaders--cms-834.

As proof of progress, I finally wrote/modified/created my own blank app - threejs ready html file – I didn’t need their’s! For example, in following part two I’m making changes to my file with notepad++ while viewing the browser output and developer console, very satisfying.

The lessons and videos I've looked at favor fragment (or pixel) shaders. I remember having seen and mentioning Shadertoy https://www.shadertoy.com to you guys before; but in following part one I spent my first time playing with the https://www.shadertoy.com/new editor. I can't believe all the fun we're having lately.

Here are a few new references that I found in a new reference. If you know any good sources - where vertex shaders are used for particle computations - please share.  

1. The Book of Shaders, by Patricio Gonzalez Vivo and Jen Lowe.
https://thebookofshaders.com/. “This is a gentle step-by-step guide through the abstract and complex universe of Fragment Shaders”.
2. IQ’s articles (rendering techniques, useful maths, coding hacks…)
http://www.iquilezles.org/index.html
3. OpenGL®️ and OpenGL®️ ES Reference Pages
https://www.khronos.org/registry/OpenGL-Refpages/
Complete descriptions of API commands and shading language functions are provided for the current versions these APIs.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Jul 01, 2018 11:29 pm

Just a quick update to let you know that I have been working on the math for this, but haven't had a lot of time for it lately. You threw me a curve ball when you mentioned magnetism and I am trying to fit it in somehow, but not seeing a nice and clear path yet.
avatar
Nevyn
Admin

Posts : 1360
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 Mon Jul 02, 2018 10:59 pm

.
Thanks Nevyn, no rush. I haven’t gotten much further yet either. I’ve made some pretty, time varying shaders but I haven’t imported any textures yet – that’s next, and uniforms. I’ve also found a couple more shader particle engines I’ll be able to study – including the “other” threejs Bird Flocking example.

I’m still considering the problem of a charged particle parameter list.  

Proto-planet’s observed mass presumably add up to a planet - we are just adding charge. If so, the unseen photons out mass the observed mass twenty to one. Even though Proto-planet’s initial charged particles shown have mass radii much larger than the proton scale, we can assume that they follow charged particle, charge recycling rules; such as, charge mainly enters the particle’s poles and is emitted mainly from the particle’s equator.

Proto-planet begins with a random distribution of observed mass within a cylindrical volume of space. Is that how the charge field would organize things, or does it make charge field sense? What are the ambient conditions?

I believe we (Jared, you, (maybe even Licht and Ciaolo too) and I had a good discussion on this subject way back in March http://milesmathis.forumotion.com/t444-the-sun-s-galactic-orbit-and-charge-field-implications. Planetary charge recycling in our solar system includes direct - say Sol to Earth insolation - and indirect, charge not direct from Sol, such as charge recycling/intake - matter will spin upward and antimatter will spin downward – into the planetary poles. I don’t see how to model unseen charge entering poles just yet.

Appropriate ambient conditions may require a large charged particle – such as Sol, or the “Center of the Galaxy” - with both a large angular aspect and a strong gravitational/charge presence. I suppose it may be distant or central to Proto-planet’s initial mass distribution. This is just discussion at present.

We may naturally try to consider the particles shown as large radii, A-spin, b-photons. Our large particles might also be non-spherical X spins. I don’t know whether a quantization of all spin radius values makes sense yet or not. If we do include such info we may be able to transition to smaller scales more easily.

Distances separating particles may be comparable to the scale of the Earth/moon system or larger. I suspect that means relativity must come into effect. Luckily, the joys of modeling include simplifications - we can ignore time delay, or include it - someday. I agree with you, wherever possible, we should strive to include real time.

I think we should “know” the approximate received photon density between particles. I spoke of radiation spin knowing we are sampling large numbers of photons over some time differential. Most – though not all - emissions exchanged between equal and average particles will tend to spin cancel over time, magnetic emissions do not cancel in the same way. Magnetism may need to be included as a new parameter related to density. I suppose as a particle becomes more magnetic, more coherent emissions would be received from that source, with more efficient transfer of each photon’s tangential spin energy. Note that the emission field - or magnetic field - of large particles are actually dual toroidal fields.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 03, 2018 1:19 am

I'm a little confused on where you want this app to go. I was thinking that we are trying to model charged particles such as electrons and protons. Not planets. So the bright spheres in this app would become the protons and we would introduce code to represent the charge field interactions of the particles. This means that the charge field does not exist in the model, it is abstracted by the code. That is, you don't see the charge photons and we don't have them in memory either. They are just part of the calculation between interacting particles. Just in the math. In essence, the math would boil down to charge densities and a given particle would move based on the densities around it.

I am trying to create an algorithm that calculates the charge density at some point from the particle emitting that charge. This takes the equator to pole differences into account. Once that is done, the main algorithm will look like this:

Code:

for each particle // this loop is actually handled by the shader framework
{
  vector v = this particles velocity
  for each other particle
  {
     calculate charge density of 'other particle' at position of 'this particle'
     add to v, possibly scaling
  }
  this particles velocity = v
}

That is a very basic overview of it. I also want to bring in the ambient field which will be a set density from all directions except where there is another particle in the way. Still not sure how to do that specifically. Maybe I will just model it as an attraction to where other particles are, rather than a repulsion from everywhere except where they are not. That seems like it will be easier to work with and amounts to the same thing.

I'm just not sure how to add spin to that. I'm not sure of what the spin is going to do. I'm not even convinced that magnetism exists at this level. Yes, it exists on the charge photons, but what we call magnetism in something that atoms do, not particles. Even when particles react to magnetism, they are doing so by magnetism created by atoms and molecules. I am tempted to just ignore it for now and see how things look with just the charge interactions.

To be a bit clearer, I think it takes a high charge density for the spin to become magnetism. The charge channels of atoms and molecules can create this coherence and density but I am not convinced that a lone proton can do it. However, each individual charge photon does have that spin component, so there are going to be some effects from it in reality, but is it enough to worry about modeling or are they small enough to ingore?

Happy to hear anyone's thoughts on that, though. I could just be trying to convince myself that I don't have to deal with it. Very Happy
avatar
Nevyn
Admin

Posts : 1360
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 Jul 03, 2018 12:14 pm

.
I mainly want to see charged particle interactions, regardless of the scale, proton or planet.

Yes, I see that this program abstracts photons as charge density emitted and received by the observed particles shown on the screen. We don’t need to worry about “indirect” charge entering the particle poles. It’s the “direct” photon collisions that result in accelerations – changes in direction and velocity - to both the forward velocity as well as the tangential spins of the particles present.

Please consider, the simplest demonstration of the order resulting from the charged field vice the gravitational field alone is shown with just two equal sized charged particles. Depending on their initial positions and velocities, they will begin to orbit or wildly swing past each other. Their close passes will cause each of their spin axii to shift. We must include a mechanism – i.e. magnetism – that allows particles to shift their spin axii without direct collisions.

It seems likely to me that over time all particle spins present will tend to a single spin axis. Magnetism is important in determining how long it takes for the interacting charged particles to reach their long term equilibrium.

Suggest changing your code’s “calculate” line from:
   
Code:
calculate charge density of 'other particle' at position of 'this particle'
to:
Code:
calculate the 3 accelerations due to charge density and gravity of 'other particle' at position of 'this particle'

There’s no good reason to leave magnetism out of the calculation.

I'd also welcome additional opinions.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 03, 2018 8:06 pm

LongtimeAirman wrote:
Please consider, the simplest demonstration of the order resulting from the charged field vice the gravitational field alone is shown with just two equal sized charged particles. Depending on their initial positions and velocities, they will begin to orbit or wildly swing past each other. Their close passes will cause each of their spin axii to shift. We must include a mechanism – i.e. magnetism – that allows particles to shift their spin axii without direct collisions.

It seems likely to me that over time all particle spins present will tend to a single spin axis. Magnetism is important in determining how long it takes for the interacting charged particles to reach their long term equilibrium.

Why would all particles tend to a single spin axis? What stops them from spinning? What are they aligning to? The spin doesn't stop just because the other particle is in some alignment. In your scenario above, the 2 particles would impart spin to each other and it will never stop. In fact, it would keep getting faster and faster until both particles are spinning at c.

LongtimeAirman wrote:
Suggest changing your code’s “calculate” line from:
   
Code:
calculate charge density of 'other particle' at position of 'this particle'
to:
Code:
calculate the 3 accelerations due to charge density and gravity of 'other particle' at position of 'this particle'

I was only outlining the charge interaction code. The gravity code is already present and doesn't need discussion (yet).

LongtimeAirman wrote:
There’s no good reason to leave magnetism out of the calculation.

Being inconsequential is a good enough reason. Making progress without unnecessary complications is a good enough reason. We can always add it in later, once we have a more solid understanding of how it effects the entities in the field.

We also don't actually need spin in order to create spin. We can use imbalanced charge fields to accomplish the same thing and it comes with a way to actually align things. In the above pseudo-code, I said that each particle will measure the other particle from its own position. I have been thinking about calculating the charge densities from a number of positions around the particle, rather than just from its center. If we measure the charge field from the N,S,E,W,F,B of the particle, we can see how they balance with respect to the orientation of the particle. So if the east and west sides have charge vectors in opposite directions, then the particle will spin. If they were in the same direction, then the particle would move.

I understand the desire to include everything at once, but it leads to stagnation when things get too complex to handle. An iterative approach often leads to a better system as you build on top of what you have. It is easier to fiddle with something that is operational than it is to create it all at once. It allows you to focus on one thing at a time as you add it into the system.
avatar
Nevyn
Admin

Posts : 1360
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 Jul 03, 2018 10:08 pm

.
Thanks for explaining things so clearly.

“I believe that all particles will tend to a common spin” is just a reasonable expectation – our own solar system appears to be an example - of the ability of particles to alter the spin direction and velocities of other particles. If radiative spin, or magnetism, is the only means available to change spins, why give it up? But I’m wrong. Your observation that spin can be changed by a differential mechanism far more effectively than the magnetism idea I’ve been defending is great news. Why didn’t you say so sooner?  Very Happy

I like your idea of monitoring the particle’s N,S,E,W,F,B a lot. I'll admit I need to give it more thought.

Your patience is appreciated.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Jul 07, 2018 9:32 pm

.
Status update. Still poking away at GLSL with a Three.js platform, I enjoy it well enough. I see how every mistake results in the same failure to compile error – no clues as to why. Glad I’ve got a wide autistic streak.

I’ve mainly spent several hours with The Book of Shaders, by Patricio Gonzalez Vivo & Jen Lowe, page 05. https://thebookofshaders.com/05/ The Algorithmic drawing page, which includes: Shaping functions, Step and Smoothstep, Sine and Cosine, Some extra useful functions, and Advance shaping functions; and links.

The reader is introduced to built-in math functions. Dividing the screen by the resolution gives one the normalized st.xy. y can be a function of st.x. I wasn’t aware of how one might plot functions in Three.js. Learning how to do so in shader language is a surprise. I have a few small problems, such as #define PI 3.14159265359; // Error, I must use 3.1415926535 instead of PI. The author insists we develop good GLSL karate skills by painting Mr. Miyagi’s fence, by recreating 35 power plots. I complied. Doubling the normalized st.x values then offsetting them by 0.5 to get the desired -1.0 <=x<=1.0 range was the main trick. The deeper lesson is the fact that single 'dimensional' functions are valuable graphics tools that may be implemented in various ways, beyond my current awareness. I'm sure Maya does these sorts of thing much easier GLSL.

I gave 06 Colors page a brief once over. The author makes many challenges without answers. I’ll go to 07 https://thebookofshaders.com/07/, Shapes, next.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Jul 09, 2018 12:56 am

While that is all great to learn, you really just need to be able to specify the math in the GLSL language and to know what data you are given, what data you pass in yourself and what you can pass back out. Most things you come across will NOT output anything because that is not the normal usage of a shader. They are meant to alter the positions of a vertex in a geometry, so you just normally set the position (which is given to you by the framework and you just set its values).

Be careful of slight changes to the language over different versions. The tutorials you find may be a bit old and the language has moved on. Also be careful of what the code is doing as the way it operates is quite different to what most modern language do. Mostly this is because you have direct access to pointers, which are awesome and horrible all at the same time. Most languages hide them from you these days, but in C (which GLSL is a variant of) you have to deal with them.

Maybe an example will help. Suppose we created a vector and called it v1. Then we decalre another vector, called v2, and make it equal to v1. Then we change the x value of v2.

Code:

vec3 v1 = vec3(1, 2, 3);
vec3 v2 = v1;
v2.x = 5;

What do you think v1.x will be at this point?

In most modern languages, it would be 5, because each vector is a reference to an object and when we assigned v1 to v2, we just copied the reference (or pointer) so both v1 and v2 actually refer to the same object. However, in C, this is not the case. When v2 was made equal to v1, it actually created a new vector and copied the values from v1 into it. So v1 and v2 are totally different objects and v1.x will still equal 1.

We can accomplish what modern language do in C though. We have to use pointers for this.

Code:

vec3 v1 = vec4(1, 2, 3);
vec3* v2 = &v1;
v2->x = 5;

After that code has executed, both v1.x and v2.x will be 5 because both v1 and v2 refer to the same object. Let me explain the changes.

Firstly, v2 is not a vector anymore, it is a pointer to a vector. We declare this with the * after the data type. It says that this variable is a pointer and can only point to other variables that are of type vec3.

Secondly the assigning of v1 to v2 now has an & in front of the v1 variable. That is the Address operator. It is used to return the address of a variable rather than the variable itself. So in essence, that line says 'get the address of v1 and copy it into v2'. Only the address, not the data.

Thirdly, the line that changes the x variable uses an arrow rather than a dot. That is the De-referencing operator. It is used to say that we want to access a field within an object, x in this case, but we have a pointer so first use the pointer to find the object and then return the x value of that object. If we used the dot operator, it would have put the value 5 into a memory location that does not represent the x value of v1 (except by accident). This is how hackers create a Buffer Overflow and access memory that they are not supposed to (only they use an array, hence buffer, and look beyond it, hence overflow).

As you can probably tell, C does not restrict you from doing what you told it you wanted to do. It does not make sure that you are referencing a valid object, it just assumes that you are and performs its job. This is why C/C++ applications are fast. It is also why they are error prone.

Why is all of this pointer stuff relevant? Because you might be thinking that you are changing something that you are not. This is especially important when passing data from one function to another. Let's assume that you wanted to pass a vector to another function that changes it for you. A pretty common thing to do. You might do something like this:

Code:

void doubleIt(vec3 v)
{
   v.x *= 2;
   v.y *= 2;
   v.z *= 2;
}

In your main function, you call that function like this:

Code:

vec3 v = vec3(1, 2, 3);
doubleIt( v );

After that has executed, you think that v1 should equal (2, 4, 6), but it still equals (1, 2, 3). That is because C always uses 'pass by value', as opposed to 'pass by reference', unless told to. So when you called doubleIt( v ), it actually created a new vec3 object, copied the content of v into it, and passed that to the function. The function then altered that temporary copy and so you don't see any change to your vector.

There are 2 ways to solve this: return the result from the doubleIt function; or pass in a pointer.

Returning the result:

Code:

vec3 doubleIt(vec3 v)
{
   v.x *= 2;
   v.y *= 2;
   v.z *= 2;
   return v;
}

void main()
{
  vec3 v = vec3(1, 2, 3);
  v = doubleIt( v );
}

OR

Pass a pointer:

Code:

void doubleIt(vec3* v)
{
   v->x *= 2;
   v->y *= 2;
   v->z *= 2;
}

void main()
{
  vec3 v = vec3(1, 2, 3);
  doubleIt( &v );
}

Using a pointer is the fastest method, as it only needs to copy the pointer, not the whole vector. It also doesn't have to return anything, which involves more copying.

As an FYI, the size of a pointer is dependent on the OS being used. This is what it means to be 32bit or 64bit. That refers to the size of an address of a single memory location (and hence how much memory you can access) and a pointer is a memory location so it will be 32 bits on a 32 bit system.

There is more funky stuff you can do with pointers, such as pointer arithmetic, but I don't want to confuse you even more. Suffice to say that most modern languages hide a lot of this from you because you can stuff things up pretty quick. Modern languages call them References, rather than pointers, and you can't do any arithmetic on them. They just reference an object. For example, in Java, every object is actually a reference. Primitives like int, long, float, double, boolean, etc, are not references, but everything else is. When you pass a reference to a function in Java, it gets the reference and not the object (but can access it through the reference). So the first code block above would work in Java, but not in C, because the vector would be an object and the variable would be a pointer, even though you can't tell that it is from the syntax. I often stuff up my C code because I am so used to Java.

I don't know if that is at all related to your problems, but it might help.
avatar
Nevyn
Admin

Posts : 1360
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 Mon Jul 09, 2018 1:13 am

I believe that I have made an important break-through in developing the charge field algorithm for this project. The funny thing is that I had to make the exact same break-through that I made for the algorithm that calculates the charge field densities at some position from a particle.

Essentially, there are 2 algorithms in use here. The first one is used to calculate the charge density of a particle at some point. The second one makes use of that to calculate the charge density from 6 positions on the edge of the particle (N, S, E, W, F, B) and then uses that to determine the changes required to the linear velocity and spin components of the particle.

When I was thinking about the charge density algorithm, I realised that I could break the vector up into 2 parts: the Y component; and the XZ components (assuming the particle is oriented with its North pole in the +Y dimension). The ratio of these components is used to determine whether we are looking at an equator or pole position or some variation in between. This then effects the charge density value to be returned.

I finally realised that I can do the same thing for the 6 positioned vectors calculated in the second algorithm. I split them up into Velocity and Spin components. I'll try to write it up for you guys to peruse.
avatar
Nevyn
Admin

Posts : 1360
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 Mon Jul 09, 2018 4:12 pm

Nevyn wrote. While that is all great to learn, you really just need to be able to specify the math in the GLSL language and to know what data you are given, what data you pass in yourself and what you can pass back out.
...
I don't know if that is at all related to your problems, but it might help.

Thanks Nevyn. I’m familiar enough with the pain and joys of programming to know that your detailed replies to my “few small problems” will help mightily. My current problems include no experience with C, and not having given more than half a thought to programming pointers, buffers, or passing data. While I’m on a tangent, enjoying this learning opportunity, I’ve also learned it’s more important to keep your directions in mind - I added the appropriate bold to your quote above.

Nevyn wrote. I believe that I have made an important break-through in developing the charge field algorithm for this project.

I'll try to write it up for you guys to peruse.

Great, let's see what you’ve got in mind. I'll draw the vector diagrams if you like. It should be easy to show how, given an emitting charged particle, a nearby particle will receive slightly varying direct charge densities at each of its N,S,E,W,F,B set of ortho-compass points. That variance - or differential – gets stronger the smaller the distance (d) between the two particles, at 1/d^3 or 1/d^4. Can't help but notice you mentioned the spin component in the received charge density.  
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Jul 09, 2018 7:01 pm

I did mention the spin component, but not the one you are thinking of. That was not meant to be the spin of the charge photons, but the spin of the central particle, such as a proton. It is just trying to induce spin based on the surrounding charge densities. Basically I am letting each cardinal point act like it is a separate entity, but it will effect, and be effected by, the other points. I'm still figuring out how that math looks but I think the rest of the algorithm is getting close to operational. I haven't actually coded any of this. I'm just playing with ideas at this stage.

With respect to coding the math, we are going to be working with vectors and matrices. I don't believe GLSL has a matrix object yet. I know they were looking into it for OpenCL (which is very close to GLSL but it is for computing, not shaders). Therefore we will need to handle the matrix math ourselves. I already have some routines for that, but you might want to look into it yourself to get familiar with them. The main problem is whether the matrices are row-major or column-major. Most things are row-major but you will come across some column-major matrices if you play with 3D systems long enough. Even within the same framework (such as ThreeJS), you can get a mix of them as the camera systems usually use column-major because it is easier to work with in that instance.

We are also going to be working with images. Not really as image data, but as a transport mechanism. This is how we will pass some of the data in and out. It is the only way to get data out but there are other options to get it in. We wouldn't need images in OpenCL, but we are working in a shader framework, not computing, so we have to make do with what we have. I will take care of that part, but it doesn't hurt to be familiar with how image data works in these systems. You can find many image manipulation routines for OpenCL. The code should be virtually identical, close enough to get the idea.

While I still don't know the specifics, I have a general idea that we are going to have to pass in a lot of data through images. I am thinking that I will create the functions that we will need and the code to retrieve the data from the images and put it back in, but let you implement the actual algorithm from my specification. That will be tricky enough without having to understand the transport mechanism as well. Of course, I will also implement it on my own, for testing if nothing else, but I want you to get a feel for converting the math into code.
avatar
Nevyn
Admin

Posts : 1360
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 Mon Jul 09, 2018 9:57 pm

Here are my very rough notes for the second algorithm. The first algorithm is used to calculate the charge density at some point from the source particle. In this algorithm, we are using that to find the charge density of all other particles from the perspective of this particle.

Charge Density Model


Given a particle, determine the charge field effects of other particles on it.


Conditions and setup:

Each particle is treated as if it was in a set orientation such that its North pole is +Y, East is +X and Front is +Z.
We want all calculations to be performed in this orientation so that we can split some vectors easily.
We will need to transform all other particles into this virtual coordinate system.
We do that by taking the orientation transform of this particle, inverting it, and applying to each other particle.
This will not actually change those particles, but will change the values in the temporary data we have for them.

Algorithm:

Code:

Calculate sum of charge densities from other particles at the cardinal positions on this particle (N,S,E,W,F,B).
For each position:
  Split charge vector into 3 components: 1 linear velocity component that points to the center of the particle; 2 spin components that point in the other 2 dimensions.
  The actual dimensions used are different for each position:
    North: V=-Y, S=X,Z
    South: V=+Y, S=X,Z
    East:  V=-X, S=Y,Z
    West:  V=+X, S=Y,Z
    Front: V=+Z, S=X,Y
    Back:  V=-Z, S=X,Y
  Where a vector with the same sign as the linear velocity dimension means a repulsion and the opposite means attraction (or do we ignore attraction and just let the other side apply repulsion?).
  The spin components work in both directions and just changes the angle from positive to negative.

For linear velocity:
Code:

We now have 6 vectors positioned at 6 positions.
We reduce that to 1 vector by summing them all to find the resultant velocity.
May need to ignore vectors that point away from the center of the particle (attraction).
Add to the particles current velocity.

For spin velocity:
Code:

We now have 12 vectors at 6 positions.
We need to reduce that to 3 angles about 3 axes.
First we reduce each opposite pair to 2 vectors for each pair.
Note that each opposite pair uses the same spin dimensions, but in opposite ways. So a positive in one is the same as a negative in the other.
Take each opposite pair to determine the rotation about both axes orthoganol to the line between their centers.
Example: East-West
    If we look at the East to West pair, then the spin components are in the Y and Z dimensions.
    We split this into 2 vectors per side, one for the Y and one for the Z.
    Now we have 2 Y vectors and 2 Z vectors.
    We subtract one vector from the other for each dimension.
    Why do we subtract? Because that removes the directional component of these vectors. You can think of it as rotating one of the vectors around to the other side.
    That gives us 1 Y vector and 1 Z vector for this pair.
    Each vector represents a tangential velocity, so we use my Spin Velocity transform to convert those vectors into an angle about each axis.
We do that for each pair so we end up with 2 X angles, 2 Y angles and 2 Z angles.
Sum for each dimension to end up with a single angle for each.
We now have 3 rotations that we need to combine into 1.
To do that, we convert them into quaternions and multiply them all together (multiply is add for quaternions).
The resultant quaternion can then be multiplied with the existing spin component of the particle.

The linear velocity will need to be converted back into the working coordinate system. This should just involve applying the original orientation transform to the results. The spin component should not matter.
avatar
Nevyn
Admin

Posts : 1360
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 Jul 10, 2018 5:59 pm

.
Overall looking good. A few questions prevent me from seeing the big picture just yet. I'm sure I'm making a bad assumption or two. Please provide additional clarification and/or corrections.

North and South poles are of course fixed by each particle’s spin axis. Selection of E,W,F, and B are somewhat arbitrary. How are they determined? We know they must all lie on the same equatorial plane, at right angle to the spin axis and through the center of the particle. Once known, the E,W,F,B positions must advance with the particle’s spin. I would assume they must all be tracked for all moments in time. Is that correct?

The proto world ‘system’ is comprised of n particles: a1, a2, …, an. Let’s start with a1. During calculations of its received charge, a1’s center becomes the center of the world system; the world system is also rotated to align with a1’s spin axis and E,W,F,B positions. All the charge density received by a1 (currently - this particle) from all the other particles are calculated for a single moment. Advancing the received charge density calculation through all the remaining charge receiving particles would show the world system is constantly rotating about each and every particle’s spin axis. That seems like a lot of rotating.
 
How are each particle’s charge emissions calculated? Emissions are a function of the particle’s latitude, or world system. I agree that a small differential due to the emitting particle’s spin will be felt on the receiving particle. Both emitting and receiving particles' linear and spin velocities through the world system must be taken into account.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 1 of 23 1, 2, 3 ... 12 ... 23  Next

Back to top


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