# Simple Orbiter 2

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

## Simple Orbiter 2

Nevyn, You totally dominate the Simple Orbiter thread. I’ll follow your suggestion (in http://milesmathis.forumotion.com/t126-simple-orbiter#900 ).

I suppose I could keep it to myself until I have a working product but I feel a pitch is in-order. The program I’m studying is canvas_geometry_birds, slightly simpler than http://threejs.org/examples/#webgl_gpgpu_birds.

I think I first read about a simulation similar to this back in the 70’s (birds are also referred to as boids, kinda makes me homesick). A large number of random birds quickly develop aerial flock behavior when each bird operates with just a few simple rules. “Birds” utilizes position, velocity, and acceleration vectors. Rotation is also tracked. I believe all the necessary functions are already in place.

Here are the two main behaviors behind “birds”, and a charge field simulator – Simple Orbiter 2:

Bird (or wall) Avoidance/Charge Field Repulsion.

Bird Grouping/Gravity.

Charge repulsion and gravity are opposed and in balance at all scales. Charge dominates at small scales, but it will still find its balance with gravity. "Brownian Motion" will be a real concern. Outside ambient charge sources may need to be minimized or eliminated to understand that balance. Initially, I imagine the simulation should be sized such that the “particles” are electrons. Later, mixing protons and electrons will add complexity. I’m certain that observable structures, including orbits, will develop.

The reason I’m still talking is because if it performs at all like I expect, I hope you make it your own, and include it with the rest of your work.

Nevyn wrote:Start very small, Airman, and work your way up. Copy one of the simple examples and reduce it back to the bare essentials and then start adding in your own stuff.

I suppose I could keep it to myself until I have a working product but I feel a pitch is in-order. The program I’m studying is canvas_geometry_birds, slightly simpler than http://threejs.org/examples/#webgl_gpgpu_birds.

I think I first read about a simulation similar to this back in the 70’s (birds are also referred to as boids, kinda makes me homesick). A large number of random birds quickly develop aerial flock behavior when each bird operates with just a few simple rules. “Birds” utilizes position, velocity, and acceleration vectors. Rotation is also tracked. I believe all the necessary functions are already in place.

Here are the two main behaviors behind “birds”, and a charge field simulator – Simple Orbiter 2:

Bird (or wall) Avoidance/Charge Field Repulsion.

Bird Grouping/Gravity.

Charge repulsion and gravity are opposed and in balance at all scales. Charge dominates at small scales, but it will still find its balance with gravity. "Brownian Motion" will be a real concern. Outside ambient charge sources may need to be minimized or eliminated to understand that balance. Initially, I imagine the simulation should be sized such that the “particles” are electrons. Later, mixing protons and electrons will add complexity. I’m certain that observable structures, including orbits, will develop.

The reason I’m still talking is because if it performs at all like I expect, I hope you make it your own, and include it with the rest of your work.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Sorry, Airman, I didn't mean to take over, I just find it hard to stop once I build momentum. I get an idea and I just have to run with it. I am happy that you are working on your own ideas and will incorporate them into my work when it is applicable. I wanted to get a simple framework up and running which could be used to test our math and I have fulfilled that in so far as I can at the moment. I did get a little side-tracked with animating it because once I had the planets visible, I just wanted to see them move.

I hope to be able to use many different inter-changeable math models which will allow us to see differences between the different models and to work on them independently from each other. I need to see what the math will look like before I can create such an abstract model though so we will deal with that when we get to it. I need to make sure that the bodies have all the degrees of freedom that they need for whatever math we throw at it and the current model does not do that in the right way (since it has been setup for an animation rather than motion based on velocity, etc).

I hope to be able to use many different inter-changeable math models which will allow us to see differences between the different models and to work on them independently from each other. I need to see what the math will look like before I can create such an abstract model though so we will deal with that when we get to it. I need to make sure that the bodies have all the degrees of freedom that they need for whatever math we throw at it and the current model does not do that in the right way (since it has been setup for an animation rather than motion based on velocity, etc).

**Nevyn**- Admin
- Posts : 1026

Join date : 2014-09-11

## Re: Simple Orbiter 2

Nevyn, Your burst of activity made apparent in that thread is clearly most welcome and appreciated. You’ve upsized and upgraded a long time personal project; closer to the instant when you can “throw the switch”.

My assertion is just - orbits should be simple. Finding Birds – at your suggestion - is a perfect way (I hope), to demonstrate that. Solar System and SO2 are on significantly different scales. Do particles equal planets? In a real sense perhaps they are; anyway, you said you’d blow Solar System into its constituent object dust before you’d be done with it. Alternative math solutions is a fine goal. Now I’ve just got to get my stuff together to remain an active partner.

My assertion is just - orbits should be simple. Finding Birds – at your suggestion - is a perfect way (I hope), to demonstrate that. Solar System and SO2 are on significantly different scales. Do particles equal planets? In a real sense perhaps they are; anyway, you said you’d blow Solar System into its constituent object dust before you’d be done with it. Alternative math solutions is a fine goal. Now I’ve just got to get my stuff together to remain an active partner.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Update. I’ve been reading “canvas_geometry_birds” and while I haven’t worked out all the physics details yet, none of it looks too difficult. I like vectors, and have some experience with them; nevertheless, I’ll admit I was taken aback when I visited http://www.euclideanspace.com/physics/index.html. Daunting but fun. I’ll carry on.

“Canvas_geometry_birds” comes with 200 birds and no control panel. At 2,000 birds the program stalls as much as it jerks forward. Meanwhile, “gpgpu_birds” http://threejs.org/examples/#webgl_gpgpu_birds handles 4,000+ birds with ease. I’ll switch to gpgpu_birds when I’m satisfied I understand “canvas_geometry_birds” better. I would like to see if I can find the difference.

Cameras, projection and rendering are still foreign to me. I also viewed the canvas_geometry_birds' source files: CanvasRenderer.js, Projector.js, Bird.js, stats.min.js, and of course three.min.js. Despite not knowing the great majority of what I’m looking at, Firefox developer tools, NetBeans, Notepad, a “Browser”, and of course a working program, make it easier than I would have believed possible.

Meanwhile I’m considering the basics, again and again. I’m confident, but it seems my thoughts involve n-particles and n^2 distances and accelerations. I can therefore use traditional gravity. And Charge - using positions, distances, spin directions and the “charge vector profile“ - it might be easiest to add roughly n “impulses” (including one for the ambient field) to each existing spin in each iteration. How does one add n impulses and a spin?

I think I’m working with a full, though not necessarily elegant set of ideas.

“Canvas_geometry_birds” comes with 200 birds and no control panel. At 2,000 birds the program stalls as much as it jerks forward. Meanwhile, “gpgpu_birds” http://threejs.org/examples/#webgl_gpgpu_birds handles 4,000+ birds with ease. I’ll switch to gpgpu_birds when I’m satisfied I understand “canvas_geometry_birds” better. I would like to see if I can find the difference.

Cameras, projection and rendering are still foreign to me. I also viewed the canvas_geometry_birds' source files: CanvasRenderer.js, Projector.js, Bird.js, stats.min.js, and of course three.min.js. Despite not knowing the great majority of what I’m looking at, Firefox developer tools, NetBeans, Notepad, a “Browser”, and of course a working program, make it easier than I would have believed possible.

Meanwhile I’m considering the basics, again and again. I’m confident, but it seems my thoughts involve n-particles and n^2 distances and accelerations. I can therefore use traditional gravity. And Charge - using positions, distances, spin directions and the “charge vector profile“ - it might be easiest to add roughly n “impulses” (including one for the ambient field) to each existing spin in each iteration. How does one add n impulses and a spin?

I think I’m working with a full, though not necessarily elegant set of ideas.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Another update. Submitted in an attempt to prove I'm not just wasting time - I'm also losing it.

The review of mechanics is, as usual, a source of new insights. Amazing, I wonder what that means?

I'm currently stuck at, Where's the pre-M field? What's its relative magnitude? How is that best expressed?

I don't recall if/where Miles describes pre-M field mechanics with respect to observed satellite tangential velocities. I'll keep looking.

To me it seems logical to assume that the pre-M field has its greatest influence when the "particles" are closest. And/or the pre-Mag field contribution is most outstanding when gravity and the pre-E field are in perfect balance? Miles says something similar in "Explaining the Ellipse" although there he is referring to the fact that gravity alone cannot create the observed orbits, that the repulsive 1/r4 pre-E field is also necessary to explain the ellipse.

Isn't orbital velocity independent of distance? For example, if Earth were in Jupiter's orbital position then I believe Miles said it would have the same "annual" orbital period as Jupiter. Is it then safe to say that pre-M just drives planetary spins? Perhaps spins are important mainly because as they align, they increase speed thereby increasing equatorial charge and maximize energy efficiency in the system? Are the “particles” that make up the rings of Saturn spinning?

The intent of the 2 matrices I've put together is to understand the number of data operations required, better than N this and N2 that.

Like the author of Birds/Boids, I think vectors are essential. Birds 2 didn't make any sense to me on a first read, so I'll stick with Birds/Boids despite the 200 limit. As if any speed limit can make me go faster.

I'd be fine with polar coordinates, but I suppose that threejs requires cartesian.

I appreciate the problem of “most efficient data structure” to define charge field object dust.

Please excuse the lack of formatting subsuperbold, it's in excel.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This simulation is an attempt to show the interaction between "particles" with both gravity and charge field properties.

"As it turns out, from the level of size of a quantum to a grain of sand, the E/M field swamps everything. We already knew this. From the level of size of the earth to the largest galaxies, gravity swamps everything. We already knew this, too. What we did not know until now is that from the level of size of a grain of sand up to the size of the earth, say, we have a mixture of the two, and that this mixture is expressed by Newton’s equation. Newton’s equation is not only a gravitational equation, it is a compound, and it includes both fields". (1)

That quote clearly suggests that particle sizes based on the scale of matter found in our solar system is a good place to start.

F = GMm/R2

Every point mass attracts every single other point mass by a force pointing along the line intersecting both points.

The force is proportional to the product of the two masses and inversely proportional to the square of the distance between them.

vector form -

F12 = -Gm1m2r12/|r12|2

F12 is the force applied on object 2 due to object 1

G is the gravitational constant: 6.673×10−11 N · (m/kg)2

m1 and m2 are respectively the masses of objects 1 and 2

|r12| = |r2 − r1| is the distance between objects 1 and 2.

r12 = (r2 - r1)/|r2 - r1| is the unit vector from object 1 to 2.

It can be seen that the vector form of the equation is the same as the scalar form given earlier, except that F is now a vector quantity, and the right hand side is multiplied by the appropriate unit vector. Also, it can be seen that F12 = −F21.

Attraction is only apparent. Newton invented the mass variable. But the variable definition hides a real physical field.

"Maxwell showed how mass is L3/T2, and that looks just like a 3-D acceleration to me. So I treat it just like an acceleration". (2)

Decomposing mass into volume and density results in two separate fields.

Gravity is a three-dimensional acceleration depending on volume alone.

The E/M Charge Field is emitted by each particles' "density", and falls off as 1/R2.

The E/M fields prevent particles from actually coming into contact.

Charge and gravity are diametrically opposed.

" Before: gravity is 1/R2 and E/M is 1/R2

After: gravity is 1/R and E/M is 1/R4 ". (3)

H = m(A + a) “Define H as the amount of force necessary to offset Gravity.

Now, if we subtract that from Newton’s equation, we should find an electromagnetic field equation.

F = GMm/R2

E = F – H

E = [GMm/R2 ] – [m(A + a)]

E = (m/R2 )[GM – AR2 – aR2] E/M field equation

H = m(a + A + 2AR/ct ) Relativistic gravitational equation

E = (GmM/R2 )(1 – 2R/ct ) – m(a + A + 2AR/ct )

Relativistic E/M field equation

Now let us re-unify the field.

F = E + H

F = (GmM/R2 )(1 – 2R/ct )

F = (GmM/R2) – (2GmM/Rct ) New Relativistic Unified Field Equation”. (2)

"This makes it quite easy to find the strength of the field. We simply calculate the small ball as a fraction of the earth.

6,378,000/.0254 = 9.815/a

a1 = 3.91 x 10-8m/s2

F = ma = .732a = 2.86 x 10-8kgm/s2 “. (1)

continued.

The review of mechanics is, as usual, a source of new insights. Amazing, I wonder what that means?

I'm currently stuck at, Where's the pre-M field? What's its relative magnitude? How is that best expressed?

I don't recall if/where Miles describes pre-M field mechanics with respect to observed satellite tangential velocities. I'll keep looking.

To me it seems logical to assume that the pre-M field has its greatest influence when the "particles" are closest. And/or the pre-Mag field contribution is most outstanding when gravity and the pre-E field are in perfect balance? Miles says something similar in "Explaining the Ellipse" although there he is referring to the fact that gravity alone cannot create the observed orbits, that the repulsive 1/r4 pre-E field is also necessary to explain the ellipse.

Isn't orbital velocity independent of distance? For example, if Earth were in Jupiter's orbital position then I believe Miles said it would have the same "annual" orbital period as Jupiter. Is it then safe to say that pre-M just drives planetary spins? Perhaps spins are important mainly because as they align, they increase speed thereby increasing equatorial charge and maximize energy efficiency in the system? Are the “particles” that make up the rings of Saturn spinning?

The intent of the 2 matrices I've put together is to understand the number of data operations required, better than N this and N2 that.

Like the author of Birds/Boids, I think vectors are essential. Birds 2 didn't make any sense to me on a first read, so I'll stick with Birds/Boids despite the 200 limit. As if any speed limit can make me go faster.

I'd be fine with polar coordinates, but I suppose that threejs requires cartesian.

I appreciate the problem of “most efficient data structure” to define charge field object dust.

Please excuse the lack of formatting subsuperbold, it's in excel.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

**Particle Gravity/Charge Interaction Simulator**This simulation is an attempt to show the interaction between "particles" with both gravity and charge field properties.

"As it turns out, from the level of size of a quantum to a grain of sand, the E/M field swamps everything. We already knew this. From the level of size of the earth to the largest galaxies, gravity swamps everything. We already knew this, too. What we did not know until now is that from the level of size of a grain of sand up to the size of the earth, say, we have a mixture of the two, and that this mixture is expressed by Newton’s equation. Newton’s equation is not only a gravitational equation, it is a compound, and it includes both fields". (1)

That quote clearly suggests that particle sizes based on the scale of matter found in our solar system is a good place to start.

**Traditional Gravity**(4)F = GMm/R2

Every point mass attracts every single other point mass by a force pointing along the line intersecting both points.

The force is proportional to the product of the two masses and inversely proportional to the square of the distance between them.

vector form -

F12 = -Gm1m2r12/|r12|2

F12 is the force applied on object 2 due to object 1

G is the gravitational constant: 6.673×10−11 N · (m/kg)2

m1 and m2 are respectively the masses of objects 1 and 2

|r12| = |r2 − r1| is the distance between objects 1 and 2.

r12 = (r2 - r1)/|r2 - r1| is the unit vector from object 1 to 2.

It can be seen that the vector form of the equation is the same as the scalar form given earlier, except that F is now a vector quantity, and the right hand side is multiplied by the appropriate unit vector. Also, it can be seen that F12 = −F21.

**Unified Field Charge and Gravity**Attraction is only apparent. Newton invented the mass variable. But the variable definition hides a real physical field.

"Maxwell showed how mass is L3/T2, and that looks just like a 3-D acceleration to me. So I treat it just like an acceleration". (2)

Decomposing mass into volume and density results in two separate fields.

Gravity is a three-dimensional acceleration depending on volume alone.

The E/M Charge Field is emitted by each particles' "density", and falls off as 1/R2.

The E/M fields prevent particles from actually coming into contact.

Charge and gravity are diametrically opposed.

" Before: gravity is 1/R2 and E/M is 1/R2

After: gravity is 1/R and E/M is 1/R4 ". (3)

H = m(A + a) “Define H as the amount of force necessary to offset Gravity.

Now, if we subtract that from Newton’s equation, we should find an electromagnetic field equation.

F = GMm/R2

E = F – H

E = [GMm/R2 ] – [m(A + a)]

E = (m/R2 )[GM – AR2 – aR2] E/M field equation

H = m(a + A + 2AR/ct ) Relativistic gravitational equation

E = (GmM/R2 )(1 – 2R/ct ) – m(a + A + 2AR/ct )

Relativistic E/M field equation

Now let us re-unify the field.

F = E + H

F = (GmM/R2 )(1 – 2R/ct )

F = (GmM/R2) – (2GmM/Rct ) New Relativistic Unified Field Equation”. (2)

"This makes it quite easy to find the strength of the field. We simply calculate the small ball as a fraction of the earth.

6,378,000/.0254 = 9.815/a

a1 = 3.91 x 10-8m/s2

F = ma = .732a = 2.86 x 10-8kgm/s2 “. (1)

continued.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

**Under Construction**

N Charge Particles

density: m1, m2, m3, …, mN m1

volume: n1, n2, n3, …, rN n1

Generate Particles

Position Vector P a1

P = aX + bY + cZ b1

ie. P 1 = a1X + b1Y + c1Z c1

Velocity Vector V d1

V = dX + eY + fZ e1

ie. V5 = d5X + e5Y + f5Z f1

Acceleration Vector A g1

A = gX + hY + iZ h1

I1

Spin Axis Vector j1

S = jX + kY k1

Tangential Velocity l1

**Distance and Direction**

D Vector

Distance(ab) = Mag(Pa - Pb)

Direction(ab) = Dir(Pa - Pb)

# calcs ea = (N-1)N/2

Note. Dab = -Dba

Accelerations

A = gX + hY + iZ

Each iteration initially :

A = 0X + 0Y + 0Z

Add (N-1)(N/2)

A1 = A1 + G1 + E1

References include:

1) The Cavendish Experiment. http://milesmathis.com/caven.html

2) The Unified Field Theory http://milesmathis.com/uft.html

3) The Solution to Tides Part 1 http://milesmathis.com/tide2.html

4) Traditional Gravity, and definition table format – taken from Wikipedia “Newton's law of universal gravitation”

https://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Another Update.

This week I reviewed:

(5) The Cause of Axial Tilt Part 1 http://milesmathis.com/tilt.html.

(6) The Charge Field causes Lagrange Points http://milesmathis.com/lagrange2.html.

(7) How to calculate the eccentricity of the Earth Using the Charge Field http://milesmathis.com/eccen.html.

( The Magnetopause calculated by the Unified Field http://milesmathis.com/pause.html

Next on my list:

Bode's Law http://milesmathis.com/bode.html

I’ve started copying Miles’ math from these papers into excel to understand his examples and mess with the numbers.

Some details:

- I’ve expanded my reference table.

- OK, OK, The drop-off of the E/M field is 1/R4.

- I finally figured out Miles’s description of the channeling behavior of planetary E/M energy approaching the sun, which increases as R.

- I forget exactly where, above, I read, “there aren’t any formulas, just mechanics”.

Spin. The spin axis, tilt, is a perturbation. Miles shows that in planetary orbits, the planet’s tilt reflects the charge field influence of the Sun (the overwhelming majority) on the one side, and the outer planets on the other. It is not a question of matter or anti-matter though I can see how it may factor in the calculation.

Mercury’s tilt, close to zero, displays an overwhelming imbalance of the Sun’s influence. Uranus’ near 90o degree tilt indicates the influence of Neptune. Again, explained to some extent, by Neptune’s solar directed charge channel perturbing Uranus. That tilt is directed toward maximizing charge reception of the planet.

That's all I think I see about "spin".

Is the spin rate, or "day", important? Easy answer, I think I'll ignore it for the present.

Any comment, agreement or discussion?

I would like put together a list of planetary and satellite data. Maybe one of you have a spare table, or directions to one?

This week I reviewed:

(5) The Cause of Axial Tilt Part 1 http://milesmathis.com/tilt.html.

(6) The Charge Field causes Lagrange Points http://milesmathis.com/lagrange2.html.

(7) How to calculate the eccentricity of the Earth Using the Charge Field http://milesmathis.com/eccen.html.

( The Magnetopause calculated by the Unified Field http://milesmathis.com/pause.html

Next on my list:

Bode's Law http://milesmathis.com/bode.html

I’ve started copying Miles’ math from these papers into excel to understand his examples and mess with the numbers.

Some details:

- I’ve expanded my reference table.

- OK, OK, The drop-off of the E/M field is 1/R4.

- I finally figured out Miles’s description of the channeling behavior of planetary E/M energy approaching the sun, which increases as R.

- I forget exactly where, above, I read, “there aren’t any formulas, just mechanics”.

From (5). The first thing we see is that we have four planets within a few percentage points of one another. The Earth, Mars, Saturn, and Neptune all have similar tilts. That is unlikely to be a coincidence. If we measure those four tilts relative to the Sun's equator, instead of relative to their individual orbits, the numbers are even closer, being 30.55, 30.65, 31.51, and 34.4. Another big clue is Mercury, with no tilt. And the final big clue is Uranus, with a near 90o degree tilt.

Spin. The spin axis, tilt, is a perturbation. Miles shows that in planetary orbits, the planet’s tilt reflects the charge field influence of the Sun (the overwhelming majority) on the one side, and the outer planets on the other. It is not a question of matter or anti-matter though I can see how it may factor in the calculation.

Mercury’s tilt, close to zero, displays an overwhelming imbalance of the Sun’s influence. Uranus’ near 90o degree tilt indicates the influence of Neptune. Again, explained to some extent, by Neptune’s solar directed charge channel perturbing Uranus. That tilt is directed toward maximizing charge reception of the planet.

That's all I think I see about "spin".

Is the spin rate, or "day", important? Easy answer, I think I'll ignore it for the present.

Any comment, agreement or discussion?

I would like put together a list of planetary and satellite data. Maybe one of you have a spare table, or directions to one?

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

This is where I got most of my planet data from. You can get moon data from the links in that page. Note that this is all based on mainstream assumptions and has been calculated from those assumptions.

**Nevyn**- Admin
- Posts : 1026

Join date : 2014-09-11

## Re: Simple Orbiter 2

Project Update.

Main docs reviewed:

- (9) Bode's Law http://milesmathis.com/bode.html

- (10) A Mathematical Explanation of the Orbital Distance of Mercury http://milesmathis.com/orbit.html. Miles recommends that we understand how to calculate charge emissions using surface differentials, it changes going up or down in size, but I don’t think I need it for this project. Also, a = v2/r, orbital velocity, was the historical basis for determining gravitational fields, erroneously. We can use all the old data if we understand the mechanics.

- NASA Planetary Factsheet.

- canvas_geometry_birds.html.

- Three.js.

I’m happy to report that I’m comfortable with the physics, and have started working on the code.

Bird objects are primarily position and velocity vectors, with some choice accelerations added to the velocity. What I thought were rotations are actually bird image direction calculations based on the velocity vector. Particles, in addition to position and velocity also include gravity, charge and spin.

Particles has a greater computational load.

No excuses, just thinking.

Main docs reviewed:

- (9) Bode's Law http://milesmathis.com/bode.html

- (10) A Mathematical Explanation of the Orbital Distance of Mercury http://milesmathis.com/orbit.html. Miles recommends that we understand how to calculate charge emissions using surface differentials, it changes going up or down in size, but I don’t think I need it for this project. Also, a = v2/r, orbital velocity, was the historical basis for determining gravitational fields, erroneously. We can use all the old data if we understand the mechanics.

- NASA Planetary Factsheet.

- canvas_geometry_birds.html.

- Three.js.

I’m happy to report that I’m comfortable with the physics, and have started working on the code.

Bird objects are primarily position and velocity vectors, with some choice accelerations added to the velocity. What I thought were rotations are actually bird image direction calculations based on the velocity vector. Particles, in addition to position and velocity also include gravity, charge and spin.

Particles has a greater computational load.

No excuses, just thinking.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

My my, it’s alive, please have a cigar. I’m a little giddy.

I don’t have spin yet, but there are several interesting behaviors.

I think I saw sparks! large numbers of particles tightly cycling/collapsing into a small volume. Small numbers of particles result in stable, though effectively unpredictable interactions. With the walls active (a complex ambient charge environment not as sexy as a torus) the particles formed strange “resonant” groups of cycling particles in a lattice geometry I couldn’t quite make out – maybe it’s just s/w magic.

I went for the minimum, converting birds by:

1. Adding the function this.gravAndChargeRepulsion.

this.gravAndChargeRepulsion = function ( boids ) {

var boid, distance, grav, char, distance4, diff,

magAndDir = new THREE.Vector3(),

totalAcceleration = new THREE.Vector3();

for ( var i = 0, il = boids.length; i < il; i ++ ) {

boid = boids[ i ];

distance = boid.position.distanceTo( this.position );

if ( distance > 0) {

magAndDir.set( 0, 0, 0 );

grav = boid.gravity / distance;

distance4 = (distance * distance * distance * distance);

char = boid.charge / distance4;

diff = 1/ (grav - char);

magAndDir.subVectors(boid.position,this.position );

magAndDir.normalize();

magAndDir.divideScalar( diff );

totalAcceleration.add( magAndDir );

}

}

return totalAcceleration;

};

2. I also commented out the prior programmed acceleration function calls (such as cohesion, repulsion, and alignment), and generally turn-off wall-avoidance. Everything else still works, such as onDocumentMouseMove.

3. Each boid now has gravity and charge properties generated during initialization.

I’ll be happy to send the whole thing to ya.

This thing’s got potential, and I need to include some additional functionality to do it justice

I don’t have spin yet, but there are several interesting behaviors.

I think I saw sparks! large numbers of particles tightly cycling/collapsing into a small volume. Small numbers of particles result in stable, though effectively unpredictable interactions. With the walls active (a complex ambient charge environment not as sexy as a torus) the particles formed strange “resonant” groups of cycling particles in a lattice geometry I couldn’t quite make out – maybe it’s just s/w magic.

I went for the minimum, converting birds by:

1. Adding the function this.gravAndChargeRepulsion.

this.gravAndChargeRepulsion = function ( boids ) {

var boid, distance, grav, char, distance4, diff,

magAndDir = new THREE.Vector3(),

totalAcceleration = new THREE.Vector3();

for ( var i = 0, il = boids.length; i < il; i ++ ) {

boid = boids[ i ];

distance = boid.position.distanceTo( this.position );

if ( distance > 0) {

magAndDir.set( 0, 0, 0 );

grav = boid.gravity / distance;

distance4 = (distance * distance * distance * distance);

char = boid.charge / distance4;

diff = 1/ (grav - char);

magAndDir.subVectors(boid.position,this.position );

magAndDir.normalize();

magAndDir.divideScalar( diff );

totalAcceleration.add( magAndDir );

}

}

return totalAcceleration;

};

2. I also commented out the prior programmed acceleration function calls (such as cohesion, repulsion, and alignment), and generally turn-off wall-avoidance. Everything else still works, such as onDocumentMouseMove.

3. Each boid now has gravity and charge properties generated during initialization.

I’ll be happy to send the whole thing to ya.

This thing’s got potential, and I need to include some additional functionality to do it justice

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

It's fun to play with the variables.

Problems?

Just as there is a three-in-a-line special rule for charge, Shouldn’t there be one for gravity too?

If we have two particles close together, and a third particle further away. Can we add the two gravities together if they appear in a line from the third particle? Expansion leads me to think not; I’ve probably over-represented gravity, especially when there are large numbers of particles.

I was worried that in some dt two particles would pass through each other, and generate large charge velocities, but I haven't observed that. But it's still wrong to have no collisions.

What about inertia? I don't think I have any. So the particles simulate an almost instantaneous response.

Just enough to temper my giddiness.

Problems?

Just as there is a three-in-a-line special rule for charge, Shouldn’t there be one for gravity too?

If we have two particles close together, and a third particle further away. Can we add the two gravities together if they appear in a line from the third particle? Expansion leads me to think not; I’ve probably over-represented gravity, especially when there are large numbers of particles.

I was worried that in some dt two particles would pass through each other, and generate large charge velocities, but I haven't observed that. But it's still wrong to have no collisions.

What about inertia? I don't think I have any. So the particles simulate an almost instantaneous response.

Just enough to temper my giddiness.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

A small change has improved performance.

grav = grav / (boids.length - 1);. Now any number of charge particles are stable. At 1,000 boids, things really slow down, but the collapsing "issue" is gone. Using wall avoidance, and the mouse pointer, it's easy to to create lava lamp type wave patterns that continue to bounce for as long as I observed them.

magAndDir.set( 0, 0, 0 );

grav = boid.gravity / distance;

grav = grav / (boids.length - 1);

// Trying to correct for expanding gravity;

distance4 = (distance * distance * distance * distance);

char = boid.charge / distance4;

diff = 1/ (grav - char); magAndDir.subVectors(boid.position,this.position );

magAndDir.normalize();

magAndDir.divideScalar( diff );

totalAcceleration.add( magAndDir );

Spins aside, I am real partial to include collisions, and am looking for a workable solution.

Needs list: Panel, meta=data, no-walls but always view the moving particle volume center.

I need to let it sit for a while.

grav = grav / (boids.length - 1);. Now any number of charge particles are stable. At 1,000 boids, things really slow down, but the collapsing "issue" is gone. Using wall avoidance, and the mouse pointer, it's easy to to create lava lamp type wave patterns that continue to bounce for as long as I observed them.

magAndDir.set( 0, 0, 0 );

grav = boid.gravity / distance;

grav = grav / (boids.length - 1);

// Trying to correct for expanding gravity;

distance4 = (distance * distance * distance * distance);

char = boid.charge / distance4;

diff = 1/ (grav - char); magAndDir.subVectors(boid.position,this.position );

magAndDir.normalize();

magAndDir.divideScalar( diff );

totalAcceleration.add( magAndDir );

Spins aside, I am real partial to include collisions, and am looking for a workable solution.

Needs list: Panel, meta=data, no-walls but always view the moving particle volume center.

I need to let it sit for a while.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

OK, ... The main spin constraint.

160. Birkeland Currents. I show that these currents must pass through the Earth. 11pp. http://milesmathis.com/birke.pdf

and

Begging your opinion, What do you think of this? (I hope I'm not back-engineering anything I shouldn't.)

160. Birkeland Currents. I show that these currents must pass through the Earth. 11pp. http://milesmathis.com/birke.pdf

We have had B, H and M, and a mess of equations relating them to one another. But since I have been able to detach D from the E/M field equations, assigning it instead to the charge field (which is a field of real photons), I have been able to clarify many problems, including now this one. The D field is both submagnetic and subelectrical, since it supports and defines them both, but it is strictly equivalent to neither. It is determined by moving photons, ...

and

Whatever the direction of the actual B-field is—and it will vary with latitude—will depend on the summed spin of the charge coming up, not on the direction of current. In short, we have a crossing of charge from both poles at the equator, and about 1/3rd of that charge is antiphotons. So to draw the fields, we sum the spins at that latitude and altitude; we don't back-engineer the B-field from E or F.

Begging your opinion, What do you think of this? (I hope I'm not back-engineering anything I shouldn't.)

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Now it’s stable with just two boids.

It includes tangential acceleration, using the sin of 2x the angle as I mentioned in my last comment. I'm sure I'm not using it correctly.

Overlap - resulting in large velocities is still a problem with very large numbers, to a small amount, but all distances are checked, so I’ve been hitting my old physics books and trying to get a handle on rotational and collision mechanics (Thanks guys).

this.gravAndChargeRepulsion = function ( boids ) {

var boid,

magAndDir = new THREE.Vector3(),

tanAcceleration = new THREE.Vector3(),

totalAcceleration = new THREE.Vector3();

totalAcceleration.set( 0, 0, 0 );

for ( var i = 0, il = boids.length; i < il; i ++ ) {

boid = boids[ i ];

distance = boid.position.distanceTo( this.position );

// ////////NOTE////////

// if ( distance > 0.001) and ( distance <1 ){

// COLLISION }

if ( distance > 0.001) {

magAndDir.subVectors(boid.position,this.position );

magAndDir.normalize();

theta = boid.spinAxis.angleTo(magAndDir);

char = boid.charge * Math.sin( 2 * theta);

grav = boid.gravity / distance;

grav = grav / (boids.length - 1);

distance4 = (distance * distance * distance * distance);

char = char / distance4;

magAndDir.multiplyScalar(grav - char);

totalAcceleration.add( magAndDir );

magAndDir.multiplyScalar(-1);

tanAcceleration.crossVectors( boid.spinAxis, magAndDir );

tanAcceleration.normalize();

tanAcceleration.multiplyScalar(char);

totalAcceleration.add( tanAcceleration );

}

}

return totalAcceleration;

};

I still need to dig into Bird’s position, velocity, acceleration and phase structure. Walls embarrass me. Plenty to do.

Here’s part of the Boid initialization.

birds = [];

boids = [];

for ( var i = 0; i < 2; i ++ ) {

boid = boids[ i ] = new Boid();

boid.position.x = Math.random() * 400 - 200;

boid.position.y = Math.random() * 400 - 200;

boid.position.z = Math.random() * 400 - 200;

boid.velocity.x = Math.random() * 2 - 1;

boid.velocity.y = Math.random() * 2 - 1;

boid.velocity.z = Math.random() * 2 - 1;

boid.setAvoidWalls( true );

boid.setWorldSize( 400, 400, 320 );

boid.charge = 1;

boid.gravity = 1;

boid.spinAxis = new THREE.Vector3();

boid.spinAxis.x = Math.random() * 2 - 1;

boid.spinAxis.y = Math.random() * 2 - 1;

boid.spinAxis.z = Math.random() * 2 - 1;

boid.spinAxis.normalize();

bird = birds[ i ] = new THREE.Mesh( new Bird(), new THREE.MeshBasicMaterial( { color:Math.random() * 0xffffff, side: THREE.DoubleSide } ) );

bird.phase = Math.floor( Math.random() * 62.83 );

scene.add( bird );

}

That's all for now!

It includes tangential acceleration, using the sin of 2x the angle as I mentioned in my last comment. I'm sure I'm not using it correctly.

Overlap - resulting in large velocities is still a problem with very large numbers, to a small amount, but all distances are checked, so I’ve been hitting my old physics books and trying to get a handle on rotational and collision mechanics (Thanks guys).

this.gravAndChargeRepulsion = function ( boids ) {

var boid,

magAndDir = new THREE.Vector3(),

tanAcceleration = new THREE.Vector3(),

totalAcceleration = new THREE.Vector3();

totalAcceleration.set( 0, 0, 0 );

for ( var i = 0, il = boids.length; i < il; i ++ ) {

boid = boids[ i ];

distance = boid.position.distanceTo( this.position );

// ////////NOTE////////

// if ( distance > 0.001) and ( distance <1 ){

// COLLISION }

if ( distance > 0.001) {

magAndDir.subVectors(boid.position,this.position );

magAndDir.normalize();

theta = boid.spinAxis.angleTo(magAndDir);

char = boid.charge * Math.sin( 2 * theta);

grav = boid.gravity / distance;

grav = grav / (boids.length - 1);

distance4 = (distance * distance * distance * distance);

char = char / distance4;

magAndDir.multiplyScalar(grav - char);

totalAcceleration.add( magAndDir );

magAndDir.multiplyScalar(-1);

tanAcceleration.crossVectors( boid.spinAxis, magAndDir );

tanAcceleration.normalize();

tanAcceleration.multiplyScalar(char);

totalAcceleration.add( tanAcceleration );

}

}

return totalAcceleration;

};

I still need to dig into Bird’s position, velocity, acceleration and phase structure. Walls embarrass me. Plenty to do.

Here’s part of the Boid initialization.

birds = [];

boids = [];

for ( var i = 0; i < 2; i ++ ) {

boid = boids[ i ] = new Boid();

boid.position.x = Math.random() * 400 - 200;

boid.position.y = Math.random() * 400 - 200;

boid.position.z = Math.random() * 400 - 200;

boid.velocity.x = Math.random() * 2 - 1;

boid.velocity.y = Math.random() * 2 - 1;

boid.velocity.z = Math.random() * 2 - 1;

boid.setAvoidWalls( true );

boid.setWorldSize( 400, 400, 320 );

boid.charge = 1;

boid.gravity = 1;

boid.spinAxis = new THREE.Vector3();

boid.spinAxis.x = Math.random() * 2 - 1;

boid.spinAxis.y = Math.random() * 2 - 1;

boid.spinAxis.z = Math.random() * 2 - 1;

boid.spinAxis.normalize();

bird = birds[ i ] = new THREE.Mesh( new Bird(), new THREE.MeshBasicMaterial( { color:Math.random() * 0xffffff, side: THREE.DoubleSide } ) );

bird.phase = Math.floor( Math.random() * 62.83 );

scene.add( bird );

}

That's all for now!

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Hey Guys, I’m still fully occupied with boids. Also studying webgl_gpgpu_birds. I’ve got a control panel (but no variables hooked up to it)! Notes with spins, collisions, and close interactions; relating angular versus linear motion. Still wobbly.

This plot is supposed to show the line-of-sight repulsion given Gravity and Charge. I’ve been treating my boids as point objects, but if my object is actually on the order of 1 (whatever unit), then the boid’s unified field is still dominated by gravity (?). Large~~accelerations~~ velocities can be generated by a nearby boid’s gravity alone.

I guess that when we work with same scale objects – say a large number of equally sized boids, there really isn’t a balance point between gravity and charge. The balance is more between boid velocity and gravity. For the moment, it seems to me we need very large along with very small, so that the balance point will be located outside the largest object.

.

This plot is supposed to show the line-of-sight repulsion given Gravity and Charge. I’ve been treating my boids as point objects, but if my object is actually on the order of 1 (whatever unit), then the boid’s unified field is still dominated by gravity (?). Large

I guess that when we work with same scale objects – say a large number of equally sized boids, there really isn’t a balance point between gravity and charge. The balance is more between boid velocity and gravity. For the moment, it seems to me we need very large along with very small, so that the balance point will be located outside the largest object.

.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Nice work with the framework and the boids LTAM. I'm really "awed" you've come this far this fast.

**Cr6**- Admin
- Posts : 956

Join date : 2014-08-09

## Re: Simple Orbiter 2

Hi Cr6, Thanks, but Nevyn told me to start studying Java last year. Actually, I’ve always been here and now. One of those divine moments. I’m stuck.

Periapsis, that moment when the charge field’s relative influence is maximum. Normally, the spin axis acts gyroscopically. The particle can travel in any direction, but it resists axis orientation changes. I imagine, at periapsis, the spin axis orientation rate of change is greatest. One can see how spin axii are being tugged at all the time. But how does the spin orientation change anything?

So Miles has clarified my question. How can I transfer energy between the spin, and linear velocity?

Can it be just “resisting E/M field torque”?

Repeating

This paragraph sounds like explicit instructions that I’m too thick to see. Throw a curve ball.

.

Seveneves. Good old-fashioned, technically accurate, science fiction. Support your local library.Neal Stephenson wrote:Any curve you could make by slicing a cone with a plane-A circle, an ellipse, or a hyperbola-could be the shape of an orbit. For practical purposes, though, all orbits were ellipses. And most of the naturally occurring orbits in the solar system-those of the planets around the sun, or of moons around planets-were ellipses so round as to be indistinguishable, by the naked eye, from circles. This was not because nature especially favored circles. It was because highly elongated elliptical orbits tended not to last for very long. As a body in a highly eccentric orbit went rocketing in toward the central body and executed a hairpin turn at the periapsis-the point of closest approach-it was subject to tidal forces that could break it up.

Periapsis, that moment when the charge field’s relative influence is maximum. Normally, the spin axis acts gyroscopically. The particle can travel in any direction, but it resists axis orientation changes. I imagine, at periapsis, the spin axis orientation rate of change is greatest. One can see how spin axii are being tugged at all the time. But how does the spin orientation change anything?

174. The Third Wave: a Redefinition of Gravity, Part IV. Retrograde orbits, Triton, and the lack of angular momentum in the Sun are explained. 10pp. http://milesmathis.com/third4.htmlMiles wrote:Now let's return to my theory. There are two possibilities, neither of which is contradicted by data. I will offer the first one as the more likely. Let us say that the torque from Neptune works preferentially on the spin of Triton and not the velocity. In this case it would never appreciably affect the orbital momentum of Triton since Triton is so large. It might only affect the angular momentum, which decreases the energy of Triton's E/M field relative to Neptune's E/M field. In this way Triton loses energy but does not lose speed or radius. If this is the case, then we only have to look at the spin of Triton. Once the spin of Triton is stopped by Neptune, it must begin to reverse, since the torque from Neptune is constant. Eventually Triton will gain enough energy to create its own torque against the field of Neptune. At some point this torque will be sufficient to create a slight addition to orbital velocity, at which time Triton will bump itself into a higher orbit. The affect will become additive and eventually Triton will escape.

You may ask how a more energetic Triton turns that energy into orbital velocity. It does so with that resisting E/M field torque. That torque will have a component that is parallel to the orbit of Triton, and this must increase the orbital velocity. Even if we give the torque preferentially to the spin, there must be some point at which this preferential treatment breaks down. That is, once Triton gains some given amount of angular momentum, the torque can no longer be given to spin, preference or no. At that point the tangential component of the torque will begin affecting the velocity.

This would explain why major satellites do not impact their primaries. It would also explain why Triton's orbit decays so slowly.

The second possibility is a bit more revolutionary, but once again I believe it is capable of explaining more than current theory. Scientists know that Triton's retrograde orbit is decaying. They extrapolate from this to the assumption that it will eventually collide with Neptune. This, however, is a baseless assumption. It is true that Triton's orbit is decaying and that this decay is due to the fact that the orbit is losing energy. But there may be a limit to this decay. It is just possible that Triton's orbital velocity and spin will someday stop altogether, but that it will remain in orbit nonetheless, held at bay momentarily at its minimum orbital distance by the E/M field of Neptune. The field will keep applying a tangential torque to Triton—the same torque that made it lose energy—and it will begin gaining energy again. It will turn around and start orbiting in the opposite direction. It will move out into higher orbits until it reaches some kind of equilibrium with the E/M field of Neptune, at which time it will be a normal satellite in prograde, stable orbit.

So Miles has clarified my question. How can I transfer energy between the spin, and linear velocity?

Can it be just “resisting E/M field torque”?

Repeating

Miles wrote:That torque will have a component that is parallel to the orbit of Triton, and this must increase the orbital velocity. Even if we give the torque preferentially to the spin, there must be some point at which this preferential treatment breaks down. That is, once Triton gains some given amount of angular momentum, the torque can no longer be given to spin, preference or no. At that point the tangential component of the torque will begin affecting the velocity.

This paragraph sounds like explicit instructions that I’m too thick to see. Throw a curve ball.

.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Open up my Proton Charge Viewer and think of the proton as the sun, or planet in this case, and the charge is, well, charge. Imagine a moon in between you and the central body and how the charge will affect that moon. It is the spin of the charge that is providing the tangential velocity.

Let's start with a few solidly placed vectors. The main vector is from the central body to the orbiting body. The tangential velocity vector of the moon is relative to the main vector. That is what it is tangential to. The charge of interest, that is, it hits our moon, is generally coming along the main vector, for simplicity. The sum of the spin components of that charge gives us a tangential force vector that we use to determine the applied force on the moon which can affect either its velocity or its spin. I would stick to velocity to start with.

Miles is saying that Triton has a velocity that opposes the tangential force vector, so it will lose energy. Eventually, it will reach zero and then, since that force is still there, it will start to gain energy in the direction of the tangential force vector.

This leads me to make some speculations:

The sum of spin on the charge photons can sum to zero. The tangential force vector would then be zero and provide no tangential velocity to any orbiting bodies. Our solar system has a 2:1 ratio of photons to anti-photons so it does not sum to zero. Are there solar systems that do not orbit but just sort of sit there as deep into the charge field of their star as possible? Would all of the planets cause each other to move based on their charge interactions?

If the tangential force is caused by an imbalance of charge to anti-charge, then the force is applied at either the top or the bottom of the orbiting body, not over its complete shell. This is not a nice clean push sideways. I think it would cause spin to a stationary orbiter. Therefore, the existing axial spin of the orbiter resists that spin and applies it as a torque to the whole body. That is, part of the force is used up working against the axial spin and the other part is allowed to express itself so the result is a sideways force.

The axial spin must be driven or it would soon stop. I think the axial spin is caused by the charge flowing through the orbiting body (north/south through-charge). Therefore the charge is working against itself (not the exact same photon but the mass of charge effecting the orbiter at a given time). This may result as heat and help explain the internal and external heat of planets.

The problem you face is how to calculate this stuff. It isn't easy and it's heavy with math. That's the joy and misery of programming, you have to fill in the gaps, you need all of the details. Focus on the vectors you have, what they represent and how they relate to the others. Then you might be able to see what you need to do with them to find the data you want. Draw them on a piece of paper, too, it really helps.

Let's start with a few solidly placed vectors. The main vector is from the central body to the orbiting body. The tangential velocity vector of the moon is relative to the main vector. That is what it is tangential to. The charge of interest, that is, it hits our moon, is generally coming along the main vector, for simplicity. The sum of the spin components of that charge gives us a tangential force vector that we use to determine the applied force on the moon which can affect either its velocity or its spin. I would stick to velocity to start with.

Miles is saying that Triton has a velocity that opposes the tangential force vector, so it will lose energy. Eventually, it will reach zero and then, since that force is still there, it will start to gain energy in the direction of the tangential force vector.

This leads me to make some speculations:

The sum of spin on the charge photons can sum to zero. The tangential force vector would then be zero and provide no tangential velocity to any orbiting bodies. Our solar system has a 2:1 ratio of photons to anti-photons so it does not sum to zero. Are there solar systems that do not orbit but just sort of sit there as deep into the charge field of their star as possible? Would all of the planets cause each other to move based on their charge interactions?

If the tangential force is caused by an imbalance of charge to anti-charge, then the force is applied at either the top or the bottom of the orbiting body, not over its complete shell. This is not a nice clean push sideways. I think it would cause spin to a stationary orbiter. Therefore, the existing axial spin of the orbiter resists that spin and applies it as a torque to the whole body. That is, part of the force is used up working against the axial spin and the other part is allowed to express itself so the result is a sideways force.

The axial spin must be driven or it would soon stop. I think the axial spin is caused by the charge flowing through the orbiting body (north/south through-charge). Therefore the charge is working against itself (not the exact same photon but the mass of charge effecting the orbiter at a given time). This may result as heat and help explain the internal and external heat of planets.

The problem you face is how to calculate this stuff. It isn't easy and it's heavy with math. That's the joy and misery of programming, you have to fill in the gaps, you need all of the details. Focus on the vectors you have, what they represent and how they relate to the others. Then you might be able to see what you need to do with them to find the data you want. Draw them on a piece of paper, too, it really helps.

**Nevyn**- Admin
- Posts : 1026

Join date : 2014-09-11

## Re: Simple Orbiter 2

Chalk up a benchmark for SO2. I’ve included a working menu, (copied from webgl_gpgpu_birdsbirds)! Just like a finished working program.

As I’ve mentioned earlier, I have a slow/stable vs fast/chaotic simulation, depending on the number of particles, and gravity. After logging several hours of observation, trying to balance the two, I found the following relationship:

// # gravity

// 2 4

// 3 2.67

// 4 2

// 8 1

// 16 0.5

// 32 0.25

// 64 0.125

// 128 0.0625

// 256 0.03125

#*gravity =8

The relationship seems clear. I cannot just double the number of particles and keep the individual g values the same - high velocities, explosive collapses and spinouts are the result. The behavior may not be entirely inappropriate. But it clearly doesn't make sense to add x expansion fields directly. Tell me I'm wrong since this slows things down and gives me the 256 limit. Eventually I will try to try to model physical expansion more directly. Plenty to do.

Nevyn, Thanks for your previous post. You shared several points that beg consideration and discussion. Let me get back to that when I include spin.

.

As I’ve mentioned earlier, I have a slow/stable vs fast/chaotic simulation, depending on the number of particles, and gravity. After logging several hours of observation, trying to balance the two, I found the following relationship:

// # gravity

// 2 4

// 3 2.67

// 4 2

// 8 1

// 16 0.5

// 32 0.25

// 64 0.125

// 128 0.0625

// 256 0.03125

#*gravity =8

The relationship seems clear. I cannot just double the number of particles and keep the individual g values the same - high velocities, explosive collapses and spinouts are the result. The behavior may not be entirely inappropriate. But it clearly doesn't make sense to add x expansion fields directly. Tell me I'm wrong since this slows things down and gives me the 256 limit. Eventually I will try to try to model physical expansion more directly. Plenty to do.

Nevyn, Thanks for your previous post. You shared several points that beg consideration and discussion. Let me get back to that when I include spin.

.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Another milestone, of sorts. I completed a run through of “Interactive 3D Graphics”, a http://threejs.org/ featured, free class put together by Eric Haines and based on threejs. http://www.udacity.com/overview/Course/cs291/.

Easily the best web class I've ever taken. An avalanche of information and additional sources, and I was ready for it. I’ll go back through it all again slowly.

.

Easily the best web class I've ever taken. An avalanche of information and additional sources, and I was ready for it. I’ll go back through it all again slowly.

.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

////////Somewhere in the initialization loop////////

boid.spinAxis.normalize();

//Sprites

var material = new THREE.SpriteCanvasMaterial( {

color: Math.random() * 0x808080 + 0x808080, program: program } );

spot = spots[ i ] = new THREE.Sprite( material );

spot.position.set(boid.position);

spot.scale.x = spot.scale.y = 10;

scene.add( spot );

//Spheres – 16 is max

var sphereGeom = new THREE.SphereGeometry( 3, 8, 8 );

var darkMaterial = new THREE.MeshBasicMaterial( { color: 0x000080 } );

var darkMaterial2 = new THREE.MeshLambertMaterial( { color: 0x000080 } );

var darkMaterial3 = new THREE.MeshPhongMaterial( { color: 0x000080 } );

sphere = spheres[ i ] = new THREE.Mesh( sphereGeom, darkMaterial );

sphere.position.set(boid.position);

// scene.add( sphere );

//Original Birds. See separate Bird.js

bird = birds[ i ] = new THREE.Mesh( new Bird(), new THREE.MeshBasicMaterial

( { color:000000, side: THREE.DoubleSide } ) );

bird.phase = Math.floor( Math.random() * 62.83 );

// scene.add( bird );

///////////////////////

Playing with three.js. My thoughts are still spinning.

Replaced the flapping winged bird with a round sprite I called spot. A very small performance improvement:

256 birds – 19 FramesPerSecond. 128 birds – 50 FPS.

256 spots – 21 FPS. 128 spots – 59 FPS.

32 spheres – 31 FPS. 16 spheres – 60 FPS.

I keep going in new directions. There are too many to choose from. Have you seen https://www.shadertoy.com ? Wow.

boid.spinAxis.normalize();

//Sprites

var material = new THREE.SpriteCanvasMaterial( {

color: Math.random() * 0x808080 + 0x808080, program: program } );

spot = spots[ i ] = new THREE.Sprite( material );

spot.position.set(boid.position);

spot.scale.x = spot.scale.y = 10;

scene.add( spot );

//Spheres – 16 is max

var sphereGeom = new THREE.SphereGeometry( 3, 8, 8 );

var darkMaterial = new THREE.MeshBasicMaterial( { color: 0x000080 } );

var darkMaterial2 = new THREE.MeshLambertMaterial( { color: 0x000080 } );

var darkMaterial3 = new THREE.MeshPhongMaterial( { color: 0x000080 } );

sphere = spheres[ i ] = new THREE.Mesh( sphereGeom, darkMaterial );

sphere.position.set(boid.position);

// scene.add( sphere );

//Original Birds. See separate Bird.js

bird = birds[ i ] = new THREE.Mesh( new Bird(), new THREE.MeshBasicMaterial

( { color:000000, side: THREE.DoubleSide } ) );

bird.phase = Math.floor( Math.random() * 62.83 );

// scene.add( bird );

///////////////////////

Playing with three.js. My thoughts are still spinning.

Replaced the flapping winged bird with a round sprite I called spot. A very small performance improvement:

256 birds – 19 FramesPerSecond. 128 birds – 50 FPS.

256 spots – 21 FPS. 128 spots – 59 FPS.

32 spheres – 31 FPS. 16 spheres – 60 FPS.

I keep going in new directions. There are too many to choose from. Have you seen https://www.shadertoy.com ? Wow.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Looking cool LTAM. Thanks for the class link too.

**Cr6**- Admin
- Posts : 956

Join date : 2014-08-09

## Re: Simple Orbiter 2

Hi Cr6, It might look like I know what I’m doing, but believe me, nothing is easy. I added an orbital camera - One of those luxuries that are now necessities. With just three lines of code, three.js allows one to move the viewing direction and distance. Of course, it’s quickly obvious that a cloud of particles offers no frame of reference. After several hours I was pleased to have solved nested i,j,k loops to give me a box set of volumetric markers. Then I found grid helpers that made my efforts moot.

Last week I forgot to say that sprites make perfectly passable particles. I can clearly see a periapsis swing which was lost in all the flapping. The multicolors also allow one to visually track one or more particles rather easily. I can also display the multicolor sprites on any color background, with maybe just a single stealth boid or two.

This has been quite a learning opportunity. Between you and me, I’m more confident than ever.

.

Last week I forgot to say that sprites make perfectly passable particles. I can clearly see a periapsis swing which was lost in all the flapping. The multicolors also allow one to visually track one or more particles rather easily. I can also display the multicolor sprites on any color background, with maybe just a single stealth boid or two.

This has been quite a learning opportunity. Between you and me, I’m more confident than ever.

.

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

## Re: Simple Orbiter 2

Status update; nothing tangible, just a fair amount of consideration.

So SO2 qualifies as a physics engine. I understand that a good developer would design an engine based on the anticipated collisions. In examining the balance of charge and gravity, this sim will violate conservation of both linear and angular momentum, as each particle is a source of charge repulsion as well as a seat of gravity. Currently, over time, the sim shows a slight increase in overall linear momentum, but the sim is far from complete.

I see normal particles traversing the simulation’s 1000 unit width, height or depth in less than 10 seconds, or an average of 100 units/second. The framerate, 60 per second, is able to handle this case, recalculating unit position changes of about 1.67. Higher speeds will involve recalculating position location changes of 2 units or more per frame. Translations of that magnitude cannot reflect accurate collision locations, although, apparently, particles are traveling too slow to pass through each other without interaction.

Currently, the fastest particles are “abnormal”, about twice as fast as normal particles. I assume their high speed is due to the acceleration delivered by the charge field of a particle upon another particle that came closer than the sum of the two particle’s “effective” radii. The boundary is still notional. This energy gets added to the total linear momentum displayed. I suppose I should do the calcs. I cleaned up some abnormal production with the tan acceleration.

Collision detection. After scanning a dozen or two sources, the eye-opener for me turned out to be an excellent description of “Sweep - and - prune”, or SAP, collision detection schemes/structures; http://www.codercorner.com/SAP.pdf, by Pierre Terdiman. Very nice, that is, while it’s still fresh in short term memory. I’ll try to clear up some thoughts as I go along.

Continuous SAP monitoring is expeditious and saves time in the long run. I would hate to drop another power of particles – 128 to 64 – as a result of increased CPU demands due to a poor collision implementation.

I appreciate the beauty of SAP, working with sorted lists to identify broad-phase collision locations requiring closer attention. SO2 is a little different. All forces due to all particles will be recalculated for each particle in turn. I believe it’s called brute force. Currently, for any possible collision, SO2 routinely performs the true collision test – what is the distance between the two particles? Is it smaller than the sum of the two radii? Even if the two radii are bounding spheres expanded by high velocities (just a wild thought). Any particle closer than, say, 5, should automatically be subject to the full collision treatment.

next morning...

I guess the full collision treatment should use both the current and previous position data for both particles (or maybe more).

.

So SO2 qualifies as a physics engine. I understand that a good developer would design an engine based on the anticipated collisions. In examining the balance of charge and gravity, this sim will violate conservation of both linear and angular momentum, as each particle is a source of charge repulsion as well as a seat of gravity. Currently, over time, the sim shows a slight increase in overall linear momentum, but the sim is far from complete.

I see normal particles traversing the simulation’s 1000 unit width, height or depth in less than 10 seconds, or an average of 100 units/second. The framerate, 60 per second, is able to handle this case, recalculating unit position changes of about 1.67. Higher speeds will involve recalculating position location changes of 2 units or more per frame. Translations of that magnitude cannot reflect accurate collision locations, although, apparently, particles are traveling too slow to pass through each other without interaction.

Currently, the fastest particles are “abnormal”, about twice as fast as normal particles. I assume their high speed is due to the acceleration delivered by the charge field of a particle upon another particle that came closer than the sum of the two particle’s “effective” radii. The boundary is still notional. This energy gets added to the total linear momentum displayed. I suppose I should do the calcs. I cleaned up some abnormal production with the tan acceleration.

Collision detection. After scanning a dozen or two sources, the eye-opener for me turned out to be an excellent description of “Sweep - and - prune”, or SAP, collision detection schemes/structures; http://www.codercorner.com/SAP.pdf, by Pierre Terdiman. Very nice, that is, while it’s still fresh in short term memory. I’ll try to clear up some thoughts as I go along.

Continuous SAP monitoring is expeditious and saves time in the long run. I would hate to drop another power of particles – 128 to 64 – as a result of increased CPU demands due to a poor collision implementation.

I appreciate the beauty of SAP, working with sorted lists to identify broad-phase collision locations requiring closer attention. SO2 is a little different. All forces due to all particles will be recalculated for each particle in turn. I believe it’s called brute force. Currently, for any possible collision, SO2 routinely performs the true collision test – what is the distance between the two particles? Is it smaller than the sum of the two radii? Even if the two radii are bounding spheres expanded by high velocities (just a wild thought). Any particle closer than, say, 5, should automatically be subject to the full collision treatment.

next morning...

I guess the full collision treatment should use both the current and previous position data for both particles (or maybe more).

.

Last edited by LongtimeAirman on Sun Dec 13, 2015 12:59 am; edited 1 time in total (Reason for editing : correct broad-band to broad-phase)

**LongtimeAirman**- Admin
- Posts : 796

Join date : 2014-08-10

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

Page

**1**of**3****Permissions in this forum:**

**cannot**reply to topics in this forum