He trabajado en una variedad de proyectos de demostración con OpenGL y C++, pero todos han implicado simplemente renderizar un solo cubo (o malla similarmente simple) con algunos efectos interesantes. Para una escena simple como esta, los datos de vértice para el cubo podrían almacenarse en una matriz global poco elegante. Ahora estoy buscando renderizar escenas más complejas, con múltiples objetos de diferentes tipos.Estructura del programa OpenGL y OOP
creo que tiene sentido tener diferentes clases de diferentes tipos de objetos (Rock, Tree, Character, etc), pero me pregunto cómo romper limpiamente seguridad de los datos y la prestación de la funcionalidad de los objetos en la escena. Cada clase almacenará su propia matriz de posiciones de vértices, coordenadas de textura, normales, etc. Sin embargo, no estoy seguro de dónde colocar las llamadas de OpenGL. Estoy pensando que tendré un bucle (en una clase World o Scene) que itera sobre todos los objetos de la escena y los renderiza.
¿Debería implicar llamar a un método de representación en cada objeto (Rock::render(), Tree::render(),...) o un único método de representación que adopte un objeto como parámetro (render(Rock), render(Tree),...)? Este último parece más limpio, ya que no tendré código duplicado en cada clase (aunque eso podría mitigarse heredando de una sola clase RenderableObject), y permite que el método render() sea fácilmente reemplazado si deseo hacer un puerto posterior a DirectX. Por otro lado, no estoy seguro si puedo mantenerlos separados, ya que podría necesitar tipos específicos de OpenGL almacenados en los objetos de todos modos (búferes de vértices, por ejemplo). Además, parece un poco engorroso tener la funcionalidad de renderización separada del objeto, ya que tendrá que llamar a muchos métodos Get() para obtener los datos de los objetos. Finalmente, no estoy seguro de cómo manejaría este sistema los objetos que tienen que dibujarse de diferentes maneras (diferentes sombreadores, diferentes variables para pasar a los sombreadores, etc.).
¿Es uno de estos diseños claramente mejor que el otro? ¿De qué maneras puedo mejorarlos para mantener mi código bien organizado y eficiente?
Gracias, eso me da algunas ideas para trabajar. Una cosa que no entiendo del todo es la distinción entre la clase que se puede hacer referencia y la clase de malla que mencionaste. ¿No querría que la clase de malla sea un renderizable que pueda dibujarse? En un nivel superior, creo que el diseño será más complicado de lo que esperaba. ¿Conoce algún recurso en línea que brinde una buena introducción al diseño de un sistema de renderizado? La mayoría de los tutoriales de OpenGL que he encontrado introducen el proceso de dibujar, texturizar e iluminar algunos triángulos, sin mucha discusión sobre la arquitectura de imágenes más grande. – Jeff
@Jeff: No. Una malla es solo una colección de datos de vértices. Una malla * sola * no es suficiente. Para representar algo, necesita una malla, el sombreador que desea renderizar con ella y el otro estado variado (texturas, etc.). –
@Jeff lo que dijo Nicol es correcto. No todo lo que dibujas será una malla (por ejemplo, también puedes dibujar líneas o algún otro primitivo como quads, donde una malla puede ser excesiva). Una clase de malla debe describir la geometría (y, a veces, el índice material por tri, y la agrupación/jerarquía), pero no mucho más. Mire en los libros que hablan sobre el desarrollo del motor del juego (incluso si no está haciendo un juego). Una buena es "Game Engine Architecture", también las "Gemas de programación de juegos" y "Game Engine Gems" tienen mucha información buena. Es posible que también desee acechar los foros de gamedev.net –