Vaya, que fuerte, hace 9 meses respondí a un compañero de este foro que quería simular agua para un videojuego y una de las opciones que le di fue ésta.
Y ahora me encuentro con esto, que utiliza exactamente la misma técnica que describía yo, es decir, partículas para la simulación y metaballs (utilizando marching cubes) para el render. La diferencia es que en vez de dinámica de fluidos, éste utiliza springs (lo mismo que se utiliza para cosas como simulación de telas o pelo), que es mucho más rápido que la dinámica de fluidos.
De todas formas, ya se está empezando a llevar a cabo simulación de fluidos real (utilizando las ecuaciones de navier-stokes) en tiempo real a través de la GPU. Por ejemplo, tenemos este artículo del GPU gems.
También hay un artículo sobre simulación de nubes. Si os descargáis el video, entre otras cosas se ve en tiempo real cómo se generan las nubes al ascender el vapor de agua del mar. Es bastante interesante.
Por cierto, hablando del libro GPU gems, una curiosidad que no tiene que ver con el tema. Esta serie de libros está más bien orientada a videojuegos, por lo tanto sus técnicas deben funcionar en tiempo real. Pues bien, en un artículo que se mencionó en estos foros sobre las técnicas que se utilizaron en piratas del caribe 2, se puede leer esto.
En fin, uno podría pensar que el sector de los videojuegos no puede aportar nada al cine, pero cómo se puede comprobar, no es el caso. También es cierto que técnicas que se utilizan en cine desde hace años (sobre todo con RenderMan), se empezaron a utilizar en videojuegos con la aparición de las GPU programables. Lo que quiero decir, es que cuando los Shaders se han convertido en un estándar, la maquinaria de genios que hay en la industria de los videojuegos ha comenzado a desarrollar técnicas bastante increíbles. Pero bueno, creo que me he ido por las ramas.
Pues como utiliza el algoritmo de marching cubes (que, por cierto, esta patentado), todo debería ser cambiar la resolución del grid de voxels. De forma que a más resolución, mayor detalle de la malla. En el caso de la aplicación ésta, parece que lo que se indica es el incremento entre voxels (define mc_grid_len en main, c). Así que, sí, por ejemplo, pones un mc_grid_len de 0.01, veras que la malla tiene bastante poco detalle. Si ese incremento lo haces más pequeño, la malla tendrá más detalle. Lo que pasa es que, al parecer hay que tocar otros parámetros (iso_radius, por ejemplo) para que la cosa quede bien.
En fin, no es un buen ejemplo de claridad de código. Pero bueno, hay que agradecer que la gente comparta conocimientos. Saludos.