|
Hay partes del mundo de los gráficos que están mejor documentadas que otras. Y creo que la parte de arquitectura de un motor 3D es la parte menos documentada de todas, o al menos, eso puede parecer en un principio. La arquitectura de un motor 3D es un procedimiento complejo, donde lo normal es cometer grandes fallos diseño, o complicar el desarrollo de forma espectacular. Requiere mucho pragmatismo y experiencia por parte de los diseñadores. Lo complicado es saber balancear. Eso, dicho de esta forma, suena genial, pero ¿cómo llevarlo a la práctica?. Pues yo creo que la única forma es centrarse profundamente en los requisitos, en qué cosas queremos mostrar por pantalla. Lo normal es que la gente conteste a esta pregunta con un "yo quiero rendearlo todo". Y me ha llevado tiempo el darme cuenta que eso realmente significa "no tengo ni idea de lo que quiero hacer". Porque tod, significa mezclar raytracing con shaders de tarjeta? significa rendear volumétricas y polígonos? Esta es la parte que nunca se habla en la documentación que podéis encontrar por internet, y es la parte para mí más fundamental en el desarrollo de una aplicación tan compleja. Porque todo es imposible, no es abarcable, y menos para una sola persona. Lo que es posible es rendear un efecto concreto, con una definición de escena concreta y con unos requisitos limitados. Personalemente, hace tiempo que mi motor personal va evolucionando, y ahora veo que es realmente flexible en muchas partes. Pero eso ha salido a raiz de refactorizar grandes partes del código. Pero lo que creo que realmente le da a una arquitectura su poder de flexibilidad es en definir las limitaciones y posibilidades del interfaz. Si en vez de centrarnos en diseñar las tripas, deberíamos de perder un tiempo en pensar cómo vamos a definir la escena a rendear (pero no la parte básica, si no todos los atributos que tiene una escena, que son muchísimos). Pongamos el ejemplo de un servidor de correo SMTP, o un gestor de bases de datos SQL. El lenguaje está definido previamente. Y la arquitectura debe de ejecutar ese código lo mejor posible. Pero el SMTP o el SQL no va a cambiar (al menos no derrepente) y son lenguajes sencillos y facilmente testeables. Por eso son protocolos que perduran en el tiempo y los servidores son tan robustos y optimizados. Lo mismo debería de hacerse con el motor gráfico: definir perfectamente las estructuras que vamos a tener, y dedicarle un tiempo al parser y a un exportador, antes que meterse en las tripas del render.
|
Noticias 
