Gráfico de escena en hilo separado


12

Desarrollo mi propio motor de juego para divertirme (pero no para obtener ganancias). Tengo renderizado en un hilo y mis actualizaciones de gráficos de escena (velocidad, etc.) en otro. Cuando llega el momento de renderizar, el hilo de renderizado agrega los nodos visibles a un nuevo búfer lineal y los atraviesa.

Más detalladamente, mi gráfico de escena tiene triple búfer. Cada nodo en mi gráfico de escena tiene tres copias de sus matrices de transformación relativas y absolutas (4x4). En cualquier momento, el hilo del gráfico de escena escribe una copia, el renderizador lee una copia y existe una tercera para que el lector o el escritor puedan pasar a la siguiente sin esperar a la otra. Esto evita escribir en algo mientras se está renderizando y generar un gráfico de escena medio actualizado. De alguna manera, también tengo una cuarta copia de cada matriz para que el usuario trabaje con el fin de no entrar en conflicto con el hilo de actualización. Esto parece funcionar bien al evitar tener que sincronizar todo el tiempo.

Sin embargo, esto es un desastre.

Estos son mis objetivos finales para el sistema:

  • La representación y la actualización del gráfico de escena permanecen en hilos separados.
  • Minimice cuánto deben esperar estos hilos entre sí.
  • No renderice una escena que ha sido actualizada a medias por el hilo de actualización. Esto es particularmente notable si la cámara se mueve rápido y, a veces, se procesa antes o después de una actualización.
  • Uso reducido de memoria. Tengo demasiadas matrices por nodo. También estoy considerando moverme a vectores para posición / rotación / escala debido al aumento de la deriva de coma flotante con matrices.
  • Capacidad para manejar decenas de miles de nodos. El sistema actual hace esto razonablemente bien.

También espero incorporar Bullet (el motor de física) y redes en el futuro, ninguno de los cuales he pensado mucho.

¿Cuáles son algunos enfoques para lograr un mejor gráfico de escena?

Respuestas:


4

¿Has leído la tesis de Johannes Spohr sobre "Pace" y su renderizador? Describe un denominado procesador paralelo de "motor de envío" * y puede darle algunas ideas.

Aquí está la página de resumen (en alemán), y aquí hay un enlace directo al PDF que está en inglés.

( *: este enlace también va al artículo donde originalmente escuché sobre la tesis).

EDITAR: solo había leído esto anteriormente, y lo miré de nuevo ... y me di cuenta de que realmente pasa por alto los detalles del gráfico de la escena. Supongo que no me di cuenta de lo ortogonal que era su diseño. Lo siento si no es particularmente útil.


1
Una parte de este documento todavía me llamó la atención: "Idealmente, la aplicación ni siquiera sabría que hay un gráfico de escena, solo debe tener en cuenta un componente de vista que debe informar sobre los cambios en el modelo de datos". Esto me inspiró una nueva forma de pensar al respecto: no necesito triplicar toda la escena, solo lo que es visible a través de la cámara actual. Puedo mover la selección desde el hilo de renderizado al hilo del gráfico de escena (cuando se encuentra con una cámara), y en cualquier momento dado, uno de estos tres buffers puede ser escrito por él y otro leido por el renderizador.
EricP

1
También puede consultar el artículo "Diseño de motor centrado en la cámara para renderizado multiproceso" en Game Engine Gems 1, y el relacionado "Renderizado práctico en paralelo con DirectX 9 y DirectX 10" - microsoft.com/downloads/en/…
Neverender

1
Parece que Game Engine Gems 1 está disponible gratis en línea: books.google.com/…
EricP
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.