--- En spain_lw@yahoogroups.com, "roque" <rgp@...> escribió:
>
> Hola Gerardo, hace unos dias andaba pidiendo en la lista si alguien
podia
> pasarme el ASA buffer saver, no lo he encontrado en la web, seguro
tu me
> puedes dar una mano, lo tendras por ahi?
>
> Abrazo, Roque
>

Hola Roque,

Estuve desconectado hace algún tiempo y no vi tu post.  En este
thread:

http://forums.cgsociety.org/showthread.php?f=5&t=646988&p=5232292

xchrisx comparte el plug.  Déjame ver si tengo aquí una versión más
reciente y te la envío.  Por cierto, ya es un plugin descontinuado,
lo necesitas por el RSMB?

Un abrazo,



Gerardo

--- En spain_lw@yahoogroups.com, Alejandro <alejandro.bahamondes@...>
escribió:

> Uf! Ya veo ya... Pero que le vamos a hacer... Esto es 3D.
> Ya me he acostumbrado a que los viajes de exploración en 3d son
laaargos y
> llenos de detalles y luego vienen las pruebas, pero algo tiene que
hace que
> uno insista...
> Gracias por el link... Saludos, Alejandrowsky.
>


Y qué historia! :) aunque esto ya es off-topic, esta técnica puede
mezclarse con casi cualquier otro método de iluminación, pero como
referencia para el valiente que aun la quiera probar, he notado que
para mucha gente esta técnica es más viable para resolver 3 de los
siguientes escenarios típicos de iluminación (de menor a mayor
complejidad):

1.  Resolver la iluminación indirecta (comunmente mezclada con IBL)
de personajes que se mueven en escena.  Entendiéndose por personaje
cualquier 'cosa' que se mueva en escena.  En realidad en este
escenario se trabaja integrando un elemento CG sobre un fondo también
CG, pero resuelto con otra solución de iluminación.

2.  Resolver la iluminación indirecta (comunmente mezclada con IBL
y/o texturas frontoproyectadas), de escenas de exteriores (outdoors),
en Planos Generales de algunas escenas puede incluso ser viable para
masivas escenas de exteriores.

3. Resolver la iluminación indirecta de interiores (indoors)
comunmente mezclada con alguna solución nodal de oclusion ambiental

La técnica es ahora mucho más simple gracias a la versión nodal del
SG_AmbOcc:
http://www.newtek.com/forums/showthread.php?t=61465
(FI'sLocalAmbient ya no es necesario en el sistema nodal).  Sebastian
Goetsch tuvo la brillante idea de automatizar el proceso en su
AmbOcc, pero el render es más lento que un setup montado por el
usuario.  De hecho, el render de un setup montado por el usuario es
aún más rápido que la radiosidad de LW 9.5.  El tiempo para el setup
depende de la escena (y el usuario).

El tutorial (que por las herramientas notarás que ya es antiguo),
pretende resolver el escenario más trabajoso (interiores), pero como
vemos, no es su única o principal utilidad.  La técnica fue
especialmente útil hace unos 3-4 años para el trabajo de VFX, ya que
permitía tener una pasada limpia de iluminación indirecta para
componer en post-producción, cosa que no podía lograrse con la GI
real (en estos días esto es logrado con mucho mayor facilidad con el
DP Filter y funciona con GI real o cualquier otra técnica de
iluminación).

Hay situaciones sin embargo en que usar radiosidad real puede ser una
mejor opción, sobre todo en escenas extensas de arquitectura de
interiores con mucho mobiliario, en el que Kray hace un trabajo
notable, y en buenas manos, en tiempos aún más notables.

Saludos,



Gerardo

--- En spain_lw@yahoogroups.com, Ana <yuldark3@...> escribió:
>...acordaros si no de cuando hablar de
> radiosidad era algo impensable en lw y la tecnica de Gerardo para
la simulacion de
> esa iluminacion con gradients..todavia hay gente por todos sitios
que no da credito
> a la tecnica.

Hey! la técnica es muy buena! lo que pasa es que nadie puede terminar
de leer el tutorial :)

Pero sí, muy de acuerdo con lo de la importancia de la mano que usa
la herramienta (en esta y muchas otras cosas).  Y en ese sentido
pienso que cada uno debe saber encontrar soluciones propias
(personales o de equipo) que, como decía al final de ese tutorial, no
necesariamente reproduzcan resultados exactos, sino globalmente
agradables y creíbles.  Que pienso tiene también que ver con lo que
comentaba Javier al final de su post.

Lo de la técnica de gradientes es curioso porque es un caso típico de
soluciones propias.  Aun la uso por aquí y sí, a mucha gente no le
gusta - de hecho algunos la destestan - aunque tengo entendido (al
menos hasta antes de la v9.5) que al menos un par de casas de VFX la
usaban para resolver algunos planos específicos.  Supongo que la
facilidad de su aplicación se debe en mi caso, a que precisamente fue
una solución general de iluminación propia (y probablemente a unos 14
ó 15 años de experiencia con LW).  Pero he visto también quienes
tienen 'buen ojo' para algunas o varias tareas y pueden lograr
resultados muy buenos o realmente impresionantes sin excesiva
experiencia.  La investigación, experimentación y adaptación de
soluciones propias sin embargo, son siempre una constante.

Saludos,



Gerardo

Hola Javier,

Sería muy interesante si puedes encontrar un tiempo en algún momento
y comentar más sobre el modelado procesal de Houdini (que he
escuchado es uno de sus mejores rasgos)  y por supuesto, esas cosas
que hacen de Houdini insuperable en dinámicas de hard bodies.

Saludos,



Gerardo


--- En spain_lw@yahoogroups.com, "javier -" <javier@...> escribió:
>
> Pues ya que Gerardo lo menciona, la verdad es que en el lado de
Houdini no
> hay tanto que comentar respecto a telas en concreto. Sí es cierto
que las
> Cloth dynamics en Houdini dan mucho más control que en Lightwave,
pero
> considerando que es un software especializado en efectos, creo que
son
> bastante mejorables aún (es moderadamente interesante el hecho de
que las
> dinámicas de rígidos de Houdini sí son las mejores que he visto
nunca, pero
> las de telas no son tan buenas).
> De hecho también existe una versión de Syflex para Houdini. Syflex
no es lo
> más realista que hay o puede haber, pero tiende a dar resultados
buenos en
> poco tiempo, que es por lo que se ha hecho tan popular en los
últimos años.
> Considero que también es mejorable según para qué cosas se use.
>
> La otra solución de la industria que se ve bastante ahora además de
Syflex
> es el NCloth de Maya, pero la verdad es que el problema es similar
al de
> Syflex, en cuanto a que da resultados decentes en muy poco tiempo,
pero no
> proporciona un control enorme, y no es un cálculo especialmente
realista. De
> hecho en el caso concreto de NCloth, son unas dinámicas basadas en
> simulaciones de partículas. Digamos que NCloth es realmente
NParticles.
> Con lo cual a niveles altos lo que de verdad se está usando son
soluciones
> propietarias (vaya novedad).
>
> Considero que con cualquier otra cosa, lo mejor no es intentar
simular la
> realidad, sino tener un método general , pero falsear la solución
para cada
> plano concreto. Al menos, es mi experiencia.
>
> Un saludo,
>
> --
> Javier Meroño Sierra
> Chief instructor - Jefe de Estudios
> Aula Temática Digital Training Center
> www.aulatematica.com
> +34 913085383
>
>
> El 29 de septiembre de 2008 13:09, gerardstrada
> <gerardstrada@...>escribió:
>
> >   --- En spain_lw@yahoogroups.com <spain_lw%
40yahoogroups.com>, "Jesús
> > Guijarro " <jegupi@>
> > escribió:
> >
> > >
> > > A mi también me pareció muy buena aunque últimamente no utilizo
> > ClothFX, ha
> > > dejado de gustarme. Por cierto ya que estamos hablando de
> > simulación de
> > > dinámicas y para los que estén en la OB mirar lo que se esta
> > cociendo en
> > > Newtek, http://www.newtek.com/forums/showthread.php?
> > p=757602#post757602 y
> > > digo Newtek porque Jay3d es el autor de Package Scene
> > >
> > > Saludos
> >
> > Bueno Jesús, de aquel tutorial sobre dinámicas de tela hasta hoy
ha
> > pasado ya tiempo y las opciones externas son cada vez mejores :)
> >
> > Realmente interesante el enlace. Sabía que Jay3D había estado
> > trabajando desde hace ya cierto tiempo en un plug basado en el
motor
> > de físicas Newton Game Dynamics. Aunque por los resultados, no sé
> > por qué se le considera un fake :D
> >
> > Gracias,
> >
> > Gerardo
> >
> >
> >
>

 

Te advierto que tiene su historia ehh ??

http://www.hdri3d.com/xtra/11estrada/index.htm

Saludos.

 

Yo quiero decir una cosa por que si no pues.....y es que bueno mas que un software u
otro que sean mejores o peores que eso tambien influye creo que al final es casi tan
importante como el software, la mano que lo utilice, yo he visto tests de syflex y bueno
el test que yo hice donde un tejido interactura con una esfera y el suelo, consegui
practicamente por no decir igual el mismo resutlado que ese mismo test de syflex y bueno
yo no soy ninguna experta. Pero si queria recalcar eso mas que los software la mano
de la persona k los usa suele ser mas importante, acordaros si no de cuando hablar de
radiosidad era algo impensable en lw y la tecnica de Gerardo para la simulacion de
esa iluminacion con gradients..todavia hay gente por todos sitios que no da credito
a la tecnica.

Saludos.

--- En spain_lw@yahoogroups.com, "Jesús Guijarro " <jegupi@...>
escribió:
>
> A mi también me pareció muy buena aunque últimamente no utilizo
ClothFX, ha
> dejado de gustarme. Por cierto ya que estamos hablando de
simulación de
> dinámicas y para los que estén en la OB  mirar lo que se esta
cociendo en
> Newtek, http://www.newtek.com/forums/showthread.php?
p=757602#post757602 y
> digo Newtek porque Jay3d es el autor de Package Scene
>
> Saludos


Bueno Jesús, de aquel tutorial sobre dinámicas de tela hasta hoy ha
pasado ya tiempo y las opciones externas son cada vez mejores :)

Realmente interesante el enlace.  Sabía que Jay3D había estado
trabajando desde hace ya cierto tiempo en un plug basado en el motor
de físicas Newton Game Dynamics.  Aunque por los resultados, no sé
por qué se le considera un fake :D

Gracias,



Gerardo

--- En spain_lw@yahoogroups.com, Alejandro <alejandro.bahamondes@...>
escribió:
>
> >  A mi me ha parecido muy buena y valiosa la explicación. La
archivaré porque
> > puede ser material de consulta en muchos casos.
> > Sobre todo me parece muy valioso que te hayas tomado la molestia
de una
> > respuesta tan larga. Este foro es mejor en función de que lo
integren
> > profesionales con conocimientos tan profundos que puedan escribir
respuestas
> > tan largas y específicas Yo te animo a seguir con tus respuestas
porque nos
> > sirven mucho a los
> > estamos aprendiendo y sobre todo que este tipo de explicaciones
dudo mucho que
> > las podamos encontrar en algún manual...
> > Saludos, Alejandro.


Gracias Alejandro,

a veces escribo las respuestas para poder también consultarlas
(agregar/corregir) luego, para que no se olviden :)

Por cierto, la técnica de las 'polychains cages' tiene ya sus años
pero los principios están aun vigentes y seguro pueden adaptarse a
otros casos:

http://es.groups.yahoo.com/group/spain_lw/message/10765

Saludos,



Gerardo

--- En spain_lw@yahoogroups.com, Ana <yuldark3@...> escribió:
>
> A mi personalmente me parecio muy buena la explicación, no hay
mucha gente
> que sepa lo suficiente de dinamicas como para poner la explicación
que distes
> en castellano......
>
>
> Saludos.


Gracias Ana,

Sé también de algunas personas en este foro que pueden explicar estos
principios mejor (gente que ha hecho tutoriales en castellano sobre
esto, Ases de Houdini, Syflex, y profesionales que comparten sus
experiencias e ingeniosos experimentos) y posiblemente los criterios
que mencioné no ayuden inmediatamente a quien pregunta, pero como
dices, no hay mucha información sobre estos criterios en
castellano.

Saludos,



Gerardo

A mi me ha parecido muy buena y valiosa la explicación. La archivaré porque puede ser material de consulta en muchos casos.
Sobre todo me parece muy valioso que te hayas tomado la molestia de una respuesta tan larga. Este foro es mejor en función de que lo integren
profesionales con conocimientos tan profundos que puedan escribir respuestas tan largas y específicas Yo te animo a seguir con tus respuestas porque nos sirven mucho a los
estamos aprendiendo y sobre todo que este tipo de explicaciones dudo mucho que las podamos encontrar en algún manual...
Saludos, Alejandro.
 

Aveces puedo escribir respuestas realmente largas - qué bueno que no
tengo que leerlas luego! :D ...y nadie tiene que obligarse a hacerlo
tampoco (a menos que sorprendentemente no te parezca un fastidio, o
te guste fastidiarte) :)  
 
Saludos,

Gerardo
 
 
P.D. Double Side es útil sólo cuando la malla no tiene espesor.  Por
cierto, collision offset es lo que antes se llamaba skin thickness.

--- En spain_lw@yahoogroups.com <mailto:spain_lw%40yahoogroups.com> , Miguel Gil <satanas_864@...>
escribió:
>
> jeje tengo que admitir que me dio fastidio leer tooodo lo que te
respondieron, creo que el clothFX tiene una opcion de que los
poligonos sean doble cara algo asi por que recuerdo que tuve el mismo
problema y lo resolvi
>
> --- El sáb 27-sep-08, gerardstrada <gerardstrada@...> escribió:
>
> De: gerardstrada <gerardstrada@...>
> Asunto: [spain_lw] RE: Problemas con ClothFX
> A: spain_lw@yahoogroups.com <mailto:spain_lw%40yahoogroups.com>
> Fecha: sábado, 27 septiembre, 2008, 7:02 am
>
>
>
>
>
>
> Sin conocer cómo está planteada la escena no es fácil saber dónde
> está el problema, y a solucionar un caso específico es mejor tener
> presente ciertos principios y características particulares en el
> sistema de dinámicas de LW que puedan ayudar, en este y otros
casos,
> a entender mejor cómo plantear un cálculo exitoso dentro de estos
> parámetros.
>
> Lo primero a considerar es que las dinámicas de LW no son las más
> robustas (echar mano de aplicaciones externas o plugins es
preferible
> en algunos casos), pero en general es posible obtener resultados
> aceptables en LW si se organizan varias soluciones sencillas, en
vez
> de una sola solución compleja.
>
> Lo segundo a considerar es que un cálculo aceptable con ClothFX es
el
> resultado armonioso de todos sus parámetros. Asumiendo en este caso
> específico que la escala, peso, spring, substructure, compress
stress
> y la resolución del cálculo están bien afinados, podemos aislar el
> tema de las colisiones.
>
> Para prevenir - en la medida de lo posible - errores en el cálculo
de
> colisiones con Clothfx, debemos tener presente que en la detección
de
> una colisión, clothfx considera sólo los polígonos para el objeto
de
> colisión y sólo los vértices para el objeto designado (target).
Esta
> particularidad en el sistema de dinámicas de LW hace que una
colisión
> tenga lugar sólo cuando los vértices de un objeto target trata de
> traspasar los polígonos de un objeto de colisión y no al revés. Es
> por este motivo que comunmente es una buena práctica reducir los
> detalles en el objeto de colisión (recomendable también en otros
> programas). Un punto debil en LW sin embargo, es que esta solución
> es de una sola vía, es decir, vértices del target contra polígonos
> del colisionador mas no polígonos del target contra vértices del
> colisionador. Es por este motivo también que es más fácil calcular
> una tela pequeña cayendo sobre un objeto grande, que uno o varios
> objetos pequeños cayendo sobre una tela grande.
>
> Ahora, la forma en que ClothFX calcula las colisiones es
> especialmente problemática para los casos de autocolisión ya que
> éstos son ejecutados de la misma manera que las operaciones usuales
> de colisión (por supuesto la detección de colisión y la
autocolisión
> deben estar activadas).
> Para solucionar este problema conozco básicamente dos opciones: una
> barata y otra cara :)
>
> La opción barata es una especie de 'fake' através del parámetro
> thickness. De acuerdo a la escala del modelo es recomendable usar
> valores muy bajos. Cuando usamos valores muy altos obtenemos saltos
> intempestivos y la malla simplemente termina colapsando. El
problema
> con esta solución es que dependiendo de la malla y nivel de
> deformación del modelo, puede no ser posible encontrar un parámetro
> que funcione para todas las áreas (una textura en este parámetro
> podría facilitar algunos cálculos).
>
> La opción cara es aumentar la resolución del modelo a calcularse.
> Esta solución comunmente ofrece mejores resultados que la solución
> anterior (sobre todo cuando el objeto de colisión y el target son
dos
> objetos diferentes), pero cuando son el mismo objeto, es necesario
> encontrar un balance entre el tamaño de los polígonos a colisionar
y
> el número de vértices que colisionarán. Y esto depende
> principalmente de un diseño pre-planeado de la topografía de la
malla
> que facilite una correcta deformación con el menor número de
> polígonos posible.
>
> Sobre las estrategias de cómo afrontar un afecto así en LW, pues
veo
> 2:
>
> Una estrategia viable podría usar un balance entre las opciones
> anteriores comenzando con muy bajos valores de thickness y
aplicando
> el cálculo sobre una especie de proxy-mesh (una malla muy
optimizada
> sin espesor geométrico). Optimizada significa que la topografía de
la
> malla debe facilitar pliegues en las áreas que consideramos
naturales
> y evitar polígonos traspasados en las zonas problemáticas, ambas
> cosas con el menor número posible de polígonos. Si la vela tiene
> forma de triángulo rectángulo por ejemplo, y debe plegarse de
manera
> vertical, sería antiproducente tener polígonos organizados de
manera
> diagonal. Filas intercaladas de polígonos más altos y bajos podría
> ser útil también.
>
> Otra estrategia quizá más viable sería usar la técnica de 'cajas'
de
> cadenas de polígonos de 2 puntos (polychain cage) para lograr un
> efecto de plegado muy rápido en el cálculo de clothFX y más
> facilmente controlable. Es posible animar el movimiento básico de
> plegado sobre estas polychains con bones (o quizá morphs) y aplicar
> cloth fx sobre esto. La configuración para las polychains no es la
> clásica configuración de rejilla, sino que son aparejadas como
líneas
> paralelas (verticales u horizontales dependiendo de la deformación
de
> la vela). Ya que estas polychains paralelas no están unidas, se
usan
> polígonos de 2 puntos perpendiculares a las polychains con un
> selectionn set en sus vértices exteriores (para usar la opción fix
> selection set en clothfx luego) a manera de 'constraints' para cada
> polychain. La longitud de estos 'constraints' sirve para prevenir
que
> los polígonos se transpasen, así que pueden ser aleatoriamente
> variables siempre y cuando cumplan esta función. Después de la
> simulación podemos substituir por una geometría en alta resolución.
> Recuerdo que Greg Malick hizo un script llamado SBD y Colin Cohen
un
> plugin llamado Cloth, para automatizar la creación de este tipo de
> polychain cages que son también muy viables para simulaciones más
> rápidas de ropa previniendo el molesto traspaso de polígonos.
>
> Para una vela, no esperaría - ni en Syflex - obtener todos los
> pliegues que hacen que una vela se vea realista a través de
> geometría, sería mejor simplificarla de tal manera de obtener sólo
> los grandes pliegues, los pequeños pueden ser agregados a través de
> texturas luego, ya sea a través de mapas de normal/bumps o de
> desplazamiento al re-aplicar el primer cálculo sobre un objeto
> subpatch con una malla mucho más densa (MDDMetaPointer) .
>
> Considera también que los parámetros y el objeto a calcular para
> digamos, el pliegue de una vela, pueden totalmente diferentes al de
> un efecto del viento moviendo una vela extendida por ejemplo.
> Diferentes tomas/efectos, requieren en LW diferentes soluciones. El
> caso de una vela plegándose no me parece sencilla en ningún paquete
> (en Syflex por ejemplo, muy probablemente tendríamos que utilizar
> pins), así que en LW, morphs/bones+ clothfx, o
> polychains/constrai nts+clothfx podrían facilitar una solución a la
de
> dinámicas exclusivamente.
>
> Saludos,
>
>
>
> Gerardo
>
> --- En spain_lw@yahoogroup s.com, "Diego Nuñez" <diego.azul9@ ...>
> escribió:
> >
> > Hola a todos:
> >
> > lo dicho, tengo un problemilla con el clothFX, el problema está
en
> que no
> > consigo de ninguna forma que la tela en cuestión, que es una vela
> de un
> > barco, colisione consigo misma, aun activando self collision
> prácticamente
> > sigue actuando igual y se atraviesa continuamente. No se si me
> salto algun
> > paso o que. Otra cosa que no acaba de salir bien, es untentar
darle
> > diferente rigidez a distintas zonas de la vela con weightmaps,
> cuando lo
> > aplico se empieza a volver loco y hacer un gurruño.¿ Alguna
> sugerencia o
> > algún tutorial que me pueda servir?
> >
> > Un saludo
> >
> > Diego
> >
>
>  
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       
__________________________________________________________
______________
> Yahoo! MTV Blog & Rock &gt;¡Cuéntanos tu historia, inspira una
canción y gánate un viaje a los Premios MTV! Participa aquí
http://mtvla.yahoo.com/
>

 
    

Aveces puedo escribir respuestas realmente largas - qué bueno que no
tengo que leerlas luego! :D ...y nadie tiene que obligarse a hacerlo
tampoco (a menos que sorprendentemente no te parezca un fastidio, o
te guste fastidiarte) :)

Saludos,



Gerardo


P.D. Double Side es útil sólo cuando la malla no tiene espesor.  Por
cierto, collision offset es lo que antes se llamaba skin thickness.







--- En spain_lw@yahoogroups.com, Miguel Gil <satanas_864@...>
escribió:
>
> jeje tengo que admitir que me dio fastidio leer tooodo lo que te
respondieron, creo que el clothFX tiene una opcion de que los
poligonos sean doble cara algo asi por que recuerdo que tuve el mismo
problema y lo resolvi
>
> --- El sáb 27-sep-08, gerardstrada <gerardstrada@...> escribió:
>
> De: gerardstrada <gerardstrada@...>
> Asunto: [spain_lw] RE: Problemas con ClothFX
> A: spain_lw@yahoogroups.com
> Fecha: sábado, 27 septiembre, 2008, 7:02 am
>
>
>
>
>
>
> Sin conocer cómo está planteada la escena no es fácil saber dónde
> está el problema, y a solucionar un caso específico es mejor tener
> presente ciertos principios y características particulares en el
> sistema de dinámicas de LW que puedan ayudar, en este y otros
casos,
> a entender mejor cómo plantear un cálculo exitoso dentro de estos
> parámetros.
>
> Lo primero a considerar es que las dinámicas de LW no son las más
> robustas (echar mano de aplicaciones externas o plugins es
preferible
> en algunos casos), pero en general es posible obtener resultados
> aceptables en LW si se organizan varias soluciones sencillas, en
vez
> de una sola solución compleja.
>
> Lo segundo a considerar es que un cálculo aceptable con ClothFX es
el
> resultado armonioso de todos sus parámetros. Asumiendo en este caso
> específico que la escala, peso, spring, substructure, compress
stress
> y la resolución del cálculo están bien afinados, podemos aislar el
> tema de las colisiones.
>
> Para prevenir - en la medida de lo posible - errores en el cálculo
de
> colisiones con Clothfx, debemos tener presente que en la detección
de
> una colisión, clothfx considera sólo los polígonos para el objeto
de
> colisión y sólo los vértices para el objeto designado (target).
Esta
> particularidad en el sistema de dinámicas de LW hace que una
colisión
> tenga lugar sólo cuando los vértices de un objeto target trata de
> traspasar los polígonos de un objeto de colisión y no al revés. Es
> por este motivo que comunmente es una buena práctica reducir los
> detalles en el objeto de colisión (recomendable también en otros
> programas). Un punto debil en LW sin embargo, es que esta solución
> es de una sola vía, es decir, vértices del target contra polígonos
> del colisionador mas no polígonos del target contra vértices del
> colisionador. Es por este motivo también que es más fácil calcular
> una tela pequeña cayendo sobre un objeto grande, que uno o varios
> objetos pequeños cayendo sobre una tela grande.
>
> Ahora, la forma en que ClothFX calcula las colisiones es
> especialmente problemática para los casos de autocolisión ya que
> éstos son ejecutados de la misma manera que las operaciones usuales
> de colisión (por supuesto la detección de colisión y la
autocolisión
> deben estar activadas).
> Para solucionar este problema conozco básicamente dos opciones: una
> barata y otra cara :)
>
> La opción barata es una especie de 'fake' através del parámetro
> thickness. De acuerdo a la escala del modelo es recomendable usar
> valores muy bajos. Cuando usamos valores muy altos obtenemos saltos
> intempestivos y la malla simplemente termina colapsando. El
problema
> con esta solución es que dependiendo de la malla y nivel de
> deformación del modelo, puede no ser posible encontrar un parámetro
> que funcione para todas las áreas (una textura en este parámetro
> podría facilitar algunos cálculos).
>
> La opción cara es aumentar la resolución del modelo a calcularse.
> Esta solución comunmente ofrece mejores resultados que la solución
> anterior (sobre todo cuando el objeto de colisión y el target son
dos
> objetos diferentes), pero cuando son el mismo objeto, es necesario
> encontrar un balance entre el tamaño de los polígonos a colisionar
y
> el número de vértices que colisionarán. Y esto depende
> principalmente de un diseño pre-planeado de la topografía de la
malla
> que facilite una correcta deformación con el menor número de
> polígonos posible.
>
> Sobre las estrategias de cómo afrontar un afecto así en LW, pues
veo
> 2:
>
> Una estrategia viable podría usar un balance entre las opciones
> anteriores comenzando con muy bajos valores de thickness y
aplicando
> el cálculo sobre una especie de proxy-mesh (una malla muy
optimizada
> sin espesor geométrico). Optimizada significa que la topografía de
la
> malla debe facilitar pliegues en las áreas que consideramos
naturales
> y evitar polígonos traspasados en las zonas problemáticas, ambas
> cosas con el menor número posible de polígonos. Si la vela tiene
> forma de triángulo rectángulo por ejemplo, y debe plegarse de
manera
> vertical, sería antiproducente tener polígonos organizados de
manera
> diagonal. Filas intercaladas de polígonos más altos y bajos podría
> ser útil también.
>
> Otra estrategia quizá más viable sería usar la técnica de 'cajas'
de
> cadenas de polígonos de 2 puntos (polychain cage) para lograr un
> efecto de plegado muy rápido en el cálculo de clothFX y más
> facilmente controlable. Es posible animar el movimiento básico de
> plegado sobre estas polychains con bones (o quizá morphs) y aplicar
> cloth fx sobre esto. La configuración para las polychains no es la
> clásica configuración de rejilla, sino que son aparejadas como
líneas
> paralelas (verticales u horizontales dependiendo de la deformación
de
> la vela). Ya que estas polychains paralelas no están unidas, se
usan
> polígonos de 2 puntos perpendiculares a las polychains con un
> selectionn set en sus vértices exteriores (para usar la opción fix
> selection set en clothfx luego) a manera de 'constraints' para cada
> polychain. La longitud de estos 'constraints' sirve para prevenir
que
> los polígonos se transpasen, así que pueden ser aleatoriamente
> variables siempre y cuando cumplan esta función. Después de la
> simulación podemos substituir por una geometría en alta resolución.
> Recuerdo que Greg Malick hizo un script llamado SBD y Colin Cohen
un
> plugin llamado Cloth, para automatizar la creación de este tipo de
> polychain cages que son también muy viables para simulaciones más
> rápidas de ropa previniendo el molesto traspaso de polígonos.
>
> Para una vela, no esperaría - ni en Syflex - obtener todos los
> pliegues que hacen que una vela se vea realista a través de
> geometría, sería mejor simplificarla de tal manera de obtener sólo
> los grandes pliegues, los pequeños pueden ser agregados a través de
> texturas luego, ya sea a través de mapas de normal/bumps o de
> desplazamiento al re-aplicar el primer cálculo sobre un objeto
> subpatch con una malla mucho más densa (MDDMetaPointer) .
>
> Considera también que los parámetros y el objeto a calcular para
> digamos, el pliegue de una vela, pueden totalmente diferentes al de
> un efecto del viento moviendo una vela extendida por ejemplo.
> Diferentes tomas/efectos, requieren en LW diferentes soluciones. El
> caso de una vela plegándose no me parece sencilla en ningún paquete
> (en Syflex por ejemplo, muy probablemente tendríamos que utilizar
> pins), así que en LW, morphs/bones+ clothfx, o
> polychains/constrai nts+clothfx podrían facilitar una solución a la
de
> dinámicas exclusivamente.
>
> Saludos,
>
>
>
> Gerardo
>
> --- En spain_lw@yahoogroup s.com, "Diego Nuñez" <diego.azul9@ ...>
> escribió:
> >
> > Hola a todos:
> >
> > lo dicho, tengo un problemilla con el clothFX, el problema está
en
> que no
> > consigo de ninguna forma que la tela en cuestión, que es una vela
> de un
> > barco, colisione consigo misma, aun activando self collision
> prácticamente
> > sigue actuando igual y se atraviesa continuamente. No se si me
> salto algun
> > paso o que. Otra cosa que no acaba de salir bien, es untentar
darle
> > diferente rigidez a distintas zonas de la vela con weightmaps,
> cuando lo
> > aplico se empieza a volver loco y hacer un gurruño.¿ Alguna
> sugerencia o
> > algún tutorial que me pueda servir?
> >
> > Un saludo
> >
> > Diego
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
______________________________________________________________________
______________
> Yahoo! MTV Blog & Rock &gt;¡Cuéntanos tu historia, inspira una
canción y gánate un viaje a los Premios MTV! Participa aquí
http://mtvla.yahoo.com/
>

Sin conocer cómo está planteada la escena no es fácil saber dónde
está el problema, y a solucionar un caso específico es mejor tener
presente ciertos principios y características particulares en el
sistema de dinámicas de LW que puedan ayudar, en este y otros casos,
a entender mejor cómo plantear un cálculo exitoso dentro de estos
parámetros.

Lo primero a considerar es que las dinámicas de LW no son las más
robustas (echar mano de aplicaciones externas o plugins es preferible
en algunos casos),  pero en general es posible obtener resultados
aceptables en LW si se organizan varias soluciones sencillas, en vez
de una sola solución compleja.

Lo segundo a considerar es que un cálculo aceptable con ClothFX es el
resultado armonioso de todos sus parámetros.  Asumiendo en este caso
específico que la escala, peso, spring, substructure, compress stress
y la resolución del cálculo están bien afinados, podemos aislar el
tema de las colisiones.

Para prevenir - en la medida de lo posible - errores en el cálculo de
colisiones con Clothfx, debemos tener presente que en la detección de
una colisión, clothfx considera sólo los polígonos para el objeto de
colisión y sólo los vértices para el objeto designado (target).  Esta
particularidad en el sistema de dinámicas de LW hace que una colisión
tenga lugar sólo cuando los vértices de un objeto target trata de
traspasar los polígonos de un objeto de colisión y no al revés.  Es
por este motivo que comunmente es una buena práctica reducir los
detalles en el objeto de colisión (recomendable también en otros
programas).  Un punto debil en LW sin embargo, es que esta solución
es de una sola vía, es decir, vértices del target contra polígonos
del colisionador mas no polígonos del target contra vértices del
colisionador.  Es por este motivo también que es más fácil calcular
una tela pequeña cayendo sobre un objeto grande, que uno o varios
objetos pequeños cayendo sobre una tela grande.

Ahora, la forma en que ClothFX calcula las colisiones es
especialmente problemática para los casos de autocolisión ya que
éstos son ejecutados de la misma manera que las operaciones usuales
de colisión (por supuesto la detección de colisión y la autocolisión
deben estar activadas).
Para solucionar este problema conozco básicamente dos opciones: una
barata y otra cara :)

La opción barata es una especie de 'fake' através del parámetro
thickness.  De acuerdo a la escala del modelo es recomendable usar
valores muy bajos.  Cuando usamos valores muy altos obtenemos saltos
intempestivos y la malla simplemente termina colapsando.  El problema
con esta solución es que dependiendo de la malla y nivel de
deformación del modelo, puede no ser posible encontrar un parámetro
que funcione para todas las áreas (una textura en este parámetro
podría facilitar algunos cálculos).

La opción cara es aumentar la resolución del modelo a calcularse.
Esta solución comunmente ofrece mejores resultados que la solución
anterior (sobre todo cuando el objeto de colisión y el target son dos
objetos diferentes), pero cuando son el mismo objeto, es necesario
encontrar un balance entre el tamaño de los polígonos a colisionar y
el número de vértices que colisionarán.  Y esto depende
principalmente de un diseño pre-planeado de la topografía de la malla
que facilite una correcta deformación con el menor número de
polígonos posible.

Sobre las estrategias de cómo afrontar un afecto así en LW, pues veo
2:

Una estrategia viable podría usar un balance entre las opciones
anteriores comenzando con muy bajos valores de thickness y aplicando
el cálculo sobre  una especie de proxy-mesh (una malla muy optimizada
sin espesor geométrico). Optimizada significa que la topografía de la
malla debe facilitar pliegues en las áreas que consideramos naturales
y evitar polígonos traspasados en las zonas problemáticas, ambas
cosas con el menor número posible de polígonos.  Si la vela tiene
forma de triángulo rectángulo por ejemplo, y debe plegarse de manera
vertical, sería antiproducente tener polígonos organizados de manera
diagonal.  Filas intercaladas de polígonos más altos y bajos podría
ser útil también.

Otra estrategia quizá más viable sería usar la técnica de 'cajas' de
cadenas de polígonos de 2 puntos (polychain cage) para lograr un
efecto de plegado muy rápido en el cálculo de clothFX y más
facilmente controlable.  Es posible animar el movimiento básico de
plegado sobre estas polychains con bones (o quizá morphs) y aplicar
cloth fx sobre esto.  La configuración para las polychains no es la
clásica configuración de rejilla, sino que son aparejadas como líneas
paralelas (verticales u horizontales dependiendo de la deformación de
la vela). Ya que estas polychains paralelas no están unidas, se usan
polígonos de 2 puntos perpendiculares a las polychains con un
selectionn set en sus vértices exteriores (para usar la opción fix
selection set en clothfx luego) a manera de 'constraints' para cada
polychain. La longitud de estos 'constraints' sirve para prevenir que
los polígonos se transpasen, así que pueden ser aleatoriamente
variables siempre y cuando cumplan esta función.  Después de la
simulación podemos substituir por una geometría en alta resolución.
Recuerdo que Greg Malick hizo un script llamado SBD y Colin Cohen un
plugin llamado Cloth, para automatizar la creación de este tipo de
polychain cages que son también muy viables para simulaciones más
rápidas de ropa previniendo el molesto traspaso de polígonos.

Para una vela, no esperaría - ni en Syflex - obtener todos los
pliegues que hacen que una vela se vea realista a través de
geometría, sería mejor simplificarla de tal manera de obtener sólo
los grandes pliegues, los pequeños pueden ser agregados a través de
texturas luego, ya sea a través de mapas de normal/bumps o de
desplazamiento al re-aplicar el primer cálculo sobre un objeto
subpatch con una malla mucho más densa (MDDMetaPointer) .

Considera también que los parámetros y el objeto a calcular para
digamos, el pliegue de una vela, pueden totalmente diferentes al de
un efecto del viento moviendo una vela extendida por ejemplo.
Diferentes tomas/efectos, requieren en LW diferentes soluciones.  El
caso de una vela plegándose no me parece sencilla en ningún paquete
(en Syflex por ejemplo, muy probablemente tendríamos que utilizar
pins), así que en LW, morphs/bones+clothfx, o
polychains/constraints+clothfx podrían facilitar una solución a la de
dinámicas exclusivamente.

Saludos,



Gerardo


--- En spain_lw@yahoogroups.com, "Diego Nuñez" <diego.azul9@...>
escribió:
>
> Hola a todos:
>
> lo dicho, tengo un problemilla con el clothFX, el problema está en
que no
> consigo de ninguna forma que la tela en cuestión, que es una vela
de un
> barco, colisione consigo misma, aun activando self collision
prácticamente
> sigue actuando igual y se atraviesa continuamente. No se si me
salto algun
> paso o que. Otra cosa que no acaba de salir bien, es untentar darle
> diferente rigidez a distintas zonas de la vela con weightmaps,
cuando lo
> aplico se empieza a volver loco y hacer un gurruño.¿ Alguna
sugerencia o
> algún tutorial que me pueda servir?
>
> Un saludo
>
> Diego
>

Hola a todos:

lo dicho, tengo un problemilla con el clothFX, el problema está en que no consigo de ninguna forma que la tela en cuestión, que es una vela de un barco, colisione consigo misma, aun activando self collision prácticamente sigue actuando igual y se atraviesa continuamente. No se si me salto algun paso o que. Otra cosa que no acaba de salir bien, es untentar darle diferente rigidez a distintas zonas de la vela con weightmaps, cuando lo aplico se empieza a volver loco y hacer un gurruño.¿ Alguna sugerencia o algún tutorial que me pueda servir?

Un saludo

Diego