Jump to content

Search the Community

Showing results for tags 'dev'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • PLAYERUNKNOWN'S BATTLEGROUNDS
    • Forum Rules & Guidelines
    • Report A Player & Appeals
  • Game Announcements & Forum Info
  • Gameplay Discussion & Suggestions
  • PC
    • PC News & Patch Notes
    • Game Discussion & Feedback
    • Help & Troubleshooting
    • Bug Reports & Known Issues
    • Test Server
  • Xbox
    • Xbox News & Patch Notes
    • Game Discussion & Feedback
    • Help & Troubleshooting
    • Bug Reports & Known Issues
    • Test Server
  • PS4
    • PS4 News & Patch Notes
    • Game Discussion & Feedback
    • Help & Troubleshooting
    • Bug Reports & Known Issues
    • Test Server
  • PUBG API Community Developers
    • Getting Started
    • Announcements
    • Community Developer General Discussion
    • Community Developer Projects
    • Community Developer Help
  • Community
    • Introductions
    • Looking For Players
    • Community Content
    • Off Topic
  • Other Languages
    • Russian
    • Turkish
    • German
    • French
    • Spanish
    • Portuguese
    • Polish
    • Italian

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 8 results

  1. In your DEV update, there was a video showing the loading building optimization. That’s great, but it was never specified what hardware was used. OG XBOX? Xbox S? Xbox X? Using a SSD? I’m currently running Xbox X with SSD. My buildings are loaded when I hit the ground. Previous to buying a SSD that wasn’t the case. So just curious as to what was being used in the video to showcase the optimization. Thanks
  2. Dear Dev Team, why the PC Version gets more and quicker Patches then the Console Version? thx for your answer. Best regards.
  3. Hola a todos: ¡Estamos de vuelta con un nuevo informe de desarrollo de consola! Esta semana, vamos a hablar sobre los distintos tipos de LOD, su significado y por qué son tan importantes para el rendimiento. LOD significa nivel de detalle y hay diferentes tipos para los numerosos objetos presentes en PUBG. Según la situación, se utiliza un LOD más o menos detallado para conseguir un equilibrio óptimo entre rendimiento y calidad visual, y de este modo proporcionar la mejor experiencia de juego posible. PUBG utiliza 3 niveles de LOD diferentes dependiendo de la situación: LOD 2, LOD 1 o LOD 0, siendo este último el más detallado de los tres. Cuanto mayor es el LOD, mayor es el impacto en el rendimiento. Aunque el rendimiento es importante, también debemos evitar que la jugabilidad se vea perjudicada por el uso de un LOD inferior. Un ejemplo de LOD en acción es el aspecto de "plastilina" que tienen algunos edificios cuando los veis desde lejos al caer en paracaídas. Esto se debe al uso del primer LOD, el menos detallado de todos. Al comienzo de una partida, los edificios cercanos también pueden tener este aspecto, ya que hay muchos objetos diferentes que procesar a la vez. Se pasa a LOD 0 (máximo detalle) tan pronto como es posible, pero la velocidad de procesamiento depende del hardware empleado. También se aplican tres tipos de LOD diferentes a los personajes: Mesh LOD, Bone LOD y AnimNode LOD. Primero vamos a hablar del Mesh LOD y del Bone LOD, para después meternos de lleno en la pieza central de este informe: el AnimNode LOD. Mesh LOD y Bone LOD El Mesh LOD determina el LOD del modelo de personajes. Cuando os acercáis a un personaje, este se muestra como LOD 0 (máximo detalle). Pero cuanto más os alejáis de él, menor será su nivel de detalle. Esto sucede en etapas, pasándose de LOD 2 a LOD 1 y a LOD 0. Por lo general no notaréis estas transiciones, ya que suceden a una distancia en la que los personajes aparecen muy pequeños en pantalla. El Bone LOD funciona de la misma manera, pero determina el número de huesos activos durante las animaciones de los personajes. Esto significa que, a grandes distancias, el juego no necesita procesar animaciones muy detalladas que podrían reducir el rendimiento. Un LOD inferior implica un uso reducido de vértices y menos datos óseos que procesar. Esto supone una gran mejora en el rendimiento en comparación con la ausencia de LOD optimizados. El uso de niveles adicionales de LOD (3, 4, etc.) aumentaría el rendimiento y reduciría el impacto en la CPU, pero la carga adicional para la memoria, E/S, etcétera, sería excesiva para el hardware de una consola, así que no se puede implementar en esta etapa. AnimNode LOD Las animaciones también tienen sus propios LOD, llamados AnimNode LOD, pero no se pueden aplicar igual que el Mesh LOD o el Bone LOD, ya que los cambios visuales son muy aparentes. Animaciones como correr, mirar a un lado o apuntar con la mira de un arma son parte del control óseo de un personaje. Las animaciones óseas de un personaje se calculan en función de cada uno de sus miembros, lo que requiere cálculos y animaciones independientes para los brazos, las piernas, el cuello, etc. Hemos desarrollado un método LOD adicional basado en el tamaño del modelo de los personajes en proporción a la pantalla. Hecho esto, establecemos parámetros que seleccionan de forma automática y dinámica un AnimNode LOD menos detallado para los modelos que estén a una distancia a la que no se note el cambio visual. Esto supone un mayor rendimiento sin afectar negativamente al juego o a la experiencia visual. Para que entendáis mejor el funcionamiento, tened en cuenta que, para los ejemplos visuales que se muestran a continuación, los cambios en el AnimNode LOD se producen a distancias muy cortas. Al jugar a PUBG, el AnimNode LOD solo tiene efecto a grandes distancias. Este es el primer ejemplo de cómo funciona un AnimNode LOD en el juego: (Esta imagen forma parte de un entorno de desarrollo y solo tiene fines ilustrativos. El AnimNode LOD solo se desactiva a grandes distancias al jugar a PUBG) En la imagen de arriba, podéis ver las diferencias entre tener un AnimNode LOD activado y desactivado. Cuando el AnimNode LOD está completamente deshabilitado, se desactivan las animaciones del personaje y no se reflejan en el modelo, lo que implica un mayor rendimiento. Sin embargo, cuando un jugador está agachado, la parte inferior del cuerpo necesita un AnimNode LOD activado, o parecería que está de pie. Para el siguiente ejemplo, en nuestro entorno de desarrollo hemos establecido que el AnimNode LOD se desactive cuando el modelo del personaje ocupe un 10 % de toda la pantalla. Esto os ayudará a entender mejor lo que sucede cuando el AnimNode LOD está desactivado. Durante el juego, el AnimNode LOD solo se desactivará cuando el modelo sea demasiado pequeño como para ver estos cambios. (Esta imagen forma parte de un entorno de desarrollo y solo tiene fines ilustrativos. El AnimNode LOD solo se desactiva a grandes distancias al jugar a PUBG) Puede que os estéis preguntando: "¿Qué sucede cuando acerco la vista sobre un enemigo lejano?". Al observar de cerca un jugador lejano, el modelo que veis llena más la pantalla y el AnimNode LOD se activa dinámicamente según la proporción del modelo de personaje respecto a la pantalla. Así se evita un impacto negativo en el juego. Aquí podéis ver un ejemplo gráfico del AnimNode LOD que utilizamos en nuestro entorno de desarrollo. Está diseñado para que se desactive cuando el modelo ocupe el 10 % de la pantalla. Esto os ayudará a entender lo que está sucediendo. (Esta imagen forma parte de un entorno de desarrollo y solo tiene fines ilustrativos. El AnimNode LOD solo se desactiva a grandes distancias al jugar a PUBG) Al jugar a PUBG, estos cambios solo tienen efecto cuando el modelo de personaje está muy lejos y ocupa una pequeña parte de toda la pantalla. Pero no podréis apreciar los cambios. Rendimiento del AnimNode LOD El siguiente gráfico mide el rendimiento del AnimNode LOD activado (azul) y desactivado (rojo) con 10 personajes en pantalla. Al desactivar el AnimNode LOD, se aprecia una mejora aproximada del 10 % en el rendimiento. * Resultados gráficos obtenidos con una Xbox One X. Cuantos más modelos en una zona tengan el AnimNode LOD desactivado, mayor será el rendimiento en comparación con el AnimNode LOD activado. En resumen, algunas animaciones de personajes se desactivan o se reducen cuando se encuentran a una distancia suficiente como para que no se note ningún cambio. Esto supone un menor uso de recursos y un aumento en el rendimiento. ¡Gracias por leernos! Nos vemos en la próxima edición de la serie "Informe de desarrollo de la consola". El equipo de consolas de PUBG
  4. Hola a todos: ¡Estamos de vuelta con un nuevo informe de desarrollo de consola! Esta semana, vamos a hablar sobre los distintos tipos de LOD, su significado y por qué son tan importantes para el rendimiento. LOD significa nivel de detalle y hay diferentes tipos para los numerosos objetos presentes en PUBG. Según la situación, se utiliza un LOD más o menos detallado para conseguir un equilibrio óptimo entre rendimiento y calidad visual, y de este modo proporcionar la mejor experiencia de juego posible. PUBG utiliza 3 niveles de LOD diferentes dependiendo de la situación: LOD 2, LOD 1 o LOD 0, siendo este último el más detallado de los tres. Cuanto mayor es el LOD, mayor es el impacto en el rendimiento. Aunque el rendimiento es importante, también debemos evitar que la jugabilidad se vea perjudicada por el uso de un LOD inferior. Un ejemplo de LOD en acción es el aspecto de "plastilina" que tienen algunos edificios cuando los veis desde lejos al caer en paracaídas. Esto se debe al uso del primer LOD, el menos detallado de todos. Al comienzo de una partida, los edificios cercanos también pueden tener este aspecto, ya que hay muchos objetos diferentes que procesar a la vez. Se pasa a LOD 0 (máximo detalle) tan pronto como es posible, pero la velocidad de procesamiento depende del hardware empleado. También se aplican tres tipos de LOD diferentes a los personajes: Mesh LOD, Bone LOD y AnimNode LOD. Primero vamos a hablar del Mesh LOD y del Bone LOD, para después meternos de lleno en la pieza central de este informe: el AnimNode LOD. Mesh LOD y Bone LOD El Mesh LOD determina el LOD del modelo de personajes. Cuando os acercáis a un personaje, este se muestra como LOD 0 (máximo detalle). Pero cuanto más os alejáis de él, menor será su nivel de detalle. Esto sucede en etapas, pasándose de LOD 2 a LOD 1 y a LOD 0. Por lo general no notaréis estas transiciones, ya que suceden a una distancia en la que los personajes aparecen muy pequeños en pantalla. El Bone LOD funciona de la misma manera, pero determina el número de huesos activos durante las animaciones de los personajes. Esto significa que, a grandes distancias, el juego no necesita procesar animaciones muy detalladas que podrían reducir el rendimiento. Un LOD inferior implica un uso reducido de vértices y menos datos óseos que procesar. Esto supone una gran mejora en el rendimiento en comparación con la ausencia de LOD optimizados. El uso de niveles adicionales de LOD (3, 4, etc.) aumentaría el rendimiento y reduciría el impacto en la CPU, pero la carga adicional para la memoria, E/S, etcétera, sería excesiva para el hardware de una consola, así que no se puede implementar en esta etapa. AnimNode LOD Las animaciones también tienen sus propios LOD, llamados AnimNode LOD, pero no se pueden aplicar igual que el Mesh LOD o el Bone LOD, ya que los cambios visuales son muy aparentes. Animaciones como correr, mirar a un lado o apuntar con la mira de un arma son parte del control óseo de un personaje. Las animaciones óseas de un personaje se calculan en función de cada uno de sus miembros, lo que requiere cálculos y animaciones independientes para los brazos, las piernas, el cuello, etc. Hemos desarrollado un método LOD adicional basado en el tamaño del modelo de los personajes en proporción a la pantalla. Hecho esto, establecemos parámetros que seleccionan de forma automática y dinámica un AnimNode LOD menos detallado para los modelos que estén a una distancia a la que no se note el cambio visual. Esto supone un mayor rendimiento sin afectar negativamente al juego o a la experiencia visual. Para que entendáis mejor el funcionamiento, tened en cuenta que, para los ejemplos visuales que se muestran a continuación, los cambios en el AnimNode LOD se producen a distancias muy cortas. Al jugar a PUBG, el AnimNode LOD solo tiene efecto a grandes distancias. Este es el primer ejemplo de cómo funciona un AnimNode LOD en el juego: (Esta imagen forma parte de un entorno de desarrollo y solo tiene fines ilustrativos. El AnimNode LOD solo se desactiva a grandes distancias al jugar a PUBG) En la imagen de arriba, podéis ver las diferencias entre tener un AnimNode LOD activado y desactivado. Cuando el AnimNode LOD está completamente deshabilitado, se desactivan las animaciones del personaje y no se reflejan en el modelo, lo que implica un mayor rendimiento. Sin embargo, cuando un jugador está agachado, la parte inferior del cuerpo necesita un AnimNode LOD activado, o parecería que está de pie. Para el siguiente ejemplo, en nuestro entorno de desarrollo hemos establecido que el AnimNode LOD se desactive cuando el modelo del personaje ocupe un 10 % de toda la pantalla. Esto os ayudará a entender mejor lo que sucede cuando el AnimNode LOD está desactivado. Durante el juego, el AnimNode LOD solo se desactivará cuando el modelo sea demasiado pequeño como para ver estos cambios. (Esta imagen forma parte de un entorno de desarrollo y solo tiene fines ilustrativos. El AnimNode LOD solo se desactiva a grandes distancias al jugar a PUBG) Puede que os estéis preguntando: "¿Qué sucede cuando acerco la vista sobre un enemigo lejano?". Al observar de cerca un jugador lejano, el modelo que veis llena más la pantalla y el AnimNode LOD se activa dinámicamente según la proporción del modelo de personaje respecto a la pantalla. Así se evita un impacto negativo en el juego. Aquí podéis ver un ejemplo gráfico del AnimNode LOD que utilizamos en nuestro entorno de desarrollo. Está diseñado para que se desactive cuando el modelo ocupe el 10 % de la pantalla. Esto os ayudará a entender lo que está sucediendo. (Esta imagen forma parte de un entorno de desarrollo y solo tiene fines ilustrativos. El AnimNode LOD solo se desactiva a grandes distancias al jugar a PUBG) Al jugar a PUBG, estos cambios solo tienen efecto cuando el modelo de personaje está muy lejos y ocupa una pequeña parte de toda la pantalla. Pero no podréis apreciar los cambios. Rendimiento del AnimNode LOD El siguiente gráfico mide el rendimiento del AnimNode LOD activado (azul) y desactivado (rojo) con 10 personajes en pantalla. Al desactivar el AnimNode LOD, se aprecia una mejora aproximada del 10 % en el rendimiento. * Resultados gráficos obtenidos con una Xbox One X. Cuantos más modelos en una zona tengan el AnimNode LOD desactivado, mayor será el rendimiento en comparación con el AnimNode LOD activado. En resumen, algunas animaciones de personajes se desactivan o se reducen cuando se encuentran a una distancia suficiente como para que no se note ningún cambio. Esto supone un menor uso de recursos y un aumento en el rendimiento. ¡Gracias por leernos! Nos vemos en la próxima edición de la serie "Informe de desarrollo de la consola". El equipo de consolas de PUBG
  5. Hola a todos: Os damos la bienvenida a la primera edición de nuestra nueva serie, Informe de desarrollo de consola, que reemplazará las publicaciones semanales de la comunidad. Como ya mencionamos, nuestra idea es publicar esta serie cada dos semanas y centrarnos en el rendimiento, los problemas de desarrollo y las soluciones que encontremos. Este cronograma puede variar según los temas a tratar. En la publicación de hoy, vamos a analizar en profundidad la velocidad de fotogramas y cómo planeamos lograr una velocidad más alta para cumplir con las expectativas de todos los jugadores de PUBG. Introducción Muchos jugadores han informado sobre caídas en la velocidad de fotogramas, en especial, durante las últimas etapas, cuando suele haber situaciones de enfrentamientos a corto alcance. PUBG calcula los recursos de todos los elementos en un radio de 600m alrededor del personaje. Esto significa que, sin importar dónde esté tu personaje, se calcula todo en un radio de 600m a su alrededor. En la etapa final de la partida, cuando la zona blanca se reduce, los jugadores se concentran en un círculo más pequeño, es decir, que hay más jugadores que requieren un cálculo de recursos en este círculo. Algo similar sucede con las caídas en zonas concurridas, pero en los momentos finales de las partidas, por lo general hay más recursos para calcular, ya que muchos jugadores llegan a esa instancia con mucho equipamiento. Los vehículos, atuendos, aspectos de armas y granadas de humo son algunos de los recursos que se deben calcular. Para mejorar el rendimiento y reducir los casos de caída en la velocidad de fotogramas en estas situaciones, tenemos que disminuir la cantidad de recursos que se calculan. Para detallar nuestro trabajo, primero debemos explicar el concepto de «espectro de visión». El espectro de visión es, básicamente, el ángulo de visión que se muestra en el monitor. Por lo tanto, si hay un enemigo que camina frente a ti y aparece en la pantalla, dicho enemigo está dentro del espectro de visión. Sin embargo, esto no significa que todo lo que está dentro del espectro de visión se muestra en el monitor. La dirección y el ángulo de visión es lo que realmente importa: un jugador que se encuentra detrás de una pared que estás mirando también está dentro de tu espectro de visión. Dentro del espectro de visión Lo que está dentro del espectro de visión siempre se calcula. Por eso, el movimiento del personaje de tus aliados o enemigos siempre se muestra. Para mostrar el movimiento de personaje de la manera más precisa posible, el servidor debe realizar algunos cálculos predictivos. Supongamos que el usuario A se mueve en una dirección, cuando el servidor recibe la información de ubicación del personaje del cliente del usuario A y la devuelve, la ubicación enviada del usuario A será una ubicación anterior del usuario A, ya que el jugador se habrá movido mientras el cliente del usuario A envía la ubicación al servidor y el servidor envía la ubicación del usuario A a tu cliente. Si el error entre ambos es muy grande, se produce una desincronización. Para ser muy preciso en la ubicación del personaje, el servidor predice la velocidad y la dirección de movimiento del usuario para discernir exactamente dónde estará. El servidor también predice la ubicación comprobando la elevación del terreno y la existencia de objetos que bloqueen al jugador en su trayectoria, por ejemplo, una pared. Esto ha mejorado notablemente el tiempo de respuesta de la ubicación de personaje para lograr una mayor precisión y solucionar los problemas de desicronizaciones. Para predecir con precisión el movimiento de personaje, se aumentaron los recursos que se deben calcular, lo cual fue uno de los motivos de las caídas en la velocidad de fotogramas. Con el objetivo de mejorar el rendimiento, hemos reducido el proceso mencionado para eliminar cálculos innecesarios y todos los componentes de movimiento innecesarios fueron retirados. De esta manera, se disminuyeron las caídas de FPS y se mejoró el rendimiento. El siguiente gráfico muestra el «tiempo de cálculo de volumen de física por cada fotograma». Esto se probó con 30 bots, y compara la versión actual con la versión mejorada, que se incluirá en el próximo parche muy pronto. La reducción de tiempo significa que se calculan menos recursos y, de este modo, se mejora el rendimiento. Fuera del espectro de visión Fuera del espectro de visión, también calculamos el movimiento de cada personaje. Por lo tanto, si hay 25 personajes moviéndose fuera de tu espectro de visión, se calculan todos sus movimientos, lo que significa que se necesitan muchos cálculos que producen caídas de FPS. Para solucionar este problema, hemos reducido en gran medida los recursos que se calculan sobre el movimiento de personajes fuera del espectro de visión. Hay dos factores que se deben considerar por cada personaje: la malla poligonal y el cuerpo físico. La parte de renderización de la malla tiene que ver con el modelo del personaje y el sonido de los pasos, los disparos, etc. El cuerpo físico se relaciona, mayormente, con los puntos de impacto del personaje. Para los personajes fuera del espectro de visión, hemos decidido actualizar únicamente la malla de renderización de la ubicación del personaje, de modo que la parte de física permanece en la última ubicación del personaje, fuera del espectro de visión. Al calcular únicamente la renderización, se ahorran más de la mitad de los recursos calculados. Cuando tu personaje vuelve a mirar al personaje que estaba fuera del espectro de visión, la ubicación de la física se reúne con la ubicación de la renderización del personaje, es decir que, en lugar de calcular de manera consistente la ubicación de la física, ahora esta solo se debe calcular una vez que la ubicación de la física entra en el espectro de visión. Según la ubicación de renderización del personaje, el cálculo de ubicación de física puede continuar o no. Como la ubicación de la física permanece igual y la ubicación de la malla continúa moviéndose (o no), cuando la ubicación de la física entra en tu espectro de visión, se transfiere a la ubicación de renderización. Si la ubicación de la malla no está en tu espectro de visión, la ubicación de cuerpo físico permanece en ese lugar hasta que vuelve a entrar en tu espectro de visión, en ese momento, se transfiere a la ubicación de renderización de la malla poligonal del personaje. El siguiente gráfico muestra la mejora de «tiempo de cálculo de volumen de física por cada fotograma». Como ya mencionamos, esto se probó con 30 bots, y compara la versión actual con la versión mejorada. En resumen, nuestros cambios tanto dentro como fuera del espectro de visión mejorarán el rendimiento al disminuir el tiempo necesario para calcular la ubicación de los jugadores. Hemos reducido los recursos que se deben calcular, así que se necesita menos tiempo. Con este cambio, habrá menos caídas en la velocidad de fotogramas y se aumentará la velocidad de fotogramas media. Seguiremos trabajando para obtener una velocidad de fotogramas más alta para mejorar la experiencia de nuestros usuarios. ¡Volveremos con otra publicación de la serie dentro de dos semanas! Gracias El Equipo de PUBG
  6. Hola a todos: Os damos la bienvenida a la primera edición de nuestra nueva serie, Informe de desarrollo de consola, que reemplazará las publicaciones semanales de la comunidad. Como ya mencionamos, nuestra idea es publicar esta serie cada dos semanas y centrarnos en el rendimiento, los problemas de desarrollo y las soluciones que encontremos. Este cronograma puede variar según los temas a tratar. En la publicación de hoy, vamos a analizar en profundidad la velocidad de fotogramas y cómo planeamos lograr una velocidad más alta para cumplir con las expectativas de todos los jugadores de PUBG. Introducción Muchos jugadores han informado sobre caídas en la velocidad de fotogramas, en especial, durante las últimas etapas, cuando suele haber situaciones de enfrentamientos a corto alcance. PUBG calcula los recursos de todos los elementos en un radio de 600m alrededor del personaje. Esto significa que, sin importar dónde esté tu personaje, se calcula todo en un radio de 600m a su alrededor. En la etapa final de la partida, cuando la zona blanca se reduce, los jugadores se concentran en un círculo más pequeño, es decir, que hay más jugadores que requieren un cálculo de recursos en este círculo. Algo similar sucede con las caídas en zonas concurridas, pero en los momentos finales de las partidas, por lo general hay más recursos para calcular, ya que muchos jugadores llegan a esa instancia con mucho equipamiento. Los vehículos, atuendos, aspectos de armas y granadas de humo son algunos de los recursos que se deben calcular. Para mejorar el rendimiento y reducir los casos de caída en la velocidad de fotogramas en estas situaciones, tenemos que disminuir la cantidad de recursos que se calculan. Para detallar nuestro trabajo, primero debemos explicar el concepto de «espectro de visión». El espectro de visión es, básicamente, el ángulo de visión que se muestra en el monitor. Por lo tanto, si hay un enemigo que camina frente a ti y aparece en la pantalla, dicho enemigo está dentro del espectro de visión. Sin embargo, esto no significa que todo lo que está dentro del espectro de visión se muestra en el monitor. La dirección y el ángulo de visión es lo que realmente importa: un jugador que se encuentra detrás de una pared que estás mirando también está dentro de tu espectro de visión. Dentro del espectro de visión Lo que está dentro del espectro de visión siempre se calcula. Por eso, el movimiento del personaje de tus aliados o enemigos siempre se muestra. Para mostrar el movimiento de personaje de la manera más precisa posible, el servidor debe realizar algunos cálculos predictivos. Supongamos que el usuario A se mueve en una dirección, cuando el servidor recibe la información de ubicación del personaje del cliente del usuario A y la devuelve, la ubicación enviada del usuario A será una ubicación anterior del usuario A, ya que el jugador se habrá movido mientras el cliente del usuario A envía la ubicación al servidor y el servidor envía la ubicación del usuario A a tu cliente. Si el error entre ambos es muy grande, se produce una desincronización. Para ser muy preciso en la ubicación del personaje, el servidor predice la velocidad y la dirección de movimiento del usuario para discernir exactamente dónde estará. El servidor también predice la ubicación comprobando la elevación del terreno y la existencia de objetos que bloqueen al jugador en su trayectoria, por ejemplo, una pared. Esto ha mejorado notablemente el tiempo de respuesta de la ubicación de personaje para lograr una mayor precisión y solucionar los problemas de desicronizaciones. Para predecir con precisión el movimiento de personaje, se aumentaron los recursos que se deben calcular, lo cual fue uno de los motivos de las caídas en la velocidad de fotogramas. Con el objetivo de mejorar el rendimiento, hemos reducido el proceso mencionado para eliminar cálculos innecesarios y todos los componentes de movimiento innecesarios fueron retirados. De esta manera, se disminuyeron las caídas de FPS y se mejoró el rendimiento. El siguiente gráfico muestra el «tiempo de cálculo de volumen de física por cada fotograma». Esto se probó con 30 bots, y compara la versión actual con la versión mejorada, que se incluirá en el próximo parche muy pronto. La reducción de tiempo significa que se calculan menos recursos y, de este modo, se mejora el rendimiento. Fuera del espectro de visión Fuera del espectro de visión, también calculamos el movimiento de cada personaje. Por lo tanto, si hay 25 personajes moviéndose fuera de tu espectro de visión, se calculan todos sus movimientos, lo que significa que se necesitan muchos cálculos que producen caídas de FPS. Para solucionar este problema, hemos reducido en gran medida los recursos que se calculan sobre el movimiento de personajes fuera del espectro de visión. Hay dos factores que se deben considerar por cada personaje: la malla poligonal y el cuerpo físico. La parte de renderización de la malla tiene que ver con el modelo del personaje y el sonido de los pasos, los disparos, etc. El cuerpo físico se relaciona, mayormente, con los puntos de impacto del personaje. Para los personajes fuera del espectro de visión, hemos decidido actualizar únicamente la malla de renderización de la ubicación del personaje, de modo que la parte de física permanece en la última ubicación del personaje, fuera del espectro de visión. Al calcular únicamente la renderización, se ahorran más de la mitad de los recursos calculados. Cuando tu personaje vuelve a mirar al personaje que estaba fuera del espectro de visión, la ubicación de la física se reúne con la ubicación de la renderización del personaje, es decir que, en lugar de calcular de manera consistente la ubicación de la física, ahora esta solo se debe calcular una vez que la ubicación de la física entra en el espectro de visión. Según la ubicación de renderización del personaje, el cálculo de ubicación de física puede continuar o no. Como la ubicación de la física permanece igual y la ubicación de la malla continúa moviéndose (o no), cuando la ubicación de la física entra en tu espectro de visión, se transfiere a la ubicación de renderización. Si la ubicación de la malla no está en tu espectro de visión, la ubicación de cuerpo físico permanece en ese lugar hasta que vuelve a entrar en tu espectro de visión, en ese momento, se transfiere a la ubicación de renderización de la malla poligonal del personaje. El siguiente gráfico muestra la mejora de «tiempo de cálculo de volumen de física por cada fotograma». Como ya mencionamos, esto se probó con 30 bots, y compara la versión actual con la versión mejorada. En resumen, nuestros cambios tanto dentro como fuera del espectro de visión mejorarán el rendimiento al disminuir el tiempo necesario para calcular la ubicación de los jugadores. Hemos reducido los recursos que se deben calcular, así que se necesita menos tiempo. Con este cambio, habrá menos caídas en la velocidad de fotogramas y se aumentará la velocidad de fotogramas media. Seguiremos trabajando para obtener una velocidad de fotogramas más alta para mejorar la experiencia de nuestros usuarios. ¡Volveremos con otra publicación de la serie dentro de dos semanas! Gracias El Equipo de PUBG
  7. Hola a todos: Desde que lanzamos la versión 1.0 de PUBG a principios de este año, nos hemos centrado en formar nuestro equipo para que podamos invertir en el desarrollo continuo del juego. Hemos estado creando contenido nuevo (como Sanhok), mejoras en la calidad de vida (como la selección de mapas y el balance de armas) y toda una serie de medidas agresivas contra el fraude. Queremos que PUBG sea el mejor juego posible para que jugadores como tú sigan amándolo y jugando. A pesar de que hemos realizado algunas mejoras significativas en PUBG, nos hemos quedado cortos en otros aspectos. Los jugadores se han quejado con razón por no recibir respuestas a las quejas sobre el rendimiento, y recientemente no hemos hecho el mejor trabajo al comunicar los cambios que estamos haciendo en el juego. Hoy queremos cambiar eso hablando en profundidad sobre las cosas que priorizamos y de algunos de los próximos contenidos que planeamos agregar al juego. Esta carta Dev es la primera de muchas más por venir. Sin más preámbulos, entremos en ello. NUESTRAS PRIORIDADES MÁS IMPORTANTES Analizamos los comentarios de jugadores de todo el mundo al determinar nuestras prioridades. Hemos escuchado sus voces y, como resultado, creemos que los problemas más importantes que merecen nuestra atención son el rendimiento, la optimización del servidor y las trampas. Rendimiento y optimización del lado del servidor : en los últimos parches, hemos visto un gran aumento en las quejas sobre problemas de rendimiento, incluidas caídas de FPS impredecibles, tartamudeo visual y un rendimiento lento general. Algunos de los problemas de raíz están ocurriendo en el lado del cliente, y otros están en el lado del servidor. Lo primero es lo primero: Hemos identificado algunas soluciones simples que podemos hacer para mejorar el rendimiento general del juego: Hemos descubierto que cuando los vehículos se mueven rápidamente sobre muchos tipos diferentes de materiales , se producen demasiados efectos, lo que hace que las GPUS de los jugadores se sobrecarguen. Otra causa de la sobrecarga de la GPU (y las caídas de FPS) tiene que ver con la forma en que se procesan los efectos de iluminación. Ya estamos trabajando en soluciones para los dos problemas anteriores. También estamos cambiando la forma en que enviamos optimizaciones. Estamos planificando enviar actualizaciones a los servidores en vivo cuando las reparaciones estén listas, en lugar de simplemente esperar parches importantes. Anunciaremos cada una de estas mejoras en notas de parches posteriores. Mirando más hacia el futuro, hemos identificado bastantes maneras en las que podemos optimizar diferentes aspectos del juego para mejorarlo de manera integral. Próximo trabajo de optimización del lado del cliente Optimización de personajes: Optimizaremos la forma en que el juego maneja el movimiento de los oponentes que no puedes ver. El proceso y las animaciones de vaulting también se mejorarán; creemos que esto solucionará ciertos problemas de tartamudeo en la pantalla que afectan a los PC de baja potencia. Mejoraremos el proceso de representación del modelo de personajes para evitar algunos problemas de caída de FPS pequeños. Optimizaremos el movimiento de los personajes y la animación mientras hacemos paracaidismo para mejorar la velocidad de FPS cuando varios personajes saltan en paracaídas al mismo tiempo. Optimizaremos las animaciones de paracaídas para reducir las caídas de FPS cerca del inicio del partido Esperamos que los últimos tres cambios anteriores hagan que las primeras etapas de cada partido se sientan mucho más suaves. War Mode también se beneficiará enormemente con estos cambios. Optimización de vehículos Optimizaremos la forma en que el juego maneja el movimiento de vehículo invisible (lejano) y el movimiento de modelos de jugador dentro de vehículos lejanos. Los vehículos actualmente detenidos exigen una cantidad innecesaria de su CPU. Lo arreglaremos Optimización / estabilización de carga Optimizaremos las estructuras centrales de Miramar y Sanhok para mejorar la velocidad de carga del mapa. Optimizaremos la carga de texturas físicas al mismo tiempo, lo que debería abordar los problemas de tartamudeo en la pantalla. Hay un problema de bloqueo causado por algunos procesos que abordaremos. Otros trabajos de optimización Abordaremos el problema de caída de FPS causado por las mirillas. Algunos otros objetos lejanos se representarán de una manera menos exigente Optimizaremos el sistema de repetición para mejorar la velocidad de fotogramas para los jugadores que tengan activada la cámara de repetición/muerte. Próximo trabajo de optimización del lado del servidor Optimizaremos el código de red y reduciremos la latencia de la red. Vamos a aumentar la velocidad a la que el servidor transfiere datos sobre los objetos (elementos, puertas, vallas), para abordar el hecho de que a veces los objetos aparecen en los últimos segundos después de que los jugadores se lanzan en paracaídas. Vamos a eliminar un código de red ineficiente. Actualmente, algunos objetos envían actualizaciones al servidor innecesariamente Actualmente, el servidor actualiza rápidamente ciertos marcos (en vehículos y modelos de personajes) de forma ineficiente. Cuando abordemos esto, creemos que también resolverá algunos fenómenos físicos que afectan a los vehículos. Obviamente, estos son muchos cambios. Incluso una vez que implementamos cada una de las actualizaciones de optimización enumeradas anteriormente, seguiremos buscando más oportunidades para mejorar el juego. Hacer trampa : hacer trampa es el área donde hemos progresado más en los últimos meses. Hemos introducido una variedad de soluciones basadas en encriptación para dificultar que los hackers exploten las vulnerabilidades. También hemos baneado cientos de miles de cuentas de tramposos y refinado el proceso mediante el cual identificamos a los tramposos: la mayoría de los tramposos ahora son baneados a las pocas horas de usar un exploit. También hemos comenzado a tomar acciones legales serias contra las personas responsables de crear hacks y trampas. Todo esto continuará, pero hay más cosas que podemos hacer. Creemos que estamos ganando la batalla contra las trampas, pero no dejaremos de luchar hasta que lo hayamos eliminado. Busque más actualizaciones sobre esto en futuras cartas de desarrollo. OTROS TRABAJOS PRÓXIMOS Por supuesto, PUBG Corp. se compone de muchos equipos diferentes, y cada uno se enfoca en mejorar el juego de diferentes maneras. Las personas que trabajan en mapas, equilibrio de juego o cosméticos no van a dejar de hacer las cosas simplemente porque hemos declarado que nuestras principales prioridades están en otra parte. La mayoría de contenido en el futuro cercano es Sanhok. Nuestro objetivo es llevarlo a servidores activos antes de finales de junio, y el desarrollo en el mapa no se detendrá allí. Estamos planificando nuevos vehículos exclusivos y un arma exclusiva para Sanhok, cada uno de los cuales caerá en algún momento del mes posterior al lanzamiento oficial del mapa. Entre estos se encuentra una gran solicitud de un fanático: un vehículo de tres ruedas que se puede conducir y al que actualmente llamamos el Tukshai. En muchos sentidos, los servidores de prueba de Sanhok se han convertido en un lugar en el que podemos experimentar todo tipo de cambios y características, incluido el clima dinámico, una variedad de sistemas de círculos y el comportamiento de spawn de armas. Continuaremos probando los cambios durante el próximo ciclo de prueba. También estamos entusiasmados de mostrar el trabajo que nuestro equipo de Worldbuilding ha estado haciendo para hacer de Sanhok nuestro mapa más bello hasta el momento. Por ejemplo, una persona en el equipo ha pasado innumerables horas retocando varias rocas y terrenos de la isla, agregando musgo a los que están cerca del agua: Otro miembro del equipo ha estado creando cuidadosamente objetos decorativos para hacer que las ciudades se sientan mejor. Una enorme cantidad de elementos artísticos originales como este ... ... aparecerá en el juego en lugares como el mercado abandonado a continuación: el equipo se centra en hacer literalmente cada centímetro de Sanhok perfecto para los jugadores, ya sea la textura en una pared de roca o pequeños recortes únicos alrededor de cada una de las casas de las islas. Cada detalle importa, y el equipo está ansioso por recibir comentarios de ustedes durante la última prueba. Tendremos mucho más que compartir sobre los otros objetos que vendrán a Sanhok en las próximas semanas. Y puede esperar más cartas como esta de nosotros en el futuro. Hay tanto trabajo que tenemos que hacer para realmente entregar el potencial de PUBG. ¡Hablaremos de nuevo pronto! Gracias por jugar, El equipo de PUBG Dev
  8. Hello Community, first of my pc: cpu: i7-6700k @4.5ghz gpu: evga gtx 1080 ftw ram: 16gb ddr4 2133mhz mainboard: msi z170 pro carbon (playing in 1440p) So the game runs ok for me i have around 40-110 fps, it vary´s quite alot, so sometimes im have a lag which happens everytime my fps drops from 70 to 50 for example. Yesterday i was playing and i monitored alot of stats about my cpu and my gpu and i noticed that everytime i had such an fps drop my gpu usage went down from 99% to what ever, sometimes 80% sometimes to 50% and even lower and i just thought id share this so the devs might have some use of this info. (other games run fine and dont show this gpu usage drop behaviour) have fun playing everyone i can get some screenshots later if needed.
×
×
  • Create New...