Mi propio impact system en Houdini

**MiguelPerez** · 07-07-2006, 18:14

Hola a todos, como ha cogido algo más de fama el impact system tool de Slime para 3ds Max, y otras personas tratan de imitarlo, me he decidido a hacer algo parecido, pero en Houdini.

Es una herramienta simple para crear agujeros como los de un disparo y pequeños trozos de piedra. Utiliza la tecnología de los digital assets, de Houdini, que permite automatizar tareas de forma muy fácil. No he utilizado script, y la verdad es que es muy sencillo, no me ha llevado ni 20 minutos, pero sirve para divertirse.

Se controla la posición y rotación del arma, la emisión de disparos, cantidad de disparos, diámetro del agujero, tamaño de los pedazos, su riudo, gravedad, colisión y velocidad.

Pongo un vídeo que acabo de grabar en el que lo utilizo.
http://rapidshare.de/files/25204136/...mple, avi.html.

Y de paso, pongo otra escena en la que he hecho que saliera también sangre de una especie de bicho, y con unos bloques moviéndose (Slime, espero que me perdones por hacer una escena tan parecida a la de tu video de demostración, hasta en el movimiento de los bloques, pero es como mejor queda).
http://rapidshare.de/files/25187066/impacts, rar.html.

-- IMÁGENES ADJUNTAS --

**RavenX** · 07-07-2006, 18:22

Oye. Quiero la verdad. De donde has salido? Tu no tienes 14-15 años. Esto es increíble, tío. Los chavales de tu edad deberían estarcon los amigos en el pueblo y las motocicletas, ligando y de fiesta, y tal.

En serio, quiero conocerte, me das envidia, a tu edad yo era un pringado y tu eres ya un monsturo.

Me gusta, tu impactsiste, y tranquilo, que Slime seguro que está orgulloso que un chico de tu edad esté aprendiendo de su trabajo (y por dentro seguro que le corroe un dita sea, este crío ya me está imitando y quiere sustituirme en Sony imgw.).

De veras, un aplauso, llegaras muy lejos.

**Josich** · 07-07-2006, 18:28

No puedo ver el video, pero me lo imagino, gran trabajo i sigue así. Un saludo.

**bealobo** · 07-07-2006, 18:38

El primer vídeo dice que no lo encuentra, el segundo está muy bien. Intenta hacerte una escena más completa y acabada, que te quedará muy bien.

La sangre que yo voy a hacer* va a ser una cosa menos gore.
*nota: vete a trabajar ya Beatriz.

**MiguelPerez** · 07-07-2006, 19:08

Gracias. Vale, el enlace es este, algo ha pasado.
http://rapidshare.de/files/25204136/...mple, avi.html.

Pero la verdad es que he de mejorarlo. Añadir más cosas como polvo o chispas cuando es metal.

También tiene fallos, por ejemplo, cuando van dos disparos al mismo sitio se ralla y hace cosas raras, porque son operación booleanas en cada impacto. Pero lo mejoraré.

Lástima que no haya muchos houdinieros para probarlo.

**Birkov** · 07-07-2006, 20:40

Está muy bien, pero espero que las booleana de Houdini sean más estables que las de 3ds Max, hace tiempo que no las pruebo, pero cuando usabas booleanas animadas petaba como una escopeta de feria.

**MiguelPerez** · 07-07-2006, 20:50

En Houdini no pasa eso. Mira la imagen. Simplemente se crean los polígonos nuevos y ya. Aunque a veces ocurren cosas por no hacer otras bien.

**slime** · 07-07-2006, 22:46

Hey Miguel, puedes subir la segunda animación sin (*.rar) en otro sitio que no sea rapidshare? Estaría bien que te montases una página web, para ensenar todas estas cosas.

Ahora te pongo un problema de producción real. Si tienes tiempo y te animas, intenta diseñar un sistema. No es muy complicado, pero puede ser un reto divertido para ti:
Tienes un modelo de un personaje animado. Sin modificar la topología (no cambiar el número de vértices, puntos, primitivas.) y sin cambiar la posición de los mismos durante todo el rango de fotogramas, podrías hacer que el impact system generara agujeros, pero según la dirección del disparo en ese momento y que mantuvieran esa orientación en todo momento?
Al sistema le darías, por ejemplo, un objeto y un Vector para representar el arma, o también puedes usar puntos en la geometría del objetivo (personaje) que activar en distintos fotogramas.

Dime como lo ves.

El primer video si que lo vi, pero es algo confuso, se ve el otl, pero no se aprecia cómo funciona. Un saludo.

**bealobo** · 07-07-2006, 23:52

No puedo ver el segundo vídeo, me dice que ha llegado al máximo de descargas.

Generara agujeros, pero según la dirección del disparo en ese momento y que mantuvieran esa orientación en todo momento?

¿cómo para simular un disparo oblicuo?
No acabo de entender el que mantuvieran esa orientación en todo momento, de hecho, estoy pensando a ver a que te puedes estar refiriendo al querer hacer agujeros manteniendo la topología. ¿algo de mapeado normal? Venga Miguel, acepta el reto de Dixan.

**slime** · 08-07-2006, 00:02

¿Cómo para simular un disparo oblicuo? No acabo de entender el que mantuvieran esa orientación en todo momento, de hecho, estoy pensando a ver a que te puedes estar refiriendo al querer hacer agujeros manteniendo la topología. ¿algo de mapeado normal?

Lo de la topología es para instanciar geometría en el modelo.

Lo de la orientación es para que sea realista. Imagínate que disparas una flecha contra un brazo de un tipo y este empieza a moverlo con la flecha clavada. La flecha cambiara de orientación dependiendo del movimiento es algo básico, pero que hay que tener en cuenta.

**Leander** · 08-07-2006, 00:19

¿Y si lo consigue? Prometele curro en Sony.

**MiguelPerez** · 08-07-2006, 01:53

Lo de la topología es para instanciar geometría en el modelo. Lo de la orientación es para que sea realista. Imagínate que disparas una flecha contra un brazo de un tipo y este empieza a moverlo con la flecha clavada. La flecha cambiara de orientación dependiendo del movimiento es algo básico, pero que hay que tener en cuenta.

Tienes toda la razón, la verdad es que me preocupé por ello. Cuando ves las normales de los puntos pegados a la geometría que se mueve, éstas no cambian. Intenté arreglarlo haciendo cosas simples, pero no le di importancia. Simplemente pensé que al no tener demasiado ruido los agujeros, no se notaría que no están orientados correctamente.

Subo el segundo vídeo aquí comprimido con divx, aunque no tiene mucha calidad. Ya tengo una web en iespana, pero tengo puesta la demo y ocupa bastante.

-- IMÁGENES ADJUNTAS --

**bealobo** · 08-07-2006, 11:54

Qué interesante todo esto. Miguel, compra un dominio con hosting. Ahorra la paga o suplica en casa o que se yo. El vídeo está muy chulo por cierto.

**MiguelPerez** · 08-07-2006, 19:58

No lo consigo. Estoy con el point SOP intentando que la orientación de las normales de las partículas esté correcta respecto a las de la geometría con la que colisionan, pero por ahora no he conseguido nada.

Se basa en orientar las normales correctamente ¿no?

**slime** · 08-07-2006, 21:19

Hay varias formas de hacerlo. La más sencilla es guardar el Vector de la normal en el momento del impacto y el Vector de la trayectoria del disparo y ajustar la segunda con la primera fotograma a fotograma. Echa un ojo al ángulo dihedral (trigonometria): http://en.wikipedia.org/wiki/dihedral_angle.

Este problema es interesante para darse cuenta de que en producción, muchas veces las reglas establecidas son muy estrictas. Ánimo que estoy seguro de que conseguirás resolverlo.

Por otro lado, lo que dice Bea es una buena idea, pilla un dominio con hosting y así te empezaras a dar a conocer. Allan Mckay empezó a ser conocido con más o menos tu edad y gracias a su página web y tutoriales. Saludos.

**MiguelPerez** · 08-07-2006, 21:34

Eso es lo que he hecho yo, coger por una parte el Vector de la normal del punto donde impacta, y la normal de la trayectoria. Lo que pasa es que en vez de intentar ajustarlo manualmente cada frame (no sé si te refieres a eso), intentaba hacerlo automáticamente combinando de alguna forma los dos vectores, para que mantengan el mismo ángulo, y así poder haber muchos impactos.

**Josich** · 09-07-2006, 19:39

Me he estado fijando en algunos detalles de vuestros videos. He visto el tuyo Slime que me parece impresionante. ¿cómo hacéis para que se generen las deformaciones de la superficie después del impacto?
He visto una imagen de un Panzer que tiene los puntos con sus subdivisiones ya preparadas para su deformación. ¿pero que ocurre si el lugar de impacto es aleatorio? ¿cómo generáis esa geometría? Gracias.

**MiguelPerez** · 09-07-2006, 19:46

Slime en su herramienta utiliza desplazamiento, y las partes subdivididas se crean al aprieta el botón execute impact system. Le lleva unos segundos calcular, en el que mira donde van a tener que estar las subdivisiones y las crea.

Yo he utilizado operación booleanas, aunque ahora estoy probando desplazamientos.

**MiguelPerez** · 09-07-2006, 20:55

Por ahora voy consiguendo cosas calculando las coordenadas polares de las normales y poniendo fórmulas. Creo que me falta poco.

Por otra parte, el hacer esto con los disparos hechos con booleanas, no es completamente necesario, ya que simplemente se le puede transferir a la partícula la normal del punto de impacto y así estará siempre orientrada. Aunque ya sería necesario si los agujeros fueran más profundos según el Vector de la trayectoria.

**HalfVector** · 09-07-2006, 23:25

A mí se me ocurren varias formas para mantener el proyectil en la posición y orientación a lo largo de toda la secuencia. Pero eso sí, no tengo ni pajolera idea de si se puede aplicar en Houdini.

La más genérica de ellas y que es independiente de si el objeto se deforma (ya sea con Morph targets o Bones) o no se deforma, sería crear un sistema de coordenadas para el polígono donde se produjo la colisión.

Para ello necesitamos una base ortonormal y un origen. La base ortonormal estaría compuesta por el Vector normal del triángulo, una de sus aristas normalizadas y otro Vector que sería el resultado de hallar el producto vectorial entre la normal y la arista. El origen del sistema podría ser perfectamente el punto de colisión.

Una vez tenemos el sistema de coordenadas que define el espacio en relación al polígono, transformamos la posición y la dirección del proyectil por la matriz inversa del sistema de coordenadas que acabamos de definir. Eso nos dará la posición y la rotación en relación a dicho sistema de coordenadas (¿lo llamamos polygon-space?) evidentemente la posición será (0,0,0) si escogimos la posición de impacto como origen del sistema.

Ahora ya sería muy sencillo recalcular la posición y orientación del proyectil en cada frame. Tan sólo habría que volver a hallar el sistema de coordenadas para el polígono en cuestión (tal como he explicado antes) y transformar la posición y dirección del proyectil en polygon-space (que calculamos anteriormente) por la matriz del nuevo sistema de coordenadas del polígono. De esta forma obtendremos la posición y dirección del proyectil en world-space, que es lo que buscamos.

En cualquier caso, éste me parece un método a demasiado bajo nivel. Tal vez Houdini tenga alguna capa superior que facilite está tarea. Saludos.

**MiguelPerez** · 09-07-2006, 23:59

Yo lo que he intentado es calcular la diferencia de cada Vector (el normal y la trayectoria) respecto a los ejes en el frame del impacto, y aplicar el mismo ángulo en todos los frames siguientes. Aun así, no he conseguido la fórmula final necesaria. Creo que se basa en lo mismo que tú respuesta, en aplicar la misma diferencia en cada frame. Si lo que decir es una tontería, no hagas caso.

**slime** · 10-07-2006, 00:11

Esa es la forma a bajo nivel de hacerlo, Halfvector, que, por supuesto se puede aplica en Houdini, pero más sencillo es calcular las dihedrales en los ejes x y, z, grabarlas en una partícula (los sistemas de partículas pueden almacenar información en el tiempo, al contrario que la geometría, que solo se almacena en un fotograma, por culpa del paradigma procedural de Houdini) y luego ajustar las normales con esos ángulos.

Por ejemplo.

Un disparo impacta en el hombro del personaje en el fotograma n. La normal en ese momento del punto de impacto en la geometría es [nx, ny, nz]. La dirección del impacto en ese momento es [ax, ay, az]. Se calculan las dihedrales del Vector [n] con [a] y sale [dx, dy, dz]. Se crea una partícula y se pega en la posición del impacto, guardando el Vector de la dihedral ([d]) y se mantiene constante para ese punto durante toda la secuencia. Para calcular el Vector del impacto en cualquier fotograma, solo tenemos que aplicar la dihedral a la normal en ese fotograma por componentes.

Para que la topología no cambie, en vez de usar booleanas se mueven los puntos en la zona del disparo siguiendo el Vector opuesto al Vector del impacto. Si se subdivide la zona previamente (para toda la secuencia) y se aplican distintas profundidades dependiendo de la distancia al origen y se anyade ruido se pueden conseguir resultados muy buenos sin alterar la topología y que soporten animación en el personaje.

Espero que esto sea interesante. Saludos.

**bealobo** · 10-07-2006, 00:15

Lo es, lo es.

**Stewie** · 10-07-2006, 00:19

Están interesante como complicado. (dónde quedará el bachillerato tecnológico), nada, en realidad se entiende muy bien la idea.

**HalfVector** · 10-07-2006, 00:22

Esa es la forma a bajo nivel de hacerlo, Halfvector, que, por supuesto se puede aplica en Houdini.

Pues si eso se puede hacer con el sistema de nodos de Houdini, debe ser una delicia para un programador gráfico o de física. Menuda maravilla. Saludos.

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

Halfvector, animate a probar Houdini. Seguro que te encanta.

**MiguelPerez** · 10-07-2006, 00:40

¿A qué te refieres con la dihedral entre los dos vectores? ¿un ángulo diedrico no es el ángulo que forman dos planos que se cortan?
¿Te refieres a la expresión dihedral(v0, v1) de Houdini?

**HalfVector** · 10-07-2006, 00:41

Halfvector, animate a probar Houdini. Seguro que te encanta.

Lo cierto es que estuve mirándolo muy por encima durante una semana, sobre todo su sistema de Shaders. Y la verdad es que ya podía atisbar que tenía un potencial muy grande y su workflow parecía bastante amigable para alguien conocimientos de programación.

Pero lo cierto es que, aunque me encanta el lado artístico y técnico del mundo del CG (y alucino y me da envidia ver las cosas que hace la gente de éste y otros foros), al final siempre acabo sumergido entre líneas y más líneas de código. O sea que me imagino que no tengo remedio, soy programador y es difícil que me saquen de ahí.

Pero bueno, como pasatiempos no descarto profundizar algo más con Houdini algún día. Lo cierto es que me gusta ver el funcionamiento de todos los programas que puedo porque después me da ideas para desarrollar mis propios programas. De hecho, Houdini sería un buen ejemplo para desarrollar un buen editor de partículas. Saludos.

**bealobo** · 10-07-2006, 00:47

Ya se ve que disfrutas programando.

**slime** · 10-07-2006, 01:42

¿A qué te refieres con la dihedral entre los dos vectores? ¿un ángulo diedrico no es el ángulo que forman dos planos que se cortan?
¿Te refieres a la expresión dihedral(v0, v1) de Houdini?

Eso mismo. Manana subo un fichero de Houdini.

**HalfVector** · 10-07-2006, 01:46

Por cierto, ahora que sale el tema de las expresiones, cuando estuve probando Houdini no encontré algo parecido al Maxscript Listener para poder probar expresiones. ¿existe algo similar? Gracias.

**MiguelPerez** · 10-07-2006, 11:56

Qué bien. Muchas gracias Slime. He hecho lo que decías de crear los agujeros desplazando los puntos y subdividiendo esa zona. A ver qué os parece.

Se basa en que una esfera copiada en las partículas colisionadas, crea un grupo con las primitias que quedan dentro de ella, y ese grupo se subdivide. Luego, la operación se vuelve a repetir, agrupando finalmente unos puntos, que se desplazan en la dirección opuesta a las normales de la geometría, y posteriormente se suavizan (no se subdividen).

-- IMÁGENES ADJUNTAS --

**HalfVector** · 10-07-2006, 12:35

Posteriormente se suavizan (no se subdividen).

Sí, no sé si Slime lo hizo así en su impact system (me imagino que sí) pero por lo que yo vi, aplicar un MeshSmooth quedaba muy bien, mejor que hacer una teselación en un edit_mesh.

Lo único raro que veo es que debido a la subdivisión, por alguna razón (tal vez pérdida de precisión), no parece que las nuevas coordenadas de textura se interpolen correctamente para los nuevos vértices, lo cual causa un pequeño desplazamiento en la textura.

Donde más se nota es en la zona que he marcado con el círculo rojo, cuando aparece el agujero que hay más arriba, dentro del círculo.

Por lo demás lo veo muy bien. Desde luego no pierdes el tiempo. Saludos.

-- IMÁGENES ADJUNTAS --

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

Si, gracias Halfvector, ya lo vi. Eso pasa por que la geometría se va subdividiendo por cada impacto. Es decir, si en el frame 10 no ha chocado aún la partícula, no estará subdividida, y cuando se subdivida de un frame a otro, producirá esa deformación.

Ahora lo que estoy haciendo es que esté subdividida en las partes que toca desde el pincipio de la animación. Mira que no haberlo pensado antes del render.

**MiguelPerez** · 10-07-2006, 17:13

Como decía, ya está resuelto. Ahora la naturaleza de la geometría es la misma desde el principio al final, y no provoca deformaciones en la textura.

-- IMÁGENES ADJUNTAS --

**Josich** · 10-07-2006, 21:00

La cosa está que arde, ya casi lo tienes. Pero mi pregunta de profano es: y si los impactos fueran aleatorios? Es decir que no supieras donde va a impactar el proyectil? ¿se podría generar una geometría aparte que se solapara sobre el objetivo como un parche?
Si digo alguna tontería con ignorarme ya es suficiente, no os preocupéis estoy acostumbrado a ello.

**slime** · 10-07-2006, 21:06

Estupendo.

(tal vez pérdida de precisión), no parece que las nuevas coordenadas de textura se interpolen correctamente para los nuevos vértices, lo cual causa un pequeño desplazamiento en la textura.

Houdini generalmente interpola los valores de los puntos cuando se genera nueva geometría usando subdivide, pero a veces no funciona correctamente.

Para mantener los mapas UV después de la subdivisión se puede hacer un attribute transfer de antes de la subdivisión a después.

A veces en geometría compleja, la única forma de conseguir que no haya fallos después de subdividir es usar un divide. El divide no hace interpolación así que, hay que regenerar atributos y grupos (de igual forma, con un attribute transfer).

Ya tienes el sistema casi listo, Miguel. La técnica de mover puntos por las normales la tienes que, aplicar ahora a los ángulos correctos. (ahora te mando el archivo). Lo que te recomiendo después de terminarlo es generar algunos de los sistemas con Vex.

Será un buen ejercicio sencillo y puedes empezar con mover puntos en geometría.

**MiguelPerez** · 10-07-2006, 21:19

Gracias Slime. No he utilizado un point para mover los puntos. En este último e utilizado dos software peak, que desplazan los puntos en dirección de las normales y, además se suavizan algo.

Josich, si guardas que primitivas están seleccionadas en el último frame y haces que estén igual en todos, las tienes desde el principio.

Espero ese archivo.

**slime** · 10-07-2006, 21:22

Aquí tienes. Espero que se entienda, que no tengo tiempo para comentarlo en profundidad. Onv = original normal Vector (normal en el momento de impacto / no cambia).

Anv = actual normal Vector (normal de la geometría en este momento).

Idv = impact direction Vector (Vector de dirección de impacto / no cambia).

New Vector:
(vector3($idvx,$idvy,$idvz) * dihedral(vector3($onvx,$onvy,$onvz), vector3($anvx,$anvy,$anvz)))[0].
(Vector3($idvx,$idvy,$idvz) * dihedral(vector3($onvx,$onvy,$onvz), vector3($anvx,$anvy,$anvz)))[1].
(Vector3($idvx,$idvy,$idvz) * dihedral(vector3($onvx,$onvy,$onvz), vector3($anvx,$anvy,$anvz)))[2]. http://www.danielpferreira.com/Houdini/impacts, hip. Saludos.

**slime** · 10-07-2006, 21:24

No he utilizado un point para mover los puntos. En este último e utilizado dos software peak, que desplazan los puntos en dirección de las normales y, además se suavizan algo.

Buena idea lo de usar el peak. Pero imagínate que quieres que quede realista. Los agujeros no deberían ser perfectamente redondos necesita ruido y diferentes niveles de profundidad, incluso en un mismo impacto.

**bealobo** · 10-07-2006, 22:24

Vaya nivel, maripili.

**MiguelPerez** · 11-07-2006, 00:13

Gracias Slime. Pero la escena no tiene geometría. ¿es adrede? Al abrirla me da varios errores, el primero, el switch que hay al principio del pop network.

Aun así, creo que lo entiendo. Ahora lo intento aplicar.

**bealobo** · 11-07-2006, 00:24

Ánimo Miguel. Eres el orgullo de partículas y dinámicas, sigue así.

**slime** · 11-07-2006, 00:28

Miguel, el switch es porque no encuentra un operador propietario. Suele transformarlos en un switch por alguna extraña razón.

Lo de no pasarte la geometría si que es adrede.

A ver si lo consigues hacer funcionar.

**MiguelPerez** · 11-07-2006, 01:55

Vale, lo he intentado. Pero falla al crear el Vector final. Con la fórmula, se crea el atributo del nuevo Vector, pero tiene el mismo valor para x, y, y z en todo los frames.

En todo caso, no sé que geometría va en cada input del popnet. Y aunque he intentado simplemente hacerlo según la teoría, y no imitando tu escena, no estoy seguro de haber elegido correctamente cada Vector. A ver.

Con onv, ¿te refieres al Vector de la normal de la geometría con la que colisiona la partícula, pero que se mantiene siempre igual ya que solo la transferimos en el frame de la colisión?
Con anv, ¿te refieres a el Vector de la normal del punto de impacto, pero que es siempre perpendicular a la geometría, y por lo tanto varía en cada frame?
Con idv, ¿te refieres simplemente a el Vector alineado con la trayectoria, y que siempre apuntara en la misma dirección?

**slime** · 11-07-2006, 02:11

Con onv, ¿te refieres al Vector de la normal de la geometría con la que colisiona la partícula, pero que se mantiene siempre igual ya que solo la transferimos en el frame de la colisión?
Con anv, ¿te refieres a el Vector de la normal del punto de impacto, pero que es siempre perpendicular a la geometría, y por lo tanto varía en cada frame?
Con idv, ¿te refieres simplemente a el Vector alineado con la trayectoria, y que siempre apuntara en la misma dirección?

Eso es. Onv e idv se graban en la partícula, ahora te preparo la escena con geometría. Con un poco de suerte no me echan por no trabajar en lo que debo.

**slime** · 11-07-2006, 03:48

He actualizado el fichero para que funcione, pero hay un ligero problema de orientación, los vectores cambian ligeramente con el movimiento del objeto. Mirándolo rápido no sé dónde está el problema, mañana le echaré un vistazo con más calma, pero te puede servir para ver cómo funciona. Saludos.

**MiguelPerez** · 11-07-2006, 14:16

Gracias. Si, no se orientan debidamente. A ver qué pasa.

**MiguelPerez** · 11-07-2006, 16:22

Al fin, o eso parece. A ver qué tal. Cometía a veces un fallo, no poner al final de la fórmula el [0], [1], y [2] para especificar el Vector.

Perdona que copie la escena, pero al no salirme con una mía, decidí copiar la tuya. Ahora lo aplico en otra.

Me parece que la sombra de los palitos confunde un poco.

Por cierto, Slime, por curiosidad, ¿Qué hacía ese nodo de Sony que se transformaba en un switch? Y ¿Qué es lo que te tocaba hacer mientras hacías la escena del ejemplo?

-- IMÁGENES ADJUNTAS --

**slime** · 11-07-2006, 19:52

Ese nodo era para generar partículas a partir de puntos en espacio SOP, heredando valores de los mismos. Estos días estoy intentando conseguir que partículas sigan la animación que yo quiera a la vez que están restringidas a una superficie tridimensional. Es un tema complicado, porque son muchos millones de partículas y el sistema tiene que ser rápido.

**MGue** · 11-07-2006, 20: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, 21:46

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

-- IMÁGENES ADJUNTAS --

**slime** · 11-07-2006, 21: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, 22: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** · 12-07-2006, 00: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** · 12-07-2006, 00: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, 09:45

Miguel, está genial.

**essmigol** · 13-07-2006, 10: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, 10: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, 21: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, 22: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, 09: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, 10: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, 20: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, 09: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, 16: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, 18: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, 20:12

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

-- IMÁGENES ADJUNTAS --

**MGue** · 10-12-2006, 21: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, 21: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, 23: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, 23: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, 23:42

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

**slime** · 11-12-2006, 00: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, 10: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, 15: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, 18: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, 20: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, 20: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** · 12-12-2006, 00:27

Puta madre que bueno eres miguelin.

**lisux** · 12-12-2006, 01: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, 07: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, 18: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, 19: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, 20: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, 20: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, 21:06

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

**lisux** · 13-12-2006, 15: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, 19: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, 19: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, 20: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, 20: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, 22: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, 18: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, 23:13

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

-- IMÁGENES ADJUNTAS --

**MiguelPerez** · 25-01-2007, 17: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, 17:43

Buenísima pinta Miguel. A por la escena.

**Drakky** · 25-01-2007, 17: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, 10: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, 14:56

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

**MiguelPerez** · 26-01-2007, 15:13

Gracias.

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.

Si. Con chops averiguo desde el primer frame la zona donde van a haber agujeros y se subdividen con un subdivide, la geometría queda así: .

me parece que a mí no se me crean polígonos de más de 4 vértices, pero sí que he visto algún artefacto.

Una escena de prueba: http://www.miguelperezsenent.com/med...mpacts_ts1.avi.

-- IMÁGENES ADJUNTAS --

**slime** · 26-01-2007, 19:47

Si que se pueden aparecer problemas con el subdivide, al crearse polígonos de más de cuatro vértices, o estropearse zonas de la malla, aunque hay varios algoritmos dentro del nodo y distintas opciones. La mejor opción para evitar eso es subdividir con un divide, que tiene una opción para ello (no la de bricker, que genera topología variable).

El único problema del divide es que no se produce una promoción de atributos, y transferir las UVS en un personaje es difícil, ya que esos datos se alojan en los vértices, con distintos valores por vértice (recordad que cada punto tiene varios vértices dependiendo del número de aristas). Al hacer un attribute promote, esos valores se interpolan, y al estar los vértices en el mismo punto espacial, todos ellos adquieren el mismo valor UV, por lo que se producen artefactos en la textura.

Después de este, la verdad es que la última prueba está genial, los agujeros los veo perfectos, aunque ahora se ve como los trozos son demasiado uniformes y tienen una densidad muy similar en cada impacto, además de que rebotan de una manera demasiado parecida. Esas cosas no se suelen notar con una iluminación correcta, pero sí que se ven en esa prueba. Un saludo.

**MiguelPerez** · 26-01-2007, 20:15

Te refieres a la opción Smooth Polygons ¿no? Lo he probado y no me estropea la malla de algunos objetos curvos como el subdivide, no sé si afectara, pero el divide también crea polígonos de más de 4 lados: http://www.miguelperezsenent.com/med...cts/divide.jpg

He hecho una chorrada de integración con una imagen real que he encontrado por Google (aquí en Valencia llueve a cantaros, cuando pare, saldré a fotografiar alguna fachada).

No queda muy bien, lo sé, lo he hecho en un rato, pero me ha servido para entender mejor la proyección de cámara con Houdini.

-- IMÁGENES ADJUNTAS --

**slime** · 26-01-2007, 21:10

Te refieres a la opción Smooth Polygons ¿no? Lo he probado y no me estropea la malla de algunos objetos curvos como el subdivide, no sé si afectara, pero el divide también crea polígonos de más de 4 lados: http://www.miguelperezsenent.com/media/impacts/divide. Jpg.

.[/quote]Si que es verdad, lo acabo de probar, aunque eso no es un problema, hace ya un año que termine ese sistema, así que, no me acuerdo de algunas cosas.

He hecho una chorrada de integración con una imagen real que he encontrado por Google (aquí en Valencia llueve a cantaros, cuando pare, saldré a fotografiar alguna fachada).

No queda muy bien, lo sé, lo he hecho en un rato, pero me ha servido para entender mejor la proyección de cámara con Houdini.

Queda bien, aunque necesitas más luz de ambiente y el polvo debería de ser de color similar a la fachada, si te haces con una cámara progresiva, puedes grabar a un amigo disparando contra algunas fachadas y luego hacer un matchmove de la escena y poner los efectos.

**MiguelPerez** · 27-01-2007, 19:15

La verdad es que el divide es bastante más rápido que el subdivide. Aquí otro intento de integración en una pared cercana a mi casa: http://www.miguelperezsenent.com/med...mpacts_la2.avi.

Mañana cogeré la videocámara y haré un matchmove.

-- IMÁGENES ADJUNTAS --

**MiguelPerez** · 27-01-2007, 21:12

3dpoder, no hace falta que me edites el mensaje para poner el vídeo adjunto en (*.rar), no me importa tenerlo en mí hosting.

**3dpoder** · 27-01-2007, 21:16

Hola Miguel, estaba repasando este hilo, y he visto que en los mensajes del principio no funcionaban las imágenes, así que, he decidido mirarlo de principio a fin y adjuntar todo aquello que pudiera, para no perder más datos, es importante que la documentación gráfica se adjunte al hilo en cuestión, aunque se utilicen otros links, ya que, con el tiempo, todo lo que no está adjunto al foro, sea por un motivo u otro, se acaba perdiendo, un saludo amigo, y esplendido trabajo.

**MiguelPerez** · 27-01-2007, 21:24

Si, tienes razón, al final se acaba perdiendo. Gracias entonces, tremendo trabajo de adjuntar.

**Leander** · 28-01-2007, 00:44

¿Cómo se va a colgar tus experimentos en webs ajenasí eso sería sacrilegio. Las joyas se quedan aquí en 3dpoder.

**MiguelPerez** · 28-01-2007, 21:47

Gracias Leander. Aquí otra escena toda CG. Esta vez con texturas. A ver qué os parece. http://www.miguelperezsenent.com/med...mpacts_ts2.avi.

-- IMÁGENES ADJUNTAS --

**lisux** · 29-01-2007, 10:55

Gracias Leander. Aquí otra escena toda CG. Esta vez con texturas. A ver qué os parece. http://www.miguelperezsenent.com/med...mpacts_ts2.avi.

Esá muy bien, sobre lo de las subdivisiones te lo pregunte porque yo tuve un problema parecido y me estuve cvomiendo la cabeza a ver cómo lo podía solucionar, en los puntos de los impactos la imagen flickea y en la frontera entre polígonos subdivididos y sin subdividir esta generando N-Gons que son muy difíciles de controlar, yo al final desistí de subdividir por zonas, por unas rtazones o por otras dan problemas y como la geometría es procedural es un tema difícil de solucionar, la mejor opción yo creo es que uses el Vex que deforma en SOP y hagas un Shader de desplazamiento, si la deformación la creas con un Shader de desplazamiento el problema de aliasing lo tendrás solucionado.

**MiguelPerez** · 30-01-2007, 18:02

https://www.foro3d.com/showthread.php?t=43886.

**MiguelPerez** · 01-02-2007, 20:08

Una integración con matchmove y todo. Esta comprimido y no tiene demasiada calidad, pero se ve bien. http://www.miguelperezsenent.com/med...nimpactsdx.avi.

-- IMÁGENES ADJUNTAS --

**slime** · 02-02-2007, 04:45

Hey, muy bueno. El suelo está un poco of pero la pared queda de maravilla con los agujeros. El polvo yo lo haría menos denso y de color más parecido a la pared (ten en cuenta que se produce por partículas minúsculas de pared que se quedan suspendidas en el aire) y haría que tuviera más variaciones de forma, que no fuese tan parecido entre uno y otro impacto. Los pedazos que caen también son demasiado uniformes entre los disparos. Con más variación, más aleatoriedad quedaría más realista, pero vamos, que al ponerlo al final de la demostración ya gana muchos puntos así.

**essmigol** · 02-02-2007, 12:05

Lo veo estupendo Miguel, tiene razón Slime sobre lo que dice del polvo y eso. Enhorabuena tío.

**RavenX** · 02-02-2007, 12:14

Genial, no es perfecto, pero es sencillamente genial, este chico me asombra. Editado y añadido: nos va a sobrepasar a todos, vas a ser uno de los grandes, ya lo veras.

**MiguelPerez** · 02-02-2007, 14:53

Me alegro que os guste. Gracias RavenX. A ver qué tal con esas correcciones.

**MiguelPerez** · 02-02-2007, 15:50

A ver qué os parece ahora el polvo: http://www.miguelperezsenent.com/med...impacts2dx.avi.

-- IMÁGENES ADJUNTAS --

**RavenX** · 02-02-2007, 15:58

Vale, en cuanto a color, me gusta más, pero las partículas de polvo, deberían estar más en escena, durar más, y que se evaporen mucho más despacio.

Que se queden como suspendidos en el aire, expandiéndose lentamente.

Como si fuese niebla. Imagina una mesa llena de polvo, y lo soplas, como reacciona el polvo en el aire? Cuánto tiempo se sustenta? Pues algo parecido. Ya sé que estas partículas deben pesar más que el polvo en sí, pero el efecto puede ser igual.

Que me corrijan si es necesario, pero es como creo que podría ser.

**slime** · 02-02-2007, 19:51

De acuerdo con RavenX. Y añadir de paso que las sombras no deben de ser negras, especialmente del polvo. En los agujeros entra menos luz, pero en el polvo si que incide mucha luz que rebota del suelo y otros objetos, así que, en vez de negras, las sombras deberían de ser de color ambiente, algo azuladas por el cielo y anaranjadas por el entorno.

Venga, trabaja más el siguiente update, a ver si nos puedes convencer que lo que está ocurriendo es real en vez de 3d.

**MiguelPerez** · 02-02-2007, 21:57

El polvo si que incide mucha luz que rebota del suelo y otros objetos, así que, en vez de negras, las sombras deberían de ser de color ambiente, algo azuladas por el cielo y anaranjadas por el entorno.

¿te refieres a las sombras que se autoproyecta el polvo, o a las que proyecta contra la pared?
Si mañana sale un día parecido al del vídeo, salgo a la misma hora a tirar piedras y arena y lo grabo mejor referencia imposible.

**slime** · 02-02-2007, 23:16

¿Te refieres a las sombras que se autoproyecta el polvo, o a las que proyecta contra la pared? Si mañana sale un día parecido al del vídeo, salgo a la misma hora a tirar piedras y arena y lo grabo mejor referencia imposible.

A las sombras en general, las del polvo en sí mismo, las de las piedrecillas en la pared y el suelo, lo mejor es lo que has dicho, que salgas a tirar pedradas a una pared y grabarlo en video. También puedes taladrar agujeros y meter petardos potentes. Solo ten cuidado de que no te pillen. Todo sea por el bien de los efectos especiales.