paginacion

[Alexpi]

Buenas, estoy dandole vueltas a una cosa y como no acabo de estar seguro os lo pregunto :P.

Cual es el principal motivo de usar paginacion en la carga de heightmaps enormes que tienen algunos juegos?

"Solo" pueden ser 2 cosas, mejora de fps o ahorrar memoria?

Si es por los fps, con un octtree y un limite de vision no serviria para reducir drasticamente el nº de poligonos?

Y por memoria... tanto puede ocupar tener cargado todo un mapa en ella?

[Shaitan]

El problema principal suelen ser las texturas, sobre todo si trabajas en alguna aplicación que requiera gran nivel de detalle (por ejemplo un simulador de vuelo, etc.). Las texturas con mucho detalle ocupan muchisimo, y no hay tarjeta gráfica que se trague por ejemplo un mapa de España con texturas de resolucion 1 pix*5metros. (se que es un caso bastante extremo)

J.

[Alexpi]

seria mas efectivo crear un mapa enorme  con heightmap y luego cargarlo con un programa de diseño 3D obener la malla y retocarlo. Esta malla partirla en trozos (sectores) y guardarlos como modelos para luego usar los como mapa en lugar del heightmap?

[AK47]

Lo bueno de los heightmaps es que se pueden calcular los niveles de detalle de forma muy fácil, simplemente jugando con los índices. Además la creación de contenido también es sencillo, uno se crea un bmp y ya puede verlo en el juego :)

[Shaitan]

Todo depende del tamaño del mapa y de las texturas. Hace tiempo vi que nvidia recomendaba en las últimas tarjetas cargar toda la geometría posible y olvidarse de paginaciones y métodos de simplificación de terrenos (si es posible, claro)

J.

[tamat]

seria mas efectivo crear un mapa enorme  con heightmap y luego cargarlo con un programa de diseño 3D obener la malla y retocarlo. Esta malla partirla en trozos (sectores) y guardarlos como modelos para luego usar los como mapa en lugar del heightmap?

Depende, pero piensa que en una malla por cada vertice tienes componente X,Y,Z pero con un highmap realmente solo tienes la Y de cada pixel, lo demas lo puedes calcular en funcion de la posición del valor dentro de la textura.

Ademas como te han comentado antes una de las cosas importantes a la hora de desarrollar algo es la facilidad con la que puedes aplicar cambios a los datos, si lo haces como tu dices y luego quieres probar con otra imagen entonces reconstruye la mesh, resubdivide, etc.

Yo hice como proyecto un render de planetas que los cargaba dinamicamente del disco lo que me permitía tener gigas de texturas.

[JL10]

Yo hice como proyecto un render de planetas que los cargaba dinamicamente del disco lo que me permitía tener gigas de texturas.

Muy espectacular!! :shock: . Podrías indicarnos cómo lo has hecho. No consigo ver un ejemplo de código sobre este tema y me parece interesante. Gracias tamat.

[tamat]

Puedes ver un video aquí aunque ya te avanzo que tampoco es nada del otro mundo. El truco es tener todas las texturas en disco bien organizadas, detectar cuando hace falta una nueva textura y cargarla, y cuando detectes que ya no se usa descargarla.

[JL10]

Entonces el quiz de la cuestión está en tener una buena gestión de las texturas!. Pero pienso que no es fácil leer texturas de disco en pleno render, se debe notar algún retardo. ¿Cómo solucionas estos problemas?.

Por cierto, el video me ha gustado, sobre todo cuando muestras el LOD y el frustum!.

[tamat]

El truco para cargar texturas en ejecucion se basa en dos puntos:

- Cargar los datos de disco a memoria RAM en un thread, para evitar colapsar el bucle de render. Digo lo de subir a RAM porque si lo subes a la VRAM desde un thread tendras problemas.

- Tener los mipmaps precalculados, ya que calcular los mipmaps es algo muy lento, para eso lo mejor es usar texturas en formato DDS que ya incluyen los mipmaps, hay plugins para photoshop que permiten guardar en DDS. Otra ventaja de los DDS es que tienen compresion pero las tarjetas la soportan con lo que puedes subirlas en mucho menos tiempo.

Y luego aparte pues tratar de evitar subir muchas texturas de golpe, si puedes ir subiendolas poco a poco pues mejor.

Otra cosa que ayuda tambien es tenerlas todas almacenadas juntas en algun archivo del disco duro, para evitar que esten dispersas, así cuando lees secuencialmente va más rapido.

Eso es todo lo que aprendí de mi PFC.

[JL10]

...lo mejor es usar texturas en formato DDS que ya incluyen los mipmaps....

El formato DDS está más indicado para trabajar con DirectX, pero OpenGL también lo soporta?. ¿Cual sería el más apropiado para OpenGL?

He visto que el formato MrSID es muy bueno para extraer de forma rápida el segmento de imagen que necesitas a la resolución que requieras, sin necesidad de tener una coleccion de imágenes troceadas. ¿Sabes algo más de esto?.

Muchas gracias por tu colaboracion, tamat.

[tamat]

DDS fué creado para DirectX pero al estar soportado desde el hardware pues sería absurdo que openGL no sacase provecho de ello, así que en openGL va perfecto, a fin de cuentas es solo subir la textura en un formato especial y la tarjeta ya sabrá que hacer con él.

Por eso existen diferentes formatos internos de DDS, con mayor o menos compresión, algunos más soportados que otros.

Yo uso la OpenIL que es una librería para imagenes y lo soporta, ademas con DDS puedes guardar cubemaps que va muy bien para iluminacion.

Del formato MrSID no he oido nada, le echaré un ojo.