XSIforum.com

Referencia de conceptos

0 Usuarios y 1 Visitante están viendo este tema.

Re: Referencia de conteptos
« Respuesta #10 en: 22 Diciembre 2010, 21:40:16 »
... Por lo que me ha parecido entender, lo que hacia era generar previamente una variable SCALAR PER POINT (grid.Patata), en donde almacenas el incremento que quieres meter al WEIGHT MAP. Después, en el siguiente puerto del ice_tree, hace un GET de dicha variable y se la aplica al WEIGHT MAP. Parece que hacerlo directamente, no cuela...
Puedes hacerlo directamente sin ningún problema, pero las variables/atributos están para ayudarte y supongo que lo hizo (no conozco el tutorial) porque es mucho más limpio trabajar en tu propio nivel de abstracción, teniendo el cálculo ya luego lo podrás aplicar en un weightmap o en lo que requieras...vamos que es igual que en scripting, si tienes que manipular un valor es mejor meterlo en una variable y reutilizarlo que hardcodear todo directamente, son "buenas costumbres".

Sobre lo del closest location, si, parece un workflow extraño, pero es el mecanismo que han creado para hacer esto... por cierto, no hace falta conectar el pointposition ni nada para obtener las variables, si en el caso del size lo haces con respecto al [0,0,0] (vector por defecto) se calculará sólo 1 vez para todo el objeto y es muuuuuuucho más rápido, tal como lo tienes es bastante más lento porque depende de la topología (se calcula por cada vértice). El concepto de location es bastante más poderoso que sólo una coordenada de intersección, es tu puerta de entrada a los atributos de otro objeto.

Y para pruebas siempre puedes usar el reloj, con él podrás ver cuanto tarda en cada nodo y conexión... es muy útil para rastrear problemas.

Un saludo

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conceptos
« Respuesta #11 en: 22 Diciembre 2010, 22:43:15 »
¿ Te refieres a quitar los GET POINT POSITION que aparecen en la segunda imagen ?. ¿ Si los quito. Como va a saber el ice cuales son los vértices que son impactados por las partículas ?

PD: Acabo de darme cuenta que el titulo era "Referencia de conteptos". Con T. Que fallo XD.

Re: Referencia de conceptos
« Respuesta #12 en: 23 Diciembre 2010, 02:08:34 »
Lógicamente me refiero al primero, el que usas para obtener el tamaño de las partículas, si lo usas sin cutoff obtienes el valor 1 vez (con respecto a [0,0,0]) con el consecuente ahorro de tiempo... tal como lo tienes obtiene el tamaño de las partículas para cada punto del grid.

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conceptos
« Respuesta #13 en: 23 Diciembre 2010, 10:12:17 »
He probado con desenchufar el GET POSITION POINT del primer GET CLOSEST LOCATION, y el resultado me ha dejado un poco intrigado.

Ciertamente va un poco mas ligero en calculos, pero ahora parece que funciona con algunas partículas si y con otras no.

¿ Porque ?

La única diferencia que he visto, es que el primer GET CLOSEST LOCATION ahora es un EXECUTE PER OBJECT. Antes era un EXECUTE PER POINT. Pero a parte de eso ... :P
« Última modificación: 23 Diciembre 2010, 10:25:50 por Quel »

Re: Referencia de conceptos
« Respuesta #14 en: 23 Diciembre 2010, 20:50:08 »
Prueba hacer un log del atributo antes y después del cambio, es una buena forma de encontrar la diferencia y entender los "porques" de las cosas... Una vez que lo encuentres te darás cuenta de que es fácil convertir la información que recibes sin el pointposition al formato "per point" sin tener que recalcular todo por cada vértice del grid ;)

Re: Referencia de conceptos
« Respuesta #15 en: 23 Diciembre 2010, 22:25:32 »
Esa pagina esta anticuada. El manual esta mas actualizado.


Gracias! Aunque lo cierto es que generalmente uso más bien la ayuda del propio Softi, pero nunca viene mal tener el link guardado
Que por cierto ¿se puede acceder al manual online? Es que no consigo llegar al índice/main page

Re: Referencia de conceptos
« Respuesta #16 en: 24 Diciembre 2010, 02:21:59 »

Re: Referencia de conceptos
« Respuesta #17 en: 24 Diciembre 2010, 15:01:09 »
Gracias César!

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conceptos
« Respuesta #18 en: 05 Enero 2011, 12:36:18 »
Tras las fiestas y las pesadas digestiones, es hora de retomar donde lo dejamos. En intentar entender como piensa ICE. Para ello me he propuesto destripar los ejemplos hasta entenderlos. Ni corto ni perezoso, tras husmear en los ejemplos mas fáciles, me propongo desmontar uno de los que, al menos para mi, tienen su chicha.

Voy a comentarlo en publico por si alguien puede corregirme, ampliar o simplemente cotillear (Ademas, el "hablar" en voz alta me ayuda a entenderlo mejor). Para el siguiente ejemplo, voy a usar una de las escenas que se encuentran en el proyecto SAMPLES del propio ICE. Asi que quien quiera puede mirarlo de su propio ordenador.

- Desmontando a Deformation_Bi_directional_Mesh_to_Mesh_Deformation_with_Bulge -

Nota: Antes de empezar, advierto de que el archivo tiene 2 ICE TREEs, uno para el grid y otro para la esfera. En esta caso he deshabilitado el de la esfera y voy a centrarme unicamente en el que se encuentra dentro el grid.
Importante: De momento, todo lo que pongo aquí, son mis propias conclusiones !. Podrían estar mal.

Al abrirlo, nos encontramos con un ICE TREE muy simple. Un COMPOUND con nombre DENT*. Vale, creo que es evidente que tenemos que sumergirnos un poco mas. Testeando en las opciones de este COMPOUND ya se pueden apreciar algunos cambios en el funcionamiento de la escena, pero de momento, no esta muy claro el porque.


- Abrimos el DENT y lo que aparece ya empieza a ser un poco mas respetable. Sin andarnos con rodeos, empecemos a indagar.


- En primer lugar tenemos un VECTOR, un ROTATE VECTOR, el GET DATA kine.global, etc ...
No entiendo muy bien como funciona esto y aun me confunde un poco. Lo que si he entendido es para que sirve. Se utiliza para definir el sentido de "abajo". Sin él, el ICE TREE trabaja con los valores LOCALES del grid. Si lo conectamos, vamos a trabajar en valores GLOBALES, independientemente de si el grid tiene alguna rotación o no.
Seguiré investigando ...

- El primer SET DATA que aparece en la parte superior, tiene una función muy simple. Crear una variable "Self.DeformDistance" con valor por defecto de 0. De momento aun no me queda muy claro como funciona esto. Al crear la variable esta es un SCALAR PER OBJECT, pero mas tarde será convertida en un SCALAR PER POINT. Esta variable será usada para guardar el desplazamiento que aplicaremos a cada punto. Si, porque primero calcula el desplazamiento y lo guarda en esta variable. Después aplica realmente el desplazamiento según el valor de esta variable.
Vease que también se encarga de resetear el valor a 0 tras cada iteración.

- El segundo punto es un PERFORM RAYCAST. Aquí se empiezan a ver algunas de las pequeñas genialidades de este ejemplo. Lo que hacemos en esta parte es calcular que puntos es del grid han sido engullidos por la pelota y guardar en la variable "DeformDistance" (que ahora ya es tratada mágicamente como un SCALAR PER POINT) la distancia entre el punto y el borde de la pelota. Asi que los puntos que no han sido tocados por la pelota, mantienen su valor en 0. Pero para los que han sido engullidos, ese valor cambia según la la profundidad.
Ya nos podemos empezar a imaginar que, si después cogemos estos puntos y los desplazamos hacia abajo en esta misma cantidad, los puntos se quedarán justito en el borde de la pelota.

- Bajando hacia el siguiente paso, nos aparece el CALCULATE BULGE. Mucho ojo en que dice "calcular" no "aplicar". Aquí lo que se hace es un complejo calculo para calcular el Bulge, partiendo de los valores previamente asignados por el PERFORM RAYCAST y almacenados en el "DeformDistance" de cada punto.
Este es sin lugar a dudas, al punto mas complejo del COMPOUND. Busca por cada punto, si sus vecinos mas cercanos han sido empujados por la esfera. De ser así, modifica el valor de "DeformDistance" para lograr el efecto Bulge. Luego lo miraremos mas detenidamente, que el condenado tiene su miga.
Después del CALCULATE BULGE, hay un IF. Supongo que no es necesario explicar que hace y como funciona ;).

- Por acabar tenemos el APPLY DEFORMATION que se encargará de mover realmente los puntos segúun el valor de "DeformDistante". Ese desplazamiento se va a hacer según el eje Y GLOBAL o la NORMAL de cada punto. Va a depender de lo que especifiquemos en las opciones del DENT*.

PD: De momento subo esto, que después ya se lo que pasa. Te peta el navegador y se va todo al traste ^_^.
« Última modificación: 05 Enero 2011, 14:48:32 por Quel »

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conceptos
« Respuesta #19 en: 05 Enero 2011, 13:04:46 »
Sigamos ... Hemos empezado con un rapido vistazo a cada COMPOUND dentro del DENT, pero ahora toca mirar dentro de esos compounds.

Nota: Voy a saltarme el SET DATA, pues no hay mucho mas que añadir.

- Desmontando PERFORM RAYCAST -


Aparentemente no tiene mucha complicación pero este punto me ha sorprendido por una pequeña genialidad. El RAYCAST Coge cada punto de nuestro grid y partiendo de este, lanza un rayo hacia la dirección que previamente ha sido asignada como "abajo". Si toca la pelota, hay premio y nos devuelve la posición en la que el rayo ya tocado el borde de la pelota. Si no, pues nada.

Tardé un rato en comprender porque funcionaba. Si la pelota esta "arriba", ¿ porque lanza los rayos hacia abajo ?. Pues la respuesta es tan simple como ingeniosa. Lo hace porque nos interesa detectar los puntos que ya han atravesado el grid, y esos puntos están POR DEBAJO del grid. De forma que mientras la pelota se mantiene por encima, el HIT del RAYCAST da siempre resultados nulos. Pero en cuando la pelota empieza a atravesar el grid, los primeros empiezan a detectarla y a reaccionar.

Como vemos al final, hay un FILTER. De forma que si el punto no encuentra la pelota, no pasa nada. Pero si ha habido contacto, el SET DATA asigna a la variable "DeformDistance", la distancia que hay entre el punto del grid que estamos tratando en ese momento y el punto que el RAYCAST ha encontrado en el borde de la pelota.

El NEGATE, si no lo he entendido mal, también tiene su razón de ser. Cuando calculamos la distancia mediante el GET DISTANCE BETWEEN, el resultado es positivo(obviamente). Pero nuestra intención es desplazar los puntos hacia "abajo", así que nos interesa guardar ese valor invertido.
Si anulamos este nodo, cuando los puntos tocan la pelota, estos son lanzados hacia arriba, en lugar de abajo.

- Desmontando CALCULATE BULGE -


Esto es lo primero que nos encontramos. Vemos que se trata de un FILTER que controla la modificación final de la variable "DeformDistance". Junto con el AND, tenemos que si se falla alguna delas dos siguientes condiciones, el FILTER se "cierra" y la variable permenecerá intacta manteniendo el valor que se le ha asignado previamente en el paso PERFORM RAYCAST.
· Condición 1; Que la variable "DeformDistance" sea mayor o igual que 0. En realidad, es imposible que encontremos valores superiores a 0. Recordemos que en al inicio la variable fue definida a 0, y que después, lo único que hemos hecho, ha sido restarle un valor X, a aquellos vértices que quedaron engullidos por la esfera. En otras palabras. Todos los vértices que han sido tocados por la esfera, tendrán un "DeformDistance" inferior a 0. Por lo que devolverán un resultado FALSE, quedarán libres del CALCULATE BULGE. Fin.
· Condición 2; Que los puntos se encuentren lejos de la esfera. Como dice el propio COMMENT del a imagen, esto se hace para limitar los cálculos, ya que los puntos lejanos son rápidamente descartados del resto de cálculos. Eliminar esta condición solo relentiza la máquina, pero sigue funcionando igual.


Si nos desplazamos un poquito mas abajo, tenemos mas ...

Para saber si un punto tenemos que elevarlo mucho o no (el Bulge), lo que necesitamos es saber como esta de lejos o de cerca, de los puntos que han sido aplastados por la esfera. Por ello montan el tingalado que hay en la imagen de arriba.
Para empezar un GET NEARBY POINTS nos da todos los puntos que se encuentran dentro del área de influencia, a 2 unidades de distancia. Con esos puntos obtenemos varias cosas.
Primero una ARRAY de SCALARS PER POINT con el valor de la variable "DeformDistance" de cada uno de estos puntos.
Segundo, mediante un GET POINT POSITION, tenemos una ARRAY de 3D VECTORS con la posición de cada uno de estos puntos.
Y tercero, el GET ARRAY SUB INDICES nos crea una ARRAY con los INDICES de la ARRAY de puntos. Un poco confuso, pero no tanto como puede parecer al principio. Si no lo imagino mal, supongo que al tratarse de una array de indices de una array recien creada, lo que tenemos en su interior es ... [0, 1, 2, 3, 4, 5, 6, ... etc].

Bien, para lograr hallar el punto aplastado mas cercano, lo primero que tenemos que hacer es obtener la distancia de todos y cada uno de los puntos cercanos. Por eso tenemos un GET DISTANCE BETWEEN, que nos calcula la distancia entre el punto que estamos tratando en ese momento y cada uno de los puntos del array que obtuvimos con el GET NEARBY POINTS -> GET POINTPOSITION. El resultado es un array de SCALARS, donde cada SCALAR nos da la distancia.
Ahora, usando ese array de distancias ordenamos el array de SUB INDICES que hemos generado prebiamente. Por ello tenemos el SORT ARRAY WHIT KEY. Supongo que lo que hace, es colocar las dos tablas una al lado de la otra (tablas que deben ser del mismo tipo y tamaño), y después mientras ordena una, la que esta en "Key Away" repite los mismos pasos en la otra, en "Array". Al final, obtenemos una array de sub indices, ordenada segun la distancia. Debe de tener un aspecto parecido a esto ... [6, 0, 2, 1, 5, 3, 4, ... etc].
Ahora, usando ese nuevo array de sub indices ordenado, sacamos los valores de uno en uno con el SELECT IN ARRAY y los comparamos con el FIND IN ARRAY. Los vamos chequeando uno tras otro, para comprobar si el "DeformDistance" es inferior a 0 o no (Recuerda que si es inferior a 0, significa que la pelota lo ya aplastado).
El primer punto que encontremos, será el mas cercano. Lo que queríamos, ya que gracias a haber ordenado previamente el array de sub indices por distancia, los chequeamos siempre en orden de cerca a lejos.
Teniendo ya el sub indice del punto aplastado mas cercano, usamo un nuevo SELECT IN ARRAY para mirar en la array de distancias y obtener asi la distancia que separa el punto que estamos tratando con el punto aplastado mas cercano.

Juder ... como se las saben. Pero lo mas curioso de este ultimo tocho, es que no sirve par nada. Pero ahí esta ^_^.

Nota: Voy subiendo esporadicamente lo que escribo, para que no se me pete y lo pierda. Seria un palo.
« Última modificación: 05 Enero 2011, 16:40:51 por Quel »