
The Powder Toy - shouyatf
http://powdertoy.co.uk
======
oxplot
Some interesting electronics examples I found on youtube:

[https://www.youtube.com/watch?v=TbSmrjmP85Q](https://www.youtube.com/watch?v=TbSmrjmP85Q)

[https://www.youtube.com/watch?v=e0zHiVw-c7k](https://www.youtube.com/watch?v=e0zHiVw-c7k)

[https://www.youtube.com/watch?v=h4eHgnLFk9k](https://www.youtube.com/watch?v=h4eHgnLFk9k)

~~~
goomanhimer
I actually made a bi-propellant rocket engine in this sim, though I had to use
a lua script to get the hydrogen to be in liquid form it works surprisingly
well.
[https://twitter.com/Goomanhimer/status/694048595041976320](https://twitter.com/Goomanhimer/status/694048595041976320)

------
Manishearth
Looks like it's a revamped version of [http://dan-
ball.jp/en/javagame/dust/](http://dan-ball.jp/en/javagame/dust/)

~~~
drdeca
[http://dan-ball.jp/en/javagame/dust2/](http://dan-ball.jp/en/javagame/dust2/)
also exists.

------
moron4hire
Are you simulating the powder on the GPU or the CPU? I couldn't find any
shader code that looked relevant to the sim, so I'm guessing it's the CPU. Any
plans on making a GPU version? Seems loke you'd be able to overcome the perf
issues and finally make that 3D version.

~~~
halomru
I have serious doubts a 3d version would be better. It would be hard (if
possible at all) to make an equally simple interface that conveys the same
information and is equally easy and fast to use while allowing free 3d
interaction.

Maybe that becomes a lot easier once virtual reality and 3d input devices
become common, but until then I think there are better ways to use extra
computation power

~~~
chc4
The grandparent said GPU simulation, for the extreme parallel benefits, not
making it 3D. Encoding the simulation in a GPU shader, for example.

~~~
halomru
I should have been clearer, I was referring only to the last part of the last
sentence

>Seems loke you'd be able to overcome the perf issues and finally make that 3D
version.

Which I interpreted as "once GPU simulation makes things fast, why not make a
3d simulation"

Apart from that part I agree with the ancestor comment, the code seems to do
CPU simulation and GPU simulation is likely to be faster. On the other hand
GPU simulation would likely mean rewriting the entire simulation engine from
scratch, so I'm not holding my breath.

~~~
moron4hire
There was commentary in the FAQ that he was not going to try to make a 3D
version because of the perf issues. I assumed that meant figuring out GPU sim
would mean he'd try to make a 3D version.

------
striking
I remember playing with this.

Making electronics can be pretty fun.
[http://powdertoy.co.uk/Browse/View.html?ID=915343](http://powdertoy.co.uk/Browse/View.html?ID=915343)

(It's not actually an ALU. All it does is add or subtract. But it was the best
of its time!)

------
amelius
This looks nice. But, ideas are more important than code. So to be honest, I
would enjoy a description of how this works more than actually playing with
this program.

~~~
halomru
From a quick look at the code it seems to be coded as a fairly standard
particle system. Modern processors are fast, if you have a million particles,
a 2GHz processor, and do 20 simulation steps per second you can spend 100
clock cycles per particle on simulating it. On modern processors 100 clock
cycles usually translates to over 100 instructions.

Of course the ~100 clock cycles latency for fetching from main memory has to
be avoided, so you code in a language like c++ (like this project) and pack
your data in big arrays in the order it's accessed in. Then processor caches
and prefetching do the magic.

Particle interactions that usually imply quadratic runtime can be made fast by
mapping particle positions to a grid and either looking up neighbouring
particles in the grid or calculating large scale effects directly with the
grid.

Personally, I think for this project the working whole and the value it
provides as a fun educational tool is a bigger deal than architectural or
development ideas that went into it (but I'm happy to be proven wrong)

