 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Weee... I think I might have to Zazzle some of these when I got the
> program working smoothly. ;-)
>
> I could stare at this for quite some time. (Especially if it was at a
> decent resolution.) But nothing compares to seeing it move! ;-)
Sweet! What's the coloring scheme?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Sweet! What's the coloring scheme?
For each pixel, initialise a particle to that starting point, and let it
wander under the influence of the attractors in the system. (Three
"magnets" plus a "string" force to simulate a gravitational pull towards
the center.) Colour each pixel according to the current X, Y coordinates
of the particle. (X = red, Y = green.)
It actually comes out looking far more interesting if you colour by
magnet proximity, and I'm investigating other possible colouring
algorithms too. (The sharp lines are where the red or green intensity
"wraps around" back to zero. They're not part of the actual system. It's
just quick and easy to implement the colouring this way to check whether
the rest of the program is working OK.)
Obviously, since all these particles are in motion, the image constantly
changes colour - most obviously with large repeating oscilations, which
gradually go out of phase with each other as various areas of particles
pass particularly near a magnet. Hence the fractal nature of the image.
If you're paying attention, you'll note that the magnets aren't *quite*
in a triangle formation; the top two are slightly too close together,
compared to the bottom one. Hence the lack of 3-fold symmetry.
There are *so* many animation possibilities here. You can animate the
orbits of the system, or you can show the system after X seconds and
move the magnets around. Or just change the colouring algorithm. (Thus
far I haven't used particle velocity at all yet...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I still don't really comprehend why RK4 is different to just integrating
> in smaller steps.
RK4 takes into account how the slope of the function changes during the
step, Euler just assumes it's constant (equal to the value at the beginning
of the step). Of course to the "outside" user of such a function there is
no difference, RK4 just gives a certain level of accuracy or stability for
much less CPU time than Euler.
> RK4 manages apparently total stability with really quite large integration
> steps, which is puzzling.
The effect of RK4 over Euler is squared when you are doing it twice (from
acceleration to velocity, and from velocity to position) so it's not too
surprising. Also your forces are smooth and easily predictable for RK4
(just sums of 1/r^2) so it should perform very well. Compare to eg a car
suspension going over rough terrain, there are often sharp changes in forces
which RK4 (or any other continuous curve predictor) is not so good at.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> For each pixel, initialise a particle to that starting point, and let it
> wander under the influence of the attractors in the system. (Three
> "magnets" plus a "string" force to simulate a gravitational pull towards
> the center.) Colour each pixel according to the current X, Y coordinates
> of the particle. (X = red, Y = green.)
Those images are really cool! So let me get this straight, you colour each
pixel based on where the point that started at that pixel is at that
instant?
Must be really cool to see it being animated.
You could calculate the speed of each point, and assign that to the blue
channel :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> For each pixel, initialise a particle to that starting point, and let
>> it wander under the influence of the attractors in the system. (Three
>> "magnets" plus a "string" force to simulate a gravitational pull
>> towards the center.) Colour each pixel according to the current X, Y
>> coordinates of the particle. (X = red, Y = green.)
>
> Those images are really cool!
Thank you. :-D
> So let me get this straight, you colour
> each pixel based on where the point that started at that pixel is at
> that instant?
Yep, that's the one. Start a particle from each pixel, colour that pixel
according to where the particle is now. (Using any arbitrary colouring
algorithm you fancy.) You *could* use an image map, for example...
> Must be really cool to see it being animated.
Clearly I'll have to put the result on YouTube at some point. ;-)
> You could calculate the speed of each point, and assign that to the blue
> channel :-)
Yeah, possibly. Or maybe add some white or something. Of course, when
it's in motion, you can tell by how quickly each point changes colour.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Sweet! What's the coloring scheme?
The *other* possibility is to colour each pixel by the density of points
that have reached there. (Kind of "backwards" compared to the current
algorithm.) I suspect the result wouldn't be as pretty though.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, now this is just *weird*... I just reimplemented the same program at
home, and it now produces the same images. However, it runs very, very
much slower than at work. And yet, the PC at work is an AMD AthlonXP
1700+, while the PC here is an AMD Athlon64 X2 4200+.
In other words, somehow I've made a mistake somewhere that makes the
program slower than it should be. But it produces the right answers, so
finding the program is going to be... uh... "interesting". o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
