¿Como se cargan mapas/terrenos?

[Eskema]

Muy buenas, estoy dando mis pasitos en 3d y la carga de modelos ya esta controlada, ahora viene el tema de los mapas. ¿Como se hace un mapa/nivel/terreno/loquesea para un juego?
Es decir, por ejemplo supongamos que quiero hacer un GTA, muy basico, asi que pillo el blender y dibujo unas casas, y una calle. ¿Eso lo grabo en 3ds (por ejemplo) y lo importo tal cual en mi "engine"?, ¿o bien a la hora de un mapa se carga cada modelo por separado?

Supongamos un juego como resident evil, ¿modelo la mansion con sus habitaciones, o modelo cada habitacion y la cargo por separado?

A ver si me podeis sacar de dudas que no se me ocurre el como se usan/diseñan mapas.

Saludos,

[Alvaro (Garred)]

Supongo que dependerá de como de optimizado quieras que esté tu juego.

Si no consume mucho (unas pocas calles) podrias cargarlo entero. En cambio si es un mapa como el del GTA lo suyo es que la ciudad este dividida en muchos trozos que vayan cargandose según la posición del jugador. Ademas estos trozos tendrian varias versiones segun el nivel de detalle: cuando el jugador esté situado en ese trozo, se mostrará la versión con el maximo detalle, mientras que si se encuentra muy alejado de ese trozo, se mostrará con el minimo detalle (los edificios que se ven al horizonte seran simples cubos texturizados).

Para escenarios de interior no tengo mucha idea. Hay algoritmos, como el bsp, que te particionan el escenario ellos mismos y al renderizarlos te ocultan automáticamente las partes que no se ven desde la posición de la cámara. Así, en teoría, podrías cargar el escenario entero (salvo que sea una salvajada de mapa vamos). Pero ese algoritmo tiene su tiempo, ahora no tengo ni idea de como irán los tiros. Hay algo llamado portales muy util para eso, pero no se casi nada al respecto.

[tamat]

en el mundo de la programacion de videojuegos no hay soluciones genericas, tienes que evaluar tus necesidades y adaptarlas a las limitaciones del hardware, esa es la gran tarea del programador.

[Eskema]

en el mundo de la programacion de videojuegos no hay soluciones genericas, tienes que evaluar tus necesidades y adaptarlas a las limitaciones del hardware, esa es la gran tarea del programador.

si pero habra un punto de partida sobre el que empezar a trabajar ¿no?.

De momento me queda claro que debo cargar la escena completa y luego ya vere que se pone o quita, segun la potencia de la plataforma

[Prompt]

si pero habra un punto de partida sobre el que empezar a trabajar ¿no?.

El punto de partida es el análisis y el estudio de la solucion a los problemas de ese análisis.

[Alvaro (Garred)]

en el mundo de la programacion de videojuegos no hay soluciones genericas

El punto de partida es el análisis y el estudio de la solucion a los problemas de ese análisis.

Por supuesto, pero a lo mejor el hombre queria que le dieramos ideas un poco más concretas con las que inspirarse.

[senior wapo]

Si el escenario es muy detallado no hay mas narices que cargarlo todo al principio y limitar el tamaño total. Dado el nivel de detalle es inviable cargarlo sobre la marcha, Toca esperar mientras se carga el nivel al principio.

Si el escenario debe ser extenso, no vas a tener suficiente memoria y entonces debes limitar el nivel de detalle de manera que puedas ir cargando del disco las partes necesarias sobre la marcha. Dada la velocidad del disco duro o DVD no vas a poder cargar muchos datos por segundo.

Lo de arriba se aplica tanto a personajes como a escenarios. Lo que no esté cargado a tiempo pues no se dibuja en ese fotograma, por ejemplo.

En cuanto a como representar los escenarios, lo típico es tener todo subdividido en grandes bloques de, por decir algo, 40x40 metros, o una habitación o lo que sea que se ajuste a tu tipo de escenario. El rollo del batching y coste de hacer llamadas al API 3D. Dependerá de como funcione el motor que uses.

[Eskema]

El punto de partida es el análisis y el estudio de la solucion a los problemas de ese análisis.

Pues eso no te lo crees ni tu  :P existen unas pocas formas de hacer las cosas, luego cada cual las implementa como sabe (en esta parte es donde te doy la razon) pero ni de coña uno solo se pone a hacer un juego 3d sin tener alguna idea de por donde empezar.

Gracias por las ideas senior wapo, empezare a modelar grupos de cosas y a cargarlas a ver que pasa

[Mars Attacks]

Hay otras técnicas como la de instanciación de mallas y posicionamiento de referencias que puede ayudarte (separas el escenario en trozos y lo que cargas es un mapa que te indica dónde cargas cada trozo y con qué transformación). Es útil si replicas mucha malla, ya que sólo la lees una vez de disco y la replicas donde te hace falta con la transformación que necesites.

[Prompt]

Yo empezaría por estudiar el altgoritmo ROAM el update es en CPU. Pero quizás es muy avanzado.

La idea inicial es tener una malla y leer una textura de 8bits (escala de grised), según si el color es más blanco será valor / alturaMaxima. Simplemente modificas los vertices de la malla. Hay cientos de ejemplos por ahí.

[Marci]

Yo empezaría por estudiar el altgoritmo ROAM el update es en CPU. Pero quizás es muy avanzado.

Si lo que quieres es representar un terreno, estoy de acuerdo en que ROAM es bastante lioso para empezar. Yo comenzaria buscando informarción sobre height maps (es lo que te comenta Prompt de guardar el terreno en una imagen de grises) y dibujaria la malla pasandole todos los triangulos a la GPU.

Para descartar triangulos o simplificar la malla que representa el terreno, empezaria por algo sencillo como un quadtree antes de pasarme a cosas como el ROAM

[tamat]

joer, recomendar ROAM así de buenas a primeras... ale, alegría

[ethernet]

Cargalo todo en memoria y pintalo a lo bruto. Es lo más simple y tendrás resutlados en pantalla en una tarde.

Si luego necesitas más ya lo harás y si no pues seguramente te hayas ahorrado dolores de cabeza.

[flipper83]

comparto plenamente la opinión de ethernet

[Eskema]

La opcion de ethernet es la que al final estoy usando, ya habra tiempo de ir metiendo mano y optimizar, cambiar algoritmos y demas. Pero para ir viendo un poco el meollo no hay nada como los metodos brutos de siempre :)

Por supuesto me apunto todas las sugerencias para ir estudiandolas, gracias chicos