Mi propio impact system en Houdini

**MGue** · 11-07-2006, 19:04

Qué complejos parecen todos los ejercicios que habéis estado comentando. Puede ser muy útil, ahora o en un futuro, para los que estamos aprendiendo sobre el tema. Gracias.

**MiguelPerez** · 11-07-2006, 20:46

Ya lo he aplicado a una de mis escenas, a ver qué os parece.

-- IMÁGENES ADJUNTAS --

**slime** · 11-07-2006, 20:59

Muy bien, ahí se ve cómo funciona el sistema correctamente. Te animas con Vex a probar como mover puntos?

**MiguelPerez** · 11-07-2006, 21:03

Lo que más me gustaría ahora aprender, es Vex. Me leeré toda la ayuda, y a ver si saco algo. ¿Se utiliza mucho Vex en producciones complejas?

**MiguelPerez** · 11-07-2006, 23:12

Y una pregunta. ¿a qué te refieres, a escribir código en el Vex pop, o a conectar nodos en el Vop pop? Porque el segundo es más fácil, creo yo.

**slime** · 11-07-2006, 23:45

Empieza conectando nodos, lo que hace esto es crear código automáticamente. Como es lógico, ese código no está optimizado. Ese código puedes compilarlo en otls, más tarde cuando controles el lenguaje, ya puedes hacerlo usando solo un editor.

Las ventajas del código Vex compilado es que la velocidad es muchísimo mayor que cadenas de operadores. Para sistemás complejos se utiliza un montón. Por ejemplo, un sistema antes tardaba minuto y medio para calcular una serie de operación y después de optimizarlo y compilarlo como Vex solo tarda seis segundos.

**bealobo** · 12-07-2006, 08:45

Miguel, está genial.

**essmigol** · 13-07-2006, 09:52

Vaya tela Miguel enhorabuena, bueno a ambos por que tú sistema Slime es la cara también, muy interesante esto lo que pasa que no me enterado de nada. A ver si indago en el tema, pero lo veo complicado.

**lisux** · 26-07-2006, 09:05

La verdad que este hilo esta de lo más interesante, imporesionante de verdad, algunas dudas.

Empieza conectando nodos, lo que hace esto es crear código automáticamente. Como es lógico, ese código no está optimizado. Ese código puedes compilarlo en otls, más tarde cuando controles el lenguaje, ya puedes hacerlo usando solo un editor.

Las ventajas del código Vex compilado es que la velocidad es muchísimo mayor que cadenas de operadores. Para sistemás complejos se utiliza un montón. Por ejemplo, un sistema antes tardaba minuto y medio para calcular una serie de operación y después de optimizarlo y compilarlo como Vex solo tarda seis segundos.

Slime, cuando te refieres a empieza conectando nodos y luego cuando controles el lenguaje ya puedes hacerlo usando solo un editor, te refieres a empezar usando Vex a pelo y luego el Vex Builder?
En cuento a las ventajas del Vex compilado te estas refiriendo a hacer en Vex Builder lo que hacías en SOP y así pasar a código Vex toda la network de sopsí.

Por último, para lo de ruido en los impactos yo haría lo que dice Slime, me haría un nuevo SOP desde el Vex Builder que hiciese todo el proceso de calcular la dirección en la que moveremos los puntos, el cálculo de diedrales, para ello podría estar toda la información necesaria en atributos de la geometría que luego usara el nuevo operador. Y una vez sepamos la dirección, ver cuánto se moverán, por distancia al origen del disparo, tipo de impacto, y a esos puntos que se mueven aplicarles patrones de ruido, otra forma es usar atributos para que un Shader de desplazamiento solo actue en los puntos de impacto y con ditintas intensidades dependiendo de la distancia al punto de impacto.

Simplemente para añadir más lenya al fugo, en la doc de Houdini viene una escena de ejemplo que ya de por si es casi un impact system, es esta:
$hfs/demo/helpcards/dop/sopsolver/dop_example_sopsolver_dentingwithpops, cmd.
la diferencia es que usa dinámicas, dops, más lento, pero aporta realismo sobre todo si estamos disparando.

Por ejemplo, a un personaje y queremso que este reaccione al impacto, mantiene topologías, dirección del impacto etc.

Con un poco de refinamiento se puede hacer un sistema de impact muy completo usando.

De base esta escena.

Como se nota dónde están los chicos de Houdini.

Por cierto, una pregunta Miguel, cuánta programación te ha hecho falta para hacer este sistema de impactó (scripting, C++). Saludos, a todos.

**slime** · 26-07-2006, 20:56

Slime, cuando te refieres a empieza conectando nodos y luego cuando controles el lenguaje ya puedes hacerlo usando solo un editor, te refieres a empezar usando Vex a pelo y luego el Vex Builder?
En cuento a las ventajas del Vex compilado te estas refiriendo a hacer en Vex Builder lo que hacías en SOP y así pasar a código Vex toda la network de sopsí.

Me refiero a empezar con vops, que lo que hace es generar código, estudiar ese código y cuando se domine, escribir el código Vex directamente, no solo el Vex compilado se puede usar para reemplazar sops de forma mucho más efectiva, también se puede usar para pops. Desgraciadamente dops no permite Vex, aunque si que se pueden introducir scripts en un lenguaje similar al C++. Saludos.

**MiguelPerez** · 26-07-2006, 21:23

Gracias. No he usado nada de códigos de ninguna clase, no fue necesario y además no sé ninguno. Además, esto es muy, pero que muy sencillo, de veras. Y además los digital assets son muy fáciles de usar y muy efectivos.

Lisux, ese ejemplo me lo revisé mucho hace un tiempo, y me sirvió para conseguir esto.

-- IMÁGENES ADJUNTAS --

**lisux** · 27-07-2006, 08:49

Me refiero a empezar con vops, que lo que hace es generar código, estudiar ese código y cuando se domine, escribir el código Vex directamente, no solo el Vex compilado se puede usar para reemplazar sops de forma mucho más efectiva, también se puede usar para pops. Desgraciadamente dops no permite Vex, aunque si que se pueden introducir scripts en un lenguaje similar al C++. Saludos.

Vale entonces el código que genera Vex Builder no es lo suficientemente óptimo?
Si uno examina el código generado por Vex Builder se ve que en cuanto a programación no es lo más óptimo que se querría, esto le pasa a todos los generadores de código, pero la mayoría son cosas que el compilador puede solucionar fácilmente, en este caso se nota mucha diferencia en la ejecución de código de Vex Builder vs Vex escrito?
Si lo de pops ya lo sabía de hecho, ahora mismo estoy trabajando en un Vex pop, en cuanto a lenguaje similar a C++ en dop te refieres a hscriptí o hay algo más para dopsí.

**lisux** · 27-07-2006, 09:00

Gracias. No he usado nada de códigos de ninguna clase, no fue necesario y además no sé ninguno. Además, esto es muy, pero que muy sencillo, de veras. Y además los digital assets son muy fáciles de usar y muy efectivos.

Lisux, ese ejemplo me lo revisé mucho hace un tiempo, y me sirvió para conseguir esto.

Eso es lo que quería escuchar.

Todo eso sin tirar código, me alegro de que vieses esos ejemplos están muy chulos, la verdad es que cuando los estuve viendo es cuando piensas lo potente que son las dops y el intercambio de información entre distintos contextos: dop, SOP, pop.

**slime** · 27-07-2006, 19:05

Vale entonces el código que genera Vex Builder no es lo suficientemente óptimo?

Para cosas sencillas está muy bien, pero en cuanto te metes con loops o cosas más complejas, deja de ser efectivo. En tiempos de ejecución, escribiendo tu el código tienes acceso a más comandos y expresiones, por lo que en algunos casos si que se pueden hacer sistemas más eficientes incluso para temas que no sean complejos.

Si lo de pops ya lo sabía de hecho, ahora mismo estoy trabajando en un Vex pop, en cuanto a lenguaje similar a C++ en dop te refieres a hscriptí o hay algo más para dopsí.

Si, estoy hablando del script Solver usando hscript +, aunque por supuesto también se puede usar la Api para compilar tus propios nodos propietarios. Saludos.

**lisux** · 28-07-2006, 08:55

Para cosas sencillas está muy bien, pero en cuanto te metes con loops o cosas más complejas, deja de ser efectivo. En tiempos de ejecución, escribiendo tu el código tienes acceso a más comandos y expresiones, por lo que en algunos casos si que se pueden hacer sistemas más eficientes incluso para temas que no sean complejos.

Si, estoy hablando del script Solver usando hscript +, aunque por supuesto también se puede usar la Api para compilar tus propios nodos propietarios. Saludos.

En cuanto a lo de usar Vex Builder con cosas complejas estoy de acuerdo, hay es donde yo le pongo el limite, empiezo con vexbuilder y si veo que el tema de programación se va haciendo complejo pongo un inline code Vop y a picar código, si tengo que picar código prefiero usar el inline code Vop que hacerme el código fuera porque luego para que lo pille Houdini tengo que meter los fichero en el directorio Vex, generar el fichero ds de diálogos (aunque lo hace el vcc), vamos que haciendo el código desde vexbuilder ya lo tengo directamente integrado, el único problema es que el editor de texto no es muy, allá, a ver si lo mejoran para la próxima versión, lo que no tenía claro del todo es que el código generado por vexbuilder fuese mucho menos óptimo que el hecho a mano, porque la mayoría de redundancias que genera son eliminadas por el vcc automáticamente, lo del script Solver no sabía que existía, la verdad es que no estoy tan puesto en dops cómo me gustaría. Aunque si es hscript yo diría que se parece muacho más, de hecho, es, Shell scripting, CSH, se parece a c, pero tiene algunas diferencia notables, gracias por la información del script Solver le echaré un ojo.

**MiguelPerez** · 10-09-2006, 15:54

Retomando este tema de hace algún tiempo. Después de ver el ejemplo de Slime, hice el mismo sistema, haciendo el cálculo de las dihedrales y el desplazamiento de los puntos en Vex creando una matriz que sea igual a la dihedral.

Por cierto, Slime, me parece que te equivocaste en la expresión, que en vez de ser (idv*dihedral(onv, anv)), era (anv*dihedral(onv, idv)). O al menos de esta forma evito que las normales tengan un movimiento incorrecto.

El caso es que, ahora lo he hecho directamente en pops, juntándolo en un solo nodo que lo calcula automáticamente seleccionando la geometría de la colisión.

Y aprovechando esto, hice otra escena con impactos, en la que he añadido partículas de polvo.

Adjunto esa escena.

-- IMÁGENES ADJUNTAS --

**MiguelPerez** · 10-12-2006, 17:42

Vuelvo a retomar el tema. En CGtalk se ha resucitado un tema sobre el sistema de Slime, y he querido acabar esto. He juntado todo el sistema y he añadido controles para el polvo con sprites.

Ahora la profundidad de los impactos varía según lo lejos que esté el punto de colisión respecto al arma en el momento del impacto.

Unas imágenes: http://www.miguelperezsenent.com/med...impsys_img.jpg. http://www.miguelperezsenent.com/media/tests/img1.jpg.

Pongo el video que puse en el mensaje anterior. El sistema hace esto, pero más automatizado. http://www.miguelperezsenent.com/med...s/impacts, avi.

Adjunto la otl por si algún houdiniero quiere jugar.

-- IMÁGENES ADJUNTAS --

**MiguelPerez** · 10-12-2006, 19:12

Otra escena rápida: http://www.miguelperezsenent.com/med...s/impacts2.avi.

-- IMÁGENES ADJUNTAS --

**MGue** · 10-12-2006, 20:17

Eres un crak. Puedes aplicar esos impactos a cualquier superficie sin tener que modificar nada en el sistema? Por que no pruebas a aplicar el sistema en alguna escena? Podría quedarte una secuencia muy buena para una futura reel. Un saludo.

**dsolo** · 10-12-2006, 20:21

Es realmente bueno. Cosas que yo veo a mejorar: Eliminar la vibración final de las piedras que se quedan botando indefinidamente. Linux me ha comentado que hay un sistema sencillo para eliminar esto.

Estaría bien desde el punto estético que el tamaño de los agujeros fuera diferente.

**slime** · 10-12-2006, 22:25

Me alegro un montón de que lo hayas llevado un poco más lejos. Este último video está genial. Lo único que veo es que falta integración entre los pedazos (partículas) y el polvo (sprites). Una forma de conseguir que quede mejor es variar más el tamaño de los pedazos e introducir una tercera capa más densa de partículas, más pequeñas para que sirva de nexo entre el polvo y las piedrecillas.

También como dice Dsolo, el tamaño y forma de los agujeros podría variar algo y ser más orgánico (podrías introducir algo de ruido). Un saludo.

**MiguelPerez** · 10-12-2006, 22:37

Gracias. Dsolo, supongo que, Lisux se refiere a pasarlas por un filtro en chops. Eso voy a hacer. Variar la anchura me parece que no es difícil, y como el desplazamiento es Vex, pues no me cuesta nada meterle ruido.

Slime, las piedras tienen variación en su tamaño, pero la aumentaré. No te entiendo bien con lo de otra capa, ¿mas polvo o más trocitos?

**Leander** · 10-12-2006, 22:42

Este pronto estará en una superproducción como supervisor de efectos especiales.

**slime** · 10-12-2006, 23:00

Gracias, Dsolo, supongo que, Lisux se refiere a pasarlas por un filtro en chops. Eso voy a hacer.

Si le pasas un filtro en chops también vas a modificar las trajectorias y en general suavizar las animaciones / movimientos de todas las piedras, que hará que quede menos orgánico y más CG, así que, yo lo que haría seria implementar un sistema de perdida de energía, modificando la velocidad dependiendo del módulo del Vector v y cuando baje de cierto número, que puede variar dependiendo del id de las partículas, la paras totalmente.

Slime, las piedras tienen variación en su tamaño, pero la aumentaré. No te entiendo bien con lo de otra capa, ¿mas polvo o más trocitosí.

En la vida real, el polvo no son más que trocitos microscópicos. En una explosión, o en un impacto, se desprenderan piezas de muchos tamanos, dependiendo de la consistencia y material del objeto afectado, pero en tu simulación hay una diferenciación clara entre microscópicos (polvo) y piedras grandes, así que, pienso que quedaría mejor con otra simulación adicional de partículas que use muchas más, pero que sean más pequeñas para que quede más realista, lo mejor siempre es mirar referencias, - Si existen. - E intentar conseguir algo similar. Un saludo.

**bealobo** · 11-12-2006, 09:27

Muy bueno Miguel. Con las variaciones que te van sugiriendo ya quedará de muerte. (A ver cuándo tengo tiempo yo para acabar el que estaba haciendo en max).

**MiguelPerez** · 11-12-2006, 14:09

Si le pasas un filtro en chops también vas a modificar las trajectorias y en general suavizar las animaciones / movimientos de todas las piedras, que hará que quede menos orgánico y más CG.

Es verdad, no me acordaba de que estuve haciendo pruebas y que al pasar el filtro por puntos botando el movimiento queda fatal. Las trayectorias pasan a parecerse a ondas.

**lisux** · 11-12-2006, 17:05

Otra escena rápida: http://www.miguelperezsenent.com/med...s/impacts2.avi.

Muy bueno Miguel, a ver si saco un ratio y pruebo la otl, estoy de acuerdo con lo de las partículas que comenta Slime, les falta algo de integración, también quizás jugar un poco con el alfa, desaparecen de forma un poco brusca, pero bueno son detalles menores, la herramienta como tal está muy bien ya el resto creo que es ajustar los ruidos y demás, pero para un ejercicio va de sobrado, para los de las chops puedes usar un lag en lugar de un filter, actúa sobre la velocidad de los cambios en lugar de filtrar todo, muy bueno para controlar ciertos movimientos un poco alocados
Las piedras son un RBD ¿no? Lo mismo el autofreze RBD te ayuda a pararlas.

**MiguelPerez** · 11-12-2006, 19:07

Mirad este. He añadido otra capa, y creo que queda mejor. Además, ahora se quedan paradas, Lisux, las piedras son partículas, los agujeros todavía no tienen ruido ni variación de tamaño. http://www.miguelperezsenent.com/med...s/impacts3.avi.

-- IMÁGENES ADJUNTAS --

**slime** · 11-12-2006, 19:45

Mucho mejor. Si acaso, el polvo desaparece demasiado rápido, pero ahora se ve más realista, mejor integrado. Ahora le metes ruido a esos agujeros, que no tardas nada.

**M-TUNE** · 11-12-2006, 23:27

Puta madre que bueno eres miguelin.

**lisux** · 12-12-2006, 00:06

Mirad este. He añadido otra capa, y creo que queda mejor. Además, ahora se quedan paradas, Lisux, las piedras son partículas, los agujeros todavía no tienen ruido ni variación de tamaño. http://www.miguelperezsenent.com/med...s/impacts3.avi.

Si ahora las partículas quedan mucho mejor, si las piedras son partículas, entoncés tendrás que hacer lo mismo que el autofreze, pero con chops, pero vamos ya he visto en le video que ahora ya no vibran y se paran correctamente, queda muy bien.

**dsolo** · 12-12-2006, 06:59

Mirad este. He añadido otra capa, y creo que queda mejor. Además, ahora se quedan paradas. Lisux, las piedras son partículas.

Los agujeros todavía no tienen ruido ni variación de tamaño. http://www.miguelperezsenent.com/med...s/impacts3.avi.

Muy bueno Miguel, siendo muy puntilloso diría que la piedras se quedan clavadas un poco de más en el suelo, una fase en la que deslicen (solo un poco) antes detenerse sería perfecto (en mi opinión). Pero vamos que nada de esto se va a apreciar con estos efectos montados sobre un plano de acción. Las cámaras fijas es que son muy puñeteras.

Estoy deseando ver ese nuevo ejemplo con los agujeros con su noise y su variación de tamaño. Excelente el trabajo que haces y excelente lo rápido que introduces mejoras. Un saludo.

**MiguelPerez** · 12-12-2006, 17:35

Ahí va una con ruido. Dentro de un rato pongo una animación con todo esto más luces en cada impacto, la nueva novedad. Por cierto, Slime, me ha contestado en odforce Alvin yet. Si no recuerdo mal, le ayudaste a hacer su propio script de los impactos para 3ds Max, ¿no? Se ve que está empezando con Houdini.

-- IMÁGENES ADJUNTAS --

**slime** · 12-12-2006, 18:20

Ahí va una con ruido, dentro de un rato pongo una animación con todo esto más luces en cada impacto, la nueva novedad.

Por cierto, Slime, me ha contestado en odforce Alvin yet. Si no recuerdo mal, le ayudaste a hacer su propio script de los impactos para 3ds Max, ¿no? Se ve que está empezando con Houdini.

Yo le metería más ruido, que hay que fijarse mucho para ver que los agujeros no son idénticos, si que ayude a Alvin para montar su sistema de impactos en 3dsmax, ahora voy al hilo ese de odforce, curiosamente está mañana me mando un mail Marc horsfield diciendo que alguien estaba hablando de mi en sus foros. Saludos.

**MiguelPerez** · 12-12-2006, 19:33

Si, Marc también ha respondido. Aquí dejo la animación. He añadido más ruido e implementado el light instancing. A ver qué os parece. http://www.miguelperezsenent.com/med...s/impacts4.avi.

-- IMÁGENES ADJUNTAS --

**dsolo** · 12-12-2006, 19:54

Yo creo que le falta ruido y algo más de variación de tamaño, si es que la tiene. Por cierto, que en los fragmentos de piedras más grandes se aprecia que no rotan y queda un poco raro.

**Caronte** · 12-12-2006, 20:06

El fogonazo va primero y el impacto después (ya sabes 300.000 km/s).

**lisux** · 13-12-2006, 14:33

Yo le metería más ruido, que hay que fijarse mucho para ver que los agujeros no son idénticos, si que ayude a Alvin para montar su sistema de impactos en 3dsmax, ahora voy al hilo ese de odforce, curiosamente está mañana me mando un mail Marc horsfield diciendo que alguien estaba hablando de mi en sus foros. Saludos.

Hey Slime estas con Marc, dale un saludo de mi parte, bueno de parte de Pablo desde España, no sé si se conacordará de mí, vendrásmuy buen tío y muy grande él, estas también con Steven ONG y con marque story? Si es así mándales un saludo de mi parte también, gracias.

**MiguelPerez** · 13-12-2006, 18:52

Caronte, no te entiendo. Ya tengo el sistema por chops que me calcula automáticamente las zonas de subdivisión desde el frame 1 nada más seleccionar la geometría de colisión.

En cuanto a la diferencia de tamaño de los impactos. Yo los hago con un attribute transfer, seleccionando ahí el radio de los agujeros, y me parece que no me deja cambiarlo por diferentes puntos.

Se me ocurre hacerlo copiando esferas en los puntos de colisión y seleccinando con ellas los necesarios en la geometría como bounding object. Lo malo de esto es que el group, si dos esferas se superponen, en la zona que están superpuestas, no me selecciona puntos.

Estoy buscando soluciones.

-- IMÁGENES ADJUNTAS --

**slime** · 13-12-2006, 18:56

Trabajo con Marc y Steven, con Marc ya desde Narnia y Steve me ayudó mucho cuando estaba aprendiendo Houdini. Son unos tipos estupendos. A marque story no le conozco, pero a los otros ahora voy a verles y darles un saludo de tu parte.

**Pepius** · 13-12-2006, 19:19

Muy bueno Miguel me encanta. Sigo tus pasos desde la sombra. Caronte se refiere a que el instanciamento de la luz debe ir ligeramente antes que la modificación de la geometría. Un saludo.

**MiguelPerez** · 13-12-2006, 19:38

Gracias Pepius.

Caronte se refiere a que el instanciamento de la luz debe ir ligeramente antes que la modificación de la geometría.

Y lo va. Un frame antes.

**Caronte** · 13-12-2006, 21:02

Y lo va. Un frame antes.

En el momento en que el fogonazo es visible, ya se ve un poco el agujero. Yo retrasaría el impacto 1 o 2 frames más, aparte del que dices que tiene (que supongo que, se lo come la progresión de apagado a encendido).

Yo haría los agujeros mucho más variados (pero mucho) porque si no parece que en vez de una pared sea metal.

**MiguelPerez** · 14-12-2006, 17:41

Aquí está la variación en el tamaño. El problema con este método es que, si hay dos impactos superpuestos sale mal. Sigo buscando soluciones o alternativas, se me ocurren algunas, pero pesadas. Lo tendré que hacer en pops, ya que los grupos tienen la opción de preserve group.

-- IMÁGENES ADJUNTAS --

**MiguelPerez** · 15-12-2006, 22:13

Un render con más disparos porsegundo: http://www.miguelperezsenent.com/med...s/impacts5.avi.

-- IMÁGENES ADJUNTAS --

**MiguelPerez** · 25-01-2007, 16:34

Aquí estoy otra vez. He cambiado la forma de hacer que los agujeros tuvieran un tamaño variable. Ahora creo que funciona bien. También he cambiado el ruido y he sustituido bastantes nodos por Vex para agilizar la simulación.

Dejo una imagen del sistema en una simple caja. Voy a hacer una escena algo más compleja con objetos volando y eso.

También me gustaría hacer un vídeo mostrando un ejemplo del uso del sistema.

-- IMÁGENES ADJUNTAS --

**bealobo** · 25-01-2007, 16:43

Buenísima pinta Miguel. A por la escena.

**Drakky** · 25-01-2007, 16:45

También me gustaría hacer un vídeo mostrando un ejemplo del uso del sistema.

Y nosotros que lo veamos, adelante, fiera.

**lisux** · 26-01-2007, 09:18

La forma de los agujeros mola bastante, una cosa, aumentas la resolución de la geometría en las zonas donde aplicas el ruido? Con un subdivide o similar?
Si es así, has tenido problemas al renderizar esa geometría?
Lo digo porque yo me he encontrado a veces con ese problema, aumentar la resolución en una parte y entonces se producían artefactos en el render, debidos a un Smooth mal hecho ya que se generan polígonos de más de 4 vértices.

**dixan** · 26-01-2007, 13:56

Es un placer la última animación, está muy logrado.