COMIENZO
Forrest Stephan y Sandi Gardiner presentan el episodio, recordando que quedan unos días de vuelo gratuito con la SuperHornet, que están añadiendo nuevas cosas a 2.6 cada día mientras se acerca su lanzamiento mientras los Evocati siguen probando el nuevo equilibrio de vuelo, se añaden nuevas misiones a Crusader, se implementa el nuevo sistema lógico de música, dos nuevas naves (Herald y Vanguard Hoplite), modo de enjambre pirata para Arena Commander, recoger munición al vuelo en los modos de AC, nuevo sistema de cámaras y mucho más. Están haciendo pruebas internas de Star Marine para recibir opiniones sobre el mismo, y también están terminando una revisión al sistema de red para Star Marine. Y por supuesto, siguen quitando los bugs más gordos del parche, como en el Bugsmashers de esta semana.
ACTUALIZACIÓN DEL ESTUDIO DE ALEMANIA Brian Chambers
EQUIPO DE CONTROL DE CALIDAD DE FRANKFURT
Melissa Estrada (Especialista de Control de Calidad para el Motor Gráfico): El equipo de QA tiene en estos momentos 3 empleados, dos dedicados a probar el motor gráfico y otro dedicado a probar Escuadrón 42 y el FPS. Trabajamos de cerca con el equipo de desarrollo sea probando nuevos cambios al motor o investigando un problema que exista.
Hay una serie de pruebas que hacemos diariamente, pero las peticiones de pruebas están altas en nuestra de tareas regulares y se refieren a peticiones de un desarrollador para que probemos los cambios que han hecho en el motor y que podrían romper la versión. Para prevenir esto el juego pasará por una tercera prueba en la que el juego entero o sólo una parte de él debe ser probado.
En esta prueba uno de nuestros ingenieros nos ha enviado un Bin64 personalizado para optimizar las sombras y los objetos, así como otros cambios en el código y nosotros lo probamos, descubriendo que había un crash de vez en cuando y un parpadeo de sombras excesivo en Homestead. Luego lo comparamos con el código que teníamos de la versión del juego sin modificar e informamos de los resultados finales al desarrollador. Esto proceso impide que se añadan nuevos problemas en una versión.
Aún así, el desafío al que nos enfrentamos a veces es si han existido cambios de código recientes en el mismo sistema en el que estamos probando estos mismos cambios, ya que al compilarse una nueva versión con ambos cambios puede aparecer un problema y no sabemos cual de los dos códigos es el responsable. A pesar de esto, todos los problemas son registrados, se investigan y los cambios finales acaban proporcionando sombras mejoradas sin parpadeos y sin crashes. Y esto es lo que me gusta de formar parte de Control de Calidad en Frankfurt, en el que puedo rastrear estos problemas y ser parte del proceso de solucionarlos junto al equipo de desarrollo. Es una experiencia muy gratificante y me considero afortunada de formar parte de este equipo y contribuir al proceso de desarrollo.
EFECTOS ESPECIALES DE HOMESTEAD: LA TORMENTA DE ARENA
Caleb Essex (Artista de Efectos Especiales Senior): Os voy a dar un desglose extensivo de la gran tormenta de arena que pudisteis ver en la demo de Homestead. Requirió de mucho trabajo en equipo con el departamento de cinemáticas y sonido para que funcionase de manera apropiada dentro del motor gráfico.
Aquí estamos dentro del editor en el nivel de Homestead. El efecto de la tormenta de arena en si es de hecho bastante sencillo, porque está hecho de 3 sprites distintos:
- Hay una textura fina de arena por encima del efecto.
- Una textura más gruesa por debajo.
- Y la textura de los relámpagos.
Estas dos texturas incluyen mapas de normales y los mapas de flujo ópticos para la mezcla de fotogramas. Estos mapas de flujo ópticos son los que nos dan unos fotogramas prácticamente ilimitados para nuestras texturas. Debido a esto podemos ralentizar el efecto de la tormenta o acelerarlo sin que la animación parezca que va a golpes, que es algo que aceleramos a medida que se acerca al jugador para dar una sensación de escala y de amenaza.
El movimiento frontal de la tormenta de arena es controlado por TrackView, la línea azul representa el camino que recorre. A medida que se aproxima al jugador también aparece una entidad de volumen de niebla que se mueve hacia el jugador desde el suelo. Esto es utilizado como una técnica de optimización.
Cuando el jugador está en el interior de la tormenta podemos desactivar el efecto y activar un efecto localizado de arena pasando junto a la cámara. Desactivando el efecto mientras se está oculto en la niebla podemos esquivar parte de los problemas de sobredibujado que aparecen cuando toda la pantalla está llena de partículas.
A medida que avancemos todos estos sistemas serán unificados y controlados por el sistema de clima planetario. Aquí tenemos el efecto final funcionando en tiempo real en el motor gráfico.
Brian Chambers: Como rápida actualización quería indicar que la expansión de la oficina que mencioné hace unos episodios ya está aquí, y que pronto os daré un tour por ella.
ACTUALIZACIÓN DE LA COMUNIDAD Tyler Witkin
- Esta es la última semana de vuelo gratuito con la SuperHornet.
- Los suscriptores tendrán para pilotar durante Noviembre la M50.
- CitCon fue en Frankfurt este fin de semana, con 500 asistiendo al evento además de algunos desarrolladores de la oficina de CIG allí (ndt: confirmando cosas como que habrá cavernas excavables bajo el terreno en los planetas, por ejemplo)
- 7 MVP para varios habituales del HelpDesk del canal de chat de RSI, que llevan ayudando e informando desde hace muchos meses.
- Mañana será el RTV como siempre, esta vez desde Frankfurt.
CÓMO SE HIZO: PLANETAS PROCEDIMENTALES
Hannes Appel (Director de Cinemáticas): Bienvenidos al que probablemente será el primero de varios documentales sobre lo que hace funcionar a nuestra tecnología de planetas procedimentales que estamos creando aquí en Frankfurt principalmente de la mano de Franco, Carsten, Marco, Sasha... Básicamente, con la demo de Homestead en CitizenCon hicimos una prueba práctica de lo que llamamos la tecnología V2 de los planetas, pero ahora ya estamos básicamente en la V3 y simplemente quisimos mostraros un punto de referencia con la V2 en el evento (risas). Ya tenemos un par de nuevas features siendo implementadas.
Esta demo no se hizo sólo por nuestro amor por los gusanos espaciales gigantes, si no para tener artistas e ingenieros trabajando con algo sustancial de pruebas para hacer madurar nuestras herramientas y el editor de planetas que llamamos "PlanEd" y para llegar a algo que tenga una malla con el sistema de distribución de objetos, vegetación, "pintura" del Ecosistema y mapa de alturas del terreno.
Trabajé con nuestro artista de entornos, Pascal, en Homestead para para crear los ecosistemas en si... y en este caso sólo había 5 ecosistemas distintos.
Hannes Appel: Mi trabajo en Homestead como director de Cinemáticas se centró en inicializar la iluminación, ambiente, y sensación del planeta, así como trabajar con nuestros artistas de entornos Pascal en los propios Ecosistemas. Y cada día pase un par de horas con Marco, Sasha y Carsten trabajando en las herramientas en si.
Marco Corbetta (Director Técnico Senior): Buenas, hoy vamos a hablar de planetas. Gracias a todos los miembros del subreddit de Star Citizen y el foro de la comunidad de Star Citizen por sus opiniones y comentarios positivos, lo apreciamos de verdad. Inicialmente no estabamos planeando tener transiciones transparentes y sin barreras del espacio a los planetas en Star Citizen.
En Septiembre de 2015 empezamos a re-escribir desde cero el sistema de terreno de CryEngine. Aquí podéis ver el experimento que hicimos de un planeta procedimental sin ninguna atmósfera al final de octubre de 2015.
Este es nuestro primer experimento con la atmósfera en Noviembre. Carsten Wenzel estuvo trabajando en los efectos atmosféricos y en las nubes, así como en un número de características adicionales para el motor gráfico.
En nuestra primera actualización pública al final de 2015 mostramos nuestra primera versión de la tecnología de los planetas, que en ese momento era mucho más procedimental. Ya esta integrado en el editor, por lo que podías poner Zonas de Aterrizaje sobre el planeta.
En Febrero de 2016 ya teníamos a un personaje jugador andando sobre el planeta. En esta fase todavía no teníamos detalles del suelo y todavía teníamos problemas visuales como veis aquí.
En Marzo, Abril y Junio hicimos mucho progreso. Podemos ver más detalles cuando hacemos zoom sobre un planeta y aquí tenemos un vídeo de nuestro primer paseo en buggy por la superficie de un planeta. Todavía hay muchos elementos procedimentales porque se estaba volviendo difícil personalizar de verdad los planetas
Pascal Muller (Artista de Entornos Senior): No había diversidad en los planetas: o eran grandes planetas rocosos, o planetas jungla, o planetas desérticos. No había variaciones en los ecosistemas de estos planetas.
Con la V2 todo esto cambió, ya que introdujimos un sistema de Ecosistemas. Cuando hablamos de estos puedes pensar en ellos como si fuesen su propio "nivel": es un trozo de terreno que cubre 4 o 8 kilómetros cuadrados. Cada ecosistema contiene muchos tipos distintos de recursos artísticos creados por los artistas, como el terreno en si, la información que define qué aspecto tiene ese terreno (montaña, dunas, mesetas, cañones...). Y además tenemos todas las texturas del terreno que se ocupan de crear el terreno en eso, con suelo rocoso, herboso, nevado, sales, barrancos... Y sobre todo esto tenemos por supuesto todo tipo de recursos artísticos que deben ser desperdigados de una manera procedimental.
Esto no puede ser hecho a mano si piensas en esto a nivel global, por lo que todas estas cosas están dentro del Ecosistema. Y para esto Sasha Hoba creó su propio editor para el motor y dentro de este editor nosotros acumulamos toda esta información y la ajustamos, sean mapas de alturas de las montañas, donde van las texturas, qué recursos artísticos se ponen en qué ecosistemas y posiciones, qué superficies van juntas en el ecosistema. Una vez que todas estas cosas están hechas tu puedes tomar tu planeta, que en ese estado es básicamente gris, escoger los ecosistemas que te interesen y pintarlos sobre el planeta. Y así es como se genera el terreno del planeta al final.
Cuando esto se genera quieres que tenga sentido, quieres que tenga ricas líneas de montañas y tras ellas quieres que haya colinas y tras estas unas praderas llenas de hierba o desiertos o lo que sea.
Así pues, en CitizenCon 2016 estábamos soportando terreno esférico, transiciones transparentes, generación de terreno en tiempo real, 60 FPS sin pre-procesado alguno, distancia de visión sin restricción alguna y una escala planetaria, además de diferentes ecosistemas y la primera versión de la vegetación procedimental, además de teselación por hardware y desplazamientos por pixel.
Yendo un poco al pasado, antes de Gamescom podéis ver la prueba que Pascal creo rápidamente para un planeta con el aspecto de Marte. Usando unos pocos ecosistemas y cambiando algunos parámetros como el color de la atmósfera y así sucesivamente.
Con unos cuantos ecosistemas pintados sobre la esfera del planeta podemos crear muchos tipos distintos de entornos y planetas.
(Ndt: Si, es la Tierra WIP. Si, Francia está inundada y Andorra tiene playa XD Tampoco se ha perdido mucho...)
Aquí tenéis una demostración de los siguientes pasos que estamos dando, como mejorando el posicionamiento procedimental de la vegetación y distribución de los objetos.
En este clip de video podéis ver como la hierba y los árboles son renderizados a través del sistema de zonas y del que hablará Chris Bolte en un rato.
En este otro vídeo podéis ver una nueva característica: un planeta rotando sobre si mismo. Está rotando un poco rápido, de hecho, pero a esta escala parece que no se está moviendo.
Pero si os acercáis mucho y te pones sobre está grande torre estática en el mar podemos ver como el planeta rota muy rápidamente. Otra de las cosas en este vídeo es la tecnología del océano que ha escrito Anais, uno de nuestros nuevos trabajadores de Frankfurt. El Océano está re-utilizando los parches del terreno con distintos desplazamientos, y de esta manera obtenemos sub-divisiones adaptativas computadas gratis y ni siquiera necesitamos tener geometría extra para los océanos.
El terreno del océano era básicamente una superficie de terreno "plano"; pero para el planeta necesitábamos que las aguas funcionasen como un terreno esférico también. Esta característica ya está implementada y podéis ver cómo como hay olas apropiadas, animaciones de vértices y está decentemente teselada. El shading está funcionando y se nota que Anais ha puesto un montón de trabajo en ello.
La otra característica en la que estamos trabajando es las nubes y se encuentran en una etapa muy temprana todavía. Carsten Wenzel está trabajando mucho en esto, investigando mucho... pero ya podéis ver como tienen un comportamiento muy realista.
Podéis ver cómo están emitiendo sombras, tienen diferentes grosores en ciertas áreas por lo que penetra menos luz a través de ellas...
Hablando de luz, una de las cosas que más ha cambiado es el Sol. Debido a que es un objeto esférico obtienes diferentes condiciones de luz a lo largo del planeta.
Así que puedes decir que para este planeta quieres que sea de día, o quieres que las cosas sucedan durante el atardecer... dependiendo de dónde te encuentres en el planeta tienes diferentes situaciones lumínicas. Si es el atardecer obviamente todo se vuelve anaranjado.
Y durante el día tienes luz azul rebotando desde la atmósfera y todo ese tipo de cosas.
CAMBIOS AL MOTOR GRÁFICO
Chris Bolte (Programador del Motor Senior: Hola a todos. Me gustaría hablar de los cambios que hemos hecho a nuestra tecnología principal en el motor gráfico que nos permiten implementar los planetas tal y como habéis visto durante CitizenCon.
Uno de los primeros componentes que cambiamos fue el Sistema de Trabajos. Este sistema es el responsable de distribuir el trabajo que se debe hacer para computar cada uno de los fotogramas que ves en un videojuego a lo largo de distintos núcleos de la CPU. Esto recibe el nombre de "Trabajos" en nuestro motor.
El viejo sistema aplicaba de 3.000 a 5.000 Trabajos por Fotograma, pero con el nuevo podemos manejar un número mucho mayor de Trabajos. Esto fue hecho principalmente utilizando el paralelismo inherente a los juegos, lo cual es una manera inteligente de decir que obviamente tenemos que actualizar más de un objeto.
Además de esto, cambiamos como funcionaba el Sistema de Trabajos para que se comunicase mejor con el ordenador para que pueda utilizar mejor los recursos a su disposición. Hemos construído nuestro propio sistema, que es sistema de administración de objeto por zonas de espacio. Ese sistema es responsable de permitir la creación óptima de objetos en función a sus propiedades especulares, como por ejemplo mostrar objetos son visibles a la cámara y no crear los que no ves en cada "caja".
El sistema sustituyó la manera de hacerlo habitual, basada en Octrees, y nos permite ahora almacenar los objetos en su posición en el espacio vertex. Este sistema tiene dos características importantes:
- Ser eficiente. Debería escalar bien. Tenemos actualmente 200.000 objetos presentes en Crusader y esto se ha hecho realidad asegurándonos de que tenemos una estructura de datos eficiente en el planteamiento del procesado para permitir el uso de múltiples núcleos a través del Sistema de Trabajos.
- El sistema debería ser muy bueno a la hora de hacer ocuparse de grandes agrupaciones de múltiples objetos en movimiento. Aquí usamos un nuevo sistema para poder utilizar múltiples sistemas de referencia.
La manera habitual de hacer esto en los juegos es mediante un almacenamiento de objetos en un sistema de coordenadas único, el así llamado VertSpace. este posicionamiento es manejado por la GPU en bloques de coordenadas de 32 bits y representado en la pantalla con una matriz de proyección.
Para Star Citizen no podemos usar este método por dos razones:
- La GPU sólo puede procesar 32 bits de precisión en coma flotante de manera eficiente, pero nosotros necesitamos 64 bits de precisión al tener un mundo de juego enorme: queremos mover naves de un kilómetro de largo sobre planetas o a través del espacio.
- La manera tradicional significaría que seria necesaria la actualización de los antes mencionados planetas, objetos y naves, lo cual no sería posible en tiempo real.
Así que a alto nivel organizamos nuestro universo en un sistema de coordenadas de 64 bits de precisión. Para renderizar los objetos almacenados en esas coordenadas computas un posicionamiento relativo a la cámara que envía luego esos datos a la GPU. Esto nos permite mantener el mundo en un único sistema de coordenadas, usando al mismo tiempo el más eficiente sistema de 32 bits para renderizar en la GPU.
Para mover objetos dentro del sistema de coordenadas de 64 bits usamos múltiples zonas. Una zona es su propio sistema de coordenadas de objetos pequeños que se mueven juntos: como una nave espacial en pequeño o un planeta en grande.
Con este sistema podemos mover un número arbitrario de grandes objetos simplemente moviéndolos juntos pivotando sobre el sistema principal de coordenadas. El culling en un sistema como este se implementa convirtiendo los objetos que se están "probando" contra los objetos del espacio en el que se mueve (ndt: Culling es un termino de renderización que indica un sistema para dejar de renderizar cosas que no son necesarias para mostrar correctamente una escena y así mejorar el rendimiento. Ejemplo: no renderizar lo que está fuera de una habitación sin ventanas y con la puerta cerrada. Al abrir la puerta se renderiza el pasillo que hay detrás pero no las habitaciones que están tras las puertas cerradas de ese pasillo. Y así sucesivamente).
Esto resume las tecnologías necesarias para tener un universo que vive y que respira. Gracias.
