Todo sobre RealFlow

[bealobo]

Tienes que controlar las densidades del fluido y del objeto y el hecho de que flote saldrá solo. O sea, que ve jugando con la masa del objeto.

[DARR3D]

Gracias Bealobo, trataré y te diré si me funciona, este es el mejor foro de todos.

[Marquitos]

Hola a todos, veréis, acabo de empezar con RealFlow para fluidos, me gustaría saber si alguien sabe de algún tutorial, y sobre todo cómo puedo importar al Maya 2008 desde RealFlow, ya que no sé dónde puedo conseguir plugins para esta versión del Maya o para la versión 8.5. Gracias a todos de antemano.

[bealobo]

Para la versión 2008 no han salido aún y los de la 8.5 te los puedes bajar de la página RealFlow.com, rellenando el formulario.

Hay unos videotutoriales sin sonido de cómo usar el plugin. aquí.

Y en la ayuda del programa viene explicado. También hay un documento junto con el plugin.

[Marquitos]

Muchas gracias Bealobo, ya he conseguido los plugins, ahora trataré de buscar tutoriales y ala a aprender. Gracias.

[codigopost]

Tutorials si es que existen.

[Leandro Salerno]

Aquí tienes un foro en español con mucha data: http://www.RealFlow.es/foro/index.php.

Aquí unos tutoriales de la página oficialhttp://www.nextlimit.com/RealFlow/te_resources.htm.

Y aquí unas escenas de ejemplo: http://www.nextlimit.com/RealFlow/te_scenes.htm saludos.

[yandel]

Están col.

[sdsmvcc]

Gracias por los tutoriales me han servido.

[claubbb]

Buenas gente, quisiera que me digáis donde puedo descargar el RealFlow, que tengo que entregar un trabajo para el mes que viene de líquidos y con el LightWave no queda muy realista, gracias.

[Extraterroide]

rf4: fluids & dynamics simulation tool. Un saludo.

[Neo_one]

: c4des magazine :. Descárgate el número 4, ahí te dirán que hacer para conseguir una versión gratuita (limitada, eso sí).

[claubbb]

Gracias.

[arlequin]

Pues la verdad he escuchado que si se puede, pero nadie sabe. Si alguien sabe cómo puedo podner varias máquinas vía red a calcular la dinámica en RealFlow? Gracias.

Por favor si saben sería de gran ayuda.

[bealobo]

Hola. No, no se puede hacer cálculo distribuido. Lo que sí se puede hacer es hacer el mallado en varias máquinas, precalculando las partículas y asignando un rango diferente para cada máquina para el mallado.

[arlequin]

O una forma para que el cálculo sea más rápido. Conservando los settings ya pre estraclecidos.

[bealobo]

Si no quieres cambiar settings de tu simulación entonces simula desde la command line. En la ayuda viene cómo help/contents/rf4/command line.

[Netvudu]

Ya que surge el tema y tengo a la experta por aquí, y usando deadline de frantic films que es un gestor de render en red? ¿sabes si es sólo para la parte del mallado o para todo? frantic films.

[bealobo]

Buenas, no lo he usado, pero vamos, será para el tema de gestión de escenas y versiones de simulaciones y para el mallado, porque es imposible distribuir el cálculo ahora mismo, no es una cuestión de software sino de la tecnología debajo, de hecho, para que te hagas una idea, ni siquiera es eficiente mandar a mallar un solo frame a cada máquina, lo suyo es hacerlo por rangos de fotogramas.

[slime]

Scanline presume de que su sistema de fluidos es distribuido. Me imagino que lo que hacen son muchas simulaciones de baja resolución y luego usarlas para distorsionar una superficie implícita de resolución extremadamente alta. (hablando de líquidos).

[slime]

Ya que surge el tema y tengo a la experta por aquí, y usando deadline de frantic films que es un gestor de render en red? ¿sabes si es sólo para la parte del mallado o para todo?
frantic films.

Hey netvudu, hablas de deadline o de flow?

[bealobo]

Sí, por lo visto fedwik también presume de lo mismo. Yo no sé cómo lo harán los de Scanline porque también dicen que simulan en un solo pase.

Lo cierto es que hay que hacerlo muy bien para que el coste de distribuir y partir el cálculo (y juntar las soluciones) no supere el de hacerlo en un puesto multithreading.

[Netvudu]

Hey netvudu. Hablas de deadline o de flow?

Hola. Me refería a deadline. Efectivamente flow anda también por ahí, por frantic, pero no tengo referencia alguna de él.

La razón de preguntar por deadline es porque es posible que lo evalúe en poco tiempo, y me he fijado que entre las capturas del programa, sale una para RealFlow, lo que me ha chocado con la idea de no poder distribuir el cálculo.

Por otro lado, lo que dice Bea suena con bastante sentido dentro mi minúsculo cerebro cuasisapiens.

[bealobo]

Por cierto Slime, estoy pensando en lo que has dicho de distorsionar una superficie implícita de alta resolución. Me imagino que hablas de simulaciones con diferente semilla y un level sets al final, ¿no? Distribuido también?
Es que según lo que se le, sacan el render en un pase. Y si todo es distribuido quiere decir que meten la simulación y sacan el render, por lo que en algún momento tendrán que juntar las soluciones y redistribuirlo (ya sea el grid o polígonos dependiendo de sus sistema de render).

No sé, tengo mucha curiosidad. La verdad es que no se ni si usan partículas.

Bueno.

[slime]

Por cierto Slime, estoy pensando en lo que has dicho de distorsionar una superficie implícita de alta resolución. Me imagino que hablas de simulaciones con diferente semilla y un level sets al final, ¿no? Distribuido también?

Exactamente. Me imagino que dará resultados smilares a los de una simulación de fluidos de mucha más resolución. Otra posibilidad que se me ocurre para hacer fluidos distribuidos es el dicing con bastante área de superposición. Cada fotograma se distribuye a varios procesadores o Cores pasando a cada un (cubo) subdominio donde se calculara un fotograma de simulación independiente. Los subdominios tendrán un área de superposición grande (20%+). Luego al hacer el surfacing, se genera el dominio final utilizando una mezcla de subdominios donde las zonas donde había intersección se funden.

El problema es que en simulaciones rápidas, vectores de velocidad elevados del fluido puede pasar de un subdominio a otro y el sistema tendría que tener eso en cuenta (quizás reseteando buckets con la nueva información o haciendo que los subdominios sean adaptativos dependiendo de los vectores de velocidad).

Esto es muy complicado.

[slime]

Sobre lo de Scanline, yo no creo que usen partículas. Sera vectores de velocidad + surfacing del levelser en tiempo de render. Las partículas son demasiado lentas y no soy capaz de imaginar cómo se podrían conseguir resoluciones muy altas o distribuir la carga con partículas.

[Netvudu]

¿Se puede deducir de eso que el futuro de los fluidos están en la evolución de los level sets mucho más que en partículas?
Jugando en Houdini, que es muy bueno ahora para esto porque tenemos los dos sabores de fluidos, he observado que los fluidos de level sets tienen la desagradable costumbre de perder algo de volumen, lo que según para que simulación me parece peligroso.

[lisux]

Ya que surge el tema y tengo a la experta por aquí, y usando deadline de frantic films que es un gestor de render en red? ¿sabes si es sólo para la parte del mallado o para todo?
frantic films.

Deadline sirve para la simulación y para el mallado, para la simulación obviamente lo único que hace es ejecutarla desde command line en otra máquina, con el mallado hace lo mismo, pero te automatiza el proceso de separar todo entre las máquinas, deadline es muy majo.

[arlequin]

Hola a todos gracias por sus respuestas, pero la verdad no veo la respuesta a mi pregunta o no entendí si pueden explicarlo mejor sería de gran ayuda.

[lisux]

Sobre lo de Scanline, yo no creo que usen partículas. Sera vectores de velocidad + surfacing del levelser en tiempo de render. Las partículas son demasiado lentas y no soy capaz de imaginar cómo se podrían conseguir resoluciones muy altas o distribuir la carga con partículas.

Dudo mucho que puedan distribuir una simulación, eso a día de hoy es casi imposible, en una simulación de fluidos necesitas tener toda la información disponible al mismo tiempo, si estas calculado la partícula/punto x necesitas saber el estado de todas las prticulas/puntos alrededor, si lo extrapolamos a una red la latencia de pasar información enre máquinas llevaría el cálculo a cifras ridículamente altas, no es practico, incluso sistemas de alto rendimiento como mpi o redes hippy no son capaces de mover este tráfico de información lo suficientemente rápido. Necesitas una latencia muy próxima a la de dos pocesadores/Cores juntos, y eso entérminos de redes es una diferencia de muchos ordenes por encima, como que no, lo que sí puedes es procesar la malla, lo que hace RealFlow, pero claro eso es con una simulación ya hecha, por cierto, netvudu échale un ojo al particle fluid surface SOP, es como el mallado de Real Flow, pero como unas 10 veces más rápido, y no exagero, nosotros tenemos simualciones con más de 50000 particlas y tienes el mallado a alta calidad en menos de 5 segundo, una pasada, y lo mejor es que vale con partículas, puntos, nubes de puntos super útil.

Lo de los level sets yo no lo he apreciado, lo que si está claro es que dan una calidad en render excelente comparado con el clásico mallado.

[slime]

En una simulación de fluidos necesitas tener toda la información disponible al mismo tiempo, si estas calculado la partícula/punto x necesitas saber el estado de todas las prticulas/puntos alrededor.

Eso es para que sea físicamente correcta, pero en la práctica se puede asignar un radio de captación de energía o un nivel de energía mínimo donde se elimina al ser menor que ese número, por poner un ejemplo extremo, no es necesario calcular la fuerza que ejerce alfa centauri sobre una manzana en una mesa para calcular su gravedad, aunque en realidad si que está afectandola.

Quizás sería mejor mover este hilo a otro sitio.

[Netvudu]

Claro, en Sony no calculais la influencia de alfa centauri y así os quedan las simulaciones de justas, justas. En cuanto al particle fluid surface SOP Lisux, ya lo he probado, y no sólo va como un tiro (desde la 9.1, antes iba un poco más lento, pero han acelerado el calculo a lo bestia), sino que encima es muchísimo más controlable el resultado que el mallado de RealFlow, en el que al final, desde mi punto de vista, te limitas a jugar con tres o cuatro valores.

A los cálculo de fluidos de partículas les falta todavía mejorar un poco en Houdini sobre todo la velocidad. Ahí sí que está todavía RealFlow por delante creo yo, pero claro, la ventaja de Houdini de tenerlo todo junto en la misma aplicación y con todas las dinámicas interactuando juntas, y pudiendo hacer blend de animaciones y, y, y, mucho mejor, claro.

[bealobo]

Yo creo Scanline efectivamente hace surfacing en tiempo de render. Ahora RealFlow tiene una cosa así para RenderMan y claro, te ahorras un montón de tiempo. Aparte, vuelvo a lo de que lo hacen en un pase, no creo que haya otra manera de hacerlo si no, también he estado pensando en las simulaciones con diferente semilla y no sé si será ese el método que utilicen porque en realidad el resultado no sería el mismo. Con más resolución de fluido, las partículas pesan menos y reaccionan más rápido a fuerzas. Lo veo desde el punto de vista de los splashes, efectivamente todo esto es muy difícil, si.

Respecto a distribur simulaciones sí que se puede hacer. Pero es complicado porque un multithreading puede seguir siendo más eficiente, por lo que decía Lisux de la transferencia de información, de todas formas, estas cosas van muy rápido, fedwik hace simulaciones distribuidas, yo creo que debió ser el primero en hacerlo así que, no me sorprendería que en Scanline hayan encontrado un método que les sea útil, ese software no es de ayer.

Por cierto, en Houdini los fluidos son multithreading? Las pruebas que he hecho (partículas) es que era muy lento (6x frente a la misma simulación en Real Flow) y recuerdo haber mirado el tasque manager al 50% los procesadores. ¿alguien me lo confirma? Es que como no se usar bien Houdini, puede ser que se me esté pasando algo por alto.

Y el futuro de los fluidos, yo no creo que sea ni uno ni otro. Los dos métodos (grid y partículas) tienen ventajas e inconvenientes. Más o menos la novedad es lo que últimamente ha puesto fedwik en su web.
http://physbam, stanford.edu/~fedkiw/.

Una cosa, solo para que la gente que pueda estar leyendo no se líe, level set no es el método de cálculo del fluido, es un método para hallar y seguir la superficie en un espacio segmentado, se bien comúnmente de level set para referirnos a los fluidos que se calculan sin partículas, pero no es correcto. Hay métodos de cálculo con partículas que usan level sets.

Y voto como Slime, este hilo se debería mover de aquí.

arlequin: la respuesta es que no se puede distribuir el cálculo en Real Flow = no simular en red.

[SHAZAM]

Estáis aportando suficiente información interesante en vuestros comentarios como para que sea más útil dejar el hilo aquí que en infografía general, por ejemplo.

De todas maneras, se oyen sugerencias sobe el destino del hilo, queréis sacarlo, pero no me indicáis donde queréis ponerlo.

[lisux]

Eso es para que sea físicamente correcta, pero en la práctica se puede asignar un radio de captación de energía o un nivel de energía mínimo donde se elimina al ser menor que ese número.

Cierto, eso creo que se podría hacer en Houdini usando grupos para crear capas de simulaciones, no lo he probado con fluidos, pero sí con RBD y funciona bastante bien, otra forma seria crear las capas como simulaciones pre-calculdas (ya cacheadas) que luego puedes hacer interacciónar entre ellas.

Ahora RealFlow tiene una cosa así para RenderMan y claro, te ahorras un montón de tiempo. Aparte, vuelvo a lo de que lo hacen en un pase, no creo que haya otra manera de hacerlo si no.

Ese es el método que usa Houdini y otros como frantic films para renderizar fluidos definidos como volúmenes, y cualquier cosa la puedes pasar a volumen en Houdini, crea una superficie implícita que se genera en tiempo de render. Es un sistema muy potente. Está muy bien que lo hayáis metido en Real Flow para Rman es una cosa que llevaban tiempo intentando hacer en nl.

Por cierto, en Houdini los fluidos son multithreading? Las pruebas que he hecho (partículas) es que era muy lento (6x frente a la misma simulación en Real Flow) y recuerdo haber mirado el tasque manager al 50% los procesadores. ¿alguien me lo confirma? Es que como no se usar bien Houdini, puede ser que se me esté pasando algo por alto.

Si el multithreading, aunque es adaptativo, es decir si el piensa que no necesita más de dos procesadores no los usara más, a veces usar más procesadores no es la solución más rápida. Pero el sistema no funciona muy bien y se lía a veces, además como bien dices es muy lento por el momento, eso sí la cantidad de información que genera es increíble, es relativamente crar campos de vectores que se pueden aplicar a muchas cosas, échale un ojo a esto Bea, si aún no lo has heco, es interesante: http://www.sidefx.com/masterclasses/advfluid07.tar, gz.

Y el futuro de los fluidos, yo no creo que sea ni uno ni otro. Los dos métodos (grid y partículas) tienen ventajas e inconvenientes. Más o menos la novedad es lo que últimamente ha puesto fedwik en su web.
http://physbam, stanford.edu/~fedkiw/.

Yo creo que el futuro está en saber combinar ambos métodos de forma correcta y efectiva, usar partículas para la animación, suelen ser más intuitivas para un animador, y level set para el surfacing, da la malla de mejor calidad y encima en tiempo de render.

De todas maneras, se oyen sugerencias sobe el destino del hilo, queréis sacarlo, pero no me indicáis donde queréis ponerlo.

Yo lo pondría en el mismo foro, pero con otro título, porque el tema de simulaciones y efectos. Por ejemplo:
Simulación de fluidos distribuida.

[bealobo]

A veces usar más procesadores no es la solución más rápida.

Cierto, depende de cómo hagan el multithreading. Entonces, más o menos Houdini (fluidos/partículas) escala bien hasta 2 procesadores y de ahí lo evalúan ellos en tu escena. Bueno, tendré que hacer más pruebas. ¿sabes si hay algún Benchmarking por ahí?
¿Para los fluidos (no-partículas) es igual?
Y gracias por el enlace, voy a echarle un ojo.

[lisux]

Cierto, depende de cómo hagan el multithreading. Entonces, más o menos Houdini (fluidos/partículas) escala bien hasta 2 procesadores y de ahí lo evalúan ellos en tu escena. Bueno, tendré que hacer más pruebas. ¿sabes si hay algún Benchmarking por ahí?
¿Para los fluidos (no-partículas) es igual?
Y gracias por el enlace, voy a echarle un ojo.

Escala bastante bien hasta 4 Cores, las partículas pueden ser calculadas con el sistema de particlas tradicional, pop, o usadas dentro del sistema de dinámicas, dop. O incluso calcular una parte en pop y otra en dop en la misma simulación, aunque ese seria otro tema, pop no es multithreading, dop si. Los fluidos están todos en dop con lo cual son multithreading.

[Netvudu]

Una cosa, solo para que la gente que pueda estar leyendo no se líe, level set no es el método de cálculo del fluido, es un método para hallar y seguir la superficie en un espacio segmentado, se bien comúnmente de level set para referirnos a los fluidos que se calculan sin partículas, pero no es correcto. Hay métodos de cálculo con partículas que usan level sets.

Vaya, pues entonces entono el mea culpa, que soy el que lo está llamando el cálculo de level sets para referirme al cálculo de volúmenes sin partículas. Cuál es la forma habitual de referirse a este tipo de cálculo. ¿simulación de volúmenes de fluidos?

[bealobo]

Vaya, no te sabría decir. Yo lo llamo Grid, porque hay nombres más científicos pero para eso tienes que saber la ecuación y el método.

[slime]

Yo lo llamo el cálculo de liquidillos con cajas de esas. Las simulaciones de fluidos que no están basadas en partículas, lo hacen con matrices (llamadas dominios, que suelen ser bi o tridimensionales) donde se guardan valores (Vector de velocidad, densidad, etc).

Por ejemplo, para simular de un gas que sale de un punto en la parte de abajo de un dominio, la simulación anyadira densidad a esa (s) celdas cada fotograma. Una serie de fuerzas (gravedad, temperaturas, etc) modificara los vectores de velocidad en cada fotograma y la simulación lo que hará es corregir esos vectores con unas ecuaciones de dinámica de fluidos. Luego la densidad se pasa a otras celdas dependiendo de esos vectores de velocidad y se utiliza una formula de disipación, para que cada vez haya menos gas a medida que pasa el tiempo. Esto es a grandes rasgos cómo funciona una simulación de fluidos basada en velocidad en vez de partículas. Lo bueno del sistema este es que el dominio de la simulación se puede utilizar como dominio del levelset, usando la densidad como la función de signo (sdf) para triangular la geometría.

[sergiozelada]

Yo probé el deadline y funciono muy bien para la generación de mallas en 10 máquinas de un RenderFarm y debo dar fe que me salvo el pellejo un par de veces, pero como dice Bea, es imposible que también delege el cálculo, desgraciadamente solo maneja de manera local.

[Cartex]

Hola, me presento como cartex, me acabo de iniciar en RealFlow 4, y tengo un pequeño problema a ver si me podéis ayudar.

Estando en los planos me deja acerca y alejar y mover objetos, pero no me permite moverme libremente por el, alguien sabe que tengo que acer para solucionarlo? Gracias.

[Alueckard]

Hola a todos, este foro si que es una gran gran ayuda para todos los 3dmaniacos, realmente geanial. E leído y leído mensajes de RealFlow y aún no encuentro respuesta, ya se pasar objetos obj de max a RealFlow y hacer que la spartículas simuladas logren interactuar con tal objeto, pero, no tengo idea como volver esos cálculos de partículas al max para texturizar y componer, me explico.

No sé cómo exportar del RealFlow al max.

Cualquier video tutorial o referencia se agradecerá profundamente.

[ikerCLoN]

Desde la página de Next Limit puedes descargarte los plugins para importar tanto partículas de Real Flow como mallas. Échale un vistazo a la documentación que vendrá adjunta para saber cómo hacerlo.

[Alueckard]

Muchas gracias, ya descargué dicho plugin, además en la página se están haciendo video tutoriales que estarán pronto a descargar, muchas gracias.

[Alueckard]

Hola de nuevo chicos, gracias a la respuesta anterior, con ayuda del plugin pude exportar la secuencia (.bin) de real flow, pero lamentablemente no me exporta la Maya tipo liquido que hace el RealFlow, solo me lo deja como partículas ordinarias, alguien sabe cuál sería el problema? De antemano muchas gracias.

Esto va avanzando de a poco.

-- IMÁGENES ADJUNTAS --

[ikerCLoN]

Del mismo modo que en Real Flow puedes salvar la animación de tus partículas, también puedes salvar las mallas que generas. Por favor, antes de preguntar cosas tan básicas, consulta la ayuda de tu programa: es el primero sitio dónde tienes que mirar cuando tienes dudas, y me consta que esto está muy bien descrito en este caso particular.

Si no investigas por ti mismo no aprenderás jamás.

[Alueckard]

Tienes mucha razón man, gracias. Espero poder sorprenderlos pronto.

[AIZZI]

Estimado alueckard. El problema que tienes es que debes seleccionar los emisores por lo tanto haces click botón derecho sobre el icono de la malla y señalas Insert fluidos cuando se abre la ventana seleccione los emisores y das ok, de esta manera al exportar a tu programa 3d puedes ver el fuido animado con la malla y puedes renderizar, es este tu problema? Saludos.

Alberto.

[AIZZI]

Estimados. Se puede realizar espuma y spray con parámetros de RealFlow sin usar un script? Estoy realizando la animación de una ola, si bien existen script para ello, no estoy familiarizado con ellos todavía y quería saber si puedo llegar a simular tal efecto con las partículas. Saludos.

Alberto Izzi.