Proposal: Electricity Animation

Hi Jared,

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

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.

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.

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.

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.

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

Format	URL
Open Office	http://www.nevyns-lab.com/mathis/math/spin/spin-levels.ods
Excel	http://www.nevyns-lab.com/mathis/math/spin/spin-levels.xls
PDF	http://www.nevyns-lab.com/mathis/math/spin/spin-levels.pdf

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?

To work that way, you want to use 1.414, not 0.707. The 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.

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.

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.

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:

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

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.

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?

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.

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.

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.

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.

---

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?

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.

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

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!

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

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):

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.

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.

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.

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.

If you were to make this into a Y spin, then the pivot point should be at the red circle in this image:

The volume shown by the orange particles is what I call the 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.

If you move your pivot points, as described above, you are going to find that the particle doesn't stay near the center of the video. Your method of using pivot points and my method of using individual translations and rotations both have their advantages and disadvantages. One advantage of my approach is that the top level spin is always centered at the global origin. I move the particle over to create the spin where-as you move the pivot point over.

Your way is actually more realistic in the sense that the pivot point is created by a collision and the point of collision becomes the pivot point so the subsequent motion of the new spin level is based around that point. My way is a bit better for viewing as it keeps the main motion within the camera frame. You can keep using pivot points but you will probably need to move the global coordinate system (or the camera) over by (4r, r, 2r). Or is that (-4r, -r, -2r)? You'll figure it out.

Both methods end up with the same result and it is only the viewpoint that is different.

I was just taking screenshots to clarify, but you've done it wonderfully already! Thank you. Mathis had (bluntly) told me something similar but it was so short and blunt I didn't get it. "No, no better. I think I see the problem. Line up the purple notch with the pole and the direction of spin in the second spin. "

I think I get it, now! I'll change my animation to accommodate, and switch the ordering this time so we don't have to worry about that causing confusion in the future. This is a screenshot of the positions of my most recent take on it, so you know where I was coming from:



But I think you placing that red dot made all the difference. I'll work on this tonight and get back to you. Honestly I was getting frustrated with myself, and lost in all the variables and orders and spins, and about to give up. I think I got this now, thank you for your patience Nevyn.

I know that frustration very well. That's why I wanted to remove all of those inner spins and just get back to one single spin level. You have to simplify to see the concepts that let you implement complexity.

I also know the frustration of Miles' replies. For a man that can write so well, his emails can be short and sharp. His points are usually valid, but it can take a while to see what he means. I often worry about my own posts. Are they understandable? Am I using the language that the recipient will understand? Have I gone too deep? That's probably why I always end up writing a wall of text and it is certainly why I try to add as many different ways of interpreting the content as I can find. Hoping that one of them sinks in.

I think you're on the final straight now though.

Nevyn wrote: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.

I added another 2 spin sets to SpinSim last night and it was much easier than I thought. I had already made the interface work with as many spin sets as I created (thank you, past-Nevyn) so all I had to do was change the number of spin sets and I was done.

I fired up the app and turned on every spin level (all 16 of them, including the base axial spin, but no upper axial spins). I zoomed out, and out, and out, and out, and out and nothing showed on screen. I thought I might have zoomed so far out that the particle and spin path were no longer within the viewable area of the camera. So I turned off Spin Set 5 and the particle jumped back to the center of screen. I cleared the markers (you have to use line based markers at this distance or you won't see anything) and let it start building the spin path again and kept zooming out until I could see the complete 4th spin set. I turned on the 5th set again and kept zooming out, and out, and out, and out. My scroll wheel is 2 years closer to failure now but I eventually reached a point where I could see the complete shape of the spin path with all 5 spin sets on.

That should be some form of an electron or maybe even a proton, I'm not sure. All I really accomplished was confirmation of my previous statement that the general path is the same, no matter how many spin sets you use. I haven't updated my site and I'm not sure I will. If anyone wants it then just say so and I will update it. I had an idea of creating some set zoom levels, one for each spin set so that you can click a button and it will zoom to a point that you can see that spin set. That will fix the zooming problem and make it much easier to handle large spins.

LongtimeAirman wrote:
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.   

I also have great difficulty agreeing with people, in general. In specific, it's much easier. I keep placing my doubt upon Mathis's models as a function of my misunderstanding, and in this case, my software tedium which makes me feel even more stupid. I think that's why I'm pushing so hard on this one and (hopefully) getting somewhere.

But I don't think the particle need constantly recycle smaller versions of it, necessarily. I haven't actually applied any momentum or physics to this Stacked Spin doodad I'm working on here, just animation and a motion study. Would a particle actually be ABLE to move like that? Would my software even be capable of modeling that, considering nobody who wrote the physics engines (Nucleus, PhysX) knew a damn thing about stacked spins, Pi, or anything else we've been studying? I've already ran into issues with Pi in these simulations: one simply cannot describe an orbit with Newtonian physics as they stood pre-Mathis, and the elliptical orbit is even more out of the question.

So I'm hoping to diagram what's happening and we'll see if that increases or decreases viability here. Don't hesitate to tell me if there are any gaps in the motion or the logic. I'm struggling with this one tonight, I'll start a new thread for it and quit derailing yours...

...and return shortly with a quick electrical animation I've been working on a bit. Iron is my target structure.

Well in lieu of a new thread, figured I'd keep going here until we hit the mark. Nevyn, is this any closer? I think there are still some locus issues, perhaps due to World Space vs. Object Space, in my rotations?

vimeo.com/187766321
http://vimeo.com/187766321

And here is a more recent update, showing the VOI shells:

vimeo.com/187837640
http://vimeo.com/187837640

Am I getting anywhere here, Nevyn? Are my pivot points off? I thought they would all be at integers, but .5s abound, it seems?

Jared, I fixed your links.

LongtimeAirman wrote:... 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. ...

Airman, what if we agree with you? Is that acceptable? I've said something like that myself. Throwing a baseball makes it move translationally in a straight line, at least in space. On Earth gravity causes the straight line to bend into a curve. In order to get a wave motion, the thrower has to put some kind of spin on the ball, which causes lower and higher air pressures on different sides of the ball and the air pressures modify the path into a sine wave or helical path.

Likewise, with photons, in order to get a wave or helical motion, it seems there must be something like "air", which would be a field of smaller photons, or subphotons, that puts different pressures on each b-photon in flight. Your idea of the b-photons recycling smaller photons themselves sounds like that could work too to explain the wavy motion. It would be like a hollow ball with openings. It might be like a wiffle ball. It could also be like a ball that has gas inside under pressure and a few small leaks in the ball.

All of these ideas seem to have problems. Subatomic particles spray out photons under the pressure from the incoming photons, so the incoming photon pressure maintains the particle's spin as well as the outgoing photon spray. ... The density of photons in and near stars, as well as planets, seems to need to be quite high, but above and near the surface of stars and planets the density has to be thin enough to allow photons to travel past each other in many different directions without much colliding. ...

It's hard to get a holistic view of this theoretical reality, but hopefully it will develop.

The Y spin looks better, but it is still not right. The X spin is rotating correctly within the Y spin, but the Y spin pivot point is not in the right place. It is closer than it was, but still not correct. The Z spin is, well, let's get the Y spin going before we tackle that one.

The main problem I have with pivot points is that they do not actually translate anything. They just tell it to rotate around the specified point. This might mean that you just need the absolute values in order to position the pivot points. I'm not sure.

Absolute Pivot Point Locations

If my understanding is correct, then the pivot points should be positioned at:

Z	4r, r, 2r
Y	0, r, 2r
X	0, r, 0
A	0, 0, 0

If you look at that table from the bottom to the top, you can see how each pivot point is added to the pivot point of the last one. To find the X pivot point, we take the A pivot point and add (0, r, 0) to it. To get the Y pivot point, we take the X pivot point and add (0, 0, 2r) to it.

The Y spin is pretty close already. I think it is just missing the r translation in the Y dimension.

The Z spin isn't pivoting on the blue dot (which I assumed represented the pivot point). Technically, neither is the Y spin but it is very close to it so the spin itself looks close to correct.

I could be wrong about the Y spin. It might be rotating around the correct pivot point but the blue dot is in the wrong place. It also looks like the circle is sitting on the XZ plane but it should be raised up so that it is the same height as the blue dot for the X spin.

I like how the VOIs fade in and out but for now, it would be better to have them semi-transparent for the whole video. Once we get it working it would be better to do it as you are now.

You want to see the X spin VOI while the Y spin is rotating it and the Y spin VOI as the Z spin is rotating that. The Z spin VOI is not really needed since it won't move but it can still be good to show how each VOI spins within the others.

Could you write out the positions of the pivot points and describe the scene graph hierarchy so that I can get a better idea of how the pivot points are working please? It can be difficult to tell precisely where something is in 3D in a 2D image. I should be able to give more direct instructions once I have a more solid idea on how it all fits together.

Thanks for the clarification, Nevyn, and your patience. I find it easy to wrap my head around stacked spins, but once you hit Maya... The UI alone is beyond tedious, although it's amazing and so powerful. Just, a lot to keep track of both in my head and inside the software.

Ironically, my pivots were correct much earlier on, and I jacked them up along the way with 3s and .5s involved. Fixed that, and also changed the VOI shells and motion trail a bit here. There's a bit of depth peeling since I'm just in preview mode (no render time, since it's all GPU-bound), but maybe this one is a little closer?

https://vimeo.com/188006600

My pivots are at precisely what you put in your table now (again). Previously, when I had those proper, other things weren't or a few things were off. In my scene, every element you see has translate/rotate/scale attributes that need to change whenever one changes the GROUP attributes, including pivots, so it gets pretty dicey.

Is this any closer?

Yes! That's it.

The VOIs really help to show the relative spins and it is much easier to see how every spin is just an end-over-end spin of the last. I'm going to add those in to SpinSim, with a checkbox to enable/disable them, both globally and for each individual spin level (maybe even each spin set as well).

Jared Magneson wrote:In my scene, every element you see has translate/rotate/scale attributes that need to change whenever one changes the GROUP attributes, including pivots, so it gets pretty dicey.

That seems strange to me. I don't need to change anything except the rotation angle of each spin level per frame. Everything else takes care of itself. Now that you have this version working, would you like to start again using my method? You might find that it is easier to handle, especially if you want to add more spin levels. It certainly sounds like it to me. Of course, you are probably sick of stacked spins by now and there are always other projects to move on to but if you ever want to come back to it we can start a 'How to Model Stacked Spins' thread.

Ok, now that you have the core spins working correctly, I'm going to get really picky. We've come this far, let's make it the best it can be. Don't worry, it isn't much, just a slight discrepancy between the circles.

The following image shows the problem.



The circle for the X spin goes through the BPhoton. It is basically showing the path of the center of the BPhoton but all of the other circles show the boundary of the spin path.



See how the Y spin circle is on the boundary of the X spins VOI? I think you should make the X spin work that way too. You probably don't need the VOIs once that is done as they perform the same job. Personally, I still like the VOIs but you could go back to the fading in/out method you were using before and not lose information.



This image shows how the Y spin is also within the circle for the Z spin. The circle for each spin level should touch the circle for the next outer spin level.

Ahh yes, an oversight (undersight?) on my part. I still had the X-spins circle at a radius of 1, instead of 2. Initially my circles were going inside the particle, as opposed to its outermost potential edge.

I know what you mean by the group/hierarchy stuff seems strange (in Maya), and I COULD just change the main group for any given spin. But since all the subgroups are in that group's hierarchy, you have to change JUST the elements of the main group, you see. You can select them all and do it, but you still THEN have to change the pivot point of that group. It sounds absurdly complex because it is, but not needlessly so. I imagine animators for Pixar movies and such need all these transforms, and Maya is node-based from top to bottom which is also very helpful, if tedious on larger scenes.

Updated:
https://vimeo.com/188050932

Here is the same animation, with the X-spin circle fixed and I tweaked the aspect ratio since it doesn't need to be widescreen. I'll probably add the labels then go ahead and remove the others from my Vimeo at this point to declutter future projects.

Yes, that's looking good now. Although I prefer wide screen, it gets you a little closer to the particle.

Something went wrong at the end of the video, about the 1:35 mark.



Not sure if that is something in the video or if it is my video codecs. Could everyone let us know if you experience the same thing please?

Ugh, thanks for the heads-up. I'll fix it and reupload with the labels, now that the techy stuff is under control. Thanks again for your persistence and help on this one, good sir. Or madam, as the case may be. (I'm pretty bad at internet-stalking people, sorry about that)

Now on to electricity!

Jared Magneson wrote:I know what you mean by the group/hierarchy stuff seems strange (in Maya), and I COULD just change the main group for any given spin. But since all the subgroups are in that group's hierarchy, you have to change JUST the elements of the main group, you see. You can select them all and do it, but you still THEN have to change the pivot point of that group. It sounds absurdly complex because it is, but not needlessly so. I imagine animators for Pixar movies and such need all these transforms, and Maya is node-based from top to bottom which is also very helpful, if tedious on larger scenes.

The difference between what most modellers want to do and what we are doing here is that we have to deal with coordinate systems inside of coordinate systems. You can't really think in terms of a global coordinate system but, I imagine, most normal models only use that for basic translations, rotations and scaling where they are just trying to get it where they want it in the global coord sys.

I use more groups than you do so that each translation or rotation is in its own group which allows me to only change what I need to for any given spin level. Each level is isolated from any other level which makes it far easier to change them. Of course, I have the advantage of writing the engine to run it all where-as you are stuck using whatever Maya offers you (which is very powerful, if a bit clumsy for this stuff).

To be clear, my method still calculates all of those changes that you are, but the 3D API does that for me as a result of the structure of the scene graph. For every leaf node (an object that is visible and the last item in a branch of the graph), all of the transforms from its parent groups (a direct line from the leaf node to the top of the scene graph) are merged into one final transform that puts that object in the correct position and orientation for that frame. So all I need to care about is what I want to change per frame, which is just the rotation angles. I'm sure Maya could do it too.

Anyway, let's just bask in the glory of this video as the world finally sees the beauty of stacked spins! Ok, they aren't going to do that anytime soon, but it's another stepping stone on the way!

Jared Magneson wrote:Ugh, thanks for the heads-up. I'll fix it and reupload with the labels, now that the techy stuff is under control. Thanks again for your persistence and help on this one, good sir. Or madam, as the case may be. (I'm pretty bad at internet-stalking people, sorry about that)

Now on to electricity!

That's ok, I prefer to keep such details offline being quite a private person (too private, as my friends would say), but sir is just fine. Sir Nevyn. Yes, I could get used to that!

It's 5:09 a.m. Universal Time on Oct. 20 and I just tried the above vimeo and it's still messing up. It does it at 1'33".

It's pretty interesting up to that point. Would it be worth showing both poles of the b-photon, instead of just one? If so, they should be different colors. And could the b-photon be made transparent, so the back side could be seen too? I mean especially the pole on the back side. It would of course be nice for viewers to be able to speed up or slow down the action at any point.

Do all minds boggle at the thought of the infinite possibilities here? E.g., if the vimeo were to go on long enough, would it show the complete "uber-photon"? If a photon had only the axial spin and the x-spin, wouldn't the complete photon have a torus shape? One with an a, x and y-spin would form a sphere. Right? And one with a, x, y and z-spins would form a larger torus?

After enough stackings of spins we come to the electron, which somehow attains the ability to ingest and recycle photons. By when should we count on the simulations to reach that stage? Next week? I'll be very interested & maybe surprised to see how a single photon that makes up an electron can run circles around the many incoming b-photons and reflect them out of the electron's equator.

But anyway, I'm excited at the prospect of seeing electricity and maybe wifi demonstrated even sooner.

And I appreciate most or all of the work you folks are putting into this project.

I don't think (anymore) there's any reason to assume it would look like a torus. That's partly why I've been struggling at this one for so long, even before I found you wonderful folks here. I wanted to know what it would actually look like, the motion, slowed down.

Vimeo messed up my upload, the original video output from Maya was fine. But since I'm relabeling it and all, I'll wait to fix that until I'm done. Then, I'll do the frequency/wavelength variant to show how both are just intrinsic properties of the motion.

So I bounced that video off Mr. Mathis and his response was (as usual) not entirely helpful. Perhaps one of you can make sense of this?

"No, I think you want the red prong moving along the line of the second spin. That will take out the wobble."

This is in regards to my most recent video, the one that got messed up during upload at 1:33 or whatever. What does he mean? The red prong is there to show the axial spin at all levels. If he means the second spin as in the X-spin, is he saying the red prong should change to whichever spin is the top level? Or does he mean the second spin, as in the first Y-spin? It's already spinning along that plane, from worldspace anyway. Confusing.

I don't see any wobble. I thought it obvious that the red prong was to help see the axial spin, which is does well. Miles seems to be a bit of a purist, so he would probably prefer that red prong wasn't there. Try rendering the BPhoton as a solid color and then a wire-frame over the top of that to give it some texture (or you could just use a texture).

The spins look perfect to me. I've now implemented VOIs in SpinSim and our models look very similar, with respect to spin. Even once the Z spin kicks in, I can see that the X spin is rotating correctly.

Jared Magneson wrote:I don't think (anymore) there's any reason to assume it would look like a torus. That's partly why I've been struggling at this one for so long, even before I found you wonderful folks here. I wanted to know what it would actually look like, the motion, slowed down. ... Then, I'll do the frequency/wavelength variant to show how both are just intrinsic properties of the motion.

It will be interesting to see the wave motion in detail and see how it compares to the conventional model of the EM sinewave. I expect the actual wave to be helical, but it depends how the photon is observed.

If we assume that the initial photon, without any spin, is a sphere, as MM seems to assume, then with an a-spin added, it would still be a sphere. But, if our visual sensor were traveling at the same speed as the photon, and observing it from all sides, an x-spin would be a spin around a point on the equator of the photon, perpendicular to the direction of translational motion, and it would make a torus shape from the vantage point of the sensor. From our normal viewpoint the path of the photon would look like a helix. But, if the photon stopped its translational motion while still spinning, it would again look like a torus. A y-spin would then make the torus look like a sphere and a z-spin would make it a larger torus.

I discussed this with MM a few years ago and he agreed with my comment, but he said he preferred to simplify by assuming each spin-level would be a sphere. But I think the radii of the spin-levels then are likely to be skewed. A torus of this type has a minor and a major diameter with the minor being half the major.

I found this image online, the cross section of the kind of torus I'm talking about.


The photon could be thought of as one of the circles. Where the circles touch in the center would be the x-spin axis, which I think would be parallel to the a-spin axis. The a-spin axis would be vertically in the center of either circle. The torus then is the path of the spherical photon around the x-spin axis. Right?

I can party with that, but only up to the X-spin. Beyond the X-spin (which is the second spin, or the first "stacked spin") the photon no longer appears as a torus in any way - given the math and pivots we've just shown in my video, and given that they adhere to the theory properly. Note that my X-spin looks precisely like your torus image.

This is why my video is important at all, not because I seek glory or fame, but because we need to understand the actual motions. Mathis is no good at CGI and he admits that, which is why I'm here. Watch my video again, don't worry about the ending slop where Vimeo screwed up. The X-spin is the only torus and additional stacked spins cannot form a a torus. Helixical, sure, but that's not the same thing. Diagramming the motion, we see that the photon never repeats itself again in the same fashion to become an actual torus, and in fact it is also not an actual sphere ever again beyond the axial (first) spin. The "Volume of Influence" spheres I show are really only a guideline diagramming the outer boundary where the photon can be, in which case they're much like electron clouds and only useful here as a visual aid.

I think the need to conform the theory to a familiar shape may be skewing your outlook on the topic and I'll admit I also wanted something nice and neat out of this, but the motion is still nice and neat - it just doesn't conform to a shape easy for our minds to wrap around.

I will play with it at different speeds and durations, and then diagram the same motion in other ways and with additional stacked spins (up to the proton itself) and we'll see how that goes. But my suspicion is that the proton is merely so recursive in its motion that it's not a sphere at all, which is how it's permeable to charge in the first place. The quanta isn't everywhere at once, there's no boundary wall in any given instant, and it only seems spherical over a long enough dt.

Here is the latest version of that motion-model video, all cleaned up, with a turntable spinaround later on to show the motion a little better:

https://vimeo.com/188447627

As you can see, there's no real torus shape formed past the second (X-stack) spin, although the VOI is actually more of a squashed sphere. This isn't to say that there's not a "hole" in the center even at this level, so I'll admit it could (kinda) be considered a torus in some sense. But it's still possible for the photon itself to inhabit a position at the center, here. With higher stacked spins, this possibility seems to disappear. It's always closer to the edges, which is how the electron and larger guys become recursive.

Looks like the director has shown up for work now that the set is built to the specifications.

Let the art begin!