# Stacked Spins - scripting the photon's motion (technical)

Page **2** of **5** • 1, **2**, 3, 4, 5

## Re: Stacked Spins - scripting the photon's motion (technical)

Okay, here's where I'm at with the stacked spins. I went in a bit deeper to study the motions, found a few errors I'd made with pivot points and radii, and hopefully this update is a little better. I'm still not happy with the z-spin yet, but I've added simple circles showing the boundary of each motion.

Clean vid:

https://vimeo.com/217705503

And with a simple motion trail to visualize the path:

https://vimeo.com/217707510

Let me know what you folks think? Does my y-spin look funny, spinning around the z-circle, or does that seem right? Is my motion any closer to your pure-math motion, Nevyn?

I really want to get this "right" so I can proceed with cleaner presentation, annotation, and animation. My goal is to make a short video outlining stacked spins from start to proton, eventually. Until I can script it, these studies are the best I can do.

Clean vid:

https://vimeo.com/217705503

And with a simple motion trail to visualize the path:

https://vimeo.com/217707510

Let me know what you folks think? Does my y-spin look funny, spinning around the z-circle, or does that seem right? Is my motion any closer to your pure-math motion, Nevyn?

I really want to get this "right" so I can proceed with cleaner presentation, annotation, and animation. My goal is to make a short video outlining stacked spins from start to proton, eventually. Until I can script it, these studies are the best I can do.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

The X spin is not oriented correctly. Every spin level must be oriented such that its circle goes from the center to the outside of the next higher spin level. The Y spin is doing that but the X is not. See how the X spin rolls around the Y spins circle? Like it is a wheel rolling along that path, but it should not be rolling, it should be rotating in a way that no wheel should be rotating (to perform its intended function).

The motion is still fairly close to my animations. That is because the top two spin levels provide most of that motion and they are correct. It is just the inner X spin that is a problem.

The motion is still fairly close to my animations. That is because the top two spin levels provide most of that motion and they are correct. It is just the inner X spin that is a problem.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Thanks, Nevyn. I thought that was pretty odd and so did Miles, but I delved in even further into the actual collisions and hopefully corrected it. Please take a look when you get a chance?

https://vimeo.com/217771731

It seems like my output is looking a lot more like yours now, hopefully not just a coincidence. By tracking the actual collisions this way, and basing the pivots on those points instead of how I was doing it before, I think this is coming along a lot more naturally.

https://vimeo.com/217771731

It seems like my output is looking a lot more like yours now, hopefully not just a coincidence. By tracking the actual collisions this way, and basing the pivots on those points instead of how I was doing it before, I think this is coming along a lot more naturally.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Yeah, that looks better. I can see the start of the through-charge hole after it reaches the Z spin.

It must have taken some effort to time those collisions.

It must have taken some effort to time those collisions.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Thanks, but does it just look better, or does it look

Miles' response:

I think there's plenty of margin for error on my end here. Add in Maya's cumbersome antics, and that margin can get really fucking huge, to say the least. It's really daunting at times. Even trying to fix that wheel-like motion just a bit ago was an arduous task, but I think we're making progress here.

And I'm learning a lot. Tracking the collisions this way is actually pretty easy, since I'm just keyframing them. That is to say (for layfolk), I start with the incoming collision particle off-set at the start of the video, then I simply scoot forward to where I want it to collide with our initial B-photon and move that particle there, then click Key Translation. Maya handles all the tweening. But I did the outgoing rotations by hand (rough, not physically accurate) and translations just so they would get out of the way after the collisions. It's not physics at all there, just animation. Annoying, but that's the best I can do right now until I learn some more scripting.

If this process is helpful or looking correct, I can go ahead and advance through the additional collisions and add linear velocity. Ideally, I'd like to take this to the proton level - but I no longer know what that level is. Hah! Questions within questions.

*right*?Miles' response:

Mathis wrote:Yeah, it's getting better. There's still a glitch in the exhaust I don't understand, but the larger motions are pretty good.

I think there's plenty of margin for error on my end here. Add in Maya's cumbersome antics, and that margin can get really fucking huge, to say the least. It's really daunting at times. Even trying to fix that wheel-like motion just a bit ago was an arduous task, but I think we're making progress here.

And I'm learning a lot. Tracking the collisions this way is actually pretty easy, since I'm just keyframing them. That is to say (for layfolk), I start with the incoming collision particle off-set at the start of the video, then I simply scoot forward to where I want it to collide with our initial B-photon and move that particle there, then click Key Translation. Maya handles all the tweening. But I did the outgoing rotations by hand (rough, not physically accurate) and translations just so they would get out of the way after the collisions. It's not physics at all there, just animation. Annoying, but that's the best I can do right now until I learn some more scripting.

If this process is helpful or looking correct, I can go ahead and advance through the additional collisions and add linear velocity. Ideally, I'd like to take this to the proton level - but I no longer know what that level is. Hah! Questions within questions.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

I'm glad you made me look again, because there does seem to be something weird going on with the spins.

The X spins circle does not stay at the center of the Y spin. The X spins circle should be pivoting from the center of the Y spins circle and it should stay anchored to that position while the other side of the X spins circle moves along the Y spins circle. You may need to read that a few times to get it to sink in. I did just to make sure it was right.

The Y spin should do the same for the Z spin. In essence, the

The X spins circle does not stay at the center of the Y spin. The X spins circle should be pivoting from the center of the Y spins circle and it should stay anchored to that position while the other side of the X spins circle moves along the Y spins circle. You may need to read that a few times to get it to sink in. I did just to make sure it was right.

The Y spin should do the same for the Z spin. In essence, the

**diameter**of a spin level should equal the**radius**of the next higher spin level and the inner spins circle should always be in a position that its**diameter**is coincident with the higher spins**radius**. You should always be able to find a length that can be used to measure both of those at the same time. Another way to put that, is that the circle for any spin**must remain inside of**the next higher spins circle.**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Thanks, Nevyn. It's terribly daunting, trying to match the collisions with the motions. It seems like there's only one point along a given spin and one vector that could make stacked spins work in that fashion, for each stack. I'm likely wrong about that, but if we're tracking collisions things become even more... fuzzy. No, that's not right. Iffy?

The X1 spin is a piece of cake. It could also be a Z1 spin, but not a Y1, given we're using the Y-axis as "Universe-up" basically, but we start with X for the sake of alphabetism. New word.

Here I haven't changed anything (yet) but I believe you're correct. I'm just using a different tracing mechanism for the paths and momentums, ghosting. Old animation trick.

The video:

https://vimeo.com/217784789

I'll try to realign the pivots and centers tonight and make it right. What I'm wondering again is how a particular hit "knows" to spin the B-photon about a pivot point so far away. The X-spin seems intuitive, but the rest do not. I keep having to re-wrap my head around this all, so I apologize if there's a great deal of back-tracking and side-tracking.

The X1 spin is a piece of cake. It could also be a Z1 spin, but not a Y1, given we're using the Y-axis as "Universe-up" basically, but we start with X for the sake of alphabetism. New word.

Here I haven't changed anything (yet) but I believe you're correct. I'm just using a different tracing mechanism for the paths and momentums, ghosting. Old animation trick.

The video:

https://vimeo.com/217784789

I'll try to realign the pivots and centers tonight and make it right. What I'm wondering again is how a particular hit "knows" to spin the B-photon about a pivot point so far away. The X-spin seems intuitive, but the rest do not. I keep having to re-wrap my head around this all, so I apologize if there's a great deal of back-tracking and side-tracking.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

I don't know if I'm being clear enough in my confusion, so I made some screenshots to try to explain where I'm getting messed up:

Here we have the incoming "Y1-collider" photon, at its collision point with our main Hero Photon. Which is already in its X1 spin, only at a full rotation so it's back in the 0,0,0 point for ease of math.

The X1-pivot seems simple to me. A collider at a range of angles and energies could cause this flip, not all angles, but quite a few. To the photons, they don't experience "Universe-up", so it seems viable.

But where is the Y1-pivot's center coming from, mechanically? Is the center of this next spin at the

From above, so the Y-collider is coming from the left. Which circle would describe the motion, or would it be centered on the collision contact point itself?

I'm a little lost here, sometimes it feels like I'm in over my head but I can't stop contemplating and trying to wrap my brain around it. It feels intuitive, until I try to simulate it. That doesn't mean anything at all about the theory - it's my implementation that concerns me.

Here we have the incoming "Y1-collider" photon, at its collision point with our main Hero Photon. Which is already in its X1 spin, only at a full rotation so it's back in the 0,0,0 point for ease of math.

The X1-pivot seems simple to me. A collider at a range of angles and energies could cause this flip, not all angles, but quite a few. To the photons, they don't experience "Universe-up", so it seems viable.

But where is the Y1-pivot's center coming from, mechanically? Is the center of this next spin at the

*point*of collision? Or is that on the radius of that next spin?From above, so the Y-collider is coming from the left. Which circle would describe the motion, or would it be centered on the collision contact point itself?

I'm a little lost here, sometimes it feels like I'm in over my head but I can't stop contemplating and trying to wrap my brain around it. It feels intuitive, until I try to simulate it. That doesn't mean anything at all about the theory - it's my implementation that concerns me.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

I can't get too far into it right now, but an important thing to remember is that a stacked spin

That little BPhoton, spinning on its pole, ah, spin axis, really wants to continue that spin. It is so small and the velocity so fast that it acts like a solid object with twice the radius of the actual particle. This is how the radius is doubled because a spin about an axis that touches the edge of a sphere takes up two times its own radius.

Any collision that will cause a new stacked spin will require a particle moving in the same direction as the spin axis. So the incoming particle is moving up or down with respect to the top spin levels spin axis. If you are looking at the circle that describes the top spins path, then the incoming particle is moving into or out of the screen.

So the new spin level, added on top, might have a center that is

As I have said, velocity is everything, so I am kind of leaning towards the opposite side being the new center. By opposite side I mean you take the point of collision and draw a line back to the center of the top spin level, then you keep drawing that line until you reach the circumference on the opposite side.

**does**have an idea of**up**. To each spin level, up is the direction of its spin axis. It is orthogonal to the plane of motion for that spin level. You probably think in terms of points because you are using pivots where-as I think in terms of vectors. Let's put it this way: if the BPhoton was a pole dancer, the spin axis would be the pole.That little BPhoton, spinning on its pole, ah, spin axis, really wants to continue that spin. It is so small and the velocity so fast that it acts like a solid object with twice the radius of the actual particle. This is how the radius is doubled because a spin about an axis that touches the edge of a sphere takes up two times its own radius.

Any collision that will cause a new stacked spin will require a particle moving in the same direction as the spin axis. So the incoming particle is moving up or down with respect to the top spin levels spin axis. If you are looking at the circle that describes the top spins path, then the incoming particle is moving into or out of the screen.

So the new spin level, added on top, might have a center that is

*either*the point of collision*or*the opposite point on the current spin path. I like the collision point because it is a real point but the opposite side is an abstract point or a possible point. However, I also like the point of collision being the point that the tangential velocity is taken from and that puts the center of the new spin level on the opposite side.As I have said, velocity is everything, so I am kind of leaning towards the opposite side being the new center. By opposite side I mean you take the point of collision and draw a line back to the center of the top spin level, then you keep drawing that line until you reach the circumference on the opposite side.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Indeed, it's becoming more and more apparent that velocity causes the mass (ponderability).

My real problem is all the offsets, to be honest. Where to put those central pivot points.

My real problem is all the offsets, to be honest. Where to put those central pivot points.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

If my understanding is correct, each pivot point must be at the center of its spin level. I assume that the pivot point is the point that things are rotated around. In my nomenclature, the pivot point is the base of the spin axis. That is, the spin axis starts at the center and points up, with respect to that spin level, not a general idea of up. For an X spin, up is the X axis, for a Y spin it is the Y axis, etc. I should say it is in the same direction as the X axis, or Y axis, etc. It is not coincident with the universal axis, but points along that dimension from the center of the spin level.

So for each new spin level, you just need to know which dimension you want to translate the pivot point in. This can be arbitrary, to a certain degree, but we want to remain alphabetical, so we just choose a direction for each spin axis. To keep it simple, I move an X spin in the Y dimension, Y in the Z and Z in the X. This makes it easy to remember which way to move things as I just move it in the next dimension from the current one.

How far do we move it? You take the last pivot point and add the radius of that spin level to it, in the dimension we chose, in order to create the new spin level. An example will help, I think.

Axial spin: pivot point = (0, 0, 0).

X spin: pivot point = (0, 0, 0) + (0, r, 0) = (0, r, 0).

Y spin: pivot point = (0, r, 0) + (0, 0, 2r) = (0, r, 2r).

Z spin: pivot point = (0, r, 2r) + (4r, 0, 0) = (4r, r, 2r).

X2 spin: pivot point = (4r, r, 2r) + (0, 8r, 0) = (4r, 9r, 2r).

Y2 spin: pivot point = (4r, 9r, 2r) + (0, 0, 16r) = (4r, 9r, 18r).

Z2 spin: pivot point = (4r, 9r, 18r) + (32r, 0, 0) = (36r, 9r, 18r).

However, they are absolute points. When we discussed this stuff a while ago it seemed that you needed absolute points for your pivots, but I don't think that you should. Each spin level is inside of the next higher spin level and so it should be relative to that spin level.

The scene hierarchy should look something like this:

Each spin level takes care of its own spin and its parent takes care of spinning that whole spin level. Therefore, each spin level is relative to its parents coordinate system. If you only have an A spin, then its center is at (0, 0, 0) but if you have A and X, then the center of the A spin is now at (0, r, 0). However, the A spin doesn't know that. It still thinks it is at (0, 0, 0) because it is in its own coordinate system. In the universal coordinate system it is at (0, r, 0), but not locally. Same for the X spin if we have a Y spin above it. The X spin thinks it is at (0, 0, 0) and the Y spin moves it over to (0, 0, 2r).

When using relative points like this, our example above becomes:

Axial spin: pivot point = (0, 0, 0).

X spin: pivot point = (0, r, 0).

Y spin: pivot point = (0, 0, 2r).

Z spin: pivot point = (4r, 0, 0).

X2 spin: pivot point = (0, 8r, 0).

Y2 spin: pivot point = (0, 0, 16r).

Z2 spin: pivot point = (32r, 0, 0).

You'll have to figure out if you need absolute or relative points.

So for each new spin level, you just need to know which dimension you want to translate the pivot point in. This can be arbitrary, to a certain degree, but we want to remain alphabetical, so we just choose a direction for each spin axis. To keep it simple, I move an X spin in the Y dimension, Y in the Z and Z in the X. This makes it easy to remember which way to move things as I just move it in the next dimension from the current one.

How far do we move it? You take the last pivot point and add the radius of that spin level to it, in the dimension we chose, in order to create the new spin level. An example will help, I think.

Axial spin: pivot point = (0, 0, 0).

X spin: pivot point = (0, 0, 0) + (0, r, 0) = (0, r, 0).

Y spin: pivot point = (0, r, 0) + (0, 0, 2r) = (0, r, 2r).

Z spin: pivot point = (0, r, 2r) + (4r, 0, 0) = (4r, r, 2r).

X2 spin: pivot point = (4r, r, 2r) + (0, 8r, 0) = (4r, 9r, 2r).

Y2 spin: pivot point = (4r, 9r, 2r) + (0, 0, 16r) = (4r, 9r, 18r).

Z2 spin: pivot point = (4r, 9r, 18r) + (32r, 0, 0) = (36r, 9r, 18r).

However, they are absolute points. When we discussed this stuff a while ago it seemed that you needed absolute points for your pivots, but I don't think that you should. Each spin level is inside of the next higher spin level and so it should be relative to that spin level.

The scene hierarchy should look something like this:

Z | |||

- | Y | ||

- | X | ||

- | A |

When using relative points like this, our example above becomes:

Axial spin: pivot point = (0, 0, 0).

X spin: pivot point = (0, r, 0).

Y spin: pivot point = (0, 0, 2r).

Z spin: pivot point = (4r, 0, 0).

X2 spin: pivot point = (0, 8r, 0).

Y2 spin: pivot point = (0, 0, 16r).

Z2 spin: pivot point = (32r, 0, 0).

You'll have to figure out if you need absolute or relative points.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Thank you for taking the time for all that, Nevyn. It's totally helpful and makes it way easier for me to just lay out the spins (yet again!) properly. I was probably closer in this way before, with my old model. The new one has the proper timings however so I'll just keep messing with this one until it's right.

Totally with you on the hierarchy. That's exactly how I have it laid out in Maya.

In Maya, everything is a node but everything also

Transforms:

Pivots:

In my hierarchy, the "_GP" naming means _Group, of course, and a Group has no other nodes except the Transform node (pivot is part of that). So I have each Stacked Spin running in its own original local space but then inheriting the world space vector from the next stacked spin up. The _GP nodes are transforming, basically, everything below them. So it's the _GP nodes that are key-timed to our specific .707 rotation math, relative to the spin below each one.

All that is just an aside so you have a better idea what I'm dealing with here. I'm going to plug in your numbers next and then re-work the collider photons after that, from scratch. Clean slate often helps me, well, cleaner in this case.

Totally with you on the hierarchy. That's exactly how I have it laid out in Maya.

In Maya, everything is a node but everything also

*has*nodes, specifically a Transform node. A geometry sphere (polygons) for example has a geometry node (the sphere itself) and a Transform node attached to it, including all pivot information such as the pivot point and object vs. world space data.Transforms:

Pivots:

In my hierarchy, the "_GP" naming means _Group, of course, and a Group has no other nodes except the Transform node (pivot is part of that). So I have each Stacked Spin running in its own original local space but then inheriting the world space vector from the next stacked spin up. The _GP nodes are transforming, basically, everything below them. So it's the _GP nodes that are key-timed to our specific .707 rotation math, relative to the spin below each one.

All that is just an aside so you have a better idea what I'm dealing with here. I'm going to plug in your numbers next and then re-work the collider photons after that, from scratch. Clean slate often helps me, well, cleaner in this case.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Is the pivot inside of the transform? Do the transforms values get added to the local pivot point? All of this is so much easier to deal with if you work in local coordinates, but you have to be aware of how the coordinate systems affect each other, which I'm sure you are.

It looks like the transform and the pivot are just attributes of the node, Y3_Spin_GP in this case. So I can't tell if the transform applies to the pivot or not. If they do not, then the pivot just needs to apply the rotation from the local (0, 0, 0) of each spin level. The next spin level up will take care of the translation.

So the A spin just specifies a pivot at local (0, 0, 0).

The X spin specifies a pivot at local (0, 0, 0) and a translation of (0, r, 0).

The Y spin has a pivot at local (0, 0, 0) and a translation of (0, 0, 2r).

The Z spin has a pivot at local (0, 0, 0) and a translation of (4r, 0, 0).

The translation applies to the children of the group and the pivot rotates the group itself around its center. If that is how they work.

If the translation is applied to the pivot then it is all different. I think you will need to add more groups if that is the case as you will need the translation inside of the pivoting group.

The A spin just has the pivot at local (0, 0, 0).

The X spin has a pivot at local (0, 0, 0) and contains a group that has a translation of local (0, r, 0) and that translation group is what the A spin is inside of. You might find it easier to work with this longer scene graph. I know I do as it keeps things separate and you can think about them individually, rather than having to figure out how everything fits together.

It looks like the transform and the pivot are just attributes of the node, Y3_Spin_GP in this case. So I can't tell if the transform applies to the pivot or not. If they do not, then the pivot just needs to apply the rotation from the local (0, 0, 0) of each spin level. The next spin level up will take care of the translation.

So the A spin just specifies a pivot at local (0, 0, 0).

The X spin specifies a pivot at local (0, 0, 0) and a translation of (0, r, 0).

The Y spin has a pivot at local (0, 0, 0) and a translation of (0, 0, 2r).

The Z spin has a pivot at local (0, 0, 0) and a translation of (4r, 0, 0).

The translation applies to the children of the group and the pivot rotates the group itself around its center. If that is how they work.

If the translation is applied to the pivot then it is all different. I think you will need to add more groups if that is the case as you will need the translation inside of the pivoting group.

The A spin just has the pivot at local (0, 0, 0).

The X spin has a pivot at local (0, 0, 0) and contains a group that has a translation of local (0, r, 0) and that translation group is what the A spin is inside of. You might find it easier to work with this longer scene graph. I know I do as it keeps things separate and you can think about them individually, rather than having to figure out how everything fits together.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

I'm with you so far, implementing the changes now.

Yes, the pivots are a subset of the transform node attributes. So if you need to offset your pivot, you can, but otherwise it just follows the transform. Mostly this is used for joint orientation in character rigs but it may or may not be helpful in our case.

Yep, that's precisely how it works. By default the pivots follow the transforms, but you can offset them manually if so inclined.

Nevyn wrote:Is the pivot inside of the transform? Do the transforms values get added to the local pivot point?

Yes, the pivots are a subset of the transform node attributes. So if you need to offset your pivot, you can, but otherwise it just follows the transform. Mostly this is used for joint orientation in character rigs but it may or may not be helpful in our case.

Nevyn wrote:The translation applies to the children of the group and the pivot rotates the group itself around its center. If that is how they work.

Yep, that's precisely how it works. By default the pivots follow the transforms, but you can offset them manually if so inclined.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

If the pivot point follows the transform, then you definitely need a child group for the translation. That is because we want to translate the content and then rotate that from the center of the parent node. This is critically important. You can't trust the framework to perform the operations in the correct order so you have to separate the translation and rotation of a spin level. In your case, it is easier to let the pivot follow the transform of its own group and then create a child group to specify the translation for the spin level as it will make the numbers easier.

Here is how I would setup a spin level:

The Translation Group is used to translate the contents of this level so that one edge of that content is at local (0, 0, 0) of the parent node. This is the group you attach an inner Spin Level Group to, or the BPhoton itself if the first X spin.

The Pivot Group is used to perform the rotation and its pivot point will be local (0, 0, 0). Always. Every level.

The Spin Level Group allows you to attach other nodes for other purposes, such as a circle to show the path or a sphere to show the VOI. These children will not be rotated since they are not inside of the Pivot Group. They will be rotated if this Spin Level Group is a descendant of another Spin Level Group but only by the rotation of that parent group.

With that structure, you only have to think about the Translation Group and what its transform should be. Oh, you also have to think about the timing for the rotation. Both of these are easy enough on their own so it becomes much easier to handle as a whole.

Here is how I would setup a spin level:

Spin Level Group | ||

Pivot Group | ||

Translation Group |

The Translation Group is used to translate the contents of this level so that one edge of that content is at local (0, 0, 0) of the parent node. This is the group you attach an inner Spin Level Group to, or the BPhoton itself if the first X spin.

The Pivot Group is used to perform the rotation and its pivot point will be local (0, 0, 0). Always. Every level.

The Spin Level Group allows you to attach other nodes for other purposes, such as a circle to show the path or a sphere to show the VOI. These children will not be rotated since they are not inside of the Pivot Group. They will be rotated if this Spin Level Group is a descendant of another Spin Level Group but only by the rotation of that parent group.

With that structure, you only have to think about the Translation Group and what its transform should be. Oh, you also have to think about the timing for the rotation. Both of these are easy enough on their own so it becomes much easier to handle as a whole.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

I don't think that level of complexity is necessary here, though we shall see if I eat my words.

Does this look any better? This is based on your math precisely from the last few posts, I mean, minus any errors of mine.

https://vimeo.com/218109655

I really don't mean to add any complexity to the concept. I was mostly just showing you how Maya functioned so you could analyze with me better, but I hope we're not bogging down in unnecessary difficulties.

That is, I'm the one faltering here and trying to keep up. I really appreciate you picking apart my animations. At the point we both agree things look right (and I guess Mathis can have his say as well), I'll feel like it's going somewhere. Until then, I'll keep pushing on.

Does this look any better? This is based on your math precisely from the last few posts, I mean, minus any errors of mine.

https://vimeo.com/218109655

I really don't mean to add any complexity to the concept. I was mostly just showing you how Maya functioned so you could analyze with me better, but I hope we're not bogging down in unnecessary difficulties.

That is, I'm the one faltering here and trying to keep up. I really appreciate you picking apart my animations. At the point we both agree things look right (and I guess Mathis can have his say as well), I'll feel like it's going somewhere. Until then, I'll keep pushing on.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

It's impossible to judge the spin levels with the ghosting. I need the circles to see how everything fits together.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Yeah, sorry about that. If the ghosting isn't helpful for stuff like this I'll revert to cleaner, lighter particle "trails" for our purposes.

https://vimeo.com/218190909

https://vimeo.com/218190909

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

That's much better. Each spin level is spinning the right way. The outside edge of each spin level is touching the circle of its parent spin level, however, they do not touch the center. There seems to be some problem with the radii of the spin levels

You can see it in the above screenshot. The Y spin's circle does not touch the point where the axes arrows are. Same for the X spin which does not touch the point at the center of the Y spin.

I suspect the problem is with the radius of the circles.

*or*the circle to denote their path.You can see it in the above screenshot. The Y spin's circle does not touch the point where the axes arrows are. Same for the X spin which does not touch the point at the center of the Y spin.

I suspect the problem is with the radius of the circles.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

I've definitely got issues with the radius now, re-analyzing the structure from bottom to top. Gah, one step forward, three back.

In my x1 spin, the circle was describing the outside of the Bphoton's surface. I tried to make the other spins do the same, but got screwed up in my numbers and mistook the radius for the diameter in those transforms along the way. I was scaling each by the diameter, not the radius.

So I fixed it and redid the first three stacked spins, and came up with this update. Radii should be proper, and the spin axes too, hopefully!

https://vimeo.com/218240359

In my x1 spin, the circle was describing the outside of the Bphoton's surface. I tried to make the other spins do the same, but got screwed up in my numbers and mistook the radius for the diameter in those transforms along the way. I was scaling each by the diameter, not the radius.

So I fixed it and redid the first three stacked spins, and came up with this update. Radii should be proper, and the spin axes too, hopefully!

https://vimeo.com/218240359

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Yes, that looks better. You can see how each circle connects to its inner and outer spins.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

## Re: Stacked Spins - scripting the photon's motion (technical)

Alright, here is the barebones footage of what I've been working on. It needs more work, but I'm ready to present it for analysis here. Please, anyone chime in, but Nevyn if you see anything fishy (like gimbal lock or any weird axial motions, indicating I'm running it wrong?) please let me know!

https://vimeo.com/224734216

Are the ghosts (fading transparent clones) of the incoming photons distracting? Should I just make those animated curves, with little arrows along the curve indicating motion vector?

I've got a small script I'll overlay into the video, as well as explanations of what's happening, but I'm still pretty new to movie-making and feel like it needs a lot of polish.

Any thoughts?

https://vimeo.com/224734216

Are the ghosts (fading transparent clones) of the incoming photons distracting? Should I just make those animated curves, with little arrows along the curve indicating motion vector?

I've got a small script I'll overlay into the video, as well as explanations of what's happening, but I'm still pretty new to movie-making and feel like it needs a lot of polish.

Any thoughts?

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

My basic script, so far. I think it needs to be compressed and simplified as much as possible, though.

Me wrote:Postulate: The photon is the fundamental quanta, the smallest particle we are aware of. It is a real particle, and thus has some volume, extension, and chirality. It has spin. It has a linear velocity c and a tangential velocity from its spin also moving at c. E=mc², and photons transmit energy, so they must have mass. The c² in Einstein's equation comes directly from this linear motion and tangential velocity; as the photon collides with another particle, it transmits its velocity through linear motion as well as its spin motion.

Theory: The photon as the fundamental quanta becomes all larger particles through stacked spins. As particular collisions occur, a photon can be induced into an end-over spin outside the gyroscopic influence of the prior spin. This end-over spin effectively doubles the photon's radius each time a new spin is induced. As the photon stacks enough spins, its complex motion becomes more and more recursive, confining other smaller less-spun photons it encounters and redirecting them, recycling the ambient volume of other photons. It is emitting charge. If the photon stacks enough spins, gaining radius each time, it becomes what we know as an electron. Several more spins and it becomes a neutron or proton. In this way, all particles are built fundamentally from the photon.

The yellow sphere represents our photon. We will give it a radius of 1 for the sake of easy, relative math. We will also give it an axial spin to visualize how it moves. We have a spinning photon, which has polarity. It is spinning one way and not the other (the direction doesn't matter here) for example, and its tangential (spin) velocity will be greater at its equator than at its poles. It may collide with many other photons or larger particles on its journey through space, and most of those collisions will simply refract or redirect its path, but some collisions will affect its motion in more complex ways. Since this is an axial spin only, we will call it the A1 spin.

Here we have an incoming photon (marked as red) striking our original at a certain angle, causing the photon to "tumble" in the X-axis. Since it's already going c linearly and spinning at c, the collision energy is most easily expressed or transferred at the opposite pole - flipping the photon end-over-end. It can't add any more energy in those other directions, so it tumbles. This is the first stacked spin - we will call it the X1 spin.

Since it is now traveling a longer distance, it takes a bit longer to move through the larger spin. It now has a radius of 2, relative to our initial state. This doubling of the radius also doubles its mass - it's taking up twice the volume as before in its motion, over a given timespan. Its energy has increased.

Let's add another spin. An incoming photon (green) strikes our X1 spin photon along that X axis, so our photon can't exchange this velocity except to tumble on its Y axis, just outside the influence of our previous X1 spin. This is the second stacked spin, or Y1 spin.

This doubles the radius again, giving us a relative radius of 4. A photon with two stacked spins is 4 times as large as a photon with only its axial spin.

Let's add yet another spin. The incoming blue photon strikes our Y1 spin photon, tumbling it into the Z1 spin. Each new stacked spin must be a tumble, outside the gyroscopic influence of our previous spin, orthogonal to the main vector: the right-hand rule.

Now we have doubled our radius yet again. A Z1-spin photon is 8x the size of a lone, axial-spinning photon. This is the infrared photon, which experiment has shown is by far the most common state. It's a stable average photon, and most of the ambient charge field is in the infrared spectrum. Heat is generally a measure of infrared photon density in a given volume; though other photon spin-configurations will contribute to heat, the average spin-state is around the Z1 level.

**Jared Magneson**- Posts : 440

Join date : 2016-10-11

## Re: Stacked Spins - scripting the photon's motion (technical)

That looks good to me. The spins are correct. Each spin path links its inner path to its outer path.

The Y spin collision happens at the wrong time though. To induce a Y spin, the green particle must hit the target particle when it is at 9 o'clock on the X spins circle/path. It is currently hitting at 6 o'clock, a quarter turn too late since it is spinning anti-clockwise from the cameras perspective.

I think the Z spin collision is coming down in the wrong spot. It is harder to see this one so here is an image with a red circle added where the collision should occur.

The Y spin collision happens at the wrong time though. To induce a Y spin, the green particle must hit the target particle when it is at 9 o'clock on the X spins circle/path. It is currently hitting at 6 o'clock, a quarter turn too late since it is spinning anti-clockwise from the cameras perspective.

I think the Z spin collision is coming down in the wrong spot. It is harder to see this one so here is an image with a red circle added where the collision should occur.

**Nevyn**- Admin
- Posts : 1290

Join date : 2014-09-11

Page **2** of **5** • 1, **2**, 3, 4, 5

Page

**2**of**5****Permissions in this forum:**

**cannot**reply to topics in this forum