Foro x-plane.es

Hola a todos.

Ayer, inspirado por el fabuloso proyecto de Japo http://www.x-plane.es/modules/smf/index.php?topic=2452.0 y su vídeo sobre la lluvia en cabinas 3D, algo que nadie, salvo el, había estudiado -hasta donde llega mi conocimiento- y dado que tenía algo de tiempo me decidí a analizar este fenómeno atmosférico y como podría implementarse en X-Plane de forma realista.

Varias son las ideas -vagas- que llegué a concebir, como por ejemplo lo expuesto aquí: http://www.x-plane.es/modules/smf/index.php?topic=2452.msg38126#msg38126 (http://www.x-plane.es/modules/smf/index.php?topic=2452.msg38126#msg38126) y aquí:
http://www.x-plane.es/modules/smf/index.php?topic=2452.msg38173#msg38173 (http://www.x-plane.es/modules/smf/index.php?topic=2452.msg38173#msg38173)

Sin embargo, la idea es conseguir el efecto sin la abrumadora necesidad de usar complicadas APIs gráficas en las cuales yo no tengo experiencia.

El presente hilo pretende ser, pues, un marco de estudio y desarrollo –ensayo podríamos decir- de una posible solución al problema anteriormente mencionado. Aquí aportaré mi idea inicial, podremos comentarla entre todos y llegar a una aplicación práctica. Quizá sirva hasta como aprendizaje sobre la realización de plugins. Simplemente es mi deseo haceros partícipes activos de este proyecto, nada más y nada menos que conseguir lluvia realista en cabinas 3D,  de forma general. Tened en cuenta que todo esto podrá o no funcionar en último término, quizá recorramos mucho trecho para llegar a ningún lado, pero algo habremos aprendido por el camino, los unos de los otros, o eso espero.

Primero pretendo realizar una exposición teórica, lo que se podría denominar un análisis funcional –los que sepáis de programación me habréis entendido perfectamente-, para luego pasar a la práctica, a implementar mediante código aquello que es teórico. De modo que este hilo va a ser una especie de historial desde la concepción de una posible solución hasta su ejecución y su éxito o fracaso, porque, a priori, no se puede saber si lo expuesto aquí funcionará ni con qué inconvenientes nos podemos encontrar. No he visto en ningún foro un hilo como el presente, no sé si es una buena idea o no, vosotros, con vuestros comentarios, me diréis.

De todo lo que se me ocurrió he salvado una idea que, ni se cimenta en la filosofía del constructor de aviones virtuales que no tiene conocimientos de programación ni tampoco en el programador que no tiene conocimientos de creación de aviones virtuales. La idea final está a caballo de las dos porque, requiere el uso de modelado y texturizado y también programación, pero no de un nivel que, a priori, asuste.

Procedo pues a exponer mi idea de como implementar todo esto. Ni que decir tiene que podéis comentar, consultar o criticar lo que queráis. Pasemos pues a la exposición.

En cualquier momento hay un número finito de gotas en un parabrisas, por ejemplo. Porque a medida que algunas resbalan y desaparecen, otras impactan y quedan pegadas. Por otro lado las gotas resbalan normalmente hacia abajo, pero en realidad eso depende del ventor de inercia del vehículo, si aceleramos, resbalarán a los lados, siguiendo la curvatura del cristal, si caemos hacia abajo, incluso subirán, es decir, su movimiento depende de la fuerza G.

Pues bien, la intención es simular todo ello de la forma más realista que se pueda, con las lógicas limitaciones, claro. A priori no se que PC se requerirá para mover esto con soltura, aunque no creo que sea mucho, y siempre será adaptable a nuestras necesidades.

Mi idea consiste en un sistema multi-capa de transparencias de visibilidad variable junto con un sistema dinámico de simulación del movimiento de las gotas, cuando éstas resbalan. ¿Suena complicado? No lo es tanto, o ya veremos.

El sistema está dividido pues en dos partes bien diferenciadas e independientes, que pueden implementarse por separado.


1.- Sistema multi-capa

He pensado que se podrían implementar 4 planos (polígonos rectangulares) sobre la ventanilla, texturados con una imagen de gotas de lluvia, con transparencia. Las texturas para cada uno de estos planos deben ser distintas y bien diferenciadas, de modo que se evite la apreciación de gotas idénticas entre las del mismo plano y entre las de un plano y otro.

De estos 4 planos uno puede ser continuamente visible, y los otros 3 ir cambiando su estado de visibilidad de forma cíclica, con el paso del tiempo, de modo que siempre habrá dos únicos planos visibles, el fijo, llamémosle 1 y otro de los otros 3. Sirva de referencia la siguiente figura:

(http://i212.photobucket.com/albums/cc188/Khaleg/DynamicRain0.png)

De los últimos 3 planos, a cada ciclo de la simulación, hacemos visible el siguiente plano e invisibles los otros 2. La frecuencia con la que se pasa a activar visiblemente el siguiente plano podemos hacer que dependa, directamente, del DataRef de X-Plane rain_percent de este modo simulamos que el cambio sea más agresivo –parezca que caen gotas más frecuentemente o menos- a medida que la intensidad de la lluvia aumenta o disminuye. Pensad en este sistema como un conjunto de transparencias con las gotas dibujadas, una de las transparencias es fija y las otras 3 van alternando su visibilidad, de modo que se crea una especie de animación de aparición de gotas de lluvia. Comentar que conviene que las gotas de la capa fija, las de la 1, sean de mayor tamaño en general que las de las otras tres.


2.- Sistema dinámico de gotas

Adicionalmente al sistema de capas de gotas fijas, podemos implementar un sistema en el que simularemos N gotas en movimiento. Para ello se pueden modelar N rectángulos, de pequeño tamaño, los cuales situaremos inicialmente fuera del área del cristal, todos en la misma posición, entre las dos superficies del fuselaje, por ejemplo, para que inicialmente no sean visibles desde la cabina. O bien se puede probar a hacerlos visibles solo cuando los DataRefs tomen el valor adecuado –esto ya lo veremos más adelante-.

Cada uno de estos pequeños rectángulos se textura con la imagen de una única gota de agua, haciéndolos de distinto tamaño, según la imagen de la gota a representar. Se pueden aprovechar las mismas texturas que para los planos del 1 al 4 solo que mapearemos por UV solo una gota a estos N polígonos.

Se crean dos animaciones para cada polígono de gotas dinámicas. Uno representará la posición de la gota en X, el otro en Y, unos custom DataRefs de X-Plane, que nosotros crearemos y gestionaremos por plugin marcarán los valores de referencia para esos ejes y cada gota de agua. Recordemos que las gotas dinámicas, inicialmente, estarán situadas fuera del área del cristal sobre el que se van a desplazar, es decir, los valores de sus DataRefs X e Y estarán fuera del rango del área del cristal –esta circunstancia podemos aprovecharla para que sean objetos invisibles cuando estén fuera del área del cristal, es decir, su visibilidad o no dependerá de los valores de sus DataRefs X e Y-.

Nuestro plugin, a cada ciclo de la simulación, para cada gota de las N que esté fuera del área, del cristal generará valores aleatorios para los DataRef X e Y, de modo que las gotas irán apareciendo en posiciones aleatorias en el cristal, como si hubieran caído en esa posición. También a cada ciclo de la simulación los valores de esos DataRefs X e Y, para cada gota se incrementarán proporcionalmente al vector de inercia, es decir, el movimiento de las gotas dependerá de la G y su vector. Cuando una gota, de las N, salga del límite del cristal, se le volverá a asignar una nueva posición distinta y aleatoria, de modo que se consiguen nuevas gotas en movimiento al reciclar los objetos que representan las que se salen por los bordes del cristal.

La siguiente figura pretende representar este sistema dinámico:

(http://i212.photobucket.com/albums/cc188/Khaleg/DynamicRain.png)

Hasta aquí el planteamiento inicial, ahora queda irlo implementando, poco a poco, que mucho tiempo no tengo. Sois libres de probarlo por vuestros propios medios si lo deseáis y publicar aquí vuestras experiencias. Yo, por mi parte, continuaré en cuanto pueda, tengo que repartir mi tiempo entre el trabajo y otro proyecto de X-Plane que tengo actualmente en marcha y del cual no he dicho nada.

Gracias por leer

Supongo que el mismo principio sería aplicable también con sus variables, a la mejora del efecto en paneles 2D.
Como el tema y su desarrollo puede llevar su tiempo, lo traslado a la sección Proyectos-aviones para que no se pierda en un mar de mensajes.

Hola,

Ayer decidí probar algo. ¿Que tal si se pueden sustituir los 4 planos de gotas de lluvia por dos generic rotarys?. El generic rotary es muy flexible, tanto que sus capacidades exceden a su nombre. Con este cotrol es posible animar cualquier superficie, es decir, a base de tener N imagenes diferentes es posible secuenciarlas de modo que parezca una animación. Además, como es un instrumento genérico, su transparencia, si lo configuramos como del tipo cristal transparente, es variable mediante un rheostato. Eso combinado le hace, en principio, un buen candidato para animar la textura de las gotas estáticas en el cristal. Se trataría de sustituir los 4 planos texturados por uno solo y mapear por UV el generic rotary a ese único plano 3D en el OBJ. La animación se realizaría "automáticamente" al variar el DataRef asociado al generic rotary.

Bueno, esa era la idea para, quizá, evitarnos el uso de los 4 planos y tener que gestionar su estado de visibilidad. Probé lo del rotary y en la cabina 2D, perfecto, se podía cambiar de fotograma símplemente variando el DataRef, pero lo que vi en la cabina 3D no me gusto nada. No se si fué por no tener definido aún ningún polígono ni mapeado por UV el rotary, pero éste control, en la cabina 3D se comportó como si fuese de tipo cristal, en lugar de cristal transparente. Es decir, en la cabina 2D se vuelve transparente su textura con el uso del rheostato, pero en la cabina 3D se vuelve totalmente negro... Ignoro ahora si es error mío o un bug, seguiré probando.

Lo de querer que la testura de gotas de lluvia podamos hacerla transparente es por crear el efecto de eliminación de gotas cuando pasa el limpia-parabrisas. Pero si en la cabina 3D no funciona el rotary como debería...bueno...habrá que buscar otras formas.

Los archivos de ejemplo los tengo que colgar en algún sitio para que el que quiera se los baje. ¿Alguna sugerencia?

Por lo que he podido experimentar con el generic rotary, para permitir animaciones de texturas transparentes en el cristal de la cabina, me he topado con el mismo problema que al intentar poner un HUD en la cabina 3D. Raro es el avión que tiene HUD en su 3d cockpit, y la razón es esa. Mi experiencia hasta ahora ha sido constatada al buscar información por Internet, resulta que para que los controles se dibujen en el polígono 3D, como textura -ignoro ahora mismo si pasa con todos o no, pero con el generic rotary si ocurre, igual que con los instrumentos del HUD- estos controles deben posicionarse en un área de la textura del panel 2D que no sea completamente transparente.

Esta tarde probaré distintos niveles de transparencia en la textura del panel, justo donde he situado el generic rotary -bajo él- para ver como se comporta X-Plane con esta configuración. Si no consigo nada positivo con esto, supongo, deberé volver a la idea inicial de usar los 4 polígonos a modo de capas para las gotas de lluvia. Sería una lástima, porque tenía pensado un sistema que creo que hubiese quedado my bien para la eliminación de gotas al pasar por ellas el limpia-parabrisas, si tengo que optar por el uso de los planos no quedará tan bien como había ideado, pues no puedo establecer la intensidad de la transparencia por medio de DataRefs, salvo que use un generic rotary, claro.

Bueno. Como comente en mi aportación anterior he estado haciendo pruebas para poder tener texturas animadas transparentes en el cockpit 3D, allá donde se deseen. Publico aqui pues el resultado de las mismas.

Para la prueba lo que he hecho es crear una textura de panel (Panel.png) con distintas áreas y distintas transparencias para cada área.

(http://i212.photobucket.com/albums/cc188/Khaleg/Panel_Text_Lluvia_01.png)
Esta es la textura en sus canales RGB, sin ver el efecto del canal alpha para transparencia

(http://i212.photobucket.com/albums/cc188/Khaleg/Panel_Text_Lluvia_02.png)
Este es el canal alpha de la textura, se puede ver que cada área tiene un nivel distinto -distintos tonos de gris- en donde negro es completamente transparente y blanco completamente opaco.
Las transparencias probadas han sido al 100%, al 25%, al 50% y al 0% de transparencia, de izquierda a derecha

(http://i212.photobucket.com/albums/cc188/Khaleg/Panel_Text_Lluvia_03.png)
Este es el resultado de la combinación de la textura con su canal alpha

Y ahora os pongo un pequeño vídeo de la prueba realizada con una cabina muy simple, que consta de dos planos mapeados por UV al Panel.png y al panel de instrumentos de X-Plane. En el video se puede apreciar como al variar un generic rotary los frames de otros 4 varían en consecuencia. Cada uno de ellos consiste en 4 fotogramas con los números del 1 al 4 en grande y color rojo. Así mismo, al variar un rheostato podéis ver como varía tambien la transparencia.

http://www.youtube.com/watch?v=7znis3R4va4

Estas dos circunstancias, el poder variar el fotograma a voluntad y la transparencia, hacen de este control uno de los sistemas de elección para implementar la lluvia en particular y animaciones -aunque cortas- en general. El funcionamiento en el ejemplo es manual, mediante otro par de instrumentos, pero se pueden variar los DataRefs correspondientes desde un plugin y animar automáticamente las imagenes, haciendo que el paso de un fotograma al otro sea todo lo rápido que necesitemos.

Al final no se si implementaré la lluvia mediante este sistema, o bien solo mediante la capa de gotas dinámicas. Si al final no opto por usar animaciones del rotary, entonces necesitaré más objetos 3D, es decir, más gotas independientes, eso aún lo estoy evaluando.

Genial, pero al mismo tiempo veo lo cazurro que soy con la informática  ;D ;D ;D y con otras cosas  ;)

¿Por qué dices eso compañero?, aqui cada uno tiene sus fuertes. Yo soy un tocho dibujando, por ejemplo.

Si, pero en el panel 3D no se puede echar mano de una capa de gotas dinámicas que se muevan y resbalen según la G a la que estén sometidas, cosa que de salir bien en la cabina 3D puede quedar espectacular.

Me corrijo a mi mismo. Si es posible sacar el objeto 3D del cockpit 3D en la vista 2D, entonces, creo que sí. También podría servir.

No termino de ver hasta donde puede llevarte este proyecto:... (bueno sí... a simular lo más fielmente posible las gotas de lluvia)

-Este proyecto ¿es especifico para un avión o general? (tipo plugin)... para todo el X-Plane ...lo digo por saber como casará esto con el METAR de turno, Real Weather... y la propia generación de lluvia por parte del X-Plane.
-Las gotas serán transparentes... ¿habrá refracción?
-Se verán influenciadas por el limpia-parabrisas ¿les afectará la curvatura/geometría del cristal?... ¿y las inercias? ¿el viento?
-¿son objetos en 3D (con volumen) o planos con textura sobre el cristal?

 ::)... a ver si me puedes aclarar estas dudas.

Saludos... y ánimo en este ingente proyecto

P.D.: sé que ahora estás empezando... es por saber si algunas cosas que pregunto están en el ideario de tu creación.

Acabo de ver el tema... Me cago en la leche!! como no se me ocurrió lo de los rotaries para animar la textura. No solo una textura sino varias!!! Es qeu así podría hacer la lluvia en movimiento por el aire. Aunque para el CRJ no puedo ahora ya que para hacerlo por rotaries debería utilizar el panel.png y lo tengo llenito. Pero para futuro vale

Otra cosa sería que se implementara la animación de textura.

de todas formas ahora que pienso.. en un panel.png mediante un rotary.. si no ocupa todo el panel.png (que no lo ocupará nunca) no se puede repetir la textura.. por lo que se vería la repetición. Siempre solucionable con distintas capas.. eso si.

bueno.. no me he leido todo el tocho ya que lo acabo de ver y es tarde ya.. pero lo haré!!!

bueno.. ya he trabajado bastante por hoy.

Hola,

El proyecto se va a intentar que sea general, es decir, no se trata de implementar la lluvia para el avión X que yo esté desarrollando, mas bien es crear las bases, las técnicas para poder implementarla en cualquier avión. De hecho la idea no es dar el qué, si no el cómo. No es dar el trigo, si no enseñar a plantarlo. Esto lo hago así por varias causas, primero, porque si se sabe cómo, se pueden aportar ideas propias y mejorar el sistema, segundo, porque aquél que tenga más habilidad gráfica que yo podrá aprovecharla y sacarle partido.

EL proyecto, por razones obvias, deberá apoyarse en un plugin que gestione la dinámica de las gotas, es decir, su aparición, movimiento, etc. El plugin será del tipo FAT basado en el SDK 2.0 de X-Plane y desarrollado en C.

La aparición y cantidad de las gotas tengo pensado tratar de sincronizarlas con el parámetro de X-Plane que define -creo, lo tengo que verificar y probar- la cantidad de lluvia que esta cayendo, es decir, que supongo se sincronizará con el real weather sin tener que hacer nada especial, porque la lógica del plugin ya tendrá en cuenta el DataRef correspondiente, bueno, esa es la idea.

Las gotas, efectívamente, serán transparentes. En cuanto a la refracción, según la mano del artista que las dibuje y su experiencia, se podrá simular, pero no será una refracción real, que cambie según el entorno, si no simulada. Para simularla es más sencillo de lo que parece, se renderiza la parte de la cabina apuntando la cámara hacia los asientos, eso en el programa 3D que estemos usando para crear el avión, con las texturas puestas y la iluminación deseada y correcta. Ese único fotograma renderizado (sería una foto sintética de la cabina mirando hacia los pilotos) se escala y adapta para cubrir a la gota en el programa de dibujado 2D con el que hagamos las gotas. Sería pues una refracción fija, como la que a veces se implementa en el parabrisas de los aviones.

Las gotas tengo pensado que si, que se vean influenciadas por el limpia-parabrisas, tengo ideadas varias técnicas que habrá que probar, esperemos que el resultado sea bueno.

La curvatura del cristal tengo pensado que sí, que también las afecte, aunque esto es más complicado, pero se va a intentar crear esa característica física. La fuerza G también tengo pensado que les afecte, de modo que, en vuelo invertido, resbalarán hacia la parte superior del cristal. En cuanto al viento, eso no lo habia pensado, pero todo es combinar en un único vector las fuerzas que queramos contemplar, luego ese vector se descompone en incremento de movimiento en X e Y para cada gota.

El sistema lo estoy ideando como un sistema mixto, en el que una capa serán gotas fijas y otra serán las dinámcias que aparecen, resbalan y desaparecen. Bueno, a lo largo del desarrollo del proyecto esto puede sufrir muchas variaciones claro. Las gotas no serán objetos con volumen, serán planos con textura transparente y semitransparente, la carga de trabajo para X-Plane se me antoja que será alta y cada objeto lo ideal es que sea lo más sencillo posible. Al contemplar la curvatura habrá que realizar también corrección de perspectiva por cada gota, para que parezca que cáda una es planar respecto de la superficie del cristal. La idea es tener un conjunto de N gotas dinámicas. Probaré con varios valores, desde 50 a 200, por ejemplo, y ver como se comporta el sistema, a más número de gotas, mejor saldrá el efecto, eso sí. A priori no se que maquina o maquinón se necesitará para mover esto, el algoritmo será complicado, porque no quiero basarlo en bucles dentro del ciclo de simulación, quiero que el propio ciclo de la simulación sea el bucle, es decir, que en lugar de gestionar el plugin las, por poner un número, 200 gotas en cada ciclo se simulación, lo cual lo retrasaría todo, quiero que cada ciclo gestione una gota, para qeu se me entienda, que a los 200 ciclos de la simulación se habrían gestionado las 200 gotas, algo así, o una combinación de este sistema con pequeños bucles gestionando loque se mueve, pero no lo que no se está moviendo.

No todas las gotas se moverán, ni tampoco las que se muevan serán las mismas, todo será aleatorio, unas se moverán a un ritmo, otras a otro.

El proyecto lo he pensado como una especie de Open Source. A lo que me refiero es que aqui no voy a publicar símplemente el resultado, si no como lo he hecho y por qué. Espero que sea un proyecto abierto, en el que todos podamos participar, aportando ideas, enjuiciando otras, probando el que quiera cosas, aprendiendo el que no sepa, yo aprendiendo del que sepa más y todos aprendiendo de todos. Al final, según como se desarrolle el asunto no será mi proyecto, será el proyecto de X-Plane.es, desarrollado aqui, con el que quiera participar. Yo tengo la idea general, las soluciones las tengo hilbanadas en mi cabeza. Si hay una cosa que pueda decir de mi es que cuando trabajo en el paso A ya estoy pensando en el F y dándole vueltas.

Todo esto tiene un peligro, eso sí. Las cosas en teoría pueden parecer muy bonitas y funcionar, y luego en la práctica no salir bien o ser imposibles de implementar o perfectamente posibles, pero por problemas de rendimiento requerir el ordenador de la Nasa. Como esto es algo vivo, será cambiante. Bueno, ya veremos a ver como se va desarrollando.

Gracias por vuestro interés.

Hola Javier,

El generic rotary es como la navaja suiza de los instrumentos...vale para todo. Jajaja.

Si que llevas mucha razón en el problema de las dimensiones de las texturas. Al ser el Panel.png finito, el área del gráfico del rotaty es limitada, por lo que si lo que se hace es poner un solo rotary mapeado varias veces a varias áreas del plano 3D en la cabina, se notaría la repetición, si. Y si lo que se hace es mapearlo una única vez, pero abarcando un área mayor, bueno, entonces se verían las gotas borrosas, con dientes de sierra, y muy grandes si no hemos tenido esto en cuenta a la hora de dibujarlas -y posiblemente deformadas, además-.

Igual hay que plantearse ya el uso de paneles a 2048x2048...no se...como cada vez queremos más cosas en los aviones... así podríamos poner varios rotarys y combinarlos. Tambien puedes mapear un UV al derecho y otro al revés, para crear un área x2 de la real del rotary.

Errrr...lo de animar la textura realmente...bueno, eso se puede hacer, pocas cosas hay imposibles en informática, y menos con las excelentes posibilidades de expansión de X-Plane y su SDK, pero para eso hay que saber OpenGL, que no se aprende en un día.

C ya sabes que lo estoy enpezando a usar ahora, cosa que no creo que sea problema por la experiencia en programación que ya tengo en otras áreas, pero OpenGL... eso ya es otra cosa. Mi trabajo nunca ha consistido en realizar aplicaciones 100% gráficas con DirectX u OpenGL. Que más quisiera yo que implementar la animación de texturas en X-Plane.

si.. yo ya empiezo a usar paneles 2048. En el CRJ no lo pensé y no sabía como modificar la cámara.. cuando era una chorrada. Ahora echaría en falta un poco más de espacio.. pero bueno.. Bien está así.
Pero tranqui.. con rotarys se puede hacer. Vamos.. yo lo mio sin rotarys ni leches... a pelo. Sin programación ninguna.
en cuanto a la reacción de las texturas con respecto a la gravedad o viento... ya lo veo más complicado.

Una forma de hacerlo.. sería mediante partículas con reacción de colisión frente al parabrisas... pero bueno.. los de Laminar siempre están unos años atrás de la última tecnología. Ya llegarán (implementaron los normal maps hace nada... y esto ya estaba desde tiempos del Doom3)

Hola,

Símplemente para comentaros por donde va la investigación en este momento.

Ahora mismo estoy estudiando cómo realizar la textura de gotas de agua sobre el cristal. Estoy partiendo de una técnica que como base obtengo texturas de esta apariencia:

(http://i212.photobucket.com/albums/cc188/Khaleg/Agua00.png)

Aparte del propio dibujado del agua, el proceso continua con la animación de la misma, dado que habrá varias capas de rotaries semitransparentes para animar el agua, con varios fotogramas por rotary, aparentando escurrir. Estoy barajando varias formas de hacerlo, aqui os puedo presentar unos breves ejemplos de por dónde van las cosas.

En el primer ejemplo -cuya imagen no usa una técnica tan complicada como la mostrada en la primera imagen- simulo el impacto de una gota al estilo "cabina 2D de X-Plane". En el segundo intento representar el escurrir de gotas de mayor superficie, aunque no está la animación completa. Todas las animaciones están hechas a mano, por lo que podréis imaginar la paciencia que hay que invertir. Os dejo las animaciones:

La gota simple
(http://i212.photobucket.com/albums/cc188/Khaleg/Agua_en_Cristal_WIP2.gif)

El escurrir del agua
(http://i212.photobucket.com/albums/cc188/Khaleg/Agua_en_Cristal_WIP.gif)

Estas animaciones, como estarán pre-dibujadas, de implementarse finalmente algo así, no se podrán animar según los vectores G y de viento. Lo único que pretendo que esté animado con esos vectores es la capa de gotas dinámicas, cuyo movimiento trataré que sea consistente con las fuerzas que influírian en las gotas.

Espero vuestras opiniones y consejos, y agradezco el interés que algunos me habéis mostrado.

Un saludo.

Respecto a la animación siguiendo la trayectoria del viento:

Las gotas caen por efecto de la gravedad pero en un vehículo en movimiento están ascienden  o hacen una trayectoria lateral por efecto aerodinámico que las arrastra sobre el cristal.
Bien, imagina que la textura en vez de estar fija, está sobre una superficie totalmente transparente (algunos efectos 3D utilizan este recurso) que gira en función de la velocidad, la otra media superficie lo haría de forma simétrica para seguir la curvatura. Este radio de giro podría estar ligado a algún dataref como por ejemplo, el que mueve la cinta que llevan algunos gliders en el cristal pero atenuado.
Todo esto es la teoría, realizarse en X-Plane no se si es posible, pero por aportar alguna idea.

Si, tu idea es my buena y correcta, de hecho las gotas ya las estoy situando sobre una superficie totalmente transparente. La podría ir girando, según un vector resultante de las sumas de los vectores de G y de fuerza del viento, eso ya lo tengo estudiado, pero entonces surge un problema, los limpia-parabrisas. Estoy ideando un sistema en el que los limpa parezca que arrastran el agua y las gotas desaparecen sobre ellos, pero esas gotas forman parte también de esa textura, aunque estaría mapeada a otro plano 3D transparente, es decir, la textura en el cristal estará formada por partes, que dará la sensación de ser una única textura animada para todo el cristal, sin embargo, algunas de esas partes se volverán transparentes según por dónde pase el limpia. Si giro la parte que no es del limpia, para que la textura sea consistente y concida esa especie de puzle de partes, debo girar también las partes debajo del limpia, pero los limpia no pueden girar, obviamente, haciendo que el sistema de simulación de arastre de las gotas por los limpia no funcionase, no al menos con las texturas animadas. Esto lo podréis ver, de forma muy patente, cuando explique, en forma de esquema, el sistema que tengo pensado para los limpia.

Es una cuestión de elección, o las texturas animadas se mueven también deacuerdo con la inercia, o los limpia parece que limpian las gotas, una de dos. Con la capa de gotas dinámicas que también pondré, no habrá problema, porque cada gota será un objeto en si mismo e independiente, que se moverá libremente de acuerdo a los cálculos realizados con los vectores de fuerzas y tambien desaparecerán de acuerdo con la posición del limpia, al menos esa es la idea.

Podría implementar únicamente el sistema de gotas dinámicas y pasar del sistema de animación de texturas, pero entonces necesitaría muchas gotas dinámicas, es decir, muchos objetos 3D representando gotas individuales y segúramente cargaría demasiado el sistema, aparte de ser una verdadera tortura crear cada gota individualmente junto con las animaciones que le correspondan, que ya adelanto que serán unos 4 ejes por objeto / gota, dos para la traslación y otros dos para la corrección de perspectiva, con los correspondientes DataRefs, claro.

Usando la capa de texturas animadas quizá solo hagan falta de 25 a 50 gotas dinámicas, pero sin usarla harían falta muchas más para que el efecto diera el pego.

De todos modos todo es estudiarlo, tendré que realizar pruebas de una forma u otra y ver cual es lo que mejor queda. Ya veremos a ver lo que finalmente podemos hacer.

Muchas gracias por tu aportación.

Simular la física de la realidad es complicado. Olvídate del sistema dinámico para cada gota, podríamos tener un buen efecto para quedarnos mirando el cristal mientras llueve, pero no podríamos mover el simulador y salir a volar de forma fluida.
Llegado el momento en el que se tenga que tomar una decisión, yo también elegiría simular el barrido del limpia antes que la trayectoria de las gotas por efecto de la aerodinámica en la superficie ya que es un efecto más visual y perceptible.

Bueno, es posible, pero quiero probarlo, porque si resulta no ser tan cargante, creo que quedaría curioso. Los cálculos en realidad no creo que sean tan masivos. Hasta que no pruebe los algoritmos no hay forma de que pueda saberlo.


Deacuerdo, lo tendré en cuenta.

Hola de nuevo, sigo informando acerca de esta investigación.

Parece ser que todo indica que, finalmente, no es conveniente usar rotaries para simular texturas animadas, no en este caso al menos, la causa de ello es la limitación que tiene X-Plane de no poder gestionar texturas de más de 2048 pixeles de tamaño, por otro lado hay que ser razonables y pensemos que texturas de mayor tamaño es consumir demasiada VRAM.

El problema radica en que para que la textura de las gotas sea creible, ésta debe tener un tamaño considerable para, a la hora de mapearla sobre el polígono superficie del cristal, ésta quede realista y no muy distorsionada de su tamaño original. Pero pensemos que si vamos a simular una textura animada de 256x128, por ejemplo -recordemos que los tamaños deben ser potencias de 2- como en el rotary esto se hace poniendo contiguos los gráficos correspondientes a cada fotograma -vease fig 1-, si nuestra animación ocupa 4 fotogramas, ello implica tener una imagen fuente del rotary de 256x4 puntos de ancho y 128 puntos de alto, es decir, que con 4 fotogramas de 256x128 ya hemos consumido una imagen de 1024x128, o lo que es lo mismo, ¡¡¡ la mitad de lo que X-Plane soporta por textura !!!.

(http://i212.photobucket.com/albums/cc188/Khaleg/Agua_en_Cristal_WIP-1.png)
Fig.1

Pense en posibles soluciones, una era dividir el tamaño total de la superficie a cubrir por la textura en "baldosas" independientes, pero que puestas de forma contigua combinasen haciendo la textura completa, como un puzle o mosaico. Ello nos daría la posibilidad de poder usar más fotogramas por "baldosa", pero, al mismo tiempo, hace que debamos usar un rotary por cada una de ellas, lo que nos lleva, indefectíblemente, a consumir mucho espacio de panel de X-Plane solo con los rotary para este efecto, además de complicar sobre manera la gestión de los mismos a través del plugin.

Este es el aspecto que tiene la textura de las gotas -un solo fotograma- al mapearlo sobre el cristal de la cabina:

(http://i212.photobucket.com/albums/cc188/Khaleg/Lluvia_v_01.png)

Para mi, totalmente inaceptable.

Resumiendo, que simulación de texturas animadas por rotaries, sí, pero limitádamente, solo para gráficos de tamaño reducido, como instrumentos, pantallas, etc. Hasta aquí mis conclusiones.

CONTINUA...

El método de elección, pues, para simular las gotas ha pasado a ser, sin detrimento del posible uso de un OBJ externo con gotas fijas sin animar, el uso de objetos que se muevan dinámicamente según las fuerzas, etc. Algo que ya contemplaba como método dinámico general, pero apoyado por otros.

Al principio pensé que podría usar objetos con una textura fija, representando una única gota simple. Luego me decidí a no desechar del todo el uso de rotaries y, si bien no es lógico usarlos para crear una textura animada que cubra todo el cristal, como tenía planeado, sí puedo usarlos para crear pequeñas gotas animadas que simulen el resbalar por el cristal y su descomposición en gotas más pequeñas, la idea es usar imágenes de no mas de 16x64 pixeles, las cuales si pueden dar más juego, a la hora de animarlas, puesto que, dado su pequeño tamaño, podremos tener un número de fotogramas por cada animación razonable. La idea es tener unos 3 o 4 tipos de gotas distintas, con animaciones diferentes, lo que nos llevaría a tener que usar 3 o 4 rotaries de 16x<nº fotogramas>x64 pixeles, bastante más razonable que el uso de un rotary mayor con escaso número de fotogramas distintos.

Al mismo tiempo que cada gota tenga su textura animada por medio de su rotary, ésta, al ser un polígono plano se moverá de acuerdo a ciertas leyes y fórmulas a determinar.

Un ejemplo de gota simple animada es este:
(http://i212.photobucket.com/albums/cc188/Khaleg/Gota_Animada_Rotary2-1.png)

Y aqui ya mapeada sobre un objeto:
(http://i212.photobucket.com/albums/cc188/Khaleg/Lluvia_v_02.png)

El siguiente paso, crear los 3 o 4 tipos de texturas animadas, fotograma a fotograma y a mano, que remedio. Despues vendrá el diseño de los movimientos a implementar por cada gota y la definición de los custom DataRefs que los gobernarán. Pero os puedo adelantar que, al márgen que falte uno o dos serán algo así:

(http://i212.photobucket.com/albums/cc188/Khaleg/Movimientos_Gota.png)

En paralelo con esto estoy estudiando también OpenGL y su uso desde plugins de X-Plane, pero es un estudio que debo realzar partiendo de cero. No creo que haya ningún problema en animar texturas desde un plugin usando esta API gráfica, de hecho es la manera en la que se tendría que hacer esto, y no descarto que, si llego a algo positivo en mis investigaciones, termine implementando la lluvia desde OpenGL, pero si ya el tema con objetos normales es complicado y va para largo, realizarlo desde OpenGL es algo aún mas a largo plazo, ya veremos.

Un saludo.

Veo que sigues con el tema, fantástico, con lo divertido que es la investigación y lo j*did* que se ve a veces  ;)

Bueno, sí, es que como buen aragonés soy cabezón... estooo... perseverante. Bien que me viene a veces.

Si, investigar es divertido... mientras todo va para adelante... pero cuando pegas con un tabique de esos que no hay quien lo tire... Además muchísimas cosas se ven fantásticas sobre el papel, luego las aplicas a la realidad y te llevas un buen chasco.

Es de suponer que algo se sacará en claro de todo esto. Si no se llega a ningún sitio, bueno, el que lo haya seguido verá por donde no hay que ir. Si se consigue, pues bueno, mejor que mejor, y si alguien lo mejora o se le ocurre algo más, pues bienvenido será.

Pero que conste que aqui todo el mundo debería estar mirándose el OpenGL este... que con eso se puede hacer gráficamente lo que te de la gana, por ejemplo las estelas por baja presión en las puntas de las alas en maniobras a alta velocidad, o el efecto visual al pasar a vuelo transónico, o por ejemplo esto de la lluvia, cualquier cosa que podáis imaginar, a costa de algunos frames, eso no te lo va a quitar nadie.

Y ahora permitidme una pequeña pataleta con reflexión.

Hay una cosa que no me gusta de la mayoría de desarrolladores de aviones, de la mayoría porque, evidentemente, hay excepciones. Su poca generosidad a la hora de compartir técnicas o conocimientos. La mayoría tratan el tema como si cada truco, cada técnica que descubren, fuese a parar al libro secreto de los Masones. La sensación que dá es como si existiera una especie de secta secreta de amigotes, entre los cuales comparten alguna cosilla, pero sin salir del círculo. Por un lado lo entiendo, es la necesidad de tener esa ventaja frente al otro a la hora de vender aviones "payware", pero por otro se pierde totalmente la experiencia, enriquecedora sobre manera, que podría extraerse de aprender los unos de los otros, mejorando los trabajos en general.

Yo no sé si es que soy raro, pero disfruto dando, viendo que el camino que he recorrido puede servir a otros a modo de guía. Alguno de por aquí os lo podría decir. No sé si será porque no tengo la necesidad de ganarme la vida desarollando para X-Plane, porque tengo mi trabajo esperándome cada día, de ahí también la lentitud en mis investigaciones, por llamarlas de algún modo exagerado.

Muchas gracias por los ánimos, así es como he entendido yo tu contribución.

Tu última frase es lo que pretendía decir y que has entendido. Tu exposición la encuentro muy acertada, el principio para el aprendizaje es compartir lo que saben los eruditos, si los conocimientos se guardan con celo durante la historia de la humanidad ya se han visto los resultados, Galileo aún ............. entre otros muchos, eso le pasó por intentar compartir sus conocimientos, pero como bien comentas, la propiedad intelectual también tiene que dar para vivir, pero no necesariamente como sultanes.

Saludos

Exacto y perfecto.

Por eso soy partidario de dejar las pocas cosas que hago totalmente libres, para que cualquiera pueda modificarlas o usar cualquiera de sus partes para otro proyecto, respetando las mismas condiciones que el mio.

No me apetece tener que reinventar la rueda cada vez.

Alguien me preguntó que porqué el Baron era gratuito. Esta es la explicacion mas acertada que he encontrado para responder a esa pregunta. De alli tambien, mi obsesion por no utilizar plugins.

Comparto competamente tus palabras.

sigo pensando que para hacer la lluvia realista.. yo la haría con partículas. A ver.. es como se hace en el resto de videojuegos y queda genial. El tema sería tener un software que procese una serie de planos mapeados pequeños (rectángulos) alineados paralelamente a una superficie (en este caso al cristal) y movidos por una fuerza (el viento) que puede ser con turbulencia. Si a eso le añadimos la textura animada.. ya sea con rotaries o lo que sea, ya está hecho.

El programa que haga eso ya existe. Incluso el plugin creo para sacar dichos polígonos y convertirlos a geometría con su animación. El tema sería exportarlos a x-plane y ahí es donde creo se necesitaría programación (por que si no ya lo habría hecho). No se si por medio de plugin o por medio de base fuente.

En cuanto a como hacer las cosas. Bueno yo siempre he dicho como las hago.. de echo en el .org todavía debe andar el post que puse sobre como hacer el HUD que hice en el Javelin y que antes pregunté a Nils sobre su hurrican (lo hizo antes que yo) y que no me quiso explicar por que si "competencia y tal y pascual".
Yo creo que el tema no es publicar los truquis.... Eso da igual. Tarde o temprano se sacan. El tema es hacer algo. Mucha gente sabe modelar y texturizar pero no hay tantos trabajos por que se tarda UN HUEVO! y exigen mucho tiempo.

En el tema de la lluvia lo que hice fue duplicar los cristales... cuadrangularlos en pequeños cuadraditos.. con textura mapeada de puntitos de lluvia. los corto y los agrupo (unos 10 grupos). los oculto o muestro con un dataref que va de 0 a 1 y vuelta a 0 (Ping-pong o algo por el estilo, seno y coseno también.. no me acuerdo del nombre ahora). Después pongo planos más largos con textura de gota resbalando. lo animo para que sea repetitivo y le asigno el dataref (no me acuerdo del nombre real pero es algo asi como rotación de luz de aeropuerto, que va de 0-360 y vuelve a 0 en un salto. Ideal para hacer animación lineal). Y ya está.
No está hecho que se comporte bien con respecto al viento.. o sea que o lo veo o lo dejo tal cual. Supongo que tarde o temprano lo veré como hacerlo.
Anton me dijo que podría averiguar cual es la textura que cargo de las gotas de lluvia con un código de bloques insertado en la textura y asi animar dicha textura. Pero como dijiste, eso es cuestión de programar en opengl y se sale un poco de madre.... Yo la verdad ni idea de programación. Bueno sí.. algo sí.. gracias a ti.. y te digo que no lo he dejado.. pero va muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuy lento el aprendizaje.

ale.. a mandar.

ah.. en cuanto a que las gotas te salen grandes en la cabina... eso es por que asignas a un plano toda la gota.. y se deforma. Divide el plano en varios segmenos y asigna a cada uno esa textura.. se verá repetitivo pero será más pequeño. Ahí entra tu habilidad para que no parezca repetitivo. De todas formas hacer los segmentos con plane maker.. chungo... o sea que te tienes que ir a blender... entonces puedes manejar una textura de pocos píxeles para ello. Con paciencia que al final se llega a puerto.

Buenas,

Gracias por tu aportación Japo, precísamente tu perteneces al grupo que es la excepción dentro del mundo de la autoría de aviones virtuales. Nunca te ha importado compartir conocimiento. Gracias por ello.

La solución que prentendo aportar se basa también, como en tu caso, en una lluvia de fondo -lo que yo llamo gotas estáticas-, representada por una cuadrícula, más una capa de gotas dinámicas que se muevan a lo largo del cristal. Si, se podría hacer por sistema de partículas, pero si prerenderizas la animación resultante el problema es aplicarla sobre el objeto que toque. Lo puedes hacer por OpenGL, que es lo mejor, pero entonces debes conocer en todo momento las coordenadas absolutas OpenGL de las esquinas de cada celda de la retícula, que depende del movimiento del avión, etc. Puedes conocer las coordenadas OpenGl del avión mediante lamadas a la API, los DataRef que indican la posición OpenGL del avión son estos:

sim/flightmodel/position/local_x
sim/flightmodel/position/local_y
sim/flightmodel/position/local_z

Hay que tener en cuenta que solo con esto no conocemos los vértices de la retícula, pues el avión no siempre apunta hacia el mismo sitio, si no que gira en sus 3 ejes. Para conocer estas coordenadas tendríamos que usar tambien los siguientes DataRef:

sim/flightmodel/position/theta -> Angulo de giro en eje X
sim/flightmodel/position/phi -> Angulo de giro en eje Z
sim/flightmodel/position/psi -> Angulo de giro en eje Y

Con los seis DataRefs anteriores y la correspondiente trigonometría podríamos conocer las 4 coordenadas OpenGL de las esquinas de un plano sobre el que mapear la textura animada, pero esto no es todo. Lo deberíamos hacer para cada rectángulo de la retícula, porque hemos dividido el cristal en rectángulos, de modo que en todo momento sepamos las coordenadas OpenGL de cada plano a texturar con la textura animada. Para animar la textura se usaría la función del API gráfica de X-Plane XPLMBindTexture2d estableciendo a cada ciclo una textura distinta -un fotograma distinto- y luego mediante OpenGL dibujar un rectángulo con esa textura en esa cuadrícula. Vamos, ya os podeis imaginar el lío y si optamos por implementar el propio sistema de partículas, en lugar de usar su renderizado, en el propio X-Plane, sería aún más complejo.

Bueno, o todo lo anterior o podemos establecer un sistema de objetos geométricos ya establecidos en el OBJ del avión, de modo que todos los cálculos ya sean relativos a la posición del mismo, evitándonos, en cierta medida, el tener que calcular las coordenadas OpenGL. Esto último es lo que pretendo.

Para la lluvia de fondo, últimamente he pensado en usar, en lugar de rectángulos, círculos. La idea es, muy parecido a lo que tu, Japo, has hecho. Cubrir el cristal con los círculos, a modo de rejilla, asignar una animación por rotary a los mismos, de modo que haya solo 4 o 5 rotaries distintos, cada uno con una animación que difiera de las otras lo suficiente. Deberán ser animaciones que representen la aparición de las gotas un pequeño resbale de las mismas y su desaparición, haciendosen transparentes, cada círculo girará respecto de su centro y de acuerdo a un custom DataRef calculado por plugin según las distintas fuerzas que actúen sobre las gotas virtuales.

Para las gotas dinámicas, pretendo usar objetos mayores y que los mismos resbalen hasta el límite del cristal y sean reutilizados y su trayectoria calculada también teniendo en cuenta la física.

Bueno, añado una nota para deciros que lo de animar texturas o dibujar, de forma adecuada, en la cabina 3D mediante OpenGL parece ser que no es posible con esta versión de X-Plane. El mismo Ben Supnik lo comentó a principios de año en esta aportación del foro de X-Plane.org: http://forums.x-plane.org/index.php?showtopic=35755 (http://forums.x-plane.org/index.php?showtopic=35755)

La idea de poder dibujar la lluvia mediante OpenGL se basaba en realizarlo en la fase xplm_Phase_Objects, pero parece ser que lo dibujado en esta fase no es mostrado en pantalla cuando se está en la vista de cabina 3D. Ignoro, por el momento, si en lugar de dibujar en esta fase se podría realizar en la xplm_Phase_Gauges, que es adecuada para dibujar en el panel. Yo de todos modos sigo con la idea inicial de hacerlo por objetos, que es además el método recomendado por Ben para dibujar en la cabina.

Alucinante, compadres. Estais a AÑOS LUZ del resto de nosotros... Ánimo con vuestras investigaciones, que redundarán sin duda en beneficio del resto de este humilde "ganao".
Recibid un respetuoso saludo.

Muchas gracias por tus palabras Francisco, de veras que agradezco mucho los ánimos que me enviais.

Ahora, al turrón, como se suele decir.

He estado perfilando en mi cabeza el algoritmo principal para la creación de las gotas de lluvia de fondo. El tema está en tener unos cuantos polígonos fijos; rectángulos, circulos, eso al final va a dar más o menos lo mismo. Cierto número de estos polígonos se mapearán por UV a un rotary, otro grupo a otro, etc. En total puede haber unos 10 rotaries, cada uno con su animación correspondiente y distintas entre ellas.

Como la idea es que el número de gotas varíe al cambiar la intensidad de la lluvia, se me ha ocurrido un sistema por el cual según el valor del DataRef rain_percent, que va de 0 a 1 cada rotary se posicionará en un fotograma correspondiente con el número de gotas proporcional al valor de dicho DataRef. ¿Como hacerlo?. Fácil, pensando en binario. ¿Extraño?, no tanto, vamos a verlo.

Creamos la animación de cada rotary con 16 fotogramas, eso son valores de 0 a 15 para el custom DataRef de un rotary particular, es decir, que el valor del DataRef, como máximo, tendrá 4 bits, porque 2^4=16 yendo de 0 a 15, como ya hemos visto. Ahora lo que hacemos es poner en cada fotograma el mismo número de gotas que el número de bits a 1 que tenga el valor del DataRef que le corresponde. Así tenemos que para el fotograma nº 1, valor de DataRef 0, no hagrá gota alguna, para el 2º fotograma (valor 1) habrá 1 gota, para el 3º (valor 2) habrá una gota, para el 4º (valor 3) habrá dos gotas, porque el número 3 tiene dos bits a 1 en binario (011).

De este modo, según el valor del DataRef rain_percent podemos escoger qué fotograma de cada rotary mostrar.

Para evitar el reconocimiento de patrones, para lo que el ojo humano es experto, crearemos varios rotaries, entre ellos el nº de gotas por fotograma, segun el valor de su DataRef será el mismo, pero lo habremos dibujado de forma diferente para los diferentes rotaries. Es decir, todos los fotogramas de valor de DataRef = 7 tendrán 3 gotas dibujadas (7 tiene 3 bits a 1 en binario), pero cada rotary las tendrá en posiciones distintas.

Para establecer el valor de cada rotary lo que se hará es escoger N posiciones aleatoriamente, dentro del medio byte que le corresponde, para establecerlas a 1. Es decir, si rain_percent es 0.85, podemos hacer 0.85*3 (el nº máximo de gotas y bits a establecer a 1, -1) = 2,55 ahora redondeamos, lo que se queda en 3, que en binario tiene 2 bits a 1, de modo que ahora escogemos dos posiciones aleatoriamente de las 4 posiciones y las ponemos a 1, y eso para el valor del DataRef de cada rotary, de modo que todos rotaries mostrarán un fotograma con dos gotas, pero podrán ser cualquiera de los correspondientes a los valores de DataRef  3, 5, 9, 10 o 12. Hay que tener en cuenta que no multiplicamos rain_percent por 4 porque solo hay un fotograma equivalente a todos los bits a 1 lo que daría lugar a que si rain_percent es 1 siempre habría el mismo fotograma por rotary y eso no es lo que deseamos.

Si ya hemos dicho que los fotogramas de mismo número de N gotas serán disintos entre los diferentes rotaries, ¿por qué aleatorizar los valores de DataRef para cada uno de ellos?. La intención es que se perciba mayor variedad, la idea es evitar, en la medida de lo posible, la existencia de patrones reconocibles, digamos que el número de rotaries distintos influye en la variedad de gotas sobre toda la superficie en general, lo que podríamos denominar caos espacial, y la aleatoriedad, a la hora de generar los bits a 1, influye en la aleatoriedad a lo largo del tiempo, el caos temporal, intentando mostrar fotogramas distintos, para el mismo polígono, aun cuando tengan el mismo número de gotas cada uno por si no varía en el tiempo el rain_percent de forma significativa.

Mapearemos los polígonos a cada rotary de forma aleatoria también, para que dos polígonos contiguos no compartan el mismo rotary de animación.

Os pongo un gráfico con el esquema de funcionamiento. No se que tal resultado dará hasta que lo pruebe, puede ser que no parezca todo lo aleatorio que sería deseable pero hay que encontrar un compromiso entre como nos parece que queda y el número de rotaries a crear. Cada fotograma de los rotaries será de tamaño reducido, lo justo para que quepan las 4 gotas como máximo (si usamos 16 fotogramas). Yo probaré inicialmente con fotogramas de 16 pixels de ancho, de modo que los 16 fotogramas quepan en un bitmap de 256 pixels de anchura.

(http://i212.photobucket.com/albums/cc188/Khaleg/Algoritmo_Lluvia_01.png)

Si tenéis el interés o curiosidad suficientes, cualquier duda que os surja con esto,  no dudéis en preguntar.

Mira que si después de tanto pensar queda mal... Bufff...

Un saludo.

Un detalle que no veo, cuando el binario es 0011, que corresponde a 2 gotas, al igual que el 0101 o el 0110 no lo veo representado en el cuadro "ejemplo con fotogramas 0, 5 y 13 para A, B y J respectivamente" pero en las secuencias de fotogramas de los rotarys A, B, y J el 0011 son 2 gotas pero en diferente ubicación, puedes aclararme el tema  ;D, solo por curiosidad y para ver si me aumentan las conexiones neuronales  :D

Ningún problema, a ver si lo explico bien.

En el ejemplo, solo he representado los fotogramas 0 para el rotary A, 5 para el B y 13 para el J, escogidos arbitrariamente, símplemente a modo de ejemplo. El 0011 que indicas, que corresponde al fotograma nº 4 -valor de DataRef de rotary = 3 (0011)- de cualquier rotary, efectívamente, no aparece en el recuadro de ejemplo porque, como digo, solo he representado el 0 del A, el 5 del B y el 13 del J, no busques lógica en por qué he representado esos, el ejemplo era mas bien para ilustrar que los rotaries se distribuyen más o menos de forma arbitraria por los distintos rectángulos, no para ilustrar el algoritmo de selección del fotograma. Si te fijas, en ese ejemplo todos los rectángulos tendrían que tener el mismo número de gotas, todos  2 o todos 3, según el algoritmo descrito, porque el DataRef rain_percent tendría el mismo valor a la hora de calcular los fotogramas a mostrar para todos los rectángulos, sin embargo el ejemplo no lo he puesto consistente con esto, símplemente porque quería hacer patente la relación entre el cuadro izquierdo con las letras de los rotaries y los fotogramas escogidos de cada rotary.

El número de gotas que puede tener cada rectángulo -polígono- dependerá directamente del valor de intensidad de la lluvia, de modo que cuando dicho indicador diga que el número de gotas a representar por rectángulo es de 2, sólo podrán aparecer fotogramas con dos gotas, es decir, podrán aparecer los fotogramas 3, 5, 6, 9, 10 y 12. Los fotogramas, dentro de un mismo rotary, aun cuando tengan el mismo número de gotas entre si, las tendrán dibujadas en distinto lugar, para que cuando ocurra que el marcador de intensidad de lluvia no varíe significatívamente y durante una cantidad de tiempo determinada y solo se muestren fotogramas con el mismo número de gotas, estas aparezcan en posiciones distintas a lo largo de ese tiempo -aunque dentro del mismo rectángulo- dado que es de esperar que el algoritmo, aun a pesar de escoger fotogramas con el mismo número de gotas, los escoja distintos a cada ciclo. Si en el caso de los fotogramas con dos gotas, 3, 5, 6, 9, 10 y 12 las hubiesemos dibujado en el mismo lugar, para el mismo rotary, cuando el número de gotas a mostrar fuese 2 daría igual escoger cualquiera de estos fotogramas, pues todos ellos serían iguales. Son distintos para que, aun cuando el número de gotas a mostrar por rotary se mantenga constante durante un tiempo determinado, las gotas varíen de lugar y de la sensación que caen gotas en posiciones distintas, dentro del mismo rectángulo.

Por otra parte los diferentes rotaries tienen los fotogramas pertenecientes al mismo binario distintos, para disimular patrones que puedan formarse dado que el cristal es dividido y cubierto por estos rotaries, pero en número limitado, repitíendosen varias veces el mapeado UV de cada rotary. Si dos rectangulos adyacentes, digamos que tienen asociado el rotary A y B, respectivamente, y el fotograma del binario 0011 fuese idéntico en ámbos rotaries, podría suceder que en ámbos rectángulos apareciese la misma formación de gotas cuando el fotograma escogido fuese ese, lo que daría a entender un patron de texturas demasiado obvio a lo largo de la superficie.

Resumiendo:
Los fotogramas con el mismo número de gotas y dentro de un mismo rotary, son distintos entre sí para disimular patrones de gotas a lo largo del tiempo.

Los fotogramas con el mismo número de gotas, entre distintos rotaries, son distintos entre sí para disimular patrones a lo largo de la superficie.

Espero haberlo aclarado y haber resuelto tus dudas. La verdad es que es un poco lioso, sí.

Ahora estoy realizando simulaciones de este algoritmo en Visual Basic, que me da un resultado muy inmediato, para ver como queda en la simulación, de momento parece que luce decente. Me gustaría poner un vídeo para que se pueda apreciar como llueve más cuando rain_percent así lo indica, aunque lo tengo chungo, no tengo conectado el PC a video y Fraps no graba aplicaciones GDI, solo Direct X y OpenGL. Veré a ver que puedo hacer para intentar mostraroslo.

Gracias y un saludo.

Hola,

He podido subir un video a youtube con el test del algoritmo a implementar para la representación de las gotas de fondo.

http://www.youtube.com/watch?v=rdPS7t2pMu0

La barra que muevo con el ratón es el equivalente al DataRef de X-Plane rain_percent, solo que multiplicado por 100. El algoritmo funciona de dos maneras distintas. La homogénea y la heterogénea. En la primera todas las celdas muestran el mismo número de gotas, es decir, que si toca mostrar N gotas por celda, N gotas aparecen en cada una de las celdas. En la heterogénea cuando las gotas a mostrar son N no se muestran esas N en todas las celdas, si no que, de forma aleatoria por celda, las gotas mostradas son entre 0 y N.

EL método heterogéneo escala mejor con los diferentes valores de rain_percent, como podéis observar, a valores bajos las gotas aparecen tímidamente, y su aumento en número es mucho más suave a medida que aumenta rain_percent. Esto viene dado por el hecho de que con el algoritmo en modo heterogéneo, es posible que el número de gotas mostrado por celda sea 0 o menor de N.

También tengo que decir que si el número de bits de valor de DataRef de los rotaries se aumenta en 2, pasando de 4 a 6, y por lo tanto en lugar de 16 fotogramas pudiese haber 64 fotogramas por rotary, podría aprovechar los nuevos para dibujar, en lugar de gotas redondas, salpicaduras de modo que el DataRef de velocidad podría gobernar la aparición de gotas redondas o salpicaduras según la velocidad del avión. Así puedo mostrar gotas normales cuando estemos parados y gotas alargadas o salpicaduras cuando estemos en movimiento. Esto incremetnaría el tamaño del gráfico de los rotaries hasta 1024 pixels de ancho (16 x 64, si dibujo cada gota con una anchura de 16 pixels, que creo que estará bien y será mas que suficiente).

Vuestras opiniones serán bienvenidas. Un saludo.

Perfectamente comprendido, lo intuía pero con intuirlo no es suficiente, ahora esta perfectamente claro.

Tras ver el video, queda, a mi parecer, mucho mas natural el método heterogeneo

Felicitaciones por tu trabajo e investigación en curso

Hola,

Tras unos días de descanso que me he tomado de mi mismo -la parte más creativa y menos lúdica- aquí os dejo otro vídeo que muestra una modificación al algoritmo de la lluvia. He agregado el método Pseudohomogeneo, que en realidad no tiene nada que ver con pseudo ni con homogéneo, pero algún nombre le tenía que dar a la etiqueta en el programa.

Con este método observaréis que la generación de las gotas escala mejor con el valor de RainPercent. El método homogéneo era demasiado agresivo, enseguida se llenaría la pantalla con gotas, además, se desperdiciarían los fotogramas con 4 gotas, porque no hay fotogramas distintos para un mismo Rotary con 4 gotas, con 4 gotas solo hay un fotograma por rotary, lo que produce que cuando son 4 las gotas a mostrar, estas no cambien de posición por celda con el tiempo, dado que el algoritmo homogéneo siempre muestra por celda el número total de gotas a mostrar según RainPercent .

El heterogéneo, como el compañero jorduran dijo, parece más natural, pero a niveles altos de RainPercent es demasiado "suave", hay muchas áreas sin gotas, de modo que me he decidido a implementar algo entre medias de los dos. El método Pseudohomogéneo genera gotas tímidamente a valores bajos de RainPercent, en valores bajos-medios hay más gotas, pero aún hay zonas con posibilidad de que no caiga ninguna, en un momento dado; a valores medios la lluvia es mas copiosa y a valores altos lo es aún más. Es decir, con el nuevo método hay más situaciones distintas en cada momento. Personalmente creo que es el que mejor queda.

Ahí va el vídeo
http://www.youtube.com/watch?v=0JlP4hUqjA4

Muy conseguido, ya hay otro paso resuelto  ;)

Hola de nuevo.

Gracias Jorduran se hace lo que se puede con lo que se tiene ;-)

Había empezado yo con el dibujado de los PNG para las texturas animadas cuando hoy -maldita sea la ley de Murphy-, al encender el equipo para continuar con el trabajo, parece ser que se ha dañado el disco duro del sistema. No es que haya perdido nada de lo hecho, pues todo en lo que trabajo lo tengo duplicado y además almacenado, aparte, en un sistema RAID 5 externo, pero bueno, tengo que diagnosticar el problema -ójala sea solo problema de disco-

Si realmente es el HD lo tendré que sustituir por uno nuevo e instalar la imagen de sistema, indudablemente, a pesar de no haber perdido nada, me llevará su tiempo.

Símplemente que lo sepáis, que si es problema de disco -que tiene todas las pintas- el lunes encargaré uno nuevo, segúramente para el miércoles ya lo tendré y en un dia o dos más estaré en condiciones de continuar.

Saludos

Hola,

Ya parece que he reparado el equipo de desarrollo gráfico, de modo que me encuentro en disposición de continuar con el dibujado de los PNGs.

Saludos.

Y has pensado en simular el efecto de los wipers?

Pues sí, entra dentro de mis intenciones. Algo haré o intentaré hacer  ;)

Muy buenas,

Aqui os dejo una pequeña muestra del trabajo. Se trata de la animación de múltiples gotas para el rotary de tipo A. Según la descripción del método, como ya habréis visto anteriormente en este hilo, habrá varios tipos de rotary, por tipo quiero decir que cada uno contendrá una animación de N gotas distinta. A X celdas rectangulares del polígono del "cristal" se le asignará un rotary del tipo A, a otras X otro de tipo B...etc. Al final no sé cuantos tipos tendremos, eso dependerá de lo aleatoria que parezca la lluvia y del tamaño de la textura del panel, dado que todos los rotaries deben ir en esa textura.

Bueno, aquí está la animación. La disposición de las gotas en ella, para cada fotograma la he hecho igual que la correspondiente en el programa en Visual Basic para la simulación del algoritmo.

(http://i212.photobucket.com/albums/cc188/Khaleg/Gota_Tipo_A.gif)

Todas las gotas son iguales, pero, en caso de necesidad, para mejorar el aspecto y aleatoriedad de las gotas en la lluvia, podremos deformar dichas gotas en cada fotograma, para que parezcan gotas distintas. Eso probaré a hacerlo posteriormente, lo primero es tener todas las animaciones para todos los tipos de rotary, de modo que pueda integrarlas con la geometría del avión de ejemplo que estoy usando, a ver como queda.

Saludos

Símplemente comentaros que el proyecto no está muerto, pero estoy "perruno", con muy poco tiempo libre y, claro, la cosa va muy, muy despacio, más de lo que había previsto, porque también me apetece volar, y claro... debo repartir el tiempo del que dispongo.

El otro día en un par de horas libres comencé con el mapeo UV del área sobre el que situar a lluvia, ya está el mapeo UV terminado -ya pondré algunas capturas-. De esta primera fase queda terminar las animaciones de los rotary -tengo hechas la de dos tipos- e ir poniendolos en el cockpit 3D. Estoy usando un cockpit de 2048 pixels de resolución, para que se vean mejor las gotas al hacer zoom.

Un saludo.

Buenas,

Como os dije en una aportación anterior, aqui os pongo unas capturas del parte del proceso de creación del sistema de la lluvia esta...

Ya tengo las animaciones de los rotaries, al he hecho 4 tipos de ellos, es decir, que podrá haber 4 tipos de animación diferente para las gotas. Todo el parabrisas consta pues de un "grid" en el que en cada celda habrá una animación de gotas chocando en el cristal, con 4 animaciones distintas en total.

Las capturas que os pongo a continuación son la parte correspondiente a la creación del UV-mapping del parabrisas, que podeis ver como se ha dividido en celdas. En la creación del UV-Map se tratará de dejar todas las celdas totalmente planares con respecto a la textura y del mismo tamaño. Posteriormente se mapeará cada celda a uno de los 4 rotaries del panel de instrumentos.

En la edición de los vertices para el UV-Mapping inicial se ha tenido como punto de referencia el cursor 2D de la ventana de texturas en Blender, tal y como indico en la siguiente captura

(http://i212.photobucket.com/albums/cc188/Khaleg/Dibujo.png)

Ahora un resumen de los pasos para la creación del mapa UV:

(http://i212.photobucket.com/albums/cc188/Khaleg/Rain_Project_UV_01.png)

(http://i212.photobucket.com/albums/cc188/Khaleg/Rain_Project_UV_02.png)

(http://i212.photobucket.com/albums/cc188/Khaleg/Rain_Project_UV_03.png)

(http://i212.photobucket.com/albums/cc188/Khaleg/Rain_Project_UV_04.png)

El próximo paso consistirá en realizar con X-Plane un "preview" del panel para posicionar adecuadamente cada celda sobre el rotary que le corresponda.

Si tenéis alguna duda sobre el proceso general de creación del mapa UV a partir de la malla con gusto os las responderé si está en mi mano.

Saludos

Uuuuuuuufff

No me he enterado de nada, pero acojona  ;D

Tranquilo, que no es para tanto. Segúro que es porque me explico como un zapato. Resumiendo, así, para ponerlo "en corto" -algo un poco complicado de hacer-

Ahora mismo lo que estoy haciendo es crear un "tapiz" de gotas de lluvia que caigan más frecuentemente según el valor del DataRef que indica la cantidad de lluvia. El efecto se intenta conseguir creando animaciones en las cuales en cada fotograma hay un número determinado y distinto de gotas. La selección del fotograma a mostrar dependerá del DataRef mencionado anteriormente, de modo que hay fotogramas con 1 gota, otros con 2, otros con 3 y un fotograma con 4, habiendo en total 16 fotogramas por animación, es decir, hay más de un fotograma con una, dos o tres gotas. Esto es así para que cuando la cantidad de gotas a mostrar, dado el valor del DataRef, sean 3, haya más de un gráfico a escoger con 3 gotas, para que parezca que caen 3 gotas pero en sitio diferente cada vez, dado que a cada ciclo de dibujado se escogerá el fotograma a mostrar.

Para implementar el sistema de fotogramas se van a usar 4 rotaries con 15 fotogramas por rotary. Por ejemplo aquí tienes todos los fotogramas en secuencia para el rotary que he denominado "de tipo A": (http://i212.photobucket.com/albums/cc188/Khaleg/Gota_Tipo_A.gif)

Se van a usar 4 rotaries para que sus animaciones difieran y haya más variedad, pues cada rotary tendrá varios fotogramas con el mismo número de gotas pero en distinto lugar, pero también serán distintos esos mismos fotogramas entre los distintos rotaries.

Estos 4 rotaries se pondrán como instrumentos en el panel del avión y será necesario mapearlos a lo largo de la superficie del parabrisas. Esa es precisamente la parte en la que estoy y he descrito. Para el parabrisas, un plano en 3D curvado, y para cualquier objeto 3D representado en el simulador, es necesario asignar una textura, como parte del proceso hay que generar lo que se denomina un mapeado UV, que no es si no indicar al motor de renderizado en dónde, a lo largo de la superficie del polígono, debe caer cada pixel de la textura.

El problema aqui radica en realizar un mapeado UV que minimice la deformación de la textura a lo largo de las caras del polígono. Como el parabrisas es un plano, en forma de malla, pero curvado, y la textura a aplicar es un dibujo 2D de unas gotas de agua -los rotaries-, lo mejor es crear un mapeado UV uniforme, de forma que cada fotograma de los rotaries caiga justo en cada rectangulo que forman el plano del cristal, y como todos los rotaries van a ser del mismo tamaño, lo mejor es procurar que en el mapeao UV todos los rectángulos sean iguales, de este modo minimizaremos la distorsión de la textura a lo largo del cristal, al menos esa es la intención. Por eso os he puesto las capturas de cómo estoy realizando ese mapeo UV.

Espero que se entienda mejor. Si alguna cosa particular no se entiende, os ruego me la preguntéis, que trataré de explicarme mejor o con otras palabras, o ejemplos, según sea el caso.

Saludos.

Entendido.

Y si no entiendo mal, se podrá implementar en distintos aviones sin demasiada dificultad, no?

La idea es establecer un método estándar y aplicable a cualquier avión sí, incluso sirviendo el mismo plugin que gestionará todo esto. Eso sí, dependiendo de la gracia artística que cada cual tenga el efecto gráfico quedará mejor o peor. Aqui, para el desarrollo, estoy usando gráficos que parecen gotas, pero lo correcto, en realidad, sería usar salpicaduras, fijándose uno en cómo queda una gota cuando ya ha impactado sobre la superficie, o una mezcla, en su justa medida, de los dos tipos de gráfico.

Bueno, me permito exponeros un poco más de información a cerca del proceso de creación.

Aquí os incluyo lo que son los gráficos correspondientes a los fotogramas de los cuatro tipos de animación de rotary representando grupos de gotas para una única celda del parabrisas

Referencia de fotogramas (usadlo como guías)
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_A_512x32_REF-1.png)

Rotary tipo A:
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_A_512x32-1.png)

Rotary tipo B:
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_B_512x32-1.png)

Rotary tipo C:
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_C_512x32-1.png)

Rotary tipo D:
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_D_512x32-1.png)

Tened en cuenta que se trata de tiras de 16 fotogramas de 32x32 pixeles cada uno, lo que hace que cada tira sea de 512x32 pixeles.
En estas muestras podréis apreciar como para un tipo hay varios fotogramas con dos gotas, pero cada uno de ellos las tiene en distinta posición, es decir, en una misma tira, en horizontal, hay varios gráficos con 1, 2, 3 o 4 gotas, pero en todos ellos están situadas de forma distinta, excepto para el de 4 gotas, que es el último y solo hay uno con cuatro. Hacer notar también que el primer fotograma equivale a no tener lluvia, por lo tanto, no hay gotas en él.

Así mismo si miráis de arriba hacia abajo, en la misma columna, recordad que cada columna, pese a no estar marcada de ninguna manera, equivale a una anchura de 32 pixeles, apreciaréis como cada tipo tiene los fotogramas con una, dos, tres o cuatro gotas en las mismas columnas, pero son también distintos entre los diferentes tipos.

La diferencia de fotogramas en una misma tira nos dará como resultado diferenciación temporal, mientras que las diferencias en columnas nos dará diferenciación espacial.

Con respecto al objeto 3D que hará de parabrisas en la vista interior. Aquí tenéis una captura de Blender en la que se aprecia el objeto y el panel, muy simples pero válidos para el desarrollo. La perspectiva del parabrisas parece extraña pero es debido a que se trata de una superficie con sus normales hacia dentro, por lo que su cara exterior se ve aquí, y en X-Plane, transparente.

(http://i212.photobucket.com/albums/cc188/Khaleg/Cockpit_3D_1.png)

Si activamos la edición de la geometría del objeto se podrá apreciar mejor su forma poligonal:
(http://i212.photobucket.com/albums/cc188/Khaleg/Cockpit_3D_2.png)

Como veis el trabajo de mapeado UV consiste en "aplanar", "des curvar" la superficie del cristal de modo que toda ella quede coplanar a la superficie de la textura, que siempre es plana al ser 2D. El proceso descrito en una aportación mía anterior ha dado como resultado lo siguiente:

(http://i212.photobucket.com/albums/cc188/Khaleg/Parabrisas_UV.png)

Lo que veis en la imagen anterior es ya el mapeo UV del parabrisas sobre la textura de la cabina 3D. En la parte con el panel se ha realizado el mapeo UV del objeto del panel de instrumentos, aunque no lo veis aquí, bajo el mapeo UV del parabrisas lo que hay es un ligero color azul con transparencia y algo de suciedad pintada en los límites. El pequeño rectángulo blanco no lo es tal, aunque aquí se aprecia blanco es transparencia del mismo nivel que el cristal del parabrisas, aquí es en dónde se colocarán los rotaries.

Aquí tenéis una captura de PlaneMaker con los instrumentos ya colocados encima de la textura del panel, incluidos los rotaries que son esos rectángulos con borde azul que se aprecian en la parte central-izquierda.

(http://i212.photobucket.com/albums/cc188/Khaleg/PlaneMaker_02.png)

Ahora un siguiente paso será mover los puntos del mapeado UV del parabrisas para poner cada celda sobre un rotary particular, intentando no usar el mismo rotary para celdas contiguas. Para facilitar la tarea lo que he hecho es crear una textura diferente de la de las gotas para los rotary, con ese borde azulado para saber dónde quedan, pues de lo contrario, con las texturas definitivas no podría saber exactamente en donde está cada rotary. La textura provisional que he usado para tener las oportunas referencias ha sido esta:

Para el layer 1 del rotary
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_A_512x32_REF.png)

Para el layer 2 del rotary
(http://i212.photobucket.com/albums/cc188/Khaleg/Rotary_A_512x32_REF-1.png)

Tened en cuenta que el layer 1 de un rotary son los archivos PNG sin numeración en el nombre, como por ejemplo Mi_Rotary.PNG, este layer representa elementos del rotary carentes de transparencia, como podría ser una arandela exterior en un instrumento. El layer 2, es decir, archivos con un '-1' agregado al nombre, como puede ser Mi_Rotary-1.PNG representan elementos translucidos cuando se usa el tipo de iluminación 'Glass' en las propiedades del rotary dentro de PlaneMaker. Por lo tanto a la hora de simular instrumentos que en realidad son gráficos dentro de un TFT, por ejemplo, se crean con un PNG totalmente transparente en la capa 1 y el gráfico en la capa 2 (los PNG con el '-1' en el nombre). En el caso que nos ocupa de las gotas de agua es lo mismo, éstas se definen únicamente en la capa 2 porque son transparentes y carecen totalmente de elementos opacos.

Una de las mayores dificultades a las que se enfrenta el diseñador de aviones para X-Plane es el mapeo UV de los instrumentos pertenecientes al cockpit 3D pero que también son parte del panel. A la hora de mapear en una aplicación 3D nosotros cargamos la textura y realizamos el mapeo UV sobre esta, pero a la hora de situar los vértices sobre un instrumento del panel no disponemos de referencia alguna de en donde está situado un determinado instrumento dentro de la textura del panel. Lo que X-Plane hace realmente es tomar nuestra textura del panel y dibujar sus instrumentos encima pero, cuando nosotros realizamos el mapeo UV, ¿en donde están exactamente esos instrumentos?. Nosotros tenemos únicamente la textura, carente de instrumentos sobre-impresos.

Una solución a esto era realizar una captura de pantalla del panel 2D de X-Plane a la misma resolución que la textura del panel, de este modo ya teníamos los instrumentos sobre-impresos y teniamos las referencias necesarias, ésto que no es tan incómodo a la hora de trabajar con texturas de 1024x1024 se hace bastante más tedioso a la hora de trabajar con texturas de 2048x2048; esto es así porque no podemos capturar la textura completa con los instrumentos superpuestos en una única captura, dado que no podemos establecer la resolución de nuestros monitores a 2048x2048, debiendo realizar las capturas a trozos y recomponer el puzle más tarde.

Sin embargo a partir de la versión 9.30 de X-Plane, Ben Supnik agregó a X-Plane la capacidad de generar un Preview del panel, a su resolución correcta, simplemente con pulsar una tecla. Esta es la opción que debéis configurar para realizar tal acción (en X-Plane para Windows):

(http://i212.photobucket.com/albums/cc188/Khaleg/make_panel_previews_02.png)

Usando ésta característica, teniendo ya cargado el avión de prueba para el desarrollo de todo esto este es el resultado del preview:

(http://i212.photobucket.com/albums/cc188/Khaleg/Panel_Preview_01.png)

Aquí ya tenemos una textura completa con los instrumentos sobre-impresos. Véanse los rotaries en el centro-izquierda, hay otros en el parabrisas pero son solo de pruebas para ver que tal quedaban las gotas al tamaño escogido. El color rosa es porque yo tengo configurado ese color en Irfanview como color de fondo por lo que toda parte con algo de transparencia se ve ese fondo detrás, esto me ayuda en muchas ocasiones a distinguir qué parte de un gráfico es transparente, cual es negra -sin transparencia- y cual es blanca -sin transparencia-.

Sin las referencias de en donde están colocados los rotaries exactamente esto es lo que deberíamos hacer:

(http://i212.photobucket.com/albums/cc188/Khaleg/Parabrisas_UV_02.png)

Podéis ver que debemos remapear cada vértice de cada celda sobre un determinado rotary, pero lo estaríamos haciendo "a ojo" pues no tenemos referencia de en donde está situado de forma exacta cada rotary. Con el Preview generado por X-Plane la cosa cambia. Como podéis ver aquí:

(http://i212.photobucket.com/albums/cc188/Khaleg/Parabrisas_UV_03.png)

Ahora ya disponemos de las referencias correctas y exactas para modificar el mapeo UV del parabrisas y que cada celda caiga sobre un rotary.

Tenemos dos posibilidades. Si usamos un solo objeto como parabrisas, remapeado por UV sobre los rotaries, tal y como estoy describiendo, entonces el espacio de textura que ya no será usado lo podemos aprovechar para otros instrumentos o texturizar otros objetos. Si usamos dos objetos, uno el cristal y otro con las celdas de los rotaries, entonces, el mapeo original es el correspondiente al cristal y el remapeo de las celdas sobre los rotaries es el mapeo UV del objeto para la lluvia. En el primer caso se aconseja no remapear sobre los rotaries las celdas del perímetro del parabrisas, para que conserven la textura de suciedad en los cantos y esquinas.

Yo probaré a duplicar el objeto del parabrisas y remapear sus celdas sobre los rotaries, de este modo no pierdo el tintado del cristal ni los detalles de suciedades en él, etc porque tendré, por un lado, el parabrisas mapeado así:

(http://i212.photobucket.com/albums/cc188/Khaleg/Parabrisas_UV.png)

Y por otro el objeto para representar las gotas, mapeado inicialmente como el parabrisas pero, luego, modificado para remapearlo sobre los rotaries, así:

(http://i212.photobucket.com/albums/cc188/Khaleg/Parabrisas_UV_03.png)

Obviamente esta técnica, de desarrollarla así, tal y como la describo, conlleva el no poder usar la vista de cabina 2D pura.

Espero que todo esto haya sido ilustrativo y haberme explicado lo suficientemente bien. Creo que es más complicado de explicar que de hacer.

Un saludo

No creo  ;) el trabajo que te estas metiendo es IM-PRESIONANTE y el mapeado no tiene desperdicio, y como dicen en marinería: AVANTE TODA, pero sin prisas  ;D

Hola,

Bueno, me permito poneros una captura con la distribución preliminar de los 4 tipos de Rotaries a lo largo de las celdas del mapeado UV del objeto para la lluvia, que es copia del parabrisas:

(http://i212.photobucket.com/albums/cc188/Khaleg/Gotas_Lluvia_UV_Map_01.png)

Como podéis imaginar he intentado disimular cualquier patrón percibible, aunque con sólo 4 rotaries distintos es bastante complicado. Ahora lo que tocaría hacer, antes de remapear de forma definitiva cada celda sobre el rotary que le corresponde, sería realizar un "análisis estadístico" de la distribución, intentando ver qué zonas son las más propensas a que pueda discernirse un patrón, ya que no quedaría bien. Eso lo puedo hacer con un programa hecho a medida y para la ocasión, que analice cada celda y sus 8 adyacentes para determinar un índice que indique el nivel de diferenciación, luego se pinta en un gráfico un pixel, correspondiente a la celda analizada, de un color específico según el nivel de diferencia para la celda y, tras terminar su generación, àra todas las celdas,  se echa un vistazo al gráfico resultante para hacernos una idea de si hay alguna parte más homogénea -con mas igualdades- que otra, en la que puedan distinguirse patrones de gotas iguales. Si resultase demasiado evidente no quedaría otra que crear más rotaries distintos para colocarlos en esas partes con poca diferenciación, para intentar crear más variedad.

Es difícil de explicar con palabras, en cuanto pueda os pondré gráficos con la idea.

Por cierto, esta parte y la de remapear, son tediosas de la muerte. Jajaja.

Del proceso que has descrito no me he enterado mucho pero me he quedado con lo siguiente:
Yo creo que no deberías de darle tanta importancia al hecho de evitar la repetición de un patrón analizando una celda y sus ocho adyacentes. La caída de gotas en una superficie es en fenómeno aleatorio, pero también rápido y en una escala de un parabrisas bastante difícil detectar una repetición al mismo tiempo a no ser que te quedes fijamente analizando una zona. En el conjunto global no se va a notar a no ser que la repetición siempre se produzca en el mismo par de celdas.

Es que ese es el caso compañero. Ten en cuenta que todas marcadas con la A, en el mismo instante, van a tener el mismo número de gotas y en la misma posición. Lo mismo para las B, las C y las D. El tema de analizar cada celda no es algo a hacer dentro del simulador, si no un método para determinar en donde se necesitaría más variedad para tratar de evitarlo, es decir, no es algo a realizar en el plugin arriesgándonos a cargar en exceso el simulador.

Si que es verdad que quizá no debería darle tanta importancia. El problema es que si después de realizar el remapeo, que lleva lo suyo de trabajo, resulta que quedan mal los patrones, por la razón que sea, es una puñeta el tenerlo que volver a hacer poniendo más rotaries, ten en cuenta que cuando tenga todas las celdas remapeadas, sobre el rotary tipo A habrá tantos grupos de 4 vértices como celdas asignadas a la A, y lo mismo para la B, C y D, de modo que, en caso de tener que remapear algo, hay que partir de cero patatero, hay que partir de una malla original sin remapear, porque habrá muchos vértices, uno sobre otro, pero de distintas celdas, cualquiera los selecciona y los mueve, de ahí la intención de prevenirlo, para que el remapeo salga bien a la primera, dado que es un viaje solo de ida. Y eso que nadie garantiza que vayan a quedar bien tras el análisis este que comento, pero vamos, en principio deberían, que con esa intención se piensa.

Por discurrir que no quede.

Hola de nuevo,

Ya tengo los resultados del análisis estadístico sobre qué áreas de celdas disfruta de mas variedad y menos con respecto a las animaciones. Primero paso a exponeros el resultado y luego pasaré a indicaros cómo lo he realizado.

Partimos del mapeado UV a realizar con el objeto de las gotas sobre los distintos cuatro tipos de rotary (lo pongo otra vez porque he corregido una pequeña errata en el gráfico):
(http://i212.photobucket.com/albums/cc188/Khaleg/Gotas_Lluvia_UV_Map_01-1.png)

Como podréis ver, en este mar de letras distribuidas a lo largo de las celdas es dificilísimo discernir siquiera qué áreas de todo el grid tienen menos diferencias que otras, con respecto a la variedad en la distribución de las letras. La idea es analizar estadísticamente igualdades y generar un gráfico de colores que nos ayude a determinar las partes del grid con menos variedad de animaciones -menos variedad de rotaries-

Estos datos los importo al programa de análisis que he realizado:
(http://i212.photobucket.com/albums/cc188/Khaleg/analizador_vbs.png)

Tras realizar el análisis este es el resultado:
(http://i212.photobucket.com/albums/cc188/Khaleg/analizador_vbs_2.png)

En dicho resultado las celdas verdes brillante son las que menos celdas adyacentes con la misma animación tienen, a medida que el color verde va cambiando a más oscuro y hacia el rojo brillante más celdas con la misma animación rodean a la analizada. Es decir, a mas verde brillante, mas variedad, a mas rojo brillante, menos.

Este es el proceso que se ha seguido para realizar el análisis:

1.- He generado un archivo TXT con la distribución de los indicadores de animación y su disposición a lo largo del grid, por filas y columnas:
(http://i212.photobucket.com/albums/cc188/Khaleg/gotas_txt.png)

2.- El archivo de texto es importado en el programa y éste recorre cada una de las celdas y compara el indicador de animación de cada celda con las de su alrededor, así:
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_00.png)

La secuencia de imágenes siguiente detalla el proceso:

Se toma un área de 9 celdas (excepto para las perimetrales):
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_01.png)

Se toma el valor de la central:
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_02.png)

Se compara con cada una de las que la rodean, secuencialmente:
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_03.png)

Cuando coincide el valor, si está en su diagonal, lo valoramos como una coincidente de valor 1:
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_03.png)
.
.
.
Si no coincide lo valoramos como 0
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_04.png)
.
.
.
Cuando coincide el valor, si está en su misma línea vertical u horizontal, lo valoramos como una coincidente de valor 2:
(http://i212.photobucket.com/albums/cc188/Khaleg/Analisis_05.png)

las coincidencias en las diagonales se valora como 1 y las coincidencias en horizontal y vertical como 2 porque es más sencillo distinguir un patrón repetitivo cuando está en la misma horizontal o vertical que otro idéntico, de modo que valoro más negativamente cuando la coincidencia es en línea recta horizontal o vertical.

Los valores 0, si no hay coincidencia, 1 si la hay en diagonales o 2 si la hay en vertical u horizontal, se suman entre si, de modo que como máximo una configuración de animaciones con este patrón:
BBB
BBB
BBB

Daría como resultado del análisis de la 'B' central, en cada una de las posiciones, los siguientes valores:
121
202
121

Dando como total el valor 12

Despues de calcular el valor total por celda se cuantiza de forma que el máximo equivalga al rojo brillante, dando como resultado el que ya os he mostrado.

De este modo es fácilmente discernible las áreas conflictivas, susceptibles de mejora y corregibles añadiendo más tipos de animaciones -4 son muy escasas-. Por ejemplo aquí os marco las áreas en las que más fácilmente se podría ver que hay animaciones repetidas dentro de ellas
(http://i212.photobucket.com/albums/cc188/Khaleg/analizador_vbs_3.png)

Un saludo.