XSIforum.com

Referencia de conceptos

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

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Referencia de conceptos
« en: 22 Diciembre 2010, 12:57:03 »
Buenas a todos/as.

Ya he intentado testear con el ICE muchas veces. En esta ocasión (ultimo mes), parece que estoy llegando bastante mas lejos de lo que otras veces. Cosa que se agradece. ¡¡ Pero aun así, a menudo me pasa algo que ODIO !!.
No me basta con lograr hacer el efecto que quiero, además quiero entender porque. Quiero ser capaz de señalar cualquier nodo al azar y poder decir claramente porque ese nodo esta allí y porque debe estar. Esto es algo que aun no logro. Demasiado a menudo hago cosas porque "las he visto en tutoriales" o porque "fulanito dice que asi fucniona". No me conformo con eso.

Vale, basta de charla. Lo que busco es si existe alguna guia/manual/referencia de cuales son los CONCEPTOS del ICE.

¿ Que es exactamente un LOCATION ?
¿ o que se entiende por POINT ? ¿ y PARTICLE ?
¿ Porque a veces la geometría son POINTS y las particulas son GEOMETRY ?
¿ A que nos referimos exactamente cuando hablamos de POSITION ?
¿ SOURCE ?
¿ y el Out/In NAME ?
¿ Porque a veces un SCALAR PER POINT no es igual que otro SCALAR PER POINT, y no se pueden unir ? ¿ no son lo mismo ?
y un largo etc de preguntas que me gustaría poder responderme a mi mismo antes de ir por ahí preguntando una a una ...

He encontrado tutoriales que de hacen preciosos efectos. Efectos que logro repetir a base de hacer lo mismo que muestra el tutorial. Como si fuese un robot. Pero siempre se omite esos conceptos básicos. Se dan por enterados o directamente no se deben considerar importantes.

He mirado por internet, algunos foros y en la documentación (F1) del ICE, pero allí también omite eso, o no lo he sabido encontrar.

Gracias
« Última modificación: 22 Diciembre 2010, 22:28:47 por Quel »

Re: Referencia de conteptos
« Respuesta #1 en: 22 Diciembre 2010, 14:40:07 »
¿ Que es exactamente un LOCATION ?
Es el equivalente a un PointLocationData del SDK, en la documentación viene bastante bien explicado :)

PointLocatorData object represents a collection of point locators. A point locator is a geometric surface coordinate, and represents a precise location on a geometry. Point locators are topologically defined, so they are not dependent on the position or the deformation of the geometry (they "stick" to the surface). The actual data defining a point locator is abstracted and depends on the geometry type.

Point locators are a generalization of Points. As points, point locators can be processed independently from the geometry type. Like point indices, point locators are not related to a particular geometry instance. You can query any geometry having the same topology with the same PointLocatorData. For instance, you can use point locators to evaluate positions of an animated geometry at different times.

Citar
¿ o que se entiende por POINT ? ¿ y PARTICLE ?
Nuevamente, es un concepto que viene del SDK...

A Point is a generic object used to access a Vertex (PolygonMesh) or a ControlPoint (NurbsSurfaceMesh or NurbsCurveList). Having a generic object allows you to write code to traverse an object's geometry without resorting to special case handling for specific geometry types.

Citar
¿ Porque a veces la geometría son POINTS y las particulas son GEOMETRY ?
¿Puedes dar un poco más de contexto?

Citar
¿ A que nos referimos exactamente cuando hablamos de POSITION ?
¿Donde? ¿PointPosition? es un vector 3D por partícula/punto (un set) que define las coordinadas de posición local XYZ (dentro del espacio del objeto al que pertenece). ¿Te refieres a eso?

Citar
¿ SOURCE ?
La fuente de información... muchas veces necesitas extraer información implicita que no tiene un "nombre" (pe un location), mediante este puerto puedes acceder a ella.

Citar
¿ y el Out/In NAME ?
Es un mecanismo hecho para "componer" el fullname del attributo al que quieres llegar, de esa forma es más fácil isolar la lógica y reutilizarla.

Citar
¿ Porque a veces un SCALAR PER POINT no es igual que otro SCALAR PER POINT, y no se pueden unir ? ¿ no son lo mismo ?
Necesito más contexto acá también. ¿será porque pertenecen a distintos objetos y no hay una relación directa entre ellos como para que el software la entienda? ¿será porque tienes que meter un "switch context" entre ellos?

-----

Si pudieras complementar un poco más las preguntas para entender exactamente a que te refieres seguro se podría precisar más aún, pero a nivel general es eso lo que se me viene a la cabeza O0

Un saludo

Re: Referencia de conteptos
« Respuesta #2 en: 22 Diciembre 2010, 15:23:07 »
Madre mía César, yo todo me lo guardo :D

Quel, a mí me pasa exactamente lo mismo que tú. Es más, he empezado varias veces, pero como no llegar a entender en la mayoría de los casos que estoy haciendo (como para reproducirlo por mí mismo), pues cuando lo dejo por trabajo y vuelvo a retomar es como empezar de nuevo. Y así una y otra vez xD

Sobre guías supongo que ya lo habrás visto, pero por si acaso esto alguna vez me ha echado una mano
http://softimage.wiki.softimage.com/index.php/ICE_Attribute_Reference

Además había unos tutoriales de DT, que analizaban casi uno por uno los nodos (los del primer ICE y los más básicos), el problema es que está completamente en inglés claro, pero si quieres puedo buscar cual era

alanf

  • *****
  • 6026
  • Pipeline Developer @ Felix & Paul Studios
Re: Referencia de conteptos
« Respuesta #3 en: 22 Diciembre 2010, 15:25:23 »
Sobre guías supongo que ya lo habrás visto, pero por si acaso esto alguna vez me ha echado una mano
http://softimage.wiki.softimage.com/index.php/ICE_Attribute_Reference
Esa pagina esta anticuada. El manual esta mas actualizado.

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conteptos
« Respuesta #4 en: 22 Diciembre 2010, 17:43:09 »
Vale. Gracias por las respuestas Cesar, pero esas solo eran preguntas un poco a la tun-tun. Sin ser ningún caso especifico.
Por ejemplo estoy teniendo algunos problemas con los Weight maps.

GET ---> SET; Guay .. no hace nada per al menos se deja.
GET ---> ADD -X-> SET; Ya no le gusta. El SET se niega a aceptar la conexión.

Pero en fin. Esto es solo uno de las docenas de cosas incomprensibles que he encontrado de momento. Supongo que para cuando uno entiende como funciona, lo verá muy lógico. Pero de momento a mi me parece absurdo y sin sentido ???.

De momento creo que el enlace que ha puesto alanf es mas o menos lo que buscaba. Tras un par de horas ojeandolo, mas o menos me resuelve algunas preguntas, pero otras aun no. De momento intentaré seguir por mi cuenta y cuando me canse de dar cabezazos al monitor, ya os preguntaré por aquí.

alanf

  • *****
  • 6026
  • Pipeline Developer @ Felix & Paul Studios
Re: Referencia de conteptos
« Respuesta #5 en: 22 Diciembre 2010, 18:15:39 »
Los ejemplos que pones son cripticos. ???

Di que quieres hacer y muestra el icetree de tu intento.

Re: Referencia de conteptos
« Respuesta #6 en: 22 Diciembre 2010, 19:00:52 »
Está muy bien este hilo. Deberíamos retitularlo como 'ICE for dummies'...
ICE es programar, por lo que en él se habla un idioma que los que ya venían de scripting les es más fácil entender.
Al resto de los mortales, que nos cuesta saber qué podemos esperar de un nodo 3D Vector o de un Multiply, un hilo así nos puede ser muy útil :-)

Re: Referencia de conteptos
« Respuesta #7 en: 22 Diciembre 2010, 19:02:15 »
Hombre, está claro que el problema está en lo que intentas sumar... Si mis bola de cristal no falla diría que estás intentando sumar un array de datos a un set.

Los weight vienen en lo que se denomina set, que no es más que 1 "valor" (sea lo que sea) por punto... los array por el contrario representan un conjunto de "valores" por punto. Si los intentas sumar obtendrás como resultado un array ya que ICE sumará a cada elemento del array el valor del set correspondiente. Si luego intentas setear eso en el weight (que espera 1 escalar por punto) es lógico que no lo acepte.

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conteptos
« Respuesta #8 en: 22 Diciembre 2010, 20:06:30 »
No es que este buscando ningún efecto en particular. Como ya mencioné, estoy testeando al azar e intentando entender porque ocurren las cosas. Cuando sale bien, ¿ porque ?. Y cuando sale mal ¿ Porque ?. Pero si con un ejemplo consigo explicarme mejor ... pues podemos decir que:
Quiero que una pelota (o particula de X tamaño) pase a traves de un GRID con mucha densidad de vertices, y al hacerlo, modifique el WEIGHT MAP. Ya sea añadiendo un incremento o un valor concreto. Modificandolo, vamos.
No es que quiera hacer nada con el weight map concreto. Pero quiero que lo modifique.

Antes lo he logrado hacerlo siguiendo un tutorial, pero sin quedarme claro como va. 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. Tienes que usar esa variable de intermediario por alguna razón que no entiendo.

Podría ser algo parecido a lo que comenta Cesar. Aun que me sigue confundiendo el tema.

No se si el problema esta en que al intentar hacer un SET sobre un WEIGHT MAP, me dice que el execute es un EXECUTE PER OBJECT. Si eso intento enlazarlo en algún a rama que sea EXECUTE PER POINT. Me dice que no.



El archivo de pruebas que estoy haciendo, lo voy improvisando sobre la marcha. Lo que empezó siendo un simple surtidor, se ha convertido en esto ...


Es un emisor de particulas de distintos tamaños.
Estos caen sobre un grid.
Al impactar, dichas particulas se eliminan.
Antes de hacerlo. Dejan un mancha en el COLOR del grid (que ahora no se ve, pero esta ahí).
También toca el WEIGHT MAP. Pone el peso de los vertices tocados a 1. (<- Pero esta aprte es la que funciona sin saber muy bien porque.)
Al mismo tiempo, hacen un pequeño agujero, dependiendo del tamaño de la partícula que lo genera.

Algunos de los problemas curiosos que me he encontrado, ha estado por ejemplo. Al calcular la colisión de las partículas con el gid. Ya que no todas las partículas son igual de grandes.
Si el al CUTOFF DISTANCE del GET CLOSEST LOCATION le ponía un valor muy bajo. Algunas partículas gordas impactaban con el grid y morían, antes de que el propio grid se diera cuenta. Asi que no reacciónaba a la colisión. Si le ponía un valor muy alto, ademas del coste en calculos, me encontraba que las partículas mas pequeñas dejaban "rayas" sobre el grid. Pues estas eran detectadas por el grid, mucho antes de tocarlo morir.
Asi que la solución fue, enlazar el CUTOFF DISTANCE con el tamaño de cada partícula. Lo bueno es que funciona. Lo malo es que para hacerlo, tengo que usar otro GET CLOSEST LOCATION.


Es decir. Si no lo he entendido mal, con el GET CLOSEST LOCATION original, funcionaria. Pero el problema es que el GET SIZE necesita de un SOURCE. Y la unica forma que he encontrado de darle ese SOURCE es con otro GET CLOSEST LOCATION.
Es una solución muy absurda. Lo se XD. Pero aun así no me preocupa arreglarlo. Me gustaría saber porque me tiene que resultar tan complicado obtener el tamaño de las partículas. ¿ Hay alguna forma mas limpia de obtener ese SOURCE ?

PD: De momento no pongo el resto del ice_tree porque esta muuuy guarro y caótico. En cuando lo arregle un poco, ya lo subiré.
« Última modificación: 22 Diciembre 2010, 20:12:02 por Quel »

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conteptos
« Respuesta #9 en: 22 Diciembre 2010, 20:15:11 »
Que conste en el ejemplo anterior. Que me interesa mas saber el porque las cosas me fallan o me van bien, mas que saber si hay alguna forma mas "directa" de lograr ese efecto.
No intento conseguir un efecto concreto. Lo que intento es, entender como piensa ICE ;).

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 »

Quel

  • **
  • 223
  • Si la vida no te sonrrie, cuentale un buen chiste.
Re: Referencia de conceptos
« Respuesta #20 en: 05 Enero 2011, 17:43:20 »
Cuando mas me miro eso del CALCULATE BULGE, menos lo entiendo ... Toda esta tontería de los arrays es muy bonita, pero no funciona.