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

Page 1 of 3 1, 2, 3  Next

View previous topic View next topic Go down

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

Post by Jared Magneson on Mon Jan 23, 2017 5:04 pm

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

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Mon Jan 23, 2017 8:28 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman on Mon Jan 23, 2017 10:35 pm

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

LongtimeAirman
Admin

Posts : 592
Join date : 2014-08-10

View user profile

Back to top Go down

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

Post by Nevyn on Mon Jan 23, 2017 11:56 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Tue Jan 24, 2017 3:44 am

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.

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Tue Jan 24, 2017 10:13 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Tue Jan 24, 2017 11:22 pm

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

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by LongtimeAirman on Tue Jan 24, 2017 11:56 pm

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

LongtimeAirman
Admin

Posts : 592
Join date : 2014-08-10

View user profile

Back to top Go down

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

Post by Nevyn on Wed Jan 25, 2017 1:01 am

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!
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Wed Jan 25, 2017 3:20 am

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 Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Wed Jan 25, 2017 6:25 pm

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!".
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Wed Jan 25, 2017 6:54 pm

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

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 Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Thu Feb 09, 2017 11:43 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Fri Feb 10, 2017 12:05 am

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.

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Fri Feb 10, 2017 12:30 am

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Nevyn on Wed Feb 15, 2017 10:16 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Thu Feb 16, 2017 5:14 am

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

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Jared Magneson on Fri Mar 10, 2017 2:10 pm

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.

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Fri Mar 10, 2017 5:03 pm

Try this for a closer approximation:

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

avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Wed Apr 19, 2017 4:57 am

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.

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Wed Apr 19, 2017 6:30 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Wed Apr 19, 2017 8:00 pm

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?


Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Wed Apr 19, 2017 8:42 pm

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

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

Post by Jared Magneson on Wed Apr 19, 2017 10:30 pm

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.

Jared Magneson

Posts : 205
Join date : 2016-10-11

View user profile

Back to top Go down

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

Post by Nevyn on Thu Apr 20, 2017 12:18 am

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.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Page 1 of 3 1, 2, 3  Next

View previous topic View next topic Back to top


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