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

I'd like to start a new technical thread to help diagram the motion of the photon as it stacks spins, in the hopes that once the script is working properly for me it can be "instanced" to as many particles at once as my computers will allow. This should give us nice visualizations for charge inside the nucleus, as well as electrical and magnetic field animations and eventually molecular animations.

I'm using Maya's "MEL" script, but we can translate to Python (PyMEL, inside Maya) if it's more helpful and if you good folks are better-versed with Python. But here's my pseudo-code so far:

Stacked Spin MEL

1. Set string for SpinStackLevel
2. SpinStackLevel==0 = Rotate along Y axis at certain rate
3. SpinStackLevel==1 = Move Rotate Pivot +Y at 1 radius
4. Rotate along X axis at certain rate
5. SpinStackLevel==2 = Move Rotate Pivot +X at 2 radius
6. Rotate along Z axis at certain rate
7. SpinStackLevel==3 = Move Rotate Pivot +Z at 4 radius
8. Rotate along new Y axis at certain rate

Pretty barebones, but am I on the right track here? Minus Maya-specific commands, of course...

That pseudo code will create a photon but it will not animate it (I realise that statements like 4. Rotate along X axis at a certain rate are meant to express the animation components but I don't think you will want those lines mixed in with the creation code, keep them separate). How do you plan to perform the animations? A little research led me to something called expressions which seem to be called every frame. I'm not sure how to associate these with an object though. Hopefully it makes more sense to you since you know the UI.

My understanding, after 10 minutes of research, is that you can write an expression, associate it with an object (or an attribute of an object) and it will be executed every frame. The way I would do it is to associate the expression with the node and then find the matrix for that node in the expression script.

Create a sphere node and add the following custom attributes to it:
  numSpinLevels - this will be an integer specifying the number of spin levels that this particle has (0=no spin, 1=axial, 2=X, 3=Y, 4=Z, 5=A, 6=X, etc), you might want to decide if you want to allow higher axial spins since we can change the code to use them or not but we can also use a static variable in the script to set whether to use them or not, obviously the latter is more flexible but it changes what the numSpinLevels value means.
  velocity - this is a vector specifying the linear velocity of the particle, you can leave this out for now but might want to add it as a placeholder.

Now we want to create an expression on that sphere node that executes every frame (or time). I won't do that right now as it gets complicated quickly. Try writing a script that just moves the photon or just creates an axial spin to ensure that everything is working as you expect.

The beauty of this method is that you only have to change the numSpinLevels value to add/remove spin levels. The code takes care of the rest.

At this point you can play with the expression script to find out what you can do inside them. Alter the nodes position, rotation, scale, set its color (try using the frame number to adjust the color so it fades from one to another), attach child nodes or create a separate node at the current position which leads to the paths I use in SpinSim. You might want to figure out how to create a line and add the position to the end of that line on each frame.

When you are ready, I can show you the math we need to implement stacked spins with an arbitrary number of spin levels. I want to make sure that you have the basics working before we get to that though as there will be some trouble porting my current code to work in Maya which is going to be made even more difficult since I can't test it myself.

.

numSpinLevels - this will be an integer specifying the number of spin levels that this particle has (0=no spin, 1=axial, 2=X, 3=Y, 4=Z, 5=A, 6=X, etc),

Nevyn, Sorry, I don't follow. Your 6 numSpinLevels here are fixed and sequential. What about YXZ or pos/neg? Where's the neutron? 6 spin levels mean many possible variations.
.

Yeah, I realise that, but you can't put things into code without some limitations. Well, to be perfectly clear, you can do it but the complexity rises very quickly. What I wrote above is an attempt at a very simple stacked spin implementation. It will give the correct motions but does not provide the complete flexibility. I was thinking about +/- directions as I wrote it but I can't see any way to implement it without needing to specify more data and create the levels explicitly.

In order to do what you propose, you need to have data for each spin level. That is what I have done in my OpenCL implementation but I can take advantage of the GPU parallelism. I doubt Maya will offer that in the same way. There are possibilities that I am contemplating, such as specifying another custom attribute that is a series of 1's or 0's (so a binary string) where each digit represents the spin direction. It becomes difficult to adjust them though. Especially as you add many spin levels.

Another area I have implemented in OpenCL is a spin velocity for each spin level. Technically, only the top level spin can have any spin velocity other than c, but I implemented it that way because the data was related to a spin level and there is nothing special about the top level with respect to the data. It basically comes down to how I map the application data into the OpenCL memory and how I find it in the OpenCL code (OpenCL is very low-level). I use this spin velocity to turn off the higher axial spins by setting their velocity to 0.

I don't think the YXZ thing is worth worrying about. While it does change the motion, it really just changes the dimensions that the motion happens in. For example, an XYZ will look a certain way when looking down the X axis and a YXZ will look different on the X axis, but the X axis view of XYZ will look the same as the Y axis view on the YXZ. Does that make sense?

I'm impressed that you saw through my words and found the problems! Well done.

I just had a quick thought that we could actually create multiple scripts: a proton script and a neutron script. That way, we can take care of the -ve spins in the code. Again, not completely flexible, but it will allow us some room for playing with it.

I'm learning MEL from the ground up and it looks like I'll be up to speed pretty quickly on this one. PyMEL can come in later for bigger things. There are a few issues I need to pre-overcome, such as the timing (especially at actual light-speed, which Maya's not going to like much at 30 frames per second). I can even make a small GUI which we can set up very similar to Nevyn's control panels, with a bit of luck.

To reiterate, the ultimate goal here is to:
1. Allow a particle to spin properly at all levels, up to or beyond the proton.

2. Apply this behavior as a per-particle array for the bigger charge simulations we want to make (similar to my current Alpha charge animation, but with the particles behaving like real photons do, including the proton's and neutron's recursive boundaries).

3. Basically push as many billions of these through my simulator as the computers will let us. If a proton is recycling 19x its own mass per second in photons, we want to be able to map at least that many.

@Nevyn: we will be able to access some GPU-computer functions through Bullet or nDynamics (Maya's "Nucleus" solver), but until then my CPUs should do okay for a few billion particles.

The problem here is that we need custom math that would be better implemented on the GPU. I had a quick look at Bullet and while it is very impressive, I didn't see if you could actually put your own code into the GPU. It looked like it was more of a property on a node which marked it for Bullet processing. But I only looked at an introductory tutorial, so it may have more to offer than what I saw.

Collisions are another problem. We don't want the standard collisions of physics. We have to incorporate the rules of gyroscopes into it, which I am trying to figure out at the moment but it is very complicated. I guess we could leave out spin ups/downs for the time being. That should be enough to see the charge emission of a charged particle.

I'm not convinced that you will be able to work with billions of particles (without taking a serious amount of time to process it all). I hope I am wrong, but my own testing has shown that even a million is a lot to handle. Hell, my OpenCL implementation even struggles at 100,000 and I am only calculating the spins, no collisions yet. But I am watching it run rather than generating a video and working in real time is a lot more taxing. The calculations themselves are part of the problem but I think it is the 3D system that struggles with so many objects in the scene.

I've tried reducing complexity of the spheres and I even tried reducing them to just a point but it didn't help as much as I had hoped. I'm sure that I don't have it working at full efficiency yet, but I'm not sure what else I can do to reduce the processing time. I've been thinking about taking out the higher axial spins since I don't use them and they take up both memory (which has to be transferred to the graphics card memory and back again) and processing time. I can save 1 in 4 spin angle calculations and another 1 in 4 matrix calculations (different stages) as well as not needing to transfer so much data between memory systems.

Part of the problem is the change in time between frames. You have to use a very small dt because of the speed of these particles. If the dt is too large, which can make it look faster, then you will miss collisions between particles. I was looking at the spin paths and making sure that they were fairly smooth and I was working with particles from a single axial spin up to about 20 spin levels (each particle had 1 more spin level than the last, up to the maximum number of spin levels when all subsequent particles just used the max number). What I wrote above was an attempt to change my algorithm so that I could reduce the number of decisions and calculations per particle (at the cost of flexibility).

Anyway, I hope you can do better than I have so far.

Well sure, it's going to be taxing, but we don't need it to run in realtime (necessarily) and I've been working with trillions of polys and billions of (mental ray) photons for a decade already. Some of my nebula simulations take five hours at a billion particles, for example, but as you've said those particles aren't the same complexity as what we're working with here. At rendertime, Maya feeds the CPU cores (fully saturated) the frame to calculate then spreads it across the network for calculation.

So any given frame could take several minutes to calculate, or even longer. In my artwork, a "given frame" (since I only do stills) could take 72 hours to render, for example. It doesn't really matter how long it takes a frame to render in the end, so long as the calculations and collisions are working cleanly, since I have nothing BUT time to play with right now.

If it takes three days to render a 30-second animation, so be it. Getting the framework in place is my main goal, making the thing work, and if we need heavier horsepower or a shift to CPU+GPU processing down the road, we can burn that bridge when we get to it.

I'm hoping to sucker my company into one of the shiny new Ryzen CPUs in a few weeks anyway, and this would be a perfect (if hidden) excuse.

Perhaps Alembic would help us in some way? We can write to the GPU cache with that method, anyway.

https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Maya/files/GUID-C893BE60-6E65-4F36-8005-FD4D1A0E9822-htm.html

.
Nevyn, I must admit that the math behind the "rules of gyroscopic motion" have been beyond me. Do you know an easier way? Have you modeled any of the rules (precession, moment of inertia, torque) yet?

I'm happy to ask, Have you collided any stacked spin particles together yet?
.

I've looked at the gyroscope math and I must say that while I don't really know enough to question it, it does smell a bit funny. Kind of like they are trying really hard to convince themselves that they have this one solved. The math itself isn't so bad, but the way they are trying to explain how a gyroscope resists gravity doesn't exactly fill me with delight! Without going into detail, they are basically saying that gravity acts on the top half of a spinning disc one way and on the bottom half it acts the other way, so they cancel out and therefore there is no force. Feels very ham-handed to me.

However, the math itself has equations to determine the precession given the rotation and length of the rod that the spinning disc is on. I'm trying to figure out how to use that to my advantage. The equations are a bit complicated but I think they will reduce to simpler ones since I am dealing with 90° angles so the sines and cosines turn into 1's and 0's so they cancel out parts of the equation or reduce it to a simpler case. I am feeling a bit overwhelmed at the moment, but I'll just give it some time to sink in and see what I can do with it.

I have been trying to figure out an easier way. Looking at the possible collisions and thinking about what forces are created. Trying to find ways to easily calculate those forces. It occurred to me that there is a lot more energy in these collisions than I had realised. There is the linear velocity which in a head-on collision provides 2c worth of force. Then there is the spin energy which, if the top level spins on the particles are spinning towards each other, will provide another 2c worth of force. That is a lot of energy!

It has given me confidence in my attempts to consider spin velocity as the mass though.

f = ma

I think that is a misleading equation though since the acceleration doesn't belong to a single entity.

f = m1v1 + m2v2

Since v1 and v2 are the linear velocity, m1 and m2 must be the spin velocity!

As I looked over the gyroscope math and concepts, and couldn't really see how to use it for what I wanted, I thought about writing an app just about gyroscopes. Sometimes playing with the math gives me ideas on how I can use it in other ways.

I'm still in the research phase for collisions. I have started to build a 3D Spatial Index in OpenCL (an index allows you to know which particles are close to each other so you only test them for collisions and not every particle in the model). I'm just using a simple cube index where each photon is associated with a single cube so I only need to test it against all other photons in that cube. It is really hard to test it though. I need a way to visualize the index after I have calculated which cube each photon belongs to. I have the functions to populate the index at the moment (which was not easy in OpenCL because I can't do things that I usually do in these situations) but I got bogged down in the collisions as that was the next step. I need to step back and make sure that index is working as I expect it to while I let me brain stew on the collisions (I swear my sub-conscious is a lot smarter than I am!).

My current thoughts are that I will work on generating a video of the scene so that I can stop myself from worrying about the speed of it. If it takes a minute to generate a video that covers a nano-second, I don't really care, but watching it move really slowly is painful. Plus, I can share the results then, so that is a good thing for you guys!

Amazing, Nevyn. I hope it was clear I'm just following in your footsteps here, often stumbling in the dark. But I think it's great stuff and totally worth working on, for certain.

I was more than skeptical of stacked spins until in one paper or another (perhaps his gravity universal spin paper?), Mathis explains that we're already living with stacked spins at the macro level and never really question its authenticity. That is, I believe he says the Earth is spinning, revolving around a sun that's spinning, revolving around a galactic core that's spinning, and on like that. We can spin around on the Earth while it's spinning, though it may make us dizzy. Our atoms and nuclei are spinning while all this is happening as well.

And if you trace the Earth's actual path (in Universe², for example) through space it actually resembles our stacked spin animations more than not. There's multiple motions going on, and while it seems complex of course reality has no problem handling it, and spends zero time calculating it.

Jared, I like the way you casually talk about taking 3 days to render something! It is completely opposite to how I see things because I usually build systems (professionally) that need to be fast and are used in real time. When I hear about processing a billion particles I just think "Wow! How do you do that at 60fps?".

You are helping me to see things from a different angle. I need to just focus on the calculations and forget about time. Make sure it is doing everything right and optimize later.

The Ryzen CPU looks pretty good. I'm glad to see AMD make a come-back. I have traditionally been an AMD guy, mainly for the price, but my last PC build I went Intel because AMD just weren't cutting it anymore. I want the most bang for my buck and Intel was worth the extra price at the time.

Thanks for the encouraging words. I'm very happy to help where I can but I also want to see how you see things since you come at it from a different direction than me. So feel free to ignore anything I say if you feel you have a better way to go about it. I don't mean to take over but when something gives me ideas I like to get them out of my head before I forget them and if that can help someone else then that's great too.

I've spent years stumbling in the dark. Trying to make sense of all this and it has started to come together in the last couple of years thanks to everyone on this forum. Sometimes it only takes an off-hand comment to get me thinking in a new way or to probe more deeply into something so please, everyone, keep the questions coming and the ideas flowing. Hopefully, one day, we can all look back and say "We were on the front line when Physics was revolutionized!".

We already are on the front line! And I think we have ALL been stumbling in the dark, without the real photon to work with. But I doubt we'll ever be celebrated, just like many others in history who go unnamed while others take credit. But the credit means little to me, I just want to understand things and then capitalize on it later in a beneficial way, not necessarily profitable, but something substantial. If the best we can do is help Mathis refine his theory, so be it. If we outshine his theory, then that's fine too. Physics is a journey that most are deathly afraid of, especially the "physicists" who are actually getting paid currently to do their non-work nonsense. /endrant

Glad to be of help regarding timeframes though. In my day-job, I do architectural visualization (arch/viz), and traditionally got paid my salary when the kitchen or bathroom or remodel images were done RIGHT, looking photorealistic enough to sell the actual construction job, and printing up clean. Sometimes I have only a day or two to make the renderings work, sometimes I have a few weeks. But generally, to render a better image the computer must take longer, process it cleaner, and approach a "brute force" method to eliminate noise in a given threshhold. This is always true of raytracing, path-tracing, and global illumination techniques. So I'm very used to test-rendering at say ten minutes or so, very low-quality and/or low-resolution images, then cranking up the quality settings (in mental ray for Maya, Nvidia's brainchild, there are dozens if not hundreds of different settings for optimization) and then "cooking it off" for an hour or two at print resolutions and qualities.

In my artwork, an image can take days to render, although I tend to do passes now and spend more time in Photoshop compositing. But a 3-day rendertime for a decent image isn't too scary. It's worth it - at least to me. Mathis wouldn't agree since he can't stand digital art, but that's his damn problem.

By all means, say whatever you need to here and don't worry about "taking over". We're on the same ship, just working different sections. If in the end Maya can't handle what we're trying to do then I'll abandon this project and focus on other animations, but I think we can at least pull off the basics if not achieve an actual, photon-for-photon simulation. If we have to scale it down or end up stuck only at the electron level, well...

...I'll just have to get my company's corporate sponsorship on some bigger/faster computers! Oh, drats.

Jared, have you had any luck with Maya scripting?

I've been spending a lot of time working on 3D spatial indexes. I got my cube index working but was not impressed with the performance. I knew of another index type called Octrees, or sometimes Binary Space Partitioning Trees, but was not aware of how they operate or how they are programmed. As I was thinking about my cube index I started to think about how Octrees might be implemented and came up with my own approach. It runs quite fast too. Theoretically, with a tree depth of 10, it has (8^10)^3 individual cubes of space. That's 1,073,741,824^3! That is using a 32bit integer but I can run it with 8, 16, 32 or 64 bit values. With 64bit values I can go 21 levels deep which is 9,223,372,036,854,775,808^3! The best part is that there is very little difference in speed between 8, 16, 32 and 64 bits.

All of those cubes don't really exist. Each particle's cube is encoded into the Nbit value (using 3 bits per level) which can be used to determine the cube it is in, so I only have a value per particle, not all (8^N)^3 of them. If I want to know if 2 particles are near each other, I just need to compare their index Id's which is just a simple number comparison. Of course, I soon found that a single cube was not enough since I was only using the position of a particle, not its actual size, so a particle could be partially outside of the cube. I then tried to include the particles radius in the calculations but abandoned it in favor of another method. I took the single cube I had previously found and calculated the cubes around it. This gives me a 3x3x3 matrix of cube Id's per particle. If the central cube of a particle is the same as any cube in the test particles matrix, then I consider them for collision detection (I am thinking of changing that to be any cube in either particles matrix for precision reasons).

With all of that working, I started to think about using it for other reasons such as view frustum culling. That is, I take the current view frustum (the volume of space that will be on screen during this rendering pass) and determine which cubes are inside of it. Then I only render those particles with the same cube Id's. I haven't made much progress down that road just yet, but it seems perfectly feasible.

Here are a few videos that show the index in action. They all show the same scene containing 10 particles with spins ranging from a single X spin up to 9 levels above that. All particles are in the same location. The first shows just the central cube for each particle. These are rendered in red. The second adds 6 more cubes per particle which all share a face with the central cube. These are rendered in green. The third video adds another 20 cubes per particle, 12 of them share a line with the central cube (rendered blue) and the other 8 share only a vertex (rendered yellow). They are 720p@30fps encoded in H.264 in an MP4 container. The videos run at 30fps but they don't generate that quickly. I can get about 20fps on my PC when rendering all of those cubes as well as the particles. It gets up around 30fps when only rendering the particles.

Center Octree Cubes: http://www.nevyns-lab.com/mathis/math/indexes/octree/Test-opengl-center.mp4

Face Octree Cubes: http://www.nevyns-lab.com/mathis/math/indexes/octree/Test-opengl-face.mp4

Full Octree Cubes: http://www.nevyns-lab.com/mathis/math/indexes/octree/Test-opengl-full.mp4

I also abandoned Java3D and am now working in OpenGL directly (Java3D can sit on top of OpenGL or DirectX). I was having trouble getting the videos to work as I wanted so I moved into OpenGL. I ended up having the same problem in there but eventually got it working and am happy to be learning OpenGL which is a lot more low-level than Java3D so I can do some things that I couldn't before (like how I render the particles). Of course, there is always a cost and I now have to implement certain things myself such as view frustum culling I mentioned earlier. I will end up with a 3D Photon Physics Engine eventually. I am limiting it to photons because I can choose to do some things (or not do some things) knowing I have spheres only.

Nevyn, those videos are GREAT and you're way ahead of me here. I think you're definitely on to something, really wish I could help somehow other than cheerlead right now.

I've made very little progress on the Maya end of things. At this point, I'm ready to abandon the Photon Physics Engine concept and focus on basic concept videos, like the two-slit one I did awhile back (I reread the paper and think I can show it MUCH better now). I just don't think Maya can handle this without some serious coding beyond the scripting I'm learning. It turns out that no matter what I do, I can't actually get two particles (hi-poly but still polygon spheres) to collide with any accuracy. It seems to use some offset/bounding box interpolation so I can't ever quite see the particles actually collide - even with collision heatmaps enabled.

I've had some feedback from Autodesk and a few of my CGI industry buddies (Jeremy Birn at Pixar is always really helpful), and they seem to think it's possible but would probably work best using Maya just for the animation end of things.

As in, we could feed it data through Alembic or some other caching system and apply that data to the animations, to drive the particles or something. Kinda where I'm stuck right now, figuring out not just how to automate spin-stacking and apply it to particles but how to tell various particles how to behave. It gets frustratingly complex.

Well, if you're going to do some cheer-leading, I hope you look good in a skirt!

Do you have any information on how to generate data that Maya can then use to render? I vaguely remember looking at the caching system when you mentioned it previously. It didn't sound like we could use that at the time, but I might be able to generate that kind of data out of my apps and then you can render it in full definition and pretty colors! The files would get very large though. They would need to contain a 4x4 transform matrix per particle which is 16*4 bytes (using 32bit floating point values) per particle per frame. That would be 62.5Mb per frame for 1,000,000 particles. At 30fps, that would be 1.875Gb for 1s worth of video! Hmmm, maybe not such a good idea.

Jared, you might want to hold off on talking your boss into a new Ryzen CPU. The Vega based AMD graphics cards look very impressive too. They should be phenomenal together.

Here is an excerpt from the article I read (http://www.pcworld.com/article/3153726/components-graphics/radeon-vega-revealed-5-things-you-need-to-know-about-amds-cutting-edge-graphics-cards.html):

To drive the potential benefits home, AMD revealed a photorealistic recreation of Macri’s home living room. The 600GB scene normally takes hours to render, but the combination of Vega’s prowess and the new HBM2 architecture pumps it out in mere minutes. AMD even allowed journalists to move the camera around the room in real-time, albeit somewhat sluggishly. It was an eye-opening demo.

Nevyn wrote:Jared, you might want to hold off on talking your boss into a new Ryzen CPU. The Vega based AMD graphics cards look very impressive too. They should be phenomenal together.

Here is an excerpt from the article I read (http://www.pcworld.com/article/3153726/components-graphics/radeon-vega-revealed-5-things-you-need-to-know-about-amds-cutting-edge-graphics-cards.html):

To drive the potential benefits home, AMD revealed a photorealistic recreation of Macri’s home living room. The 600GB scene normally takes hours to render, but the combination of Vega’s prowess and the new HBM2 architecture pumps it out in mere minutes. AMD even allowed journalists to move the camera around the room in real-time, albeit somewhat sluggishly. It was an eye-opening demo.

Indeed, we've already got this tech in our hands - that's just Maya, on any GPU really. Although a 600GB scene is really kinda, well... Ridiculous, in the arch/viz industry. Impressive, though! But keep in mind that "photorealistic" is a very far cry from the work we're trying to do from a dataset point of view. We can already render scenes to the GPU in realtime, precisely because we don't need 600GB of data to represent a scene. That's also why it was sluggish for that demonstration - a regular arch/viz scene at 1GB or less would NOT be sluggish, given that Vega GPU. It's got a lot of promise.

They Ryzens not nearly so much, although it'll be a 40%+ upgrade on CPU-based functionality. I'll try to get my hands on a Vega so we can play with it a bit though too, using "corporate sponsorshop".

Hi Nevyn and everyone,
Please take a look at this latest quick simulation of stacked spins. I'm using a motion-path technique this time, which is a simple expression played out through a series of circular paths. There's a particle "trail" to show the motion path which is of course not real, but perhaps this simpler method is more what you had in mind, Nevyn?

https://vimeo.com/207832376



The expression for this one goes like this:

nurbsCircle3.rotateZ = frame*0.125;
nurbsCircle2.rotateY = frame*0.25;
nurbsCircle1.rotateX = frame*0.5;
nurbsSphere1.rotateY = frame;

I'm pretty sure this isn't very accurate, but it sure runs quick. Around 300fps.

Try this for a closer approximation:

nurbsCircle3.rotateZ = frame*0.353;
nurbsCircle2.rotateY = frame*0.5;
nurbsCircle1.rotateX = frame*0.707;
nurbsSphere1.rotateY = frame;

While the dynamic, mathematical method to demonstrate this eludes me (still working on it, I haven't given up), here is a new Stacked Spin video I made to help refine my understanding and technique.

Can you folks take a look when you get a chance? Let me know if I did anything wrong in the dynamics? This one is based on our previous conversations and time references, keyframed. So I have each new spin going two full rotations before the next spin initiates. It's slow and I should retime it but I wanted some feedback first.

Video: https://vimeo.com/213812847

Screenshot:


I'm doing all my labels in post now (Sony Vegas, in this case) so they're much easier to fix and deal with, and I don't have to re-render the entire sequence. Still pretty raw. But hopefully the compression is a little better now, with less popping and aliasing issues.

It looks alright to me, but I can't tell if the spins are using the right timing as it adds a new spin level too quick for me to see the path before it changes the motion. I am used to seeing paths that are built from set spin levels, not adding them as it goes, so it could just be me and my expectations.

It appears to slow down as the video runs. Is that just processing time as you add new spin levels? Are the internal spins still rotating faster than the outside spins?

I like the new labeling. Explains nicely what is happening as it goes.

This is a pre-cached video playback file ("playblast), so there should be no time anomalies. It takes very little CPU power to process this since it's just keyframes, no calculations beyond the particle trail (simple as it gets) and then what it takes to draw that frame (GPU-based anyway). Compression may cause some artifacting, and maybe that's part of it, though it's not nearly as clear as it looks in Maya, obviously. But I have to compress it for Vimeo so you guys can see it.

Here's how I derived my timings, based on that .707 factor we discussed earlier:



Rounding may cause a few errors. There's a ton of ways to screw this kind of thing up, since it's all keyframed instead of math-based. So I had to enter those frame numbers by hand multiple times in various areas, from the spin groups to the volume-of-influence shaders, which was tedious.

Mostly it's a study of the mechanics. I don't see how axial spins beyond the first would work at this point. What kind of collision could cause the photon to spin around a point where it's not physically at? The end-over tumbling of stacked spins I can handle, since I can visualize that. I could even animated that - toss in a B-photon at each of these ten stacks, as collision events, showing how it knocks it into a new motion. But how could that work with axials?

Yes, those frame counts look good. Do you have to use rounded values or is that just for reference? Are the floating point numbers used for the actual spins but the rounded values used for the timing of new spins being added? I ask because rounding values can have a pretty big effect on the resultant motion.

Yeah, I have to use rounded values since I'm keyframing the animation. There are no fractions of frames. I generally run at 30fps for animation, to make the math a lot easier - none of that legacy NTSC 29.97fps shit here.

But it's still a far cry from importing your setup into mine, which would be ideal. I'm still studying it, haven't given up! It's kind of odd. On CGTalk.com, the biggest high-end 3D site in the world, I am a pretty big deal for most things Maya. Especially landscape/environmental work, which I've done cutting-edge advancement on for many years now. The community is really cool and helpful, including many top-tier folks from Autodesk and Pixar and Industrial Light & Magic.

But on these physics topics, crickets. No feedback. Nobody can help, basically. They aren't shunning me out of hand; just, nobody's done this before. And since they don't know the physics we're playing with, it just seems like an alien language to them.

But I don't mind being on my own here. It's just strange. I can ask any other question about anything else in Maya, but regarding real physics, no answers. Not even from Mathis, these days.

Of course, I should have realised that myself. I guess I still think in terms of rotation rather than frames. Frames are kind of inconsequential to how I build spins. I don't think about frames, I think about time but I still need to know how much time is in a frame transition in order to calculate the correct rotation angle but that is the kind of thing that I setup at the start and forget about. For you, it is a constant and must be dealt with at every stage. I can appreciate the frustration.

It can be a bit painful, but it is good to be humbled every once in a while. A master of one field is a novice in another. I think you learn more from doing it yourself anyway, but that may just be my own bias because I have spent most of my life teaching myself new things. When it came to Miles work, all I had was his papers. No-one else I knew, online or off, had even heard of him or his ideas. I just had to plow through it as best as I could. Each time I reached some milestone, I would sit back and re-evaluate and usually find something else that needed to be dealt with or changed is some way. However, the understanding that you eventually get to is a true treasure. Worth the sweat and tears. Every single drop.

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.

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.

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.

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.

Thanks, but does it just look better, or does it look 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.

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

This image might help. The red dots show where the Y spins circle should be touching in this image. The blue dots show where the X spins circle should be touching.

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.

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

I can't get too far into it right now, but an important thing to remember is that a stacked spin 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.

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.

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:

Z
-	Y
	-	X
		-	A

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.

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

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.

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

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.

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:

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.

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.

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

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

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

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

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

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?

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.

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.