# Proposal: Electricity Animation

Page **3** of **8** • 1, 2, **3**, 4, 5, 6, 7, 8

## Re: Proposal: Electricity Animation

Hi Jared,

Welcome aboard!

And as I will occasionally say to Nevyn, LTAM and Loyd.... "Looking Good!".

Welcome aboard!

And as I will occasionally say to Nevyn, LTAM and Loyd.... "Looking Good!".

**Cr6**- Admin
- Posts : 876

Join date : 2014-08-09

## Re: Proposal: Electricity Animation

I'm happy to see you folks making progress. I'm really eager to see how a simulation of electricity, wifi etc will look, but I'll try to be patient. I came to post a link to a very interesting paper I just heard about in an email, which apparently corrects an error in Maxwell's equations, which led to the wrong ideas in relativity and quantum weirdness. But I wanted to see how things are going here first. I look forward to Jared's freedom to post more stuff here.

**LloydK**- Posts : 448

Join date : 2014-08-10

## Re: Proposal: Electricity Animation

I don't see any wobble in the latest video at https://vimeo.com/187430663. The axial spin rotates the particle with no lateral motion. The X spin then rotates that about the X axis matching Chris Wheeler's animation on Miles' site. Then a Z spin is added which confused me for some time. I expected a Y spin and I had to adjust my thinking to accommodate. There is no reason that it couldn't be a Z spin, it is just as likely as a Y spin but I would change them around to avoid confusion as Miles always uses X then Y then Z.

I looked hard at the rotations and they look good but it is very hard to know what to expect once you add a second end-over-end spin. They do look odd to me as I am used to my SpinSim which has the velocity adjustments implemented but when I tried to isolate each dimension they looked to be spinning correctly.

It might be helpful to show the radius of each spin level which is basically the translation vector you are applying for that level. Then you could see how that is rotating as a result of its outer spin level.

Does that make sense? I'm not sure what sort of nomenclature you are used to or if you would do things in the same way that I would in code. Maybe I should describe what I am used to and how I have implemented stacked spins.

The basic tools I use for stacked spins are groups, translations, rotations and a BPhoton. A group is a scene graph node that can contain other nodes (including other groups), basic parent-child relationships. Each group can have a transform matrix that allows translation, rotation and scaling of all children in the group. A group is not visible, it just allows easy transformations of objects.

A spin level is implemented as 2 groups, one within the other. The outer, or parent, group has a rotation applied to it. The inner, or child, group has a translation applied to it. This creates an end-over-end spin but it can also create an axial spin by not using a translation. I use 2 groups because I want to ensure that I am rotating the translated object and not translating the rotated object. Not all 3D APIs use the same ordering of translation and rotation when they evaluate transformation matrices.

I take the BPhoton, usually a sphere, and put it into a spin level. I do this by adding the BPhoton to the inner group of that spin level. For the axial spin I do not specify a translation so only the rotation is applied.

To add an X spin, I create the spin level with a translation equal to the radius of its child, in this case the axial spin which is the same as the BPhoton radius. That translation must happen in the YZ plane. It can be anywhere in that plane but I usually put it in the Y dimension (SpinSim allows you to alter this and the results are quite dramatic). That creates a single end-over-end spin.

The levels are connected by adding the outer group of a spin level to the inner group of its parent spin level. So we add the outer group of the axial spin to the inner group of the X spin.

The Y spin is created in the same way as X except we use the radius of the X spin level (which will be 2 times the radius of the particle) and we must translate in the XZ plane (I usually default to Z). Similar for the Z spin and all subsequent spin levels.

The translation of each level is made with respect to the rotational axis of what it is spinning. Each level is spinning its child around the origin of its own coordinate system. When a spin level translates a child, it is moving the origin of the childs coordinate system. I'm not sure if your model is applying the right translations but I'm not convinced that it isn't, either. It's worth a good hard look at how things are being moved around when you add new spin levels, just to be sure.

I think this video is much better than the last. The wobble I saw may have been related to the other spheres showing the previous positions of the particle. I can't think of much to say on improvements, except showing the radii that I mentioned earlier. If you show the radii, you could stop spinning the axis labels and attach them to the origin of that spin level, highlighting what the blue spheres are. Right now they actually help see how it is all spinning but my brain keeps trying to read them in all sorts of orientations.

I looked hard at the rotations and they look good but it is very hard to know what to expect once you add a second end-over-end spin. They do look odd to me as I am used to my SpinSim which has the velocity adjustments implemented but when I tried to isolate each dimension they looked to be spinning correctly.

It might be helpful to show the radius of each spin level which is basically the translation vector you are applying for that level. Then you could see how that is rotating as a result of its outer spin level.

Does that make sense? I'm not sure what sort of nomenclature you are used to or if you would do things in the same way that I would in code. Maybe I should describe what I am used to and how I have implemented stacked spins.

The basic tools I use for stacked spins are groups, translations, rotations and a BPhoton. A group is a scene graph node that can contain other nodes (including other groups), basic parent-child relationships. Each group can have a transform matrix that allows translation, rotation and scaling of all children in the group. A group is not visible, it just allows easy transformations of objects.

A spin level is implemented as 2 groups, one within the other. The outer, or parent, group has a rotation applied to it. The inner, or child, group has a translation applied to it. This creates an end-over-end spin but it can also create an axial spin by not using a translation. I use 2 groups because I want to ensure that I am rotating the translated object and not translating the rotated object. Not all 3D APIs use the same ordering of translation and rotation when they evaluate transformation matrices.

I take the BPhoton, usually a sphere, and put it into a spin level. I do this by adding the BPhoton to the inner group of that spin level. For the axial spin I do not specify a translation so only the rotation is applied.

To add an X spin, I create the spin level with a translation equal to the radius of its child, in this case the axial spin which is the same as the BPhoton radius. That translation must happen in the YZ plane. It can be anywhere in that plane but I usually put it in the Y dimension (SpinSim allows you to alter this and the results are quite dramatic). That creates a single end-over-end spin.

The levels are connected by adding the outer group of a spin level to the inner group of its parent spin level. So we add the outer group of the axial spin to the inner group of the X spin.

The Y spin is created in the same way as X except we use the radius of the X spin level (which will be 2 times the radius of the particle) and we must translate in the XZ plane (I usually default to Z). Similar for the Z spin and all subsequent spin levels.

The translation of each level is made with respect to the rotational axis of what it is spinning. Each level is spinning its child around the origin of its own coordinate system. When a spin level translates a child, it is moving the origin of the childs coordinate system. I'm not sure if your model is applying the right translations but I'm not convinced that it isn't, either. It's worth a good hard look at how things are being moved around when you add new spin levels, just to be sure.

I think this video is much better than the last. The wobble I saw may have been related to the other spheres showing the previous positions of the particle. I can't think of much to say on improvements, except showing the radii that I mentioned earlier. If you show the radii, you could stop spinning the axis labels and attach them to the origin of that spin level, highlighting what the blue spheres are. Right now they actually help see how it is all spinning but my brain keeps trying to read them in all sorts of orientations.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

Indeed, Nevyn, that's precisely how I'm doing it. Maya is completely node-based from top to bottom, and each spin is simply "grouped" with the one above it, as a hierarchy. Each group has a different pivot point, which are simply the quantum stack numbers we're all familiar with; 1, 2, 4, 8, and on up, each one orthogonal in XYZ to the previous one.

(the labels and blue markers and such are also members of their respective groups)

In this way I can eventually push the spins all the way to the proton itself or beyond, but I needed to get the motions down properly.

I'll run that math and do the time variance next.

(the labels and blue markers and such are also members of their respective groups)

In this way I can eventually push the spins all the way to the proton itself or beyond, but I needed to get the motions down properly.

I'll run that math and do the time variance next.

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

I apologize for being so Off-Topic here, pertaining to electricity. But as I understand it, even a directionalized electric "stream" of photons must contain these motions as well, at least one stacked spin. Getting the foundational motions down is critical.

That said, I could easily diagram electricity vs. magnetism without these motions, but that won't necessarily help us understand them and I am often loathe to create videos that are, you know. Wrong.

That said, I could easily diagram electricity vs. magnetism without these motions, but that won't necessarily help us understand them and I am often loathe to create videos that are, you know. Wrong.

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

I thought you must be using the same method because there is only 1 other way, that I can see, to do it and that involves pure math to determine the BPhoton position at any given time. I've been working on those calculations to see what I can find as they would be more useful in a pure math scenario. But they should reach the same result since all of those transformations are just doing the same thing in a different way.

On to the velocity adjustments then. I found the relative spin speeds by analyzing Miles' Angular Velocity equation. I wasn't even thinking about stacked spins at the time, I just wanted to understand the equation a bit better, but I quickly realised the importance of what I had found.

The Angular Velocity equation is

So I started plugging in values for

Which isn't really that helpful so I started to think about relationships between spin levels. The first thing I looked at was the relationship between a spin level and its inner spin level, so I would compare Y to X and Z to Y, etc. I found the same value for all spin levels. Then I decided to compare each spin level to the axial spin level and ended up with this table of values:

That is an interesting relationship but not quite what I needed. I had to figure out what omega meant if I was to use this information correctly. Miles states that omega is an expression of the tangential velocity as travelled on the circumference. It has the same units as the tangential velocity, so m/s in this case. The problem I faced was that I had to work in angles and Miles was trying to move away from them with his redefinition of Angular Velocity. Miles may be correct that radians/s are not that useful in Physics but they are absolutely required in 3D models. So I had to find a way to express omega in radians/s.

Eventually I came to the realisation that the circumference represents a complete circle and omega represents the tangential velocity as travelled on that circumference so if I divide omega by the circumference, I would get the number of rotations per second. If I run the same comparisons as I did above, comparing spin levels to inner spin levels and the axial spin, I get these values:

That gives us the data we need. It tells us that each spin level is rotating 0.707 times by the rate of the next inner spin level.

In your model, you want to be able to specify the rotational speed of the axial spin and then have each subsequent spin level work out its own speed from that. I'm not sure if you can use math to figure it out inside of the model or if you just apply the speeds to you want to each entity. If the latter, then just take your axial speed, I think you said 3Hz, and multiply by the

Voila! Now you have velocity adjusted stacked spins. It takes a lot of working out but once you have the relationships, it is pretty easy to add to the model itself.

I have created a spreadsheet that takes these calculations through 81 spin levels, which reaches a spin radius of over 1m. I have exported it in various formats which you can find here:

On to the velocity adjustments then. I found the relative spin speeds by analyzing Miles' Angular Velocity equation. I wasn't even thinking about stacked spins at the time, I just wanted to understand the equation a bit better, but I quickly realised the importance of what I had found.

The Angular Velocity equation is

**w = sqrt( 2 * r * sqrt( v^2 + r^2 ) - 2 * r^2 )**.So I started plugging in values for

**r**using**v = c**for the tangential velocity. I used a doubling radius and built the following table:Axis | Radius | Circumference | Omega |

A | 2.72E-024 | 2.176E-023 | 4.03840435261255E-008 |

X | 5.44E-024 | 4.352E-023 | 5.71116620581121E-008 |

Y | 1.088E-023 | 8.704E-023 | 8.0768087052251E-008 |

Z | 2.176E-023 | 1.7408E-022 | 1.14223324116224E-007 |

Which isn't really that helpful so I started to think about relationships between spin levels. The first thing I looked at was the relationship between a spin level and its inner spin level, so I would compare Y to X and Z to Y, etc. I found the same value for all spin levels. Then I decided to compare each spin level to the axial spin level and ended up with this table of values:

Axis | Radius | Omega | Ratio to Inner Spin | Ratio to Axial Spin |

A | 2.72E-024 | 4.03840435261255E-008 | 1 | |

X | 5.44E-024 | 5.71116620581121E-008 | 1.4142135624 | 1.4142135624 |

Y | 1.088E-023 | 8.0768087052251E-008 | 1.4142135624 | 2 |

Z | 2.176E-023 | 1.14223324116224E-007 | 1.4142135624 | 2.8284271247 |

That is an interesting relationship but not quite what I needed. I had to figure out what omega meant if I was to use this information correctly. Miles states that omega is an expression of the tangential velocity as travelled on the circumference. It has the same units as the tangential velocity, so m/s in this case. The problem I faced was that I had to work in angles and Miles was trying to move away from them with his redefinition of Angular Velocity. Miles may be correct that radians/s are not that useful in Physics but they are absolutely required in 3D models. So I had to find a way to express omega in radians/s.

Eventually I came to the realisation that the circumference represents a complete circle and omega represents the tangential velocity as travelled on that circumference so if I divide omega by the circumference, I would get the number of rotations per second. If I run the same comparisons as I did above, comparing spin levels to inner spin levels and the axial spin, I get these values:

Axis | Radius | Omega / Circumference | Ratio to Inner Spin | Ratio to Axial Spin |

A | 2.72E-024 | 1855884353222680 | 1 | |

X | 5.44E-024 | 1312308411261770 | 0.7071067812 | 0.7071067812 |

Y | 1.088E-023 | 927942176611340 | 0.7071067812 | 0.5 |

Z | 2.176E-023 | 656154205630883 | 0.7071067812 | 0.3535533906 |

That gives us the data we need. It tells us that each spin level is rotating 0.707 times by the rate of the next inner spin level.

In your model, you want to be able to specify the rotational speed of the axial spin and then have each subsequent spin level work out its own speed from that. I'm not sure if you can use math to figure it out inside of the model or if you just apply the speeds to you want to each entity. If the latter, then just take your axial speed, I think you said 3Hz, and multiply by the

**Ratio to Axial Spin**values in that last table.Axis | Formula | Spin Frequency |

A | 3 * 1 | 3 |

X | 3 * 0.707 | 2.1213203436 |

Y | 3 * 0.5 | 1.5 |

Z | 3 * 0.3535533906 | 1.0606601718 |

Voila! Now you have velocity adjusted stacked spins. It takes a lot of working out but once you have the relationships, it is pretty easy to add to the model itself.

I have created a spreadsheet that takes these calculations through 81 spin levels, which reaches a spin radius of over 1m. I have exported it in various formats which you can find here:

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

Thanks so much for doing that math for me! I was going to dig in, but I would have surely messed it up. Architecture is easy; physics, I'm not so good at, which is why we're here in the first place: to discuss ideas from someone who is pretty damn good at it. Nice to see he's not alone! In Maya, I'm using a standard non-linear animation "timeline" with keyframes, so I'm using seconds as opposed to frequency. You can kinda see the timeline on my screenshot, but here's a better shot of it showing the keyframes on my stacked spin.

Playback is at 30 frames-per-second. As you can see, begins at frame 360 (first red ticker) and the cycle ends at frame 450, with a "post-infinity" curve modifier after that so it cycles on. 90 frames = 3 seconds.

Sp we nee to convert for seconds-per-rotation. All my spins in that video including my initial Axial spin are (currently) 3 seconds long, not 3Hz. So does that first time-length even matter, or does the length of the second spin begin the math? Since the Axial spin isn't translating at all?

Regardless, am I correct in this conversion using 3 seconds?

1st stacked spin = 3 seconds

2nd stacked spin = 3*1.707 = 5.121 seconds

3rd stacked spin = 5.121*1.5 = 7.682 "

4th stacked spin = 7.682*1.354 = 10.4 "

...and on like that? Or are all the numbers just multiples of that initial 3 seconds? I'm adding 1 to each of the multipliers to account for the prior spin's timing, as I'm not looking for spin frequency but the time it takes to travel once around each spin, you see. Is that incorrect?

Playback is at 30 frames-per-second. As you can see, begins at frame 360 (first red ticker) and the cycle ends at frame 450, with a "post-infinity" curve modifier after that so it cycles on. 90 frames = 3 seconds.

Sp we nee to convert for seconds-per-rotation. All my spins in that video including my initial Axial spin are (currently) 3 seconds long, not 3Hz. So does that first time-length even matter, or does the length of the second spin begin the math? Since the Axial spin isn't translating at all?

Regardless, am I correct in this conversion using 3 seconds?

1st stacked spin = 3 seconds

2nd stacked spin = 3*1.707 = 5.121 seconds

3rd stacked spin = 5.121*1.5 = 7.682 "

4th stacked spin = 7.682*1.354 = 10.4 "

...and on like that? Or are all the numbers just multiples of that initial 3 seconds? I'm adding 1 to each of the multipliers to account for the prior spin's timing, as I'm not looking for spin frequency but the time it takes to travel once around each spin, you see. Is that incorrect?

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

To work that way, you want to use 1.414, not 0.707. The

However, you probably need to work backwards to this so that you can set the

That might make the axial spin a bit too fast but you can just replace the value

**time**to complete a full rotation will be 1.414 times by the time of the inner spin level. If you look at my spreadsheet you will see where I have performed this inverted relationship and where these numbers are coming from.Axis | Formula | Spin Time |

A | 3 * 1 | 3 |

X | 3 * 1.414 | 4.2426406872 |

Y | 3 * 2 | 6 |

Z | 3 * 2.828 | 8.4852813741 |

However, you probably need to work backwards to this so that you can set the

**longest**time on the top spin level (as this will dictate the length of the animation).Axis | Formula | Spin Time |

A | 3 / 2.828 | 1.06066017179 |

X | 3 / 2 | 1.5 |

Y | 3 / 1.414 | 2.12132034351 |

Z | 3 / 1 | 3 |

That might make the axial spin a bit too fast but you can just replace the value

**3**in the above table and recalculate to make it longer.**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

Please note that I am using the standard

**X, Y, Z**structure but your model has**Y**and**Z**swapped around so you will need to swap the values as well.**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

That first set of numbers looks proper, since I can just lengthen my last keyframe for each spin. So the axial spin will be 3 seconds, and on up from there. But for the sake of visualization, I'm going to have each spin go at least three times on its own before the next kicks in, so I have a little work to do.

If you look at Maya's coordinate system in that screenshot, down on the bottom left of the main viewport, you'll see that Y is "up", in 3D here. Switch the camera to isometric front and Y is "up", X is left and right. Z is always depth, especially when running a z-depth pass in CGI. So if the axial spin is on the Y axis, as mine is, then that third spin must be on Z to remain orthogonal.

We can try it any way we like after I get these timings fixed.

If you look at Maya's coordinate system in that screenshot, down on the bottom left of the main viewport, you'll see that Y is "up", in 3D here. Switch the camera to isometric front and Y is "up", X is left and right. Z is always depth, especially when running a z-depth pass in CGI. So if the axial spin is on the Y axis, as mine is, then that third spin must be on Z to remain orthogonal.

We can try it any way we like after I get these timings fixed.

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

Another way to look at it that might be easier for you to implement is to use angles. The circumference represents a full rotation so it equals 2*pi (where pi=3.14). So if you are applying some angle, let's call it theta, to the axial spin level per frame, then the X spin will be theta * 0.707. The Y spin will be theta * 0.707 * 0.707, and so on.

If the axial spin takes 3s to complete a full rotation and there are 30 frames per second then theta is:

theta = 3/(3*30) * 2pi

theta = 1/30 * 2pi

theta = pi/15

theta = 0.209439510239 radians

Let's put that into a table:

And an inverted version based on the top spin level angle:

If the axial spin takes 3s to complete a full rotation and there are 30 frames per second then theta is:

theta = 3/(3*30) * 2pi

theta = 1/30 * 2pi

theta = pi/15

theta = 0.209439510239 radians

Let's put that into a table:

Axis | Formula | Angle per Frame |

A | theta | 0.209439510239 |

X | 0.209439510239 * 0.707 | 0.148096097941 |

Y | 0.209439510239 * 0.5 | 0.104719755123 |

Z | 0.209439510239 * 0.3535533906 | 0.074048048973 |

And an inverted version based on the top spin level angle:

Axis | Formula | Angle per Frame |

A | 0.209439510239 / 2.828 | 0.074048048973 |

X | 0.209439510239 / 2 | 0.104719755123 |

Y | 0.209439510239 / 1.414 | 0.148096097941 |

Z | 0.209439510239 / 1 | 0.209439510239 |

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

Jared Magneson wrote:If you look at Maya's coordinate system in that screenshot, down on the bottom left of the main viewport, you'll see that Y is "up", in 3D here. Switch the camera to isometric front and Y is "up", X is left and right. Z is always depth, especially when running a z-depth pass in CGI. So if the axial spin is on the Y axis, as mine is, then that third spin must be on Z to remain orthogonal.

The 3rd spin level does not

**have**to be on Z as a result of the axial spin being on Y. It

**can**be but it does not have to be. I can see why you would think so but I don't believe that it forces that requirement. When adding a new spin level, you only have to be orthogonal to the spin level that you are now spinning. This does get confusing. It may be easier to talk of particles rather than spin levels.

We take the BPhoton and give it an axial spin. We don't normally make this distinction but that axial spin has created a new particle, it isn't the same as the BPhoton that we started with (it has more energy for one thing). If we now give that an X spin, we have created another particle or I should say another form of particle, it hasn't created a whole new particle with the original one existing along side of it. I speak of particles as-in a proton is a particle and an electron is a particle and the proton is just an electron with more spin levels.

Any given spin level is just an end-over-end spin of the particle that it is spinning. How that end-over-end spin is applied is only dictated by the top level spin of the particle that we are trying to add a spin level to. That existing top level spin is what the new spin has to be orthogonal to.

It comes down to how a new spin level is added. We have to look at the collision that causes the new spin level. The incoming particle must be traveling in the same direction as the top spin level

**axis**of our particle. So if our particle, P1, has a top spin level on X, then the incoming particle, P2, must be traveling in the X dimension. P2 must hit P1 on the edge of P1 but it can hit

**anywhere on the edge**. To keep it simple we assume it is either on the Y or Z dimension of P1. This collision would make a great animation to help explain how stacked spins are added.

I wanted to go into a bit more detail but have run out of time. Please ask any questions you may have and I will try to explain it better. If you still think they must be orthogonal to all axes, then just make the axial spin about the Z axis. I know we are used to seeing it on the Y axis, but it is really just a pi/2 phase difference once you add the X spin.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

No, I agree completely, they do not HAVE to be orthogonal to the previous 2. I merely animated it this way as a matter of ordering, and at this point I'm almost ready to show the hypothetical collision causing the next stack. I've retimed the rotational speeds per your math, which wasn't too difficult just a little tedious, since I'm dealing with ratios of seconds @ 30 FPS. It looks pretty weird. Go to vimeo.com/187503032.

So a good question would be, are any combinations of the next-spin ordering possible? Are some more likely than others, or is it almost completely random? Since the combinations stack as well as the spins, do we get different energies at different combinations?

To make it more clear what I'm getting at, are certain colors (between the base red and violet) perhaps based on different spin configurations, as that photon hits the eye?

So a good question would be, are any combinations of the next-spin ordering possible? Are some more likely than others, or is it almost completely random? Since the combinations stack as well as the spins, do we get different energies at different combinations?

To make it more clear what I'm getting at, are certain colors (between the base red and violet) perhaps based on different spin configurations, as that photon hits the eye?

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

I had a quick look but don't have the time right now to write up a decent analysis. Something doesn't look right but I want some time to evaluate it correctly. But I'll try to quickly answer your other questions.

It seems to me that a new spin level can be added anywhere on the outer boundary of the previous spin level. This adds a lot of variance to the spin paths. I can model some of them but I have not allowed enough variance to model them all. It would be fairly simple to do so, though.

However, I think balance might come into play which would guide us back to nice alphabetical stacks. While it may be possible for a Z spin to be added to an X spin, and then add another X spin on top of that, the final particle would not be as balanced as X, Y, Z or even X, Z, Y. I'm not exactly sure, this is all exploratory physics. My mind

I don't think colors are based on that. Miles has covered color in a few papers but I must say that I have not looked too closely at them. They seemed to make sense to me at the time but I haven't worked in that area and it is through building my apps that I learn the most.

Jared Magneson wrote:So a good question would be, are any combinations of the next-spin ordering possible? Are some more likely than others, or is it almost completely random? Since the combinations stack as well as the spins, do we get different energies at different combinations?

It seems to me that a new spin level can be added anywhere on the outer boundary of the previous spin level. This adds a lot of variance to the spin paths. I can model some of them but I have not allowed enough variance to model them all. It would be fairly simple to do so, though.

However, I think balance might come into play which would guide us back to nice alphabetical stacks. While it may be possible for a Z spin to be added to an X spin, and then add another X spin on top of that, the final particle would not be as balanced as X, Y, Z or even X, Z, Y. I'm not exactly sure, this is all exploratory physics. My mind

**wants**it to be a nice X, Y, Z progression but I have to justify that somehow.Jared Magneson wrote:To make it more clear what I'm getting at, are certain colors (between the base red and violet) perhaps based on different spin configurations, as that photon hits the eye?

I don't think colors are based on that. Miles has covered color in a few papers but I must say that I have not looked too closely at them. They seemed to make sense to me at the time but I haven't worked in that area and it is through building my apps that I learn the most.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

I don't think you're off-topic and that seems to be everyone's feeling. Feel free to get down to basics for accuracy.Jared Magneson wrote:I apologize for being so Off-Topic here, pertaining to electricity. But as I understand it, even a directionalized electric "stream" of photons must contain these motions as well, at least one stacked spin. Getting the foundational motions down is critical.

That said, I could easily diagram electricity vs. magnetism without these motions, but that won't necessarily help us understand them and I am often loathe to create videos that are, you know. Wrong.

---

By the way, you all, do you agree that there is only one A spin? MM's papers mention A1, X1, Y1, Z1, A2, X2 etc, but there is no second axial spin. Right?

**LloydK**- Posts : 448

Join date : 2014-08-10

## Re: Proposal: Electricity Animation

Now that you have displayed the circular path for each spin level I can see that the spin levels are not relative to each other but are positioned relative to the origin.

The way I setup the spin levels always puts the top spin level axis at the origin. The particle inside of that spin level (including all of its spin levels) is translated so that the rotational axis of the new spin level is at 0, 0, 0.

Let's run through an example as it is often easier to see with numbers.

We start with a BPhoton with its center positioned at the origin (0, 0, 0).

We give it an axial spin which leaves the BPhoton at the origin and creates a rotational axis also at the origin. That rotational axis points along the Y dimension.

To give this an X spin, the axial spin level is translated in the Y dimension with a distance equal to the radius of the axial spin level, which equals the radius of the BPhoton, let's call that r. This translation puts the axial spin axis at (0, r, 0) which makes the BPhoton rotate around that point, not the origin. The X spin level causes the whole axial spin level to rotate around the origin.

To give this a Y spin, the X spin level is translated in the Z dimension with a distance equal to the radius of the X spin level, which is 2r. This puts the rotational axis of the X spin at (0, 0, 2r). The Y spin then rotates the whole X spin level around the origin.

This puts the center of the BPhoton, assuming no rotation has occurred, at (0, r, 2r).

To give it a Z spin, the Y spin is translated in the X dimension with a distance equal to 4r, putting the Y spin level axis at (r4, 0, 0). This puts the BPhoton center at (4r, r, 2r).

It is important to realise that each spin level creates its own coordinate system. The X spin translates the particle by (0, r, 0) but it doesn't know that the Y spin is translating the whole X spin level by (0, 0, 2r). The X spin is rotating its particle about the origin of the X spin level, not necessarily about the absolute origin. The Y spin rotates its particle about the origin of the Y spin level.

Does that make sense? It's a bit late so I'll re-read what I have written tomorrow and see if I can explain it better.

If you look at the circular paths in your video, you can see that they never go inside of the next outer spin level. They spin on the edge of it but they should be spinning around the tangent to that edge which would make the particle go inside of and outside of the spin path of its outer level.

Look at the particle when it only has an axial spin. See how the BPhoton is half in and half out of the X spin circle? That should happen for all spin levels. The outer edge of the BPhoton should be able to touch the center of its top level spin when all of its spin level align in such a way that it can do so.

The way I setup the spin levels always puts the top spin level axis at the origin. The particle inside of that spin level (including all of its spin levels) is translated so that the rotational axis of the new spin level is at 0, 0, 0.

Let's run through an example as it is often easier to see with numbers.

We start with a BPhoton with its center positioned at the origin (0, 0, 0).

We give it an axial spin which leaves the BPhoton at the origin and creates a rotational axis also at the origin. That rotational axis points along the Y dimension.

To give this an X spin, the axial spin level is translated in the Y dimension with a distance equal to the radius of the axial spin level, which equals the radius of the BPhoton, let's call that r. This translation puts the axial spin axis at (0, r, 0) which makes the BPhoton rotate around that point, not the origin. The X spin level causes the whole axial spin level to rotate around the origin.

To give this a Y spin, the X spin level is translated in the Z dimension with a distance equal to the radius of the X spin level, which is 2r. This puts the rotational axis of the X spin at (0, 0, 2r). The Y spin then rotates the whole X spin level around the origin.

This puts the center of the BPhoton, assuming no rotation has occurred, at (0, r, 2r).

To give it a Z spin, the Y spin is translated in the X dimension with a distance equal to 4r, putting the Y spin level axis at (r4, 0, 0). This puts the BPhoton center at (4r, r, 2r).

It is important to realise that each spin level creates its own coordinate system. The X spin translates the particle by (0, r, 0) but it doesn't know that the Y spin is translating the whole X spin level by (0, 0, 2r). The X spin is rotating its particle about the origin of the X spin level, not necessarily about the absolute origin. The Y spin rotates its particle about the origin of the Y spin level.

Does that make sense? It's a bit late so I'll re-read what I have written tomorrow and see if I can explain it better.

If you look at the circular paths in your video, you can see that they never go inside of the next outer spin level. They spin on the edge of it but they should be spinning around the tangent to that edge which would make the particle go inside of and outside of the spin path of its outer level.

Look at the particle when it only has an axial spin. See how the BPhoton is half in and half out of the X spin circle? That should happen for all spin levels. The outer edge of the BPhoton should be able to touch the center of its top level spin when all of its spin level align in such a way that it can do so.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

@LloydK: I agree, there's only one initial axial spin. I think perhaps Mathis got a little confused in the ordering, just as I have here. It does get complex to visualize, which is why I'm here struggling through it even now!

@Nevyn: I see precisely what you mean, and should be able to easily fix my transforms and pivots to account for this. It DID look wonky to me, but I couldn't place why.

I'm going to go ahead and switch to an A, X, Y, Z ordering for ease of communication and visual sense-making, and report back when I get these things fixed.

@Nevyn: I see precisely what you mean, and should be able to easily fix my transforms and pivots to account for this. It DID look wonky to me, but I couldn't place why.

I'm going to go ahead and switch to an A, X, Y, Z ordering for ease of communication and visual sense-making, and report back when I get these things fixed.

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

Alright, feels like I'm actually getting somewhere here! I fixed the spacing and origins, Nevyn, per your description. I also had some bad pivot transforms going on in my groups, so I fixed those too. vimeo.com/187560889

Then I ran a quick fading-outparticle emission to trace the motion path for us, although it may not be terribly helpful. I decided not to change my ordering for now, for the sake of time. So it goes A, X, Z, Y in this case still. We'll add another three stacks once this sim looks accurate to all of us (including Mathis, who responds shortly but sweetly to my emails).

What we see is no more wobble, and a pretty natural-looking progression visible through each spin at all times. There's a "kink" when the X-spin parallels the Y-spin, but that also seems pretty natural.

Take a look when you folks have time and let me know if you see anything fishy, now? Don't hesitate to tell me that it's wrong. I'm going to keep going until it's right, or at least accurate to theory here!

Then I ran a quick fading-outparticle emission to trace the motion path for us, although it may not be terribly helpful. I decided not to change my ordering for now, for the sake of time. So it goes A, X, Z, Y in this case still. We'll add another three stacks once this sim looks accurate to all of us (including Mathis, who responds shortly but sweetly to my emails).

What we see is no more wobble, and a pretty natural-looking progression visible through each spin at all times. There's a "kink" when the X-spin parallels the Y-spin, but that also seems pretty natural.

Take a look when you folks have time and let me know if you see anything fishy, now? Don't hesitate to tell me that it's wrong. I'm going to keep going until it's right, or at least accurate to theory here!

**Jared Magneson**- Posts : 330

Join date : 2016-10-11

## Re: Proposal: Electricity Animation

.

Looking at Nevyn's list, I think it's strange that there could be charged particles out there as big as me, or at least one doubling set bigger than the proton. What would it look like? Can your (and Nevyn’s) model show me that? vimeo.com/187560889 looks good. I think you’ve got it. The particle coordinate system should always be centered to the center of the top spin level, the collision point causing the top level end-over-end motion.

I suppose the stacked spin model extends Chris Wheeler’s end-over-end spin doubling applied to the b_photon out to our desired charge particle radius. We thereby understand that the electron or a proton is a single b_photon with many stacked spins. Masses are determined strictly according to those radius/mass doublings, yet the only apparent ponderability is the b_photon motion.

How can the b_photon possibly move like that? I have never been able to accept the stacked spin modeled motion at face value. I MUST rationalize that the charge particle is constantly recycling smaller particles that is not shown in the model. The particle’s volume of space would then become filled with contra-streams of smaller particles that could somehow justify the b_photon gyrations.

Forgive me if I sound heretical. I have a hard time agreeing with anyone.

.

**Hi Jared**, Sorry to join in so late. I couldn’t have kept up anyway – easier and more fun to watch.Looking at Nevyn's list, I think it's strange that there could be charged particles out there as big as me, or at least one doubling set bigger than the proton. What would it look like? Can your (and Nevyn’s) model show me that? vimeo.com/187560889 looks good. I think you’ve got it. The particle coordinate system should always be centered to the center of the top spin level, the collision point causing the top level end-over-end motion.

I suppose the stacked spin model extends Chris Wheeler’s end-over-end spin doubling applied to the b_photon out to our desired charge particle radius. We thereby understand that the electron or a proton is a single b_photon with many stacked spins. Masses are determined strictly according to those radius/mass doublings, yet the only apparent ponderability is the b_photon motion.

How can the b_photon possibly move like that? I have never been able to accept the stacked spin modeled motion at face value. I MUST rationalize that the charge particle is constantly recycling smaller particles that is not shown in the model. The particle’s volume of space would then become filled with contra-streams of smaller particles that could somehow justify the b_photon gyrations.

Forgive me if I sound heretical. I have a hard time agreeing with anyone.

**Nevyn**, Great feedback, complete and prompt explanations, data too! You're good..

**LongtimeAirman**- Admin
- Posts : 749

Join date : 2014-08-10

## Re: Proposal: Electricity Animation

No, the Y and Z spin levels are still rotating the wrong way. The X spin is perfect and you need to get Y and Z working the same way.

The key point is that every spin level, except the axial spin, is just an end-over-end spin of whatever it is spinning. When you first start to think about building stacked spins, you start with the raw BPhoton, add an axial spin, add an X spin, add a Y spin and finally add a Z Spin. It makes sense to think about it in this way. However, to ensure that you have all of the spin levels rotating correctly, it is better to start at the Z spin.

I want you to copy this model to a new file so that we can make some drastic changes without affecting the original model. Or you could just start a new model if that is easy enough for you. Basically what I want to do is isolate each spin level.

If my understanding is correct, you currently have a scene graph that looks something like this (yours probably has other levels but this is an abstract view):

The first thing I want to do is ensure that the Z spin is working correctly. In order to do this, I want to remove everything inside of the Z spin and replace it with a sphere with a radius of 4r (where r is the original BPhoton radius). If the Z spin is working correctly, this should show an end-over-end spin about the Z axis. The sphere should touch the point that it is rotating around just like the X spin in your current model. You may need to translate the sphere by 4r so that one edge of it touches the origin, assuming you are rotating around the origin. Alternatively, you can set the pivot point for the Z spin to be translated by 4r in the X dimension, whichever way you are used to. I think it will all come together a bit easier if you put the spin axis at the origin but that may just be because I am used to working that way.

The 4r sphere is showing the volume of space that anything inside of this spin level can occupy. In the complete model, the Y spin moves within that sphere and the Z spin moves that sphere around its origin.

So at this stage, you should have a scene graph that looks something like this:

In my way of doing this, I would end up with a scene graph like this:

Strictly speaking, the Z Spin group is unnecessary, but can be useful to put things in like labels, path markers, etc.

Once you have that working correctly, copy the original model to another file and remove the Z spin so that the Y spin is the top level spin. Remove everything inside of the Y spin and replace it with a sphere with a radius of 2r. This should show an end-over-end spin about the Y axis.

Sorry, I've just realised that I have assumed a top level Z spin so if you haven't yet changed the order around, do the Y level first using a radius of 4r and then the Z level with a radius of 2r. Essentially, start at the top and work your way down the scene graph.

Once you have those 2 models showing an end-over-end spin, you need to figure out how to combine them again. This should be as simple as putting the Y spin level inside of the Z spin and the X spin inside of the Y spin, etc.

To summarize this post, I want to test each individual spin level by replacing its contents with a sphere the same size as those contents. This removes the inner spins which complicate things and make it hard to see what is going on. Every spin level must act the same way that your current X spin does, just rotating about a different dimension.

The key point is that every spin level, except the axial spin, is just an end-over-end spin of whatever it is spinning. When you first start to think about building stacked spins, you start with the raw BPhoton, add an axial spin, add an X spin, add a Y spin and finally add a Z Spin. It makes sense to think about it in this way. However, to ensure that you have all of the spin levels rotating correctly, it is better to start at the Z spin.

I want you to copy this model to a new file so that we can make some drastic changes without affecting the original model. Or you could just start a new model if that is easy enough for you. Basically what I want to do is isolate each spin level.

If my understanding is correct, you currently have a scene graph that looks something like this (yours probably has other levels but this is an abstract view):

Z Spin | ||||

Y Spin | ||||

X Spin | ||||

A Spin | ||||

BPhoton |

The first thing I want to do is ensure that the Z spin is working correctly. In order to do this, I want to remove everything inside of the Z spin and replace it with a sphere with a radius of 4r (where r is the original BPhoton radius). If the Z spin is working correctly, this should show an end-over-end spin about the Z axis. The sphere should touch the point that it is rotating around just like the X spin in your current model. You may need to translate the sphere by 4r so that one edge of it touches the origin, assuming you are rotating around the origin. Alternatively, you can set the pivot point for the Z spin to be translated by 4r in the X dimension, whichever way you are used to. I think it will all come together a bit easier if you put the spin axis at the origin but that may just be because I am used to working that way.

The 4r sphere is showing the volume of space that anything inside of this spin level can occupy. In the complete model, the Y spin moves within that sphere and the Z spin moves that sphere around its origin.

So at this stage, you should have a scene graph that looks something like this:

Z Spin | ||

Pivot Point | ||

translate=4r, 0, 0 | ||

axis=0, 0, 1 | ||

angle=theta | ||

Sphere | ||

radius=4r |

In my way of doing this, I would end up with a scene graph like this:

Z Spin group | ||||

Rotation group | ||||

axis=0, 0, 1 | ||||

angle=theta | ||||

Translation group | ||||

translate=4r, 0, 0 | ||||

Sphere | ||||

radius=4r |

Strictly speaking, the Z Spin group is unnecessary, but can be useful to put things in like labels, path markers, etc.

Once you have that working correctly, copy the original model to another file and remove the Z spin so that the Y spin is the top level spin. Remove everything inside of the Y spin and replace it with a sphere with a radius of 2r. This should show an end-over-end spin about the Y axis.

Sorry, I've just realised that I have assumed a top level Z spin so if you haven't yet changed the order around, do the Y level first using a radius of 4r and then the Z level with a radius of 2r. Essentially, start at the top and work your way down the scene graph.

Once you have those 2 models showing an end-over-end spin, you need to figure out how to combine them again. This should be as simple as putting the Y spin level inside of the Z spin and the X spin inside of the Y spin, etc.

To summarize this post, I want to test each individual spin level by replacing its contents with a sphere the same size as those contents. This removes the inner spins which complicate things and make it hard to see what is going on. Every spin level must act the same way that your current X spin does, just rotating about a different dimension.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

LongtimeAirman wrote:How can the b_photon possibly move like that?

While writing these posts, I have had an idea on why the stacked spins happen. This is only an idea at this point and I have not had time to flesh it out.

On the pi=4 thread, I made a comment that reality does not use vector addition, it just applies all vectors and that is why we need to sum the length of each vector to get the distance traveled on a curve. Well, the same thing applies here. The BPhoton has an existing axial spin which is spinning with a tangential velocity of

**c**, the fastest possible spin rate. If a collision happens at the top of that axial spin (or the bottom, basically where the rotational axis meets the particle boundary) then the particle is given a new velocity vector which is must apply with all of the existing ones. The particle can't just add all of those vectors together to get one final velocity, it must apply them all.

It needs a lot more work but I think the two concepts are related.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

LongtimeAirman wrote:.

Looking at Nevyn's list, I think it's strange that there could be charged particles out there as big as me, or at least one doubling set bigger than the proton. What would it look like? Can your (and Nevyn’s) model show me that?

I didn't mean to imply that there could be that many spins, I was just interested to see how many spin levels it took to reach 1m and it isn't that many. I believe the electron is around 10^-14m and it only takes around 14 spin levels to reach that. I agree with you, spins stop being added somewhere slightly above the proton, at least naturally. In the right conditions we could probably add more spins but I would think that gravity starts to take over as the dominant force just above the proton. Or maybe it is mass that starts to become an issue around that size. Maybe it is dependent on the ambient charge field. Maybe it is all of those things together, I don't know. I was just interested to see how the numbers played out at the 1m mark because that is a size I can relate to. It is interesting that even with a spin radius near 1m, it still has a frequency of 2387Hz.

I have investigated higher spin sets (a spin set is a conceptual grouping of consecutive X, Y and Z spin levels) and they aren't that interesting. SpinSim can give you 3 spin sets which is enough to show that they are just the same general path with slight perturbations caused by the inner spins. Basically what happens is that you have to zoom so far out to see the top level spin that the smaller spin levels aren't measurable anymore. They are still there of course, but you can't see them because they are making such small differences.

They are interesting to think about. You can get a rough idea of how small a BPhoton is compared to an electron (it is really tiny) by adding all 3 spin sets in SpinSim and look how small the BPhoton is once you zoom out enough to see the top level spin path. 3 spin sets is 9 spin levels so we only need another 1-2 spin sets to reach an electron. I didn't realise it was that close when I applied the 3 spin set limitation to SpinSim. I might see if I can get it to work with 5 spin sets (adding the spins is easy but the user interface is the problem and also the zoom levels) but I can already tell what they are going to look like just by using 2 spin sets, or even just 1 spin set since the general path is the same.

Last edited by Nevyn on Mon Oct 17, 2016 1:48 am; edited 1 time in total (Reason for editing : typo)

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

I thought an image is worth a thousand words so I took a screen shot of your video to show one of the problems.

This shows the X spin with the BPhoton at the top of its circular path. The next spin (which is actually a Z spin in this video/image) should rotate around where I have added the red circle. It could also be at the bottom but the animation will work best with it at the top.

The top spin also has the same problem. Both the Y and Z spins are rotating around the correct axis but they are doing it from the wrong position. I think you just need to move your pivot points and everything will work out.

This shows the X spin with the BPhoton at the top of its circular path. The next spin (which is actually a Z spin in this video/image) should rotate around where I have added the red circle. It could also be at the bottom but the animation will work best with it at the top.

The top spin also has the same problem. Both the Y and Z spins are rotating around the correct axis but they are doing it from the wrong position. I think you just need to move your pivot points and everything will work out.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

## Re: Proposal: Electricity Animation

The volume shown by the orange particles is what I call the

This also helps to show that the translations for each spin level are made relative to the center of that volume. Not relative to the origin of the global coordinate system.

**volume of influence**or sometimes I call it the sphere of influence but it isn't really a sphere. It is the volume of space that can contain the particle for this spin level. That is the spheres I was trying to explain above. Each spin level can be given a sphere to represent this volume. In the image above, the orange particles show it for the X spin. You can do the same for the Y and Z spins and I encourage you to do so, even if you make them invisible to generate the video. They will help you to see how each spin level is working while not being hampered by the internal spin levels. If you do that, you will start to see how each spin level is just an end-over-end spin.This also helps to show that the translations for each spin level are made relative to the center of that volume. Not relative to the origin of the global coordinate system.

**Nevyn**- Admin
- Posts : 928

Join date : 2014-09-11

Page **3** of **8** • 1, 2, **3**, 4, 5, 6, 7, 8

Page

**3**of**8****Permissions in this forum:**

**cannot**reply to topics in this forum