Expansion Simulator

I was looking at my main applications webpage the other day and it looked a bit lop-sided with only 5 applications in a 2x3 grid. So I started to look over Miles papers to see if I could find something else to work on. Most of the ideas I had were quite complex and I just wanted something easier to deal with. I was thinking about a bending light application when it occurred to me that I should just create an expansion simulator.

I had built a very basic expansion app years ago but it was never anything to share. I just wanted to see how expansion looked and confirm that it could at least look like gravity. I fulfilled that desire and moved on to other things such as a stacked spin simulator.

So I thought it was time I put some effort into expansion, especially as it has been discussed a bit on the forum lately. The app starts with 2 particles but you can add as many as you like in whatever positions you desire. You can even set the radius of each sphere if you want to see how different sizes affect the situation.

A basic collision detection system has been implemented and as I did so, I found something interesting. At first, I took the amount of overlap between particles and applied half to each object, in reverse directions of each other. This worked well until I started to play with the radii. When 1 object is twice the size of the other, the force should not be applied evenly between them. So I adjusted the force by the ratio of their radii. This applies more force to the smaller particle.

As I sat and watched it operate, it occurred to me that I had just implemented mass. Mass based purely on the radius or to be more precise, based on motion of the radius. I know Miles has stated that expansion causes inertia and mass is the same motion but it still surprised me that it was that easy.

When I write an app like this one, Spin Sim is another, I try to start at the bottom and work my way up. I try not to implement things just because it has been stated (although that happens sometimes too) and find the underlying concepts that allow that thing to happen. It feels really good to discover results that I had not explicitly programmed in or to see that what I have programmed allows larger concepts to unfold.

Now, I must make it clear that in the real world, as described by Miles, all objects are the same size so what I have done is not strictly correct, or it is correct but it is irrelevant when the radii are equal. You can still see how mass arises but you need multiple particles. For example, if 2 particles expand and collide, then the expansion of both particles together (as they push away from each other) causes the outer edges to expand at twice the rate of a single particle.

The default settings show you 2 particles but you can change them and add as many as you like to the scene. It is really interesting to watch how everything moves about and tries to find the best position with respect to the other particles.

One thing I have noticed in discussions about expansion is that people get confused between being in the model, and hence expanding with the objects, and being out of the model where you can actually see the expansion. So I have implemented 2 cameras: one expanding and another that stays the same size at all times. You can switch between the cameras to see the difference at any stage.

So have a play and see what you can find. Try different particle combinations. At first you will probably put your objects into nice clean positions such as [-3, 0, 0] and [3, 0, 0] but when you are happy with that, move them to odd positions and see how they adjust themselves. For example, you might leave those 2 particles are -3 and 3 and then add in another particle at [-2, 4, 0] and see how that affects the original particles. Add in lots of particles at various positions and see what they do. If you find any interesting setups, post them here so that others can see what you have found.

Have fun!

http://www.nevyns-lab.com/mathis/app/Expansion

.
Wow Nevyn, Are you going through a growth spurt?

We cannot alter a viewpoint except by matrix transformations(!?). Is this a three.js app? Maybe you can add a pan/zoom?

Any possibility of adding charge repulsion? How about particle velocities?
.

I've had the last month off work so I've had a bit of spare time. Back to the grind on Monday though.

What do you mean by matrix transformations? I assume you mean how you specify the objects in the field which may look like a matrix, but it is not. It is just an array of arrays. Each array ([x, y, z, r]) specifies 1 object and you can have as many as you like. I would never make the user specify a matrix to alter the viewpoint, that is difficult and tedious. Programmers must make things easier for their users, not harder.

Yes, this is ThreeJS.

I have had long hard thoughts about pan/zoom. I did initially have a zoom feature in there but it messes with the cameras. I also put in the Orbital Controls like I have used in AV but they work on a camera, not a Group and since I have 2 cameras, it does not work as I need it to. That leaves me to implement some controls myself which I may get to at some point. I think I will implement pan but not zoom as that interferes with the expansion of the camera.

I have thoughts about another app that contains expansion and charge emission since it doesn't seem that difficult now that I have this expansion app.

I haven't thought about velocities though. They make it difficult to keep the objects within the viewport. It would be good to see the curved path of an object approaching a larger object. Thanks for the idea, I'll see what I can do.

.
Thanks Nevyn,

Coordinating separate viewpoints does complicate things.

I imagine manipulating coordinate strings defining object positions operate very much like matrix transformations.

I also imagine I'm a comedian. I mean well.
.

The location you specify for the object position does end up in a matrix, along with the rotation and scale data for each object but I don't use them directly. I do sometimes but not in this case. Expansion is implemented by adjusting the scale part of the matrix on each frame.

The radius is also put into the scale part of a matrix but it is a different matrix to the position and expansion data. This allows me to scale a sphere with a radius of 1 into any radius you specify but I have to keep that separate from the expansion scaling. This lower level matrix is also used to rotate the sphere by a random amount on each dimension so that different spheres with the same texture look slightly different to each other.

I have made an attempt at including velocity. You can specify the velocity of any object by adding another 3 numbers to its definition to give [x, y, z, r, dx, dy, dz] for a full description or you can leave out the radius and just specify [x, y, z, dx, dy, dz]. This velocity is never altered which means a collision will not affect it. The object keeps that velocity for its entire life span.

I'm not sure how to alter the velocity at the moment and am happy to hear any suggestions you may have. I know it seems easy, just add them together, but I have an inkling that it is a bit more complicated than that. For starters, any velocity imparted by collision is not maintained, it is added at the moment of collision and never again.

This may be the wrong part but I didn't think that a collision from expansion would impart a constant velocity, more of a quick shove. I thought that if I kept the velocity, it would make the particles move away from each other after a collision, bouncing off of each other and that didn't seem right. Now that I think about it though, on the next frame, the expansion of the radius will overcome the velocity added in the last frame and the difference between those velocities will be a constant between any 2 consecutive frames. That value is what we measure as gravity!

I have setup a couple of new webpages: one for Relativity and one for Expansion. These pages allow me to have multiple apps per subject. In the case of expansion, it is not a different application, it just specifies a parameter to setup different scenarios.

When I gave the object a constant velocity I quickly ran into a surprising realisation. What we call a constant velocity is actually an acceleration from a non-expanding viewpoint. I had to scale the velocity to match the scaling of the radius.

This is critically important because the laws of motion state that an object will maintain a velocity until acted on by a force. But if that velocity is actually an acceleration, then how does it accelerate? What force is causing the acceleration? We have to assume that the force of expansion not only acts on the size of the object but on its velocity as well.

I'm not sure how to interpret this at the moment. It could be used as an argument against expansion but it could be telling us something really important too.

If we want to work in non-expanding units, we may need to redefine velocity in terms of the radius of the particle. This gives us the equations d = kr and v = kr/t. We specify k as the velocity or distance per unit time and the expanding radius keeps the velocity constant from an expanding viewpoint.

This all gets very complicated very quickly. You can see why discussions about expansion quickly dissolve into confusion.

Link to the velocity scenario: http://www.nevyns-lab.com/mathis/app/Expansion/expansion.html?mode=velocity

.
Nevyn, How exciting! A law of motion - constant velocity - becomes a complex acceleration under Expansion theory. Make or break indeed, that is a surprise. You're probably right to suspect there's a good reason for it.

Back to the app, Entering object position and velocity data entry is a nightmare. One must prepare a list on a separate editor. Consider a kind of table on the expansion page where you can enter any or all the seven variables x,y,z,r,dx,dy,dz (for a set of say at most x objects) by just plugging in the numbers without commas and ()s. The same table could remember starting values and show all the updating data.

Absolute coordinates seem to lose meaning under expansion as well. Do you renormalize the coordinate system each dt?  
.

LongtimeAirman wrote:.
Nevyn, How exciting! A law of motion - constant velocity - becomes a complex acceleration under Expansion theory. Make or break indeed, that is a surprise. You're probably right to suspect there's a good reason for it.

I was utterly shocked when I realised what I had to do to the velocity but after thinking about it, it is obvious. How could it be any other way? If the distance is expanding (and by that I only mean our measurement of it) then the velocity must as well. The only thing common between the non-expanding and expanding systems is time. Everything else is affected by expansion.

LongtimeAirman wrote:
Back to the app, Entering object position and velocity data entry is a nightmare. One must prepare a list on a separate editor. Consider a kind of table on the expansion page where you can enter any or all the seven variables x,y,z,r,dx,dy,dz (for a set of say at most x objects) by just plugging in the numbers without commas and ()s. The same table could remember starting values and show all the updating data.

When I first started thinking about how to enter the location and radius and add new particles, I had similar ideas. A bit more dynamic than you have described as I thought I would add a button to create a new row and buttons to remove rows (each row is a particle). I created what it currently has because I needed to be able to change these values easily (before that I was specifying them in the code and refreshing the browser each time). It worked for me but I can appreciate that it is not very user-friendly and it doesn't save your changes across refreshes. I'll see what I can do.

LongtimeAirman wrote:
Absolute coordinates seem to lose meaning under expansion as well.
.

My head is in the opposite space at the moment, so I see everything from the absolute coordinate system and it is what we measure that is losing meaning. I have to program the model as an absolute system and manipulate the camera to provide an expanding viewpoint.

LongtimeAirman wrote:
Do you renormalize the coordinate system each dt?  
.

Nope. No renormalization at all. If I ever described my previous expansion app on the web then I probably talked about renormalizing the numbers to keep them in a usable range. I was thinking I would need to do this again when I started this app but I thought I would start without it and see how it went. And it went pretty well. There is a point where the numbers explode but it is a lot further away (in time) than I expected. I prefer not to renormalize anything because that caused me all sorts of problems in the first app.

Nevyn wrote:When I gave the object a constant velocity I quickly ran into a surprising realisation. What we call a constant velocity is actually an acceleration from a non-expanding viewpoint. I had to scale the velocity to match the scaling of the radius.

I may have jumped the gun a bit here. I think this may be an artifact of the way I have had to implement an expanding viewpoint. When I tried to implement expansion years ago, I was using the Java3D API. In that API, the camera has a notion of its own size and scale. This allows you to shrink the camera down to see very small things or scale it up to see very large things. ThreeJS does not have the same concept and applying a scale to the camera itself does nothing, even though it has a scale vector (which is just inherited from Object3D, like all scene objects). So I had to put the camera into a group and apply the scale to that group which would effectively keep moving the camera away from the objects we are looking at. As the camera moves away at the same rate that objects expand, you don't see any expansion.

This worked well when I was just looking at expansion but it has affected the way a velocity looks. The problem is that a camera that is moving away effectively makes space expand as well. Expansion does not include the idea of expanding space (since that would mean that space is something and we know space is no-thing). Actually it is even worse than that, a moving camera makes space expand along the line from the camera to the subject but makes it contract in most other ways. It is a bit confusing but it can make space contract along the dimension that it is expanding. It makes the space expand for the camera but makes it seem to contract for the objects. This contraction was the reason my constant velocity looked like it was slowing down.

I will try to re-implement my expanding camera by adjusting the field-of-view rather than the distance. If I can get this to work, and I'm not convinced that I can, then it will allow some other things to work differently. At the moment I have 2 cameras, 1 expanding and 1 non-expanding. I will be able to implement that using only one camera because I will just be using a different calculation for the field-of-view. This will allow me to add pan and possibly zoom functionality. Of course it also introduces other problems. As the objects are getting larger, they take up more space in the field and so they soon over-run the camera position. You can see this at the moment if you use the non-expanding camera.

Expansion is a very tricky subject to handle and any knee-jerk analysis is bound to be very wrong. It requires a lot of thought and very careful consideration of what is and what isn't expanding and how that would look to both an expanding and a non-expanding viewpoint. Once you think you have that understanding, and I'm not saying I have it all figured out, you have to find a way to implement it with tools that don't work like you want them to. But if it was easy, I would get bored and move on to some other field of study.