Spin Path Generator

by **Nevyn** Mon Nov 27, 2017 8:50 pm

I have created a new application that allows the path of a stacked spin particle to be generated without the need to watch it as the BPhoton moves through that path. While it is still a 3D application and you can rotate the camera around the particle and zoom in/out, what you see is static. The path is generated as a series of points when you press the generate button and does not change until you generate again.

You can have from 2 to 40 spin levels. That is a lot of spins and way above what we need but they are there to play with.

You can enable and disable higher axial spins. The first axial spin is about the Y axis (because the next X spin will translate the BPhoton in the Y dimension) but all higher axial spins are about the Z axis. After some deliberation, I chose the Z axis because that is the only dimension that the new spin axis can go through without touching the spin path of the particle which has a top level Z spin. Interestingly, this does not change the spin boundary all that much but it does change the spin path itself.

On the settings tab called Model, you can set the number of points to record, called Iterations. It defaults to a million points but you can go down to 100 and up to 10 million. It takes a really long time to generate 10 million points with 40 spin levels. Sleep

The other setting on the Model tab is called Unit Time and it allows you to set how much time passes between frames. This can be very useful for a large number of spin levels because the particle gets so big. You can increase the number of iterations but it is usually better to just decrease the resolution by making the unit time larger.

The third tab is called Graphics and this contains a single control that allows you to render the generated points as points or lines. If the resolution is high enough (small unit time) then points look the same as lines because they are so close together. With larger unit time settings, it can be helpful to see them as lines.

You can play with the Spin Path Generator at http://www.nevyns-lab.com/mathis/app/SpinPathGenerator

Enjoy! bounce

by **LongtimeAirman** Mon Nov 27, 2017 11:02 pm

.

Twin aliens ultrasound?

Great job Nevyn. Zooming and rotating about the particle spin level gives a view which exceeds Spin Simulator's. Of course, the two apps match perfectly, please consider including this app within Spin Simulator. It's strange how each spin level resembles the previous. Some kind of nested scaling. How about including an option of showing the superposition of the next lower level (a different color) so that we may see the relationship between consecutive spin levels.

When I returned to smaller levels I remembered to keep scaling - turning the mouse wheel - until I found the lower lever. I appreciated the fact that the origin marker remained the same across the levels. The sliding bar is a might unwieldy and takes up a long line, typing a number might be easier. Apparent bug, particle spin levels 4 and 5 are the same.
.

by **Nevyn** Mon Nov 27, 2017 11:30 pm

Spin levels 4 and 5 are the same, if you do not use higher axial spins.

There are 4 spin levels to a spin set: A, X, Y, Z. So spin level 5 is the axial spin of spin set 2. If you don't use higher axial spins then level 5 does nothing. It is a bit confusing but kind of necessary. It allows you to compare the same spin level with and without higher axial spins. I could do some math to figure out the right number of spin levels, but then that number means different things based on the higher axial spin control.

I've been thinking about providing some buttons to zoom to the current particle size because it is easy to get lost. The difference between the smallest and the largest particle is quite staggering. I did have a scale control but it was difficult to use so I removed it for release.

by **Nevyn** Thu Nov 30, 2017 8:11 pm

I've been thinking about those spin level numbers and how to show that they are different if you use higher axial spins or not.

I thought about showing both values where it currently shows the number of spin levels next to the slider but then it has to be explained and I have to squash that into the control framework I have developed because it is a special case. I am confident that I can make that happen in a generic manner, but it still feels a bit ham-handed at the moment.

I thought about changing the displayed value so that it does reflect whether higher axial spins are used or not but this causes the slider to behave strangely because the user can slide from 4 to 5 (8 to 9, 12 to 13, etc) but there will be no change in the value.

I am leaning towards the 2nd option but am open to any ideas.

by **LongtimeAirman** Thu Nov 30, 2017 9:37 pm

What's wrong with using one or two drop-down lists instead. The lists could include comments.

Spin Path Generator Stlnar10

Oh oh, a straight line artifact.

by **Nevyn** Thu Nov 30, 2017 11:35 pm

The problem is that I need to use the same number for both as the internal math ignores the higher axial spins if told to do so. So the code expects a number, let's say it is 5, and it will always execute 5 operations but that 5th one will be ignored when not using higher axial spins. By ignored I mean that it will have no translation and no rotation applied, so it is silent to the math, as if it didn't exist at all. It ends up as an identity matrix so when it is multiplied with the matrix I am generating, it does nothing and just results in the existing matrix.

Maybe I can write it out to show it. This is an array of 8 spin levels with their spin axis as a value:


[A, X, Y, Z, A, X, Y, Z]

If we are using higher axial spins then that is the exact representation. However, when not using them, the 2nd A is ignored so we actually only have 7 spin levels, not 8, but the user has no way of knowing that. They will think that they are looking at 8 spin levels which should look like this:


[A, X, Y, Z, X, Y, Z, X]

Which is a completely different path to what it is actually generating.

The real problem is that I want to be able to compare using higher axial spins to not using them easily. I want to just check/uncheck the higher axial spins checkbox and regenerate. I don't want to have to adjust the number of spin levels as well. Basically, I want my cake and I want to eat it too. That's why I thought about changing the displayed value rather than the values the user is selecting.

The reason that I wanted to compare the higher axial spins was because I found some interesting results when I tested them. That turned out to be me rotating them about the wrong axis (Y, which is used for the first axial spin) but when I thought about it I changed the higher axial spins to use the Z axis. That still doesn't feel right, but it is the only dimension that allows the spin axis to go through all of the existing spins without touching the spin path. I don't actually think that the Z axis can be used because we are putting an axial spin on Z that already has a top level spin of Z. That would effectively increase the tangential velocity above [b]c/[b]. I just don't see how higher axial spins can be implemented.

by **Nevyn** Thu Nov 30, 2017 11:38 pm

A straight path? How could that happen? My first thought was that the browser is causing that when you switch away from the webpage tab or to another application. Chrome stops the rendering process when the page goes off screen. Firefox does not. I have seen SpinSim do this for this reason. However, Spin Path Generator (SpinGen?) should not do that because it calculates all of the points and then renders them. I haven't seen it do this myself but I will try to make it happen and see if I can figure out why.

by **Nevyn** Thu Nov 30, 2017 11:47 pm

Verified!

You have to turn on Line rendering rather than Points, which is the default.

I think what is happening is that the first and last points are being joined by a line. I regenerated, without moving the camera, using Point rendering and that line becomes a gap. I did not expect it to join the end points since I am rendering as a line and not a polygon (which must be closed). I'd say that is a bug in ThreeJS, but I will see if I am causing it (always a possibility).

by **Nevyn** Thu Nov 30, 2017 11:54 pm

This is from a ThreeJS tutorial:

ThreeJS wrote:Note that lines are drawn between each consecutive pair of vertices, but not between the first and last (the line is not closed.)

So I consider it a ThreeJS bug at this point but I haven't been able to look over my code yet. However, I am using the same classes that the tutorial does and I am not doing anything fancy.

by **Nevyn** Fri Dec 01, 2017 12:00 am

I just tried a different number of spin levels and about 1,000,000 iterations and it does not connect those end points. Must be my fault.

I left the same number of spin levels but increased the iterations to 2.77m and it connected those end points again. Might be a problem in how the points array is being populated when there are a lot of points. I break it down into a number of sections to avoid having one big long calculation which would freeze up the page.

by **Cr6** Sat Dec 02, 2017 2:11 am

Nicely done as always Nevyn.

Took a bit of time to render but it came through. I don't know if you could put together a little guide, but it may help a few people trying to set the settings. With Javascript iterations at this level, it is just going to take a bit of time

This was on Firefox Quantum 54 with a lame Laptop video card and 8 gigs of Ram.

by **Nevyn** Sat Dec 02, 2017 4:34 am

Yes, calculation time is a bit of an issue. It actually calculates faster if I don't do anything about it and just run the calculations straight through. However, the page freezes up until it finishes and that is unacceptable. I break it down into smaller sections (maybe 1,000,000 points per section but it lowers it depending on how many spin levels there are), but this actually makes it run slower. It does allow me to show a progress meter though, so that helps a bit.

Unfortunately, all calculations are run through the CPU, not the graphics card. If browsers supported the WebCL standard then I could but they don't, so I can't.

I'll have to look into some sort of guide. I was hoping it would be simple enough that anyone with knowledge of stacked spin could work with it. Probably too much to assume.

by **Nevyn** Mon Dec 04, 2017 6:52 pm

I have made an attempt at a description of the app and its settings. I would appreciate any feedback you want to give.

Spin Path Generator wrote:
Spin Path Generator

This application can be used to generate the spin path of a BPhoton with up to 40 stacked spins. While the Stacked Spin Motion Simulator allows you to watch the motion of the particle, this application will just generate the path that it covers, given the constraints placed upon it. It is much quicker to calculate the path than it is to watch the particle traverse it. There is much to be learnt by watching the motion as, ultimately, the motion is what matters more than the path it creates. However, sometimes we just want to analyse the paths of various particles to see how they compare with each other.

There are various parameters you can set that will dictate what kind of particle, and how much of it, you will see. These parameters are arranged into tabs. The first tab is called Particle and gives you the ability to set the number of spin levels and whether you want to use higher axial spins or not. The latter parameter requires a bit of understanding as I have a difference of opinion with Miles Mathis, the creator of the stacked spin model, with respect to axial spins. The very first spin must be axial, however, once we start stacking spin levels, I do not see how another axial spin can be formed given that the new spin axis can not go through any existing spins. Any axial spin must go through the center of that which is spinning, therefore, I find it difficult to see how any higher axial spin can exist. Further more, one must ask what axis should the higher axial spin use. Which dimension can be used to spin around that does not go through any existing spins?

I have chosen to use the Z axis for all higher axial spins since a top level spin creates a hole through its center on the axis that it is spinning around. We need to add an axial spin on top of a Z spin so I had to use the Z axis for the next spin level. It seemed the only logical choice, but even that has problems because we are effectively adding motion to the existing top level Z spin which is already spinning about the same axis. Not just the same dimension but the exact same axis. This is exactly the same as increasing the velocity of that Z spin and that is not allowed as it already has a tangential velocity of c.

Even though that is my position on the subject, I am modelling someone else's theory, so I have included the ability to turn them on and off so that I can model both ideas in the same application. You can use this application to get a closer look at stacked spins and determine for yourself if you believe in higher axial spins or not.

There is one caveat with providing this choice of higher axial spins. Whether you use them or not determines how the number of spin levels is used. This is an implementation issue, not an issue with the theory, as my algorithm assumes that the number of spin levels chosen includes higher axial spins and then ignores them if you have turned them off in the settings. This can be confusing as when you have higher axial spins turned off, the number of spin levels is deceiving. It may not actually be the number that you see on screen.

Let's take a conceptual look at stacked spins to get a better feel for why this happens. We start with an axial spin, then we add an X spin on top of that, then a Y spin and finally a Z spin. This gives us 4 spins in the order [A, X, Y, Z]. That is what I call a Spin Set. A collection of 4 Spin Levels in that order. It is important to realise that in reality, they do not need to be in that exact order. The axial spin will be first but the X, Y and Z could be in any order. However, for simplicity, I have mandated that they use that order. It makes it easier to comprehend and discuss, if nothing else.

Now that we have a complete Spin Set, we can continue to add stacked spins. According to Miles we now add another axial spin, then X, Y and Z spins. This gives us 2 Spin Sets: [A, X, Y, Z, A, X, Y, Z]. You can see that the second A spin is a higher axial spin because it is on top of another Spin Level. That is how the number of Spin Levels is interpreted. It will always set things up assuming the use of higher axial spins. To create that list, you need to set the number of spin levels to 8. If you turn on higher axial spins then you will actually get 8 spin levels. However, when you turn them off, you will only get 7 Spin Levels because the second A spin is ingored. The list [A, X, Y, Z, A, X, Y, Z] is created but since the higher axial spin will be ignored, we actually get [A, X, Y, Z, X, Y, Z], which is only 7 levels. I am working on an effective solutions to this.

The next set of options are in a tab called Model. These settings are related to the recording of the path and how it is generated. The first setting is called Iterations and it sets the number of points to be calculated. It defaults to 1,000,000 but it can be varied between 100 and 10,000,000. If you find that the path is too short, which happens we you use many spin levels, then you can increase the number of points to see more of it. However, there is a performance penalty for doing so. The more points you want the more calculations that have to be made and it takes some time for all of that to happen. Therefore, the second setting can be used to change it in a different way. This setting is called Unit Time and it sets the amount of time that passes between consecutive points that are calculated. Increasing this value will also cause a longer path to be generated given the same settings for all other parameters. What it is doing is creating more space between points. If you create a path using the default setting and then create another path with a Unit Time twice the previous, then you are only seeing every second point from that first path. You can think of this parameter as being the resolution of the model. If you go too far though, then the gaps between points become visible. This can be useful but if you want to see the path then you need to look at the next set of options.

In the final parameter set, called Graphics, we only have 1 setting and it is called Geometry. This can be used to set how the points are rendered. The default is to render them as points but you can also render them as lines. This allows you to see the actual path that the particle follows, even when using a low resolution. The default resolution creates points that are very close together and they actually appear as lines without rendering them as such.

by **LongtimeAirman** Wed Dec 06, 2017 9:34 pm

.
The spin levels created by Spin Path Generator are fascinating objects; moving one about, zooming in or out, what exactly is it? One finds the answer most readily by viewing Spin Sim, it’s the BPhoton’s path. Any given spin level displays locations briefly occupied by light speed BPhotons, which determine the particle’s surface. I say surface because all particles displayed by the spin applications (aside from A1 in Spin Sim) show an end-over-end spin torus. The BPhoton is always somewhere defining that torus surface, and never within it. Photons pass through the surface unless they happen to collide with the BPhoton.

1. http://www.nevyns-lab.com/science/spin-apps.php On the Stacked Spin page the two applications shown side by side are very similar, but they are in slightly different. I suggest making their formats agree a little more closely by including or not including bullets in both of the two Spin application descriptions.

2. Maybe add viewing coordinates or particle rotation options? Mouse orbit controls is confusing and difficult at times – hence the home button. Being able to adjust the viewing angle by user input might be a welcome alternative to just the orbit controls. The graphics tab might include a rotate about axis option that would allow the user to capture motion with a gif application.

3. The moving slide bar doesn’t seem to work for iterations, you may have subdivided the number range properly, but the limited slide positions – not smooth at all - allows for many random appearing digits, no rounded numbers like you’ve provided in the “unit time” slide bar.

Reviewing: Spin Path Generator wrote:

* First paragraph, 3rd line, suggest changing “the path that it covers“, to “the particle’s surface created by the BPhoton’s motion”.

** First paragraph, last sentence, “to analyse the paths of various particles to see how they compare with each other”. The “path of the various particles” is confusing, the particles are spin levels, the only thing moving is the BPhoton. Consider changing to “analyze and compare the paths of various particle BPhoton motions”.

It’s my impression, using Spin Path Gen’s iteration number and sampling rate, one can create any number of BPhoton track patterns (displaying points or lines) revealing the particle’s surface. The apps show how a particle’s surface complexity increases as the spin levels increase. One can vary the sampling number and rate, (or rely on the default, thank you), giving the particle surface anything from a rough outline, contour or veil-like appearances, to far denser patterns as one views the particle. Some selections are prettier than others. Those patterns strike me as an artifact of sampling and do not represent any particle variation whatsoever. I’m not sure the pattern would necessarily point to where we may most likely find the BPhoton.

*** Second paragraph, 3rd line. I like the tabs. They may be a bit too close to the “Run”, “Stop”, and “Home” buttons. I expect additional information on the controls, yes that higher axis A spin checkbox; instead, the description veers into the justification of the Spin apps. The theoretical basis of Spin Stacking, including your simulation’s description and explanation should be front and center, not here.

**** Second paragraph, last line. “Which dimension can be used to spin around that does not go through any existing spins? “. I agree that when I apply a vertical tangential collision to a horizontally oriented z-spin, the new axis of rotation goes through the same center of rotation as the z-axis. The two spin axii are orthogonal, and the BPhoton is never at the center point of the two spin axii. The only problem I see is that there’s no radius doubling.

Your argument “given that the new spin axis can not go through any existing spins“ may be the correct and winning physics argument, is it a violation of precession? I don’t know, I’ll take it for consideration, but I’m not convinced higher A spins don’t exist. My main complaint with the two, no higher A-spin spin apps, is the idea that a BPhoton can move simultaneously in up to 40 different motions, up to ten each parallel, scaled, or sign changed X,Y and Z spin motions. In my opinion a far greater problem than the Z and A spins sharing a common center. Lately I’ve begun to assert that one cannot properly model particles without including recycling photons which may cycle through all the end-over-end sub-spins.

The additional information you provide is welcome. As far as choosing higher axial spins – where my review broke down - there’s a check box. Selecting it will not get you higher axial spins. Since you don't agree they exist, you don't model them. You indicate that you're “working on an effective solution to this”, I can’t wait. Why not might include higher axial spins with the caveat, “higher A spins have not been shown to exist”, we understand, this is your simulation dadgumit, and a dang good one at that. Still, if there were higher A spins the particle surface complexity repeats but doesn’t grow, making each X, Y or Z more self-similar, simplifying the larger particle’s appearance.

Please consider presenting Spin Gen to Miles for his input.
.

by **Nevyn** Thu Dec 07, 2017 12:18 am

LongtimeAirman wrote:
1. http://www.nevyns-lab.com/science/spin-apps.php On the Stacked Spin page the two applications shown side by side are very similar, but they are in slightly different. I suggest making their formats agree a little more closely by including or not including bullets in both of the two Spin application descriptions.

Yeah, I rushed those changes in to get the app deployed and haven't gone back to tidy them up. Will look into it soon.

LongtimeAirman wrote:
2. Maybe add viewing coordinates or particle rotation options? Mouse orbit controls is confusing and difficult at times – hence the home button. Being able to adjust the viewing angle by user input might be a welcome alternative to just the orbit controls. The graphics tab might include a rotate about axis option that would allow the user to capture motion with a gif application.

Good ideas. Assigning rotations via controls can be a bit awkward, but I will see what I can do. Auto-rotation about an axis is something I had not thought of before. Really good idea.

LongtimeAirman wrote:
3. The moving slide bar doesn’t seem to work for iterations, you may have subdivided the number range properly, but the limited slide positions – not smooth at all - allows for many random appearing digits, no rounded numbers like you’ve provided in the “unit time” slide bar.

Yeah, they could use some tweaking, for sure. The iterations are probably stepping by 1, I can make that 100,000 or something large like that. I might need to increase the minimum value, which is 100 at the moment, as the min and the step should be somewhat aligned with each other. For example, for the Unit Time slider, the min and the step are the same value.

LongtimeAirman wrote:
* First paragraph, 3rd line, suggest changing “the path that it covers“, to “the particle’s surface created by the BPhoton’s motion”.

I don't want to use the term surface, but I'm sure I can come up with something better. Maybe boundary since that doesn't imply something that exists, it can just be a concept.

LongtimeAirman wrote:
** First paragraph, last sentence, “to analyse the paths of various particles to see how they compare with each other”. The “path of the various particles” is confusing, the particles are spin levels, the only thing moving is the BPhoton. Consider changing to “analyze and compare the paths of various particle BPhoton motions”.

I was using the term particle to refer to both a BPhoton and all of its spin levels. Not just a spin level itself. Note that we could have the same number of spin levels but change whether it uses higher axial spins and that would be 2 different particles. I'll see if I can find some better words to use and make it clearer.

LongtimeAirman wrote:
It’s my impression, using Spin Path Gen’s iteration number and sampling rate, one can create any number of BPhoton track patterns (displaying points or lines) revealing the particle’s surface. The apps show how a particle’s surface complexity increases as the spin levels increase. One can vary the sampling number and rate, (or rely on the default, thank you), giving the particle surface anything from a rough outline, contour or veil-like appearances, to far denser patterns as one views the particle. Some selections are prettier than others. Those patterns strike me as an artifact of sampling and do not represent any particle variation whatsoever. I’m not sure the pattern would necessarily point to where we may most likely find the BPhoton.

True and not quite true. These patterns are most definitely a result of sampling, but they can be used to see the density variations which tell us that the BPhoton spends more time in those dense areas.

LongtimeAirman wrote:
*** Second paragraph, 3rd line. I like the tabs. They may be a bit too close to the “Run”, “Stop”, and “Home” buttons. I expect additional information on the controls, yes that higher axis A spin checkbox; instead, the description veers into the justification of the Spin apps. The theoretical basis of Spin Stacking, including your simulation’s description and explanation should be front and center, not here.

I can increase the white space on the screen to allow more space between sections. while I was developing the app, it was taking up the whole page and I was trying to avoid having scroll bars on the page. Once I deployed it to my site, I found that it didn't take up anywhere near all of the page so I think my dev browser must have some zoom applied.

I can put some short description as a tooltip on the controls, but I can't give a lengthy description in those. Hence the wall of text above. I will put that larger description, or overview, onto another tab, it was not meant to just exist here on this site, I just wanted some feedback before I made changes to the app.

I'm never sure how much I have to describe stacked spins themselves. I was planning on putting a few links in there so the user could go to Miles site to get more info on them.

LongtimeAirman wrote:
**** Second paragraph, last line. “Which dimension can be used to spin around that does not go through any existing spins? “. I agree that when I apply a vertical tangential collision to a horizontally oriented z-spin, the new axis of rotation goes through the same center of rotation as the z-axis. The two spin axii are orthogonal, and the BPhoton is never at the center point of the two spin axii. The only problem I see is that there’s no radius doubling.

I'm not too concerned about the absence of a doubling radius on higher axial spins. Much more concerned about the axis of rotation and how that relates to the previous top level spin.

If we have a top level Z spin, and we insist on a higher axial spin with an orthogonal spin axis, then that axis must be the X or Y axis. It can not be the Z axis since if it was, then it wouldn't be orthogonal. However, the X and Y axis passes straight through all of the existing spin path (before we add the next axial spin). That is, it passes through that boundary that the motion has given us. That is explicitly dis-allowed by the rules of stacked spins (or gyroscopes, actually). So I put it on the Z axis but then it really isn't an axial spin, it is just adding to or removing from the existing top level Z spin. It has to because it is the exact same spin axis.

LongtimeAirman wrote:
Your argument “given that the new spin axis can not go through any existing spins“ may be the correct and winning physics argument, is it a violation of precession? I don’t know, I’ll take it for consideration, but I’m not convinced higher A spins don’t exist. My main complaint with the two, no higher A-spin spin apps, is the idea that a BPhoton can move simultaneously in up to 40 different motions, up to ten each parallel, scaled, or sign changed X,Y and Z spin motions. In my opinion a far greater problem than the Z and A spins sharing a common center. Lately I’ve begun to assert that one cannot properly model particles without including recycling photons which may cycle through all the end-over-end sub-spins.

Yes, it is a violation of precession. It may be more accurate to say that it is a force that would cause precession. The existing motion of the gyroscope resists that force and precession is the result of, or is, that resistance.

I agree that giving the BPhoton so many different velocities is difficult to accept. It is fairly unheard of at our own scale. However, it is not completely alien. We can accept that something can have an axial spin while also having a linear velocity. Our planet does it constantly, although it may be a bit of a stretch to call that a linear velocity since it is actually a second rotation (without getting into gravity). On top of that, the Sun is rotating around the galaxy, so we live with this stuff but don't really take much notice of it.

The reason I think that higher axial spins are more important at the moment is because it is an implementation detail. Whether stacked spins are real or not is a conceptual detail. I am modelling them with the assumption that they may be real and to see how they work. I'm not trying to prove that they are real but I am trying to give a solid position for such arguments, which ever way they go.

Recycling is important, but not always necessary. They are only necessary for the charged particles. Photons don't need them at all. Of course, linear velocity is also necessary for a photon but I haven't modeled that in this app. I have thought about it though.

LongtimeAirman wrote:
The additional information you provide is welcome. As far as choosing higher axial spins – where my review broke down - there’s a check box. Selecting it will not get you higher axial spins. Since you don't agree they exist, you don't model them. You indicate that you're “working on an effective solution to this”, I can’t wait. Why not might include higher axial spins with the caveat, “higher A spins have not been shown to exist”, we understand, this is your simulation dadgumit, and a dang good one at that. Still, if there were higher A spins the particle surface complexity repeats but doesn’t grow, making each X, Y or Z more self-similar, simplifying the larger particle’s appearance.

Not sure what you mean here. I do model them, even though I don't agree with them. I just provide a way to disable them so that the user has the ability to generate what they want to see. It also allows us to compare spin paths with and without higher axial spins.

What I meant by "working on an effective solution" is just what we have been discussing in the above posts. An effective way to tell the user what is going on, which the overview will help with, but I also want the number of spin levels to show the actual number of levels that are going to be generated. I don't want to impose my beliefs onto the user if I can help it. I want to be able to generate paths that adhere to Miles ideas exactly while also allowing modifications where I think it is appropriate.

Thanks for the feedback. I will take it all into consideration and see what I can come up with to make this app better.

by **Jared Magneson** Thu Dec 07, 2017 11:38 pm

Very good stuff, Nevyn. I'm still learning how to script such things and it's inspiring to see you making some headway in your direction. And of course the conversation on higher axial spins is really important too.

It would be cool if you were able to implement GPU-acceleration too, but I'm sure that's more technical. It's really quick at lower levels/iterations, just when you drop a million in there the CPU has a lot more to chew on. It's much, MUCH faster on Firefox 57 than Chrome or Firefox <56.

@CR6 I believe FF 57 is the "Quantum" update, which allows multi-core saturation that as far as I know no other browsers are offering. It's MUCH faster than FF 56 or Palemoon, for a more direct comparison. It does suck that I lost a lot of cool add-ons but the benefits so far are great.

by **Nevyn** Fri Dec 08, 2017 12:38 am

Yeah, the new Firefox is great, but it doesn't give the developer any way to use multi-threading. That is because the underlying language doesn't (thanks, Javascript). I'd love to work in OpenCL, which I could if any browsers supported the WebCL extension. They've all taken on WebGL for 3D graphics but left out the WebCL for computing. Maybe in time they will support it.

On a side note, I just implemented SSL support on my site so everything now runs through a secure connection.

by **LongtimeAirman** Fri Dec 08, 2017 12:47 am

.
Hi Jared. Nevyn, that reminds me, my system is really loaded when I run Spin Path Generator. I’ve had to reboot a couple of times when dialing up high levels with additional programs (normally Word and one or two other browsers) running in the background. I must remember to shut everything down before running Spin Path Gen.

I made one suggestion I though was a good one that you didn’t reply to. Spin Path Generator creates a BPhoton spin level. Is it possible to create two or three consecutive spin levels and display them in the same image?

After checking the Higher Axial Spin checkbox I don’t see any A-spins.

Spin Path Generator Spinpa11

Here are the fifth and ninth spin levels, with and without Axial Spins.

Spin Path Generator Spinpa12

The difference between the two pairs of A-spin and Z-spins is 45 degrees about the Z axis, both the A and Z spin levels share the same axis.

I’ve always imagined the A-spin as spherical, not as an end-over-end spin. I described creating the A spin badly yesterday (and months ago as well) so I’ll try again. Start with a horizontally spinning Z spin level (the Z axis is vertical). Strike the BPhoton tangentially, in a vertical direction. The new A-spin axis could be at any X,Y angle, orthogonal to the Z-spin axis. I think of it as spinning a ring. The A-spin axis penetrates the Z-spin in two locations, the Z and A-spin centers are the same, the new A-spin axis doesn’t go through the BPhoton which was 90 degrees away from it at the time of the collision. I understand that the force applied orthogonally to the existing Z-spin causes precession in gyroscopes; that may indicate that the same force applied to the BPhoton spin level isn’t allowed. The only defense I can offer is - the Z-spin isn’t a structure, what precesses? The BPhoton angle?

Higher spin level self-similarity. It seems to me that spherical A-Spins allow higher spin level self-similarity. A spherical A-spin causes each consecutive X,Y and Z spin set to have the exact same boundary dimensions, differing in scale alone. A2 looks exactly the same as A3, or A4, … . Same with each X,Y and Z set.
.

by **Nevyn** Fri Dec 08, 2017 2:14 am

Now I see the confusion. There are differences, but they are subtle. Here are 2 images showing the exact same perspective:

With Higher Axial Spin
A, X, Y, Z, A, X, Y, Z

Without
A, X, Y, Z, X, Y, Z

The top image, with higher axial spins, shows a wider mouth with smaller uvula. The outer surface is also 'dented' more than the other with the 2nd image looking smoother in general.

I've just realised that I have used 8 and 7 spin levels respectively, when I really wanted to use 5 and 4. You can still see the differences here, even though there are 3 more spin levels stacked over the top of the higher axial spin.

However, I generally agree with your assessment. The Z axis can not be used for higher axial spins. It should be X or Y (technically it should be Y because the next spin is going to be an X), but I can't see how that can be allowed. It blatantly breaks the first rule of stacked spins with no reason, explanation or evidence.

It is interesting though, when I was using the Y axis for higher axial spins, it gave some really strange results. I was very shocked and started questioning myself and the implementation I was developing to generate it. I even had half of an apology for you written in my head as I thought I had to rethink all of this higher axial spin stuff. That's when I realised it was spinning on the Y axis and changed it to Z.

I wasn't thinking about collisions to form spin levels and I thank you for prompting me to think of it in that way again. That rules out the Z axis, although there is no reason that the top Z spin can't be slowed down and sped back up again. It can't go faster than c, but it can go slower.

I did notice your request for a scale marker but I am very hesitant to add anything like what you describe. I don't want to render anything in the scene other than the BPhoton position markers. Anything else I put in there may be mistaken for the particle being generated. The axis markers are necessary and should be recognized for what they are. If there was a smaller particle inside of the real particle, it could confuse users who don't really understand what they are seeing.

I have not completely ruled it out though, I just need to think of a better way to do it. It would be good if I could hook it up to the scrolling (zooming in/out) so that it only shows while you are zooming. If I can make it obvious that it is not part of the generated particle then I will do so.

by **Nevyn** Fri Dec 08, 2017 2:21 am

I think I should clear up any confusion around this statement:

Nevyn wrote:I've just realised that I have used 8 and 7 spin levels respectively, when I really wanted to use 5 and 4. You can still see the differences here, even though there are 3 more spin levels stacked over the top of the higher axial spin.

To generate those images, I set the number of spin levels to 8 and just altered the higher axial spin checkbox. I did not move the spin level slider down to 7 at any point.

I should have used 5 so that it would show A, X, Y, Z, A with higher axial spins enabled and A, X, Y, Z with it disabled.

In some ways it is better that I did accidentally add more spin levels on top of the higher axial spin because it shows you how that difference expresses itself as it bubbles up though other spins. Interesting, at least.

by **Jared Magneson** Fri Dec 08, 2017 4:20 am

It's very interesting stuff! It seems to me that only very specific though not irrationally obscure collisions would or could stack a new spin. So what happens to our photon otherwise? Does it just keep all its spins and change vectors, or would an off-spin collision "slow down" its velocity in either way, tangential or directional?

Are most photons just that, an average of non-stacked spin collisions?

by **Nevyn** Fri Dec 08, 2017 8:46 pm

I think that in order to be called a photon, it must have A and X spins. You need that first X spin to create the wave of the photon. Anything less than that I would call a BPhoton.

by **Nevyn** Fri Dec 08, 2017 9:35 pm

I have made some changes on my dev environment to show higher axial spins on the Y axis rather than the Z.

This first image is without any higher axial spin and it is included to show what we are giving an axial rotation to.

A, X, Y, Z

Now we take that and spin it in the Y dimension which is up and down in this view.

A, X, Y, Z, A

I have not changed the camera position between those two shots. It is not the best perspective to see the higher axial spins path and you really need to generate it and move around it in SpinGen to get a good feel for it. It is a strange path, to say the least.

Here is some different views of it.

A, X, Y, Z, A

From the top
A, X, Y, Z, A

For my argument, we don't even need to see the higher axial spins. I only need that first image which shows a single spin set, A, X, Y, Z. You can see that the Y dimension, the green line going from center to the top, goes straight through the spin path (which is also green, didn't think that one through very far, did I?). If you generate that and move around it, you will see that it is embedded into the boundary of the photon.

Looking at the higher axial spin path though, I think that it looks unnatural. All paths generated without higher axial spins still feel organic, in some strange way. Maybe a better word to use is complicated. It looks too complex while not using them still looks simple in comparison. This is not a strong argument, if it is one at all, but that is how I feel about it. It could just be my prejudices, I do admit. Thankfully, my real argument is just enforcing the rules of the game, so I don't need this one at all. Very Happy

I will update SpinGen with this Y spin adjustment as it is the only logical axis to use. I'm working on a few other things at the moment though, so it might be later today or tomorrow before you see it on the site.

by **Jared Magneson** Fri Dec 08, 2017 11:41 pm

I think your argument against higher axial spins is about as strong as it needs to get. I can't find or form a collision that might cause such a spin, in my collision sims. With the other stacked spins, we have gyroscopy and precession as reasons/mechanisms for how they "spin up", but with those higher axial spins it just seems very contrived. I don't think the particle itself could "know" how to spin about that common center. And that common center is constantly changing, as the path advances through that particular stacked spin.

So let's say it takes a certain, particular angle/velocity to "stack" a new spin. To stack an axial spin, it would take a certain, particular angle/velocity and it would also have to hit at very specific times along the existing stacked path. It wouldn't have the degrees of freedom the others do. It seems like only one or two collisions could possibly cause a higher axial spin, where almost all other viable collisions could cause an orthogonal stacking given the right vector.

Also, totally with you on the non-axial spins seeming and feeling "organic".
Spin Path Generator YUyKWeH

by **LongtimeAirman** Sat Dec 09, 2017 5:58 pm

.
Déjà vu! Well, not really, although we've all been here before, we now have great Spin Path Generator images.

The simulation shows the path created by a BPhoton with up to 40 simultaneous end-over-end, spin motion mass radius doublings. How can an object have 40 separate motions? Sure, the location of my old pocket watch’s second hand, given all the motions of me and the universe comes close, but that doesn't explain how a BPhoton could possibly drive 40 spin levels. Ok, another question just hanging there in the breeze. We know that charged particles usually gain or lose outermost spin motions. How can the BPhoton shown in Spin Gen protect its innermost spins while sustaining rates of random collisions throughout its path? I already know the answer, it cannot; Spin Gen doesn’t include photons.

No charged particle model is compete without showing how the spin level channels photons. We've discussed this topic and the need for a collision based charged particle model elsewhere at the site. I would like to show that photons become en-trained in the various spin loops, augmenting and amplifying the charge recycling capacity of the charged particle. The particle’s innermost spin is protected by increasing volumes of en-trained and recycling photons at every spin level. While I may believe the original BPhoton can drive an entire X,Y,Z spin set, I assume all higher spin particles would require many recycling photons rather than BPhotons alone. Maybe higher A-spins are possible when there are enough photons to actually double the radius.

Include photons!
.

by **Jared Magneson** Sat Dec 09, 2017 8:47 pm

As a Spin Path Generator, isn't Nevyn just trying to show the spin paths?

by **Nevyn** Sun Dec 10, 2017 5:55 pm

I don't think of it as a BPhoton with 40 individual velocities. I think of it in layers, or levels. Each spin level has a tangential velocity. Each level is kind of an entity in its own right. It is based on mass distribution. A spin level distributes the mass that it is spinning into a larger volume of space. With a tangential velocity of c, it acts like an entity that inhabits that volume. That entity can now be given another end-over-end spin with a collision in the right place and direction because the volume of space is not a sphere but a torus-like object. This creates a difference in balance among the dimensions. The spin axis dimension reacts to force applied along it more easily than the other 2 dimensions. This is caused by those other 2 dimensions containing all of the motion, or potential force, of this spin level.

Airman wrote:
Ok, another question just hanging there in the breeze. We know that charged particles usually gain or lose outermost spin motions. How can the BPhoton shown in Spin Gen protect its innermost spins while sustaining rates of random collisions throughout its path? I already know the answer, it cannot;

A particle doesn't need to maintain that path while in collision. SpinGen only shows you what it would do without interference of any kind.

The outer spin is the most likely to take any force but I assume that it is possible for the right collision to affect spins just under the top one. What happens in this circumstance, I don't know. I suspect that all spins above it will soon collapse. It isn't a theory ender.

Airman wrote:Include photons!

SpinGen is designed to show you a photon, or electron or proton. It can't show a nectron or neutron yet. To be technical, it can't actually show you a photon because that would require a linear velocity. I'm still thinking about how to incorporate that into the mix.

by **Nevyn** Sun Dec 10, 2017 8:34 pm

I got a bit side-tracked on another project over the weekend, but I have now updated SpinGen to use higher axial spins on the Y axis and I have also updated the Iterations slider to use more friendly values.

I made a quick attempt at formatting the number of spin levels depending on whether the higher axial spin checkbox is selected or not and it didn't work. I'll have to think about it a bit more than the 10 minutes I gave it.

by **Jared Magneson** Sun Dec 10, 2017 10:48 pm

Have you shown this to Miles yet? Or were you refining it further? It seems like something he'd be pretty interested in, unless you forget to include the genealogy or something in your email. Smile

by **Nevyn** Mon Dec 11, 2017 5:13 pm

I already know what Miles will say: "You need linear velocity to show photons.".

by **LongtimeAirman** Thu Dec 14, 2017 10:57 pm

.
Jared wrote (speaking to Nevyn). I think your argument against higher axial spins is about as strong as it needs to get. I can't find or form a collision that might cause such a spin, in my collision sims.
Airman. We all agree, neither Nevyn’s Spin apps nor, apparently, Jared’s own collision sims, show how higher axial spins can form. Nevyn (please correct me if I’m wrong) is therefore convinced higher axial spins do not exist. Jared seems to agree.

I must disagree. Electrons and protons give all indications of being spherical. If Spin apps show that higher axial spin don’t exist, the problem may in fact lie with the Spin apps model. We should all recognize the fact that the Spin apps do not include charge. Given that omission, there is insufficient basis to claim the Spin apps shows higher spin level particles.

Jared wrote. As a Spin Path Generator, isn't Nevyn just trying to show the spin paths?
Airman. I haven't seen the program code, I’d say the spin path most closely resembles a set of outside radius positions, which show the tangential light speed charged particle surface boundary limits given the sampling of up to each of the other 40+ simultaneous end-over-end spin motion light speed radius doublings. Whatever it shows, whether it’s considered a complete and valid model or not, the spin path has been treated as a physical model, enough so that it is taken as proof of the non-existence of higher axial spins. After a great deal of time and effort spent considering this subject - as we all have - it no longer makes any sense to me to suggest that a single BPhoton can span all a particle’s spin levels or form a higher spin level charged particle’s surface.

Nevyn wrote. I don't think of it as a BPhoton with 40 individual velocities. I think of it in layers, or levels. Each spin level has a tangential velocity. Each level is kind of an entity in its own right. It is based on mass distribution. A spin level distributes the mass that it is spinning into a larger volume of space. With a tangential velocity of c, it acts like an entity that inhabits that volume. That entity can now be given another end-over-end spin with a collision in the right place and direction because the volume of space is not a sphere but a torus-like object. This creates a difference in balance among the dimensions. The spin axis dimension reacts to force applied along it more easily than the other 2 dimensions. This is caused by those other 2 dimensions containing all of the motion, or potential force, of this spin level.
Airman. It’s true, those motions exist. It is not true to describe those motions as a BPhoton. A BPhoton is present with the first end-over-end motion, each higher spin level created will be beyond the BPhoton’s influence. The BPhoton position may indeed trace out a path in time, but I don’t believe it would remain at the particle surface boundary as shown by SpinGen.

Discussion of mass distribution and balance cannot replace missing charge. How do photons move through the spins? What are the charge mechanics? I could easily believe the original BPhoton is the first photon recycled through the first end-over-end spin particle.

Nevyn wrote. A particle doesn't need to maintain that path while in collision. SpinGen only shows you what it would do without interference of any kind.
Airman. The actual particle may experience a fairly constant interference while maintaining its integrity. Of course there is no interference in SpinGen because there isn’t any charge included. Instead of charge, the Spin apps add up to 40 separate motions. I do not believe those motions represent any possible single BPhoton, nor could a single BPhoton define all but the first end-over-end higher spin particle’s surface boundary. Photons entrained or recycling through the spin loops is what must form the particle’s surface. Recycling photons far outnumber the BPhoton, and are present in many more locations. Entrained or recycling charge must be part the largest part of what forms the particle’s “surface”.

Nevyn wrote. The outer spin is the most likely to take any force but I assume that it is possible for the right collision to affect spins just under the top one. What happens in this circumstance, I don't know. I suspect that all spins above it will soon collapse. It isn't a theory ender.

Airman wrote. Include photons!

Nevyn wrote. SpinGen is designed to show you a photon, or electron or proton. It can't show a nectron or neutron yet. To be technical, it can't actually show you a photon because that would require a linear velocity. I'm still thinking about how to incorporate that into the mix.
Airman. I don’t know what you mean by adding linear velocity. I would start by assuming the BPhoton (X1 spin) is acting like a spinner in a blender. Just add photons. In any case, I’ve always provided plenty of positive attention and feedback, happy to work at improving our collective understanding or efforts. With all due respect to your best design intentions, one cannot plausibly claim to model an electron or proton without including charge.

My Boids app is a real attempt at forming an alternative model, with pool hall collisions between individual particles. If we each had our own set of spinning particles and spin loops to play with, a more complete model of the charged particle may be developed. By the way, it’s been about a month, you haven’t mentioned seeing it run yet.
.

by **Nevyn** Fri Dec 15, 2017 10:41 pm

I do humbly apologize for not spending more time with Boids. You got me back into programming again and I keep getting side-tracked on other things. First SpinGen, since we were discussing similar things in another thread, and then I got excited about a little idea someone at work gave me. Although it only took me a day to solve their problem, it then gave me ideas on how to do something else, closely related.

I've spent the last 2 weeks working on it and have created a way to implement very complex problems into much simpler solutions. It's all based around multi-threaded programming and it is very powerful with very simple constructs since most of the code is generated at runtime. Hooking everything together is a problem in highly parallel systems and my framework takes care of that for you. Anyway, you're probably not interested in that, but I'm pretty excited about it.

SpinSim, SpinGen, AtomicViewer, Relativity and Expansion are my attempts to model Miles work in the way that I understand it. I build them to understand it. They may be wrong. They may be partially right. They may, however unlikely, be completely correct. I don't build them to be correct. I build them to reflect my understanding and to test ideas about it. I build them so that I can see how things move or interact or even just how they look.

SpinSim, and now SpinGen, implements a stacked spin model in the only way that I can see it working. I think it closely reflects what Miles has written about it. It certainly matches the animation he has supplied but since I go so much further than that animation, I don't have anything else to go on, other than the words themselves. I have extrapolated up from that in logical ways, so I am confident in that model.

Airman wrote:
I must disagree. Electrons and protons give all indications of being spherical. If Spin apps show that higher axial spin don’t exist, the problem may in fact lie with the Spin apps model. We should all recognize the fact that the Spin apps do not include charge. Given that omission, there is insufficient basis to claim the Spin apps shows higher spin level particles.

I have implemented higher axial spins and shown you images of it, and they are not spherical. Nothing above the BPhoton itself is going to be spherical in a stacked spin model. The rules don't allow it. But you have to ask how it is that we think that an electron is spherical. What tests have been done to determine this and how have they been interpreted? I must say that I don't know. I haven't put in the research to find out. It does have great significance though, for they could be rotating the electron around as they test from different directions because the electron re-aligns to the charge field that they are supplying.

There is no correlation between implementing charge emission and whether higher axial spins exist. Charge emission will happen with or without higher axial spins and we need higher axial spins way before we get to charge emission. That is, we need to think about higher axial spins with just 5 spin levels but we don't need to think about charge emission until above 14ish. There is also nothing about charge emission that requires a spherical source. In fact, I would say that it is much harder to explain equatorial emission with a spherical source. What makes it equatorial?

SpinSim/Gen is not trying to show charged particles. AtomicViewer does a better job of that. SpinGen is just showing stacked spin motion with no linear velocity. SpinSim can show the linear velocity as well. But that has no bearing on whether higher axial spins exist. The problem is how do you implement them and remain consistent with the rules of stacked spins? I have implemented them by attempting to break as few rules as possible. But it does still break them.

Airman wrote:
It’s true, those motions exist. It is not true to describe those motions as a BPhoton. A BPhoton is present with the first end-over-end motion, each higher spin level created will be beyond the BPhoton’s influence. The BPhoton position may indeed trace out a path in time, but I don’t believe it would remain at the particle surface boundary as shown by SpinGen.

I wouldn't describe those motions as a BPhoton, I would call it the motion of a BPhoton that defines a particle.

How could the path not remain at the so-called surface? The path defines the surface. The path tells us where we can find the actual BPhoton and any collision with that BPhoton must be on that path. The surface is defined by collisions with the BPhoton so the path and the surface are one and the same. Of course, it is not really a surface but it is the only places that a collision can occur.

I assume that you are a bit shocked by the hollowness of the spin paths. They make a lot more sense when you watch the spin path being generated, like in SpinSim. The motions of the BPhoton are quite natural looking (not suggesting that their motions are natural) and the surface is generated by taking the same general motions with slight differences over time. SpinGen shows that given enough time (or iterations) it will cover enough positions to look like a real surface. That was actually the purpose of building SpinGen. It took way too long to do that in SpinSim and it couldn't really get to the same number of points recorded.

Airman wrote:
Discussion of mass distribution and balance cannot replace missing charge. How do photons move through the spins? What are the charge mechanics? I could easily believe the original BPhoton is the first photon recycled through the first end-over-end spin particle.

Discussing mass distribution is a way of thinking about how these motions could occur, which was in response to your statements about that in the previous post. They are not about charge emission, although they do become entangled with each other soon enough. Discussing how these motions could actually work is critical to building the stacked spin collision math that is required for a charge emission model that could answer your questions.

Airman wrote:
With all due respect to your best design intentions, one cannot plausibly claim to model an electron or proton without including charge.

Well that depends on how you define an electron or proton. I would say that you can not claim to model a charged particle without including charge. However, is the charge actually part of a proton or electron? Is the charge what makes it what it is? It is what makes a charged particle for we are thinking more about the effects of that charge than the particle it is coming from. An electron or proton will continue to have the same number of spin levels with or without charge around.

So in a definitive sense, I would say that SpinSim/Gen are modelling the motion of a BPhoton that can create various particles. Some of those are the same motions that make an electron or proton.

by **Jared Magneson** Sun Dec 17, 2017 7:43 pm

Airman wrote:Jared wrote. As a Spin Path Generator, isn't Nevyn just trying to show the spin paths?
Airman. I haven't seen the program code, I’d say the spin path most closely resembles a set of outside radius positions, which show the tangential light speed charged particle surface boundary limits given the sampling of up to each of the other 40+ simultaneous end-over-end spin motion light speed radius doublings. Whatever it shows, whether it’s considered a complete and valid model or not, the spin path has been treated as a physical model, enough so that it is taken as proof of the non-existence of higher axial spins. After a great deal of time and effort spent considering this subject - as we all have - it no longer makes any sense to me to suggest that a single BPhoton can span all a particle’s spin levels or form a higher spin level charged particle’s surface.

I think you're kinda losing me here - not in general, but in specific. This is likely just due to the intimacy Nevyn and I have with the spin path topic since we've both been knee-deep in it in our different ways for so long.

That is to say, I agree with Nevyn's responses because they match mine. The spin path shows where the Bphoton would be, where any and all collisions could take place. I know what you meant by saying "we need to include charge", but I disagree - because the spin path is showing the path of charge already. Any incoming photons will (more than likely, as charge averages at the infrared, not the lone, un-spinning Bphoton itself) also have a complex but calculable spin path, you see.

Maybe think of it this way: Imagine a 4-spin photon (infrared) meeting another 4-spin photon. Both will have similar "paths", stretched linearly of course by the linear velocity (which is absent in these diagrams, as we're studying the tangential velocities instead here). So both particles will have these "spin paths" as nonexistent visual "trails" for us to track their potential collision. They don't have to collide, and there is a very low chance that they will, but given enough charge density some collisions may occur.

Spin Path Generator MMnY4Lv

Now if we let these two photons move towards each other, its not their spin paths that would collide if a collision occurs, but rather their present, current location at the head of that path. They most likely would miss. Timing would have to be quite exact for any collision tracked this way, and timing an exchange of energy that would cause a new stacked spin even more precise. We're not tracking the subspins here but rather the absolute path, if that makes sense. The subspins define that path, but the path isn't real. It's just a tool to visualize the motions, and hopefully find any issues or problems.

In some of my vids I used motion trails to show this path, some from the outer surface of the Bphoton and some from the inside center point. Again, they're just a tool to help us visualize these motions. Ideally my stacked spin motions would be identical to Nevyn's, assuming of course we're both on the right track. I tend to think he is much more than I am, which is why it's so helpful for his critiques in my previous simulations (and Miles' input as well). I got a lot of things wrong and still am, it's a struggle.

by **Nevyn** Sat Jan 05, 2019 10:17 pm

I have made an update to Spin Path Generator that allows you to export all of the coordinates generated from the motions of a BPhoton with various levels of spin. It will create a CSV (Comma Separated Value) file containing 1 point per line. Any spreadsheet application should be able to load a CSV file, but it is just a text file so any text editor can as well.

The generated files can get quite large. With the basic settings, using 1,000,000 iterations, it will create a file that is about 55MB is size.

You can set the name of the file to be generated and also if you want to scale up the values to match those used on screen. This roughly scales the points as if the BPhoton had a radius of 1.

Notice the new Save button that will start the export process. You do not need to have a model generated. It has to regenerate the points for the export anyway.

by Sponsored content

Spin Path Generator

Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Where Are The Photons?

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator

Re: Spin Path Generator