Hacker News Reader

Comment by 6ren | Hacker News Reader

The algorithms are embarrassingly parallel, but he doesn't use the GPU because it's busy rendering. I wonder if intel's increasingly powerful integrated graphics (usually supplanted with a video card) could be used for this?

> In the endeavor to achieve real-time fluid motion, some other fluid simulations exploit general-purpose computing on graphics processing unit (GPGPU). However clever, such approaches do not help with current gaming hardware, because in video games, the GPU tends to be busy with rendering and has no time left over for simulation. http://software.intel.com/en-us/articles/fluid-simulation-fo...

Also: pretty videos http://www.youtube.com/mijagourlay#p/u/4/G9E8xEjGzk0 (download http://software.intel.com/file/23546/)

View on HN

GPGPU is incredibly overkill for simulating a water surface.

Create two 256x256 RGB textures, call them foo and bar.

The R channel will store current height of wave. The G channel will store the previous height of wave (allowing you to derive velocity).

  ... each frame ...
  render_to(bar)
  sample_from(foo)
  /* insert fancy partial differential algorithm */
  foo,bar = bar,foo

In other words, you're "ping pong"-ing between two textures.

Now if you set an arbitrary texel to, say, 1.0 (maximum), that texel will propogate outwards as if it were a ripple.

Bonus: the result is a seamless tilable texture.

Look up "toyshop rain" for the exact details. But I used this method to augment an ingame lake surface's normal map (thunderstorm effect --- rippling raindrops propagating across the lake). This was in 2007, running on 2007 hardware. GPGPU need not apply.

My first two demos (Waveride and Armitage by Straylight if you search on Pouet) used a 3-array water surface simulation, cycling through them like you mentioned. The first used an implementation on the CPU with a 128x128 grid, the second did 5 separate 128x128 surfaces on the GPU (render to texture). The second ran all 5 about 10x faster than running a single one on the CPU, and that was with effectively no optimization on the GPU side. With some tweaking, I would've been able to do 10000^2 grids cheaply; the biggest bottleneck was that I moved the textures to and from the GPU for each frame, which I could eliminate with some use of vertex shaders and abuses therein.

Anyway, saying that GPGPU is overkill here is pretty silly -- sure, you can do some water surface simulation on the CPU, but you hit the wall very, very quickly if you're doing anything but that.

I never readback the textures. The water surface is entirely generated and simulated on the GPU, and its heightfield is converted into a normal map and fed into the renderer every frame. There was literally zero performance overhead (we were CPU limited, not GPU limited).

The lake surface looked utterly convincing; it was as if you were watching a rainstorm pour down on it. I wish I had a video.

The bottleneck you ran into was readback. Transferring data from GPU->CPU was, is, and always will be, "expensive".

GPGPU is completely unrelated to this; it merely enables you to perform computations on the GPU faster, nothing more and nothing less.

"toyshop rain" http://www.youtube.com/watch?v=LtxvpS5AYHQ (but youtube video content seems to be down at the moment, at least here in Australia anyway)

BTW: The article (10 parts!) deals with other fluid effects besides surfaces, the first few paragraphs even distinguish between them and gases.

Thank you. Probably my favorite tech demo of all time. It gives me goosebumps every time I watch it. Likely watched it at least 30 times by now.

Everything about it is beautiful, from the art to the music to the sound effects to the incredible feeling of "being drenched". Natalya Tatarchuk is truly a hero.

Watch it all the way through, with headphones, in fullscreen, or don't watch it at all!

The experience was so much more intense back in 2007; it was breathtaking.

(Nooooo I don't wanna get old! Make it stop!)

In case you haven't seen it, From Dust uses fluid simulation as a game mechanic. It's a god game, with flowing water that erodes rivers etc, at a constant 30 fps. There's an xbox demo, and a PC demo to come. Here's a video: http://www.youtube.com/watch?v=gSOQGazo7Oo&t=33s (I think the fluid grid is slightly coaster in the actual game, but water basically flows the same). BTW: I think it's fantastic as a toy, less good as a game.

However, from what you're saying, the fluid simulation isn't as expensive as I thought.

Wow, that's incredible! Thanks for sharing.

Sorry, I miscommunicated --- fluid simulation isn't expensive as long as it doesn't affect gameplay. Because then you can do it all on the GPU, and you don't have to transfer it back to the CPU (to perform checks like "is the water touching me?")

In this case, From Dust is simulating the fluids on the CPU, then building geometry / textures on the fly and uploading that to the GPU and rendering. It's quite an impressive tech demo, both from a technical and artistic standpoint.

There's the possibility of shared memory, between CPU and integrated GPU, as John Carmack noted, skipping the transfer. Apparently, the xbox does this already.

Big extrapolation: If intel can pull this off, they may be able to own the next platform, of GPU-based computation. I suggest that's the next platform because it seems to be the only place where many-core code is really happening. And many-core is the only way to get Moore power, since clock rates hit a wall.

It has the "uncanny valley" effect. I feel like any moment gumby is going to show up. Very creepy.

Reply on news.ycombinator.com