Grandes gráficos de planeta que giran lentamente para el juego

Question

Para un juego de computadora que estoy desarrollando, me gustaría dibujar gráficos muy grandes (~ 500 px) de planetas girando lentamente. Estos gráficos están destinados a impresionar. ¿Cuál es la mejor manera de hacer esto?

• Podría preprocesar cada fotograma, pero a 500px y un período de rotación de 10 segundos, esa es una cantidad ridícula de datos por planeta.
• Podría usar un motor 3D y mapear la textura del planeta en una malla que se acerca a una esfera, pero a 500px, me temo que el conteo de polígonos debería ser enorme para que se vea bien.
• Podría escribir un tipo de motor 3D personalizado que no hace más que renderizar eficientemente una esfera texturizada, convirtiendo la coordenada x/y de cada píxel de visión en el espacio de coordenadas de la textura de la esfera, pero esto está involucrado y no puede t beneficio de la aceleración de gráficos.
• ¿Algo más que no he pensado?

Aquí hay un ejemplo de GIF animado de lo que quiero decir. (En 100x100 píxeles y 60 cuadros, ya es bastante grande, lo siento.) Imagínese esto mucho, mucho más grande, que gira mucho más lento, y animado con mayor suavidad:

Pero si esto fuera 500x500 píxeles y 10 x 25 = 250 fotogramas, estaríamos hablando de cientos de MB de datos, por lo que este enfoque directo no funciona.

Answer 1

Fracplanet puede guardar mapas de textura "spheremap" (y mapas de relieve); mira las imágenes hacia la parte inferior de gallery. Estos están destinados a ser posteriormente leídos en una aplicación y mapeados en una geometría de esfera de resolución relativamente baja para lograr el efecto que creo que estás buscando. Este enfoque utilizará menos memoria que el enfoque de animación preprocesado o el uso del modelo de polígono de resolución completa original.

Sí, este es básicamente su segundo punto, pero no sería tan rápido para descartar ese enfoque y creo que encontrará que puede salirse con la suya con una esfera de menor resolución de la que espera; el ojo nota los detalles finos en la textura mucho más de lo que nota la baja resolución de la geometría sobre la que se cubre. El moderno tessellation hardware significa que probablemente pueda obtener fácilmente la GPU para generar y representar una cantidad ridícula de polígonos para una esfera.

Idea alternativa: represente un único polígono cuádruple cuadrado suficientemente grande para cubrir el planeta. Para cada píxel dentro de eso, ejecute un pixel-shader que computa el punto de intersección de la esfera de la pantalla de rayos (si existe). Busque el color de la textura del planeta (teniendo en cuenta el tiempo y la rotación del planeta). Evita la necesidad de muchos polígonos y te proporciona una esfera exacta.

Answer 2

Si va a pre-renderizar, ¿qué le parece un algoritmo que represente los fotogramas necesarios mientras el juego se está ejecutando, según la probabilidad de que el jugador los vea realmente, yendo desde 'cierto' pasando por cada vez más improbable ¿en función de dónde el motor del juego podría permitir que el jugador esté en x segundos frente a qué marco debería estar a la vista en ese momento, hasta "imposible" y por lo tanto no renderizado?

Answer 3

Puede mover la cámara sobre el objeto (que realmente solo funciona si todas sus cosas están centradas) o transformar el objeto. Este último se hace comúnmente.

Puedo recomendar mirar sf.net/projects/a3d que ha sido fácil de estudiar. draw_asteroids usa una llamada glRotate, eso es todo.

Además, si escuché correctamente, el motor Doom3 introdujo líneas de bezier, por lo que una esquina redondeada en un juego - o una esfera, para aplicarlo a este caso - no necesitaría estar compuesto de puntos cuantificados (produciendo el fea red de malla en la que estás pensando).

Answer 4

Si sus planetas siempre estarán girando ortogonalmente a la pantalla, solo tiene una textura de planeta único que se desplaza y se enmascara mediante un círculo.

Si desea un eje de rotación arbitrario, querrá preguntarse qué es más fácil, la solución 3D o usar un par de texturas comprimidas para contener todos los marcos. Si ya tiene un trabajo fácil con 3D Pipeline, use eso.

Si hace un marco de 256x256, podría caber 16 en una textura de 1024, por lo que 60 cuadros solo tomaría 4 texturas. Con la compresión DXT3, puede esperar que sea de aproximadamente 1 MB por textura (bastante razonable).

Answer 5

Si desea la aceleración de gráficos, los polígonos son baratos; una gran cantidad de polígonos no es un problema.

Recomiendo una textura de mapa cúbico y una correspondiente cuadrícula triangular tipo cubo: comience con una cuadrícula de vértices en forma de (la superficie de) un cubo sobre el origen, y normalice cada coordenada 3D al radio de la unidad. Esto facilitará la computación de las coordenadas de su textura.

Tenga en cuenta que debe elegir la proyección correcta para su textura: en el caso anterior, querrá una proyección tangente para cada cara del cubo, para que coincida con su cuadrícula.

Answer 6

La forma arcaica de hacer esto sería pre-crear una imagen de una esfera, pero en lugar de almacenar los colores de la textura de la superficie en cada píxel, almacena la textura UV como una tabla de búsqueda. Ahora puede renderizar la esfera dibujando la imagen renderizada previamente pero buscar el texel correspondiente en una textura de superficie del planeta a partir de la luz UV encontrada en la imagen. Para hacer que el planeta gire, puede agregar un desplazamiento a la coordenada uv que se encuentra en la imagen de la tabla de búsqueda. Asegúrate de usar un módulo adicional para que la textura se ajuste bien. Si desea sombrear el planeta, puede agregarlo como un pase separado en la parte superior de la textura.

Este enfoque probablemente sería mucho más rápido que una versión de polígono texturizado en hardware sin aceleración de gráficos incorporada y también podría representarlo con tantos polígonos como desee ya que la renderización es un proceso previo.

Answer 7

Turns out using perlin noise and a shader gives pretty good results.