Autor Tema: RTV - Object Container Streaming - 7 Septiembre 2018  (Leído 911 veces)

10 de Septiembre de 2018, 21:49:49
Leído 911 veces

Havok Specter

  • Información
  • Mensajes: 3737
  • En el espacio impera la ley del oeste
VÍDEO OFICIAL EN INGLÉS

https://www.youtube.com/watch?v=E0YYKIjEC0E

TRANSCRIPCIÓN EN INGLÉS

https://relay.sc/transcript/reverse-the-verse-7th-september-2018

RESÚMENES EN VÍDEO

Bored Gamer

https://www.youtube.com/watch?v=DKa4j-xxy2I

RESÚMENES TRANSCRITOS EN ESPAÑOL

- El OCS es una gran parte de Star Citizen ya que se necesita para tener una gran área de juego sin pantallas de carga.

- En este momento el OCS funciona a nivel de cliente y el OCS a nivel de servidores vendrá después. Esto significa que los jugadores utilizarán menos recursos cuando jueguen a Star Citizen, lo que resultará en una experiencia más suave (eliminación del stuttering).

- Debido a la gran variedad de PCs, la mejora del rendimiento con OCS es una gran incógnita, lo que significa que el cliente y el servidor sólo cargarán lo que necesites, lo que reducirá la cantidad de espacio necesario para el rendimiento y el uso de memoria (menor uso de la RAM).

- El OCS valora un objeto por su tamaño para determinar si debe ser cargado en memoria. Por ejemplo, Levski se cargaría a una gran distancia, pero una nave pequeña no. El sistema tendrá en cuenta la distancia desde el objeto manejado a nivel de servidor.

- Cuando se imaginó por primera vez, el OCS consistía en tres pasos:
1.- El "Bind Culling" (otra tecnología que están desarrollando) decide deshacerse de las entidades en función de la distancia, lo que hace que esencialmente no existieran para el jugador, pero el servidor le avisará de la existencia de un elemento si es relevante para tí en forma de "marcador", con esto sólo se notifica el marcador y no el elemento en sí mismo, lo cuál es menos drástico para el rendimiento.
2.- En lugar de renderizar los objetos como se hace ahora, gracias al OCS serán el cliente y el servidor en esencia quienes se comuniquen mediante pequeñas cantidades de datos solo cuando corresponda.
3.- Las variables serializadas son los paquetes de datos que representan los objetos de interés para tí como jugador. Por ejemplo: un jugador tiene un marcador de un planeta pero está muy lejos de la ubicación. El jugador todavía necesita mantener un registro del marcador, con el bind culling haría que el planeta 'no existiera', en lugar de cargar todo el planeta y cargarlo en el cliente, lo que afectaría al rendimiento. Los datos sobre el objeto y su ubicación actual se enviarían, esto es una variable serializada, que esencialmente mantiene un registro de los objetos y su ubicación y si el jugador necesita saber acerca de ellos y con qué frecuencia.

- Se empezó a trabajar en todo esto hace más de 3 años.

- El OCS también es necesario para Squadron 42.

- La carga de entidades asíncronas forma parte del OCS. Actualmente cuando un ítem es generado se hace en el proceso principal, lo que hará que el proceso se bloquee hasta que ese ítem sea generado, el a-sync permitirá que ese proceso sea movido a un proceso de segundo plano, permitiendo que otras entidades sean cargadas hasta que esté listo para generarse en el proceso principal. El bind culling permite que esta información se envíe como un paquete de datos más pequeño al servidor/otros clientes.

- El OCS implica muchos cambios constantes pero también permite que haya jugadores que no reciban actualizaciones constantes de todos los datos que se producen en el juego. Lo dificil es marcar los límites.

- Un ejemplo sencillo es que si tú y un amigo están en un combate, y el amigo se aleja lo suficiente, ese combate desaparecerá de tu memoria. Ahora, si dejases caer una caja de carga mientras él no está, y luego regresa, la caja de carga tendrá que indicarle que está en el espacio, etc.... Hay muchos estados de cosas que tienen que propagarse y actualizarse de cara a los jugadores. Se vuelve aún más difícil cuando hay gente por todo el espacio, no sólo en un único lugar.

- Han estado usando personajes zombies para llenar el Universe, para que puedan ver cómo es la carga en el servidor cuando hay gente por todas partes.

- Cuando el OCS entre en funcionamiento, habrá problemas. Habrá cosas que nunca han visto, problemas que no han podido ver en el control de calidad y así sucesivamente. Es necesario para hacer pruebas. Hay muchas cosas que también se están actualizando con OCS, así que habrá muchos bugs, ya que OCS afecta a casi todo Star Citizen - todo tiene que ser adaptado para que funcione con él.

- El OCS no es una bala de plata. Todavía habrá mejoras en la red en el futuro y todavía habrá mejoras en la optimización.

- Que haya más jugadores por instancia no tiene relación con el OCS. Las mejoras de OCS son *sólo* por parte del cliente. En realidad, hay más tráfico en el lado del servidor debido al OCS.

- El OCS a nivel de servidores requiere más tecnología de la que aún no disponen.

- El OCS no debería afectar a las distancias de visión, aunque puede haber algún pequeño pop-in.

- Podría llevar menos tiempo cargar el juego. Además, algunas personas que no podían cargar el juego antes podrían ahora ser capaces de cargarlo, ya que ya no necesita tanta memoria.

- No hay límite en el número de contenedores que pueden tener. Está el contenedor "sistema", luego los contenedores "planetarios", luego, digamos, un contenedor "Grim Hex", luego contenedores para cada una de las tiendas, etc....

- El OCS en SQ42 tiene que ver con el tamaño de los mapas que veremos.

- El OCS ha sido un proceso de varios años en toda la compañía. Ha tocado todos y cada uno de los elementos del juego, y sigue haciéndolo. Y no se terminará con este parche tampoco, siempre habrá más que añadir. El streaming a nivel de servidor es el siguiente paso, y hay más más allá de eso también.
« Última modificación: 10 de Septiembre de 2018, 22:49:38 por Havok Specter »
 
Los siguientes usuaríos te invitarían a una cerveza por este mensaje: Pengo, spukmeyer, Motoko


Lo siento, este hilo está cerrado. Sólo admins y moderadores pueden responder.