Para los que no quieran compilar el ejemplo de ATI del enlace que habia puesto, aqui lo teneis compilado.


Merece la pena verlo, asi podeis ver en toda su extension el efecto del scattering y el cambio radical que supone para una escena con terreno.
Al final de la demo recordad cerrar la boca y parpadear ;D.

El enlace de ATI es este
Ejemplo de ATI para descargar

Mas links:

Preetham -> A Practical Analytic Model for Daylight
Presentacion de Naty Hoffman-> Rendering Outdoor Light Scattering in Real Time

[<OFFTOPIC>]

<OFFTOPIC>

¿con qué juego estás liado?.

Se trata de un juego de coches llamado Lightning Wheels, puedes encontrar mas info en el blog que sale en la firma.
Aun quedan pendientes unos cuantos post que intentamos sacar tiempo de alguna parte para escribirlos :(.

</OFFTOPIC>

¿En que consiste el scattering?, si lo pudiera conseguir para GLSL me vendría bien, o alguna explicación detallada, si no también puedo probar a hacer uno yo mismo que además de cambiar la intensidad de niebla por distancia también cambie el tono (a más claro).

Simula el comportamiento de la luz en sus distintas longitudes de onda segun la distancia que recorre. Suele dividirse en Mie-Scattering y Raleigh-Scattering en funcion del tamaño de las particulas que intervienen.
Para mas informacion hay papers de hoffman y preetham que lo explican, ademas creo recordar que hay alguna presentacion de ATI o nVidia de alguna GDC.

El efecto viene a ser que cuanto mas lejos mas disminuye el contraste. Ademas consigues unas puestas de sol impresionantes :D. No te asustes con los formuloides que encontraras en la documentacion, es algo sencillo de entender leyendolo despacio un par de veces.

No puedo extenderme mucho mas ahora, estoy bastante liado con el juego. Si ves que no te aclaras postea aqui que me ha tocado pelearme con ello bastante y si tengo un rato te aclaro lo que pueda.

¿Como ves tú lo de las texturas grandes?, ¿o que experiencias tienes?

Hombre, yo creo que podrian funcionar bien, si tienes un radio de paginacion suficiente para poder ir cargandolas poco a poco no deberia provocarte tirones en el render.
Tambien dependera del area que te cubra cada una de esas texturas y cuantas tienes que cargar. Si vuelas a mucha altura y mucha velocidad es posible que llegues a tener problemas pq te estaran entrando nuevas zonas a cargar con mas frecuencia.

Sí, pero, en el caso de ponerse a volar no servirían los trucos que nos propone "marcode" para el caso de simuladores/juegos terrestres. Me dá la impresión que es una pequeña lacra con la que hay convivir en los simuladores de vuelo. A no ser que se impida el avance para no llegar a los límites del escenario.

En un simulador suele haber una base de datos asociada, si al contratarlo la bbdd es de España pues cuando se acaba, se acaba, vamos que no hay terreno. Recordad que un simulador es para entrenarse y suelen ser misiones especificas donde no se van a poner a explorar el resto del terreno.

JL10 escribió:

¿Cómo haces para que el color sea más ténue en la distancia?. ¿Has tenido que aplicar algún poco de niebla?.

Sí, es una niebla sencilla.

Has probado a implementar scattering?, queda muy realista y no es demasiado complejo, aunque te obliga a introducir shaders, que no se si ahora los estas utilizando.

Mi opinión es que deberá haber un thread dedicado a cargar los datos comprimidos del disco (preferiblemente de archivos grandes) a la memoria, y que hará también el proceso de descompresión y las operaciones que sean necesarias con los datos obtenidos para dejarlos preparados para ser usados rápidamente cuando sea requerido, este proceso debería ser sin mucha prioridad para que no baje mucho el rendimiento de la cpu, pero continuado.

Yo prefiero tener el control sobre cuando se leen los datos, decirle cuando debe leer y durante cuanto tiempo como maximo. En condiciones normales estaras cargando datos que se encuentran muy lejos del observador y que tardaran en entrar en escena, luego no habra problemas de quedarte pillado sin datos.
Una buena aproximacion es la de los geometry clipmaps (pesadito que estoy con este metodo :D), tiene en cuenta varios niveles de LOD de tal forma que si en un momento por lo que sea no puedes cargar datos de un cierto LOD (normalmente el mas detallado que sera el que cambie mas a menudo) se apaña con los de un LOD menos detallado que, de todas formas, si vas a mucha velocidad (buen motivo para no tener tiempo a cargar todo) no vas a notar la diferencia apenas.

Imagino que es a lo que se refiere Neophox con lo de relativizarlas, por ejemplo aunque cuenca ciudad esté en las coordenadas UTM 430000, 4570000 y yo me encuentre en la 400000, 4500000, al relativizar yo estaría en la 0,0 y cuenca se dibujará en la coordenada relativa 30000, 70000. Si avanzo 10Km al norte yo pasaré a estar de la 0,10000 a la 0,0 y cuenca quedará en la 30000,60000, es decir, todo retrocede 10000 metros.

Asi es, se trata de no permitir que las coordenadas tomen valores demasiado altos.

Muy interesante el metodo que usas, me ha recordado parcialmente los geometry clipmaps (le has echado un ojo?).
Una pregunta, mencionas que utilizas texturas de 2048, son texturas geoespecificas o geotipicas?, es decir, imagen real o algo generico?
Si son reales y paginas no solo altimetria sino tambien texturas de ese tamaño, te va suficientemente rapido? JPG? DDS?
Otra pregunta, el LOD lo calculas en funcion de la distancia en tiempo real o preprocesas la altimetria para tener listos varios LOD?

Un saludo.

Como te dice zupervaca, una buena opcion es implementar varios. Puedes empezar con el que mas sencillo de implementar te resulte, aislandote del resto de cosas, ni paginacion ni texturas ni nada, te diria que ni cargar terreno, createlo procedural. Libnoise es una libreria que puedes utilizar para generarlo sobre la marcha.
En cuanto a criterios para decidirte por uno u otro, yo no sabria decirte, leete los pros y contras de cada metodo (tampoco hace falta que te los leas todos y cada uno, muchos son copias de otro con pequeñas variaciones) y con ello decide. Entre las implementaciones que he visto yo me iria mas por aquellos con mallas regulares y buscaria minimizar el efecto popping al cambiar de nivel de detalle.
A mi el que mas me gusta es geometry clipmaps, por velocidad, detalle, simplicidad, capacidad de ser acelerado en gpu,...

AK47:
 Efectivamente, pueden existir problemas de precision si las coordenadas son muy grandes. Para ello habra que relativizarlas.


JL10:
 Si, es posible aplicar la paginacion al resto de informacion, aunque no siempre necesario. Puede haber cosas que entren en memoria sin problemas y no merezca la pena paginar. La paginacion es una herramienta mas, el hecho de descubrir el martillo no ha de llevarnos a utilizarlo para todo.


ethernet, Alexpi, gdl:

 Efectivamente, el como implementar la paginacion evitando parones en la aplicacion tiene su miga. Una opcion es la que comentais de ir cargando en un thread independiente poco a poco, aqui tendreis que controlar el tiempo disponible para la carga y con eso os tendreis que arreglar. Lo mismo se puede hacer sin thread independiente, ya que le vais a dar un tiempo y dedicaros solo a cargar en ese tiempo.
 En Windows, desconozco si en sistemas unix tb, existen los completion ports donde podeis decirle que leer y cuando termine os avisa.

 Respecto al tamaño de los archivos que pagineis, no siempre es mejor el tamaño mas pequeño, aqui os aconsejo hacer pruebas, tal vez descubrais que es mas costoso abrir muchos ficheros pequeños que menos ficheros de mayor tamaño. Incluso os animaria a hacer pruebas juntando varios ficheros en uno solo con una pequeña FAT al principio. Tambien podeis abrirlo con file mapping, teoricamente dicen que es la forma mas rapida de hacerlo en windows (las pruebas que he hecho no me han confirmado eso aunque no han sido demasiado extensas).

 En cuanto al problema que comenta Alexpi de quedarse sin datos, eso es algo que puede ocurrir, pero debemos configurar nuestro paginador para evitarlo (ampliar el radio de paginacion por ejemplo).

Vaya, cuanta respuesta :D
No estoy en casa este fin de semana (ahora mismo estoy a casi 500km :D) asi que tendreis que perdonarme hasta el domingo o el lunes que pueda contestar las dudas. De todas formas estoy seguro que hay mucha gente en este foro que sabe daros respuesta, salid de vuestro escondite !! ;)

Buen finde!

EDITO: Uppps, creo que le di al boton que no era y no lo meti en el post sobre terrenos, alguien puede moverlo please :(



Hoy habia quedado en hablar de paginacion, vamos a ver que puedo contar en el poco tiempo que tengo.

Para empezar, cuando es necesaria, pues a poco que pretendas volar sobre un terreno de grandes dimensiones (lo de grandes aqui es relativo, pongamos que grande es si no te entra en memoria con todo lo demas :D, aunque podria ser demasiado grande para que funcione en un equipo medio, digamos que es grande si al cargarlo todo va a superar el limite de memoria que quieras imponerle a tu aplicacion, esto de alguna forma tambien puede limitar la distancia a la que vas a poder ver a cierta resolucion).

Cuando no es necesaria, pues si el terreno es sintetico, es decir, lo generas sobre la marcha, evidentemente no hay nada que paginar :D. O bien si el terreno es suficientemente pequeño para entrar en memoria o es grande pero con una resolucion pobre de tal forma que los datos a cargar no ocupan demasiado. Tampoco es necesaria si haces maravillas como en el paper de Hoppe, donde comprimen la altimetria de Estados Unidos aproximadamente 100 veces y descomprimen sobre la marcha.

En que consiste la paginacion, supongo que es bastante intuitivo, pero por si acaso, se trata de ir cargando de disco los datos que seran necesarios en un futuro cercano. Es decir, mientras mostramos una parte de los datos, iremos cargando los siguientes para que cuando sean necesarios ya los tengamos disponibles y no se produzcan "tirones".

Una forma sencilla de verlo es ponerte delante un papel cuadriculado y pasarle por encima un CD/DVD. Digamos que el agujerito del CD es lo que estas pintando en pantalla, el terreno visible, cada uno de los cuadraditos del papel que caen ahi dentro serian tus trocitos de terreno. Pues bien, toda la parte del CD mas alla del agujerito seria lo que irias "paginando", tendras que elegir el "radio de paginacion", es decir, cuanto margen vamos a dejar, imaginate con un cd de 7cm o uno de 12cm, ese radio tendras que ir ajustandolo segun ciertos parametros como pueden ser: la velocidad maxima a la que permitiras moverse, la memoria disponible para cargar terreno extra, etc.

Ten en cuenta ademas que todo este proceso de paginacion no puedes hacerlo como una cosa mas en tu render loop, al menos no cargando todo lo necesario cuando lo sepas, eso produciria tirones. Aqui puedes elegir hacerlo de varias formas, lo mejor sera que experimentes por ti mismo los pros y contras de cada forma que se te ocurra. El objetivo sera ir cargando una serie de ficheros digamos que "cuando se pueda" sin que el frame rate se resienta (ideal sera que no baje de 60Hz para que el vuelo sea suave).

Bueno, para un solo post ya es bastante texto aunque muchas cosas supongo que son triviales.

Salu2.

PreIluminado me refiero a que tiene ya la capa de sombras en la propia textura. Lo que se pretente con esto, evidentemente, es ahorrarte calculos.
Lo malo de esto, es que la iluminacion de la escena es estatica, osea, que no puede cambiar.

Una forma de precalcular las sombras y luego poder cambiar la posicion de la fuente de luz son los esfericos armonicos, creo que DirectX facilita bastante el calculo de los mismos (aunque no lo he comprobado).

Con 'trabajamos' te refieres a que estas haciendo con otros algo con un terreno de esas caracteristicas? Si es asi, seguro que a JL10 (y a mi mismo!) le interesa que hables un poco mas de ello, oye  :wink:

Me referia a mi trabajo dentro de simulacion. Aunque no se hasta que punto podre hablar de ello. De todas formas la informacion disponible en internet es muy amplia. Google es tu amigo ;)

Por eso acudo a vosotros para que me ayudeis a canalizar toda esa información: LOD, paginado, frustum culling, mapeado de detalle, etc, etc. Qué algoritmos de cada técnica son eficaces y realmente cuáles de ellas hay que aplicar en cada caso.

Sobre el LOD en la web que te ha dado Astat creo que tienes bastante informacion. No recuerdo si incluye los geometry clipmaps, si no es asi, te aconsejo que te mires el paper (los papers en realidad, tiene 2, uno con aceleracion por hw de casi toda la tecnica y otro no, si no tienes hw de ultima generacion, en concreto geforce de la serie 7 que soporten vertex texture fetch mejor la opcion por soft que igualmente es muy rapida).
De todas las tecnicas que he visto la de geometry clipmaps es la que mas calidad tiene sin lugar a dudas, bajate la demo "jugable" de la web de Hoppe (ahora que lo pienso no se si hay demo sin aceleracion hw, luego si no tienes una geforce 7 puede que no te funcione, de todas formas creo que tiene un video) y los papers que alli esta toda la info. Se basa en los clipmaps de textura que te comente en el post anterior de Tanner.
En GPU Gems 2  esta el paper con aceleracion HW un poquito ampliado (no mucho) ademas ese capitulo creo que se puede bajar gratis de la web de nvidia.
Es un metodo que practicamente no adolece del popping que puedes encontrar en otros (hay que fijarse muy mucho para verlo y aun asi es muy dificil). Ademas el concepto en si es tremendamente simple y sencillo de entender. La implementacion tiene sus "trucos", cuando lo lees todo parece sencillo pero al codificar te das cuenta de todo lo que el paper no cuenta :), no te estropeare la diversion si te decides por este :D.

Mañana te contare un poquito sobre la paginacion, hoy no tengo tiempo para mas :(.

He tomado como referente utópico las demos de FS-X y de X-plane. Esto es lo que me gustaría hacer pero con menos pretensiones.

Con un par ;)
Ahora en serio, creo FS-X va a ser un referente en cuanto a calidad visual (y no utiliza geometry clipmaps, creo que mas que nada para compatibilidad con hw mas "normalito"). El trailer que han sacado es muy bueno pese a que no enseñe mucho del juego :D.


Saludos.