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 ;).