ahona escribió:Malo va a ser que tenga que volver a repetir lo mismo, porque el descanso no va a ser precisamente corto.
Stylish escribió:Joder macho. ¿Qué más da procesar una suma que el cálculo de una iluminación? Cualitativamente es exactamente lo mismo.
Tu puedes mandar a procesar a la nube en tiempo real lo que te salga de la punta del capullo, lo que Microsoft ha vendido, y con razón, es que Azure es capaz de ejecutar código en la CPU y en la GPU porque su runtime y su tecnología de virtualización así se lo permite, y no hay más.
Una vez sabido esto, que no es la primera vez que lo digo, tu puedes pedirle a Azure que te monte un servidor de base de datos y una máquina virtual corriendo apache para servir una página web o le puedes pedir que pasándole una geometría y los puntos de luz calcule en tiempo real la iluminación. Es una diferencia cuantitativa, no cualitativa.
elalexel escribió:Stylish escribió:Joder macho. ¿Qué más da procesar una suma que el cálculo de una iluminación? Cualitativamente es exactamente lo mismo.
Tu puedes mandar a procesar a la nube en tiempo real lo que te salga de la punta del capullo, lo que Microsoft ha vendido, y con razón, es que Azure es capaz de ejecutar código en la CPU y en la GPU porque su runtime y su tecnología de virtualización así se lo permite, y no hay más.
Una vez sabido esto, que no es la primera vez que lo digo, tu puedes pedirle a Azure que te monte un servidor de base de datos y una máquina virtual corriendo apache para servir una página web o le puedes pedir que pasándole una geometría y los puntos de luz calcule en tiempo real la iluminación. Es una diferencia cuantitativa, no cualitativa.
Sinceramente ante tus últimos comentarios solo puedo decirte que estás sumamente equivocado (ni sabes lo que es un motor gráfico ni por lo visto lo que es un paradigma en programación... que si eres informático tiene tela marinera esto ultimo...), ya que en base a un vídeo y unas declaraciones lo siento pero no se puede afirmar nada categóricamente, con razonamientos, en cambio, si. He aquí unos cuantos:
Pasemos a definir básicamente lo que pretende microsoft con su arquitectura de cloud compute-gaming, lo que microsoft está definiendo es un cambio de paradigma en toda regla en el entorno cliente servidor, que cambia la premisa bien conocida de tarea entregada, tarea ejecutada, resultado devuelto, por encapsular esto en un entorno de ejecución en tiempo real. Esto transforma completamente el comportamiento del servidor y del cliente, ya que no tiene NINGÚN sentido que se envíe una respuesta a una petición de cálculos cuando la necesidad de ese dato es temporalmente inexistente (la has dejado atrás en el tiempo), un cliente de renderizado no espera por nadie que no sea hardware local, si pretendes esperar por la nube para renderizar algo la llevas clara (las latencias pueden ser enormes), el cliente en el modelo cliente servidor SIEMPRE espera la recepción del resultado de forma indefinida (hasta que se rebasa el TTL esperado para no colgar procesos, por supuesto), en este caso el cliente no va a esperar a nadie, por lo que el servidor tiene que asegurar unos plazos de ejecución mínimos que serán exigidos por el cliente para no fallar en la entrega y por tanto estropear por ello el renderizado de la escena.
Ahora imaginemos un par de casos prácticos para ilustrar una serie de diferencias cruciales para entender la problemática que este tipo de renderizado supone:
Caso 1º:
Tenemos un juego con un motor gráfico estándar basado en un modelo de renderizado local normal, a excepción de un detalle, el motor renderiza un mundo abierto y realista con ciclos de noche y día, cada minuto el sistema cambia la posición del punto luminoso principal de la escena a partir del cual se calculan todas las matrices de transformación/rotación/escalado de cada objeto para aplicarlas después a los bitmaps que forman las texturas de terceros objetos creando así la sombra como una representación 2D del objeto (esto es posible dado que el punto de luz permanecerá fijo en el cielo durante 1 minuto). en este caso la latencia máxima de recepción de la información calculada (matriz de transformaciones apilada) de forma remota por el servidor será de 55 segundos, reservándose 5 segundos para hacer un calculo aproximado (usando un modelo de geometría simple) en local en caso de que fuera necesario.
Caso 2º(Empleemos el del vídeo que has enlazado en tu ultimo mensaje):
Tenemos un juego con un motor gráfico mas modificado, que ha implementado las físicas con un sistema de calculo remoto para las colisiones, transformaciones, escalados y rotaciones de todos los chunks que se crean al partir la geometría compleja que forma los edificios (esto es posible siempre y cuando se reciban los datos (matriz de transformaciones apilada) a tiempo para volver a renderizar cada chunk correspondiente en su situación correcta una vez aplicados los cálculos del servidor) esto posibilita realizar cálculos complejos sobre miles de objetos en mucho menos tiempo de lo que permite el cliente por si mismo, pero ha de hacerse en menos tiempo de lo que tarda en renderizarse un frame (entre 2 y 5ms) restando el framerate al que estás renderizando. en este caso tenemos 32FPS osea 31.25ms y 5ms dan 26,25 ms como máximo para tener el dato en memoria desde que se renderiza el frame anterior.
(tiempo de renderizado de un frame en cryengine (mismo motor que el Ryse), busca el tiempo completo "sum all passes")
Como se puede comprobar perfectamente el primero de los 2 casos es idóneo para la implementación del sistema de renderizado no local, tienes una tasa de refresco muy lenta que te permite enviar una petición sin problemas y que sea contestada varias veces en caso de perdida de paquetes u otros problemas de la red. pero... que ganas realmente? te ahorras un calculo que se hace cada minuto? y eso tiene un gran impacto en el rendimiento del juego? ya te digo yo que no, ese calculo se puede partir en zonas y hacerlo en los tiempos que sobren entre frames sin problemas, por lo que mandar eso a la nube no va a mejorar prácticamente para nada el rendimiento del motor gráfico.
pero sin embargo, que sucede en el segundo ejemplo? pues sencillo, para que te hagas una idea leete este post y las respuestas al mismo: http://stackoverflow.com/questions/88093/how-many-game-updates-per-second el motor se actualiza de unas 20 veces por segundo a unas 100 según los requisitos del juego, si tienes que mandar una petición y esperar respuesta para unos cálculos que tienen que hacerse 20 veces por segundo vas a tener que usar una conexión a Internet con muy poca latencia, para que te hagas una idea:
se emplea un tiempo precioso en establecer una conexión y en enviar y esperar la recepción de una respuesta, mas que el envío de los datos en si (que con nuestras redes actuales seria despreciable) tenemos que tener en cuenta las latencias que hay en la comunicación ya que no se donde esperas que estén los servidores de Azure en Europa pero te garantizo de antemano que en España no hay, los pings de gente que ha hecho comprobaciones en titanfall rondan los 100ms o mas (no es casualidad que los bots del titanfall sean tan mancos), y estando en países del norte de Europa, aquí en España bien podrían superar esa cifra, que sitúa el refresco de las físicas en menos de lo necesario para hacerlas realistas, mucho menos de hecho, pero hagamos el calculo:
Para refrescar en cada frame tenemos la necesidad de ser capaces de pedir un dato y recibir respuesta en menos tiempo del que tardará en ejecutarse la siguiente vez nuestro código de físicas, esto supone un intervalo de 50ms como máximo entre actualizaciones, de ahi la cifra irá a menos cuanto mejor sea el juego, sabiendo que un paquete tiene que ir de ida y vuelta para poder recibir una respuesta y siendo EXTREMADAMENTE generosos con el servicio de Azure y suponiendo un solo mensaje para realizar una petición y un solo mensaje de vuelta con el resultado tenemos que necesitamos el tiempo de ping (Round Trip Time) cumplido a rajatabla sin contar con la operación en remoto (que si la difieres es compleja, no algo trivial) por lo que puedes suponer que necesitas tener una red que funcione al menos a 40ms de latencia suponiendo 10ms de ejecución en remoto. Sabiendo el ping que hay con los servicios Azure pretendes decirme que actualmente se podría hacer algo serio con esta tecnología y ademas mantener todo el trafico de una partida multiplayer por ejemplo? déjame que te lo niegue categóricamente, de hecho si esto fuera posible haría mucho que se hubiera implementado(ya que hace tiempo que tenemos latencias así y la capacidad de computo en la nube), azure no tiene nada de especial en el plano gaming y como servidores no son mejores que otros muchos, sencillamente son mas sencillos de usar y con un precio competitivo para la calidad que ofrecen...
En definitiva, hasta que no mejoren sobre todo las redes yo dudo mucho que veamos cosas significativas realizadas con esto a menos que se precalculen con mucha antelación (segundos), pero eso seria equivalente a scriptar los efectos y que se ejecuten con unas físicas pre-calculadas, para que entonces necesitas la nube?
un saludo.
Stylish escribió:Me encantaría contestar a todas las gilipolleces que has escrito porque me parece interesante contestar, pero la falta de respeto absurda, gratuita y vacía que has hecho en tus primeras líneas hacen que te ignore completamente y reporte tu mensaje. Pensando además que eres un individuo que no merece ni siquiera mi atención.
Celebro que tengas tan claro como funciona la tecnología que ni has visto, ni has entendido ni has implementado. No tengo nada que aportarte y no lo haré.
elalexel escribió:Stylish escribió:Me encantaría contestar a todas las gilipolleces que has escrito porque me parece interesante contestar, pero la falta de respeto absurda, gratuita y vacía que has hecho en tus primeras líneas hacen que te ignore completamente y reporte tu mensaje. Pensando además que eres un individuo que no merece ni siquiera mi atención.
Celebro que tengas tan claro como funciona la tecnología que ni has visto, ni has entendido ni has implementado. No tengo nada que aportarte y no lo haré.
si te parece una falta de respeto que te muestren tus carencias es que las tienes, de hecho todos las tenemos, ¿pero te has de ofender porque te digan que ignoras ciertas cosas? creo que todos podemos aprender leyendo y escuchando de los demás cuando nos dicen que nos estamos equivocando, y me encantaría que contestaras a las gilipolleces que según tu suelto, ya que no te he visto razonar ninguno de tus argumentos hasta ahora... este, como no, tampoco.
un saludo
hay cosas que son mas sensibles a la latencia que otras, y por lo tanto son mas candidatas a poderse calcular en la nube que otras.
La generacion de los graficos 3D no se puede sacar a la nube, eso lo va a tener que seguir pintando la xbox, pero hay muchas cosas mas que necesita un juego:
- IA: 200ms e incluso 300ms es aceptable para una IA decente. es mas o menos el lag que tendria un humano jugando en multiplayer. La XboxONE enviaria el estado de juego a la nube, la nube calcularia las respuestas de los PNJ (Personajes no jugadores) y enviaria la respuesta a la consola. a efectos practicos, es como si estuvieses jugando online con bots calculados en la nube.
- fisicas: hasta 500ms pueden ser aceptables. cuando disparas un cohete sobre una pared, el como se rompe la pared y vuelan los cachitos independientemente, incluso chocando entre si y con el entorno, pueden ser calculados en la nube y enviados a la consola. para la consola no son mas que otros 'objetos estaticos a pintar' en pantalla, ya que no tiene que llevar la contabilidad de la velocidad ni el efecto de la gravedad sobre ellos.
- iluminacion indirecta: hay un video muy chulo de nVidia en el cual, una latencia de 50ms es inapreciable y una de 200ms es tolerable
- iluminacion directa: esto es mas delicado, y una latencia de 50ms empieza a ser molesta.
CLOUD COMPUTING: Vaya, al parecer funciona!
Ya desvelamos que la disposición del driver de la ethernet en XBox One extrañamente va regido a través del SoC de forma directa y no a través del procesador de apoyo de componentes como en PS4 y PC.
Esto posibilita al "cerebro" de la máquina actuar con una ínfima latencia y anoche Microsoft explicó cómo con una demo técnica que muchos ya habréis visto.
Toda la geometría que entra en escena puede ser pre almacenada en la nube, "toda, es toda". Microsoft explica que cuando entras en el área del juego, solo tienen que hacer una copia del uso del ancho de banda local. la misma copia de cálculo podría ser utilizada para todos los jugadores en el caso de ser un juego cooperativo. La única cosa que se necesita enviar desde el "cliente" hacia la nube es la "posición inicial", la trayectoria y la aceleración de disparos se puede mandar con tan sólo 20bytes de información con una precisión perfecta para cada una de las balas. Para hacer un cálculo rápido, una ametralladora que dispare 10 balas por segundo necesitará que subamos con nuestra conexión 200bytes por segundo, más el ancho de banda de las cabeceras de IP inherentes para cada transferencia que son 20bytes para IPv4, 40bytes para IPv6. 240Bytes por segundo es el únido requisito neceseario para manejar y procesar el cálculo que requiere la destrucción a tiempo real de material. Eso es un ancho de banda de subida necesario insignificante, una conexión modem de 56k podría manejar eso.
https://www.youtube.com/watch?v=QxHdUDhOMyw
Los datos devueltos necesarios para el sistema local serán por norma general, mayores en volumen, pero está calculado de la misma manera. Además de la información de la bala que puede ser entendida como un vértice, es necesario enviar la geometría de la porción creada por la susodicha colisión y la rotación de la misma. Geometría del objeto, posicion inicial y aceleración centrípeta, son los únicos datos necesarios en el sistema local
Podría apostar con una sencilla regla de 3 y como aproximación un máximo de 50bytes, por lo cual en el pico del vídeo se ve que había 36000 trozos, lo cual es una auténtica barbaridad y realmente no necesaria pero lo que sería compatible con una conexión de descarga de 25 megas, si todos estos datos se transmiten al mismo tiempo. Pero esto no es necesario porque, ya que los trozos no han sido generados simultáneamente, pueden ser branqueados 10 veces por segundo. Así que partiendo de la base que no hay más de 100 trozos generados por cada centésima de segundo al mismo tiempo, una conexión que pueda enviar 10.000bytes, topes de 100ms es todo lo que requieres. Una conexión de 1Mbps bastaría facilmente para ver en tu casa la demo técnica que MS nos enseñó.
He utilizado un tiempo de respuesta de 100milisegundos ya que es un lag positivo y viable para físicas. (Probablemente tenéis menos ping en Titanfall) ya que por muy lejos que vivas del DNS y/o enrutador local, azure hace el resto. Lo normal es tener un ping hacia AZURE de un máximo de 60ms.
Horizonte de sucesos escribió:Una pregunta:
El tema de las sombras se puede calcular sin problemas en la nube no?
El sol se mueve muy despacio, así que las sombras se pueden calcular sin importar el ping que haya. Hasta con un ping de 1000ms funcionaría a la perfección. Tampoco creo que hubiera problemas con el movimiento de la vegetación para proyectar su sombra. Luego ya las sombras de focos, linternas y derivados dejárselo a la consola.
Podríamos hacer una lista de procesos que se pueden delegar a la nube sin ser nada problemáticos con las latencias. Como por ejemplo:
1- Sombras proyectadas por el sol.
2- IA
3- Físicas de la vegetación
4- Físicas de destrucción
5- Metereología
6- Iluminación indirecta
7-...
Al igual que la sombra de los personajes o elementos moviles del escenario.argam escribió:Horizonte de sucesos escribió:Una pregunta:
El tema de las sombras se puede calcular sin problemas en la nube no?
El sol se mueve muy despacio, así que las sombras se pueden calcular sin importar el ping que haya. Hasta con un ping de 1000ms funcionaría a la perfección. Tampoco creo que hubiera problemas con el movimiento de la vegetación para proyectar su sombra. Luego ya las sombras de focos, linternas y derivados dejárselo a la consola.
Podríamos hacer una lista de procesos que se pueden delegar a la nube sin ser nada problemáticos con las latencias. Como por ejemplo:
1- Sombras proyectadas por el sol.
2- IA
3- Físicas de la vegetación
4- Físicas de destrucción
5- Metereología
6- Iluminación indirecta
7-...
Bueno, si la luz del sol impactando en tu personaje proyecta una sombra, esa sombra no puede tener un retraso en ser calculada de 1 segundo, porque en ese caso iria un segundo por detras de ti
En el tema de fisicas de destruccion, como alguien ha comentado hace poco, depende de si los elementos que son destruidos pueden interactuar con tu personaje u otros personajes. Si rompes algo que te puede caer encima, pero lleva un retraso de medio segundo o un segundo, pues puede haber problemas. Imagina que empujas una roca en el borde de un precipicio. Si las fisicas se calculan en un servidor, tu puedes empujarla, pero las fisicas no haran efecto en ella hasta que recibas los datos de "la nube". Y ahi, como han dicho, igual hasta 200ms no se nota mucho, pero yo creo que 500ms se debe notar bastante.
Un saludo!
hsaoud escribió:En serio, pensar que Xbox One no va a utilizar el cloud computing para todo lo que pueda, incluído render en diferido de algunas cosas, es ridículo. Tienen una infraestructura completa muy potente para ello: Azure, tienen los mejores ingenieros de software y programadores en sus plantillas, Xbox One está diseñada para procesar de forma especialmente rápida los datos obtenidos por Ethernet (por eso va directo al SoC y no al northbridge)
En los 5 meses que llevamos hemos visto: offload de IA en la nube y servidores dedicados para multiplayers. Por otro lado nos han enseñado demos técnicas de iluminación y físicas en diferido.
No veo yo a nadie cuestionar el Playstation Now que sólo hace streamings de juegos como onLive, sin embargo a eso se le da credibilidad absoluta y nadie cuestiona que eso vaya a ser jugable a pesar del posible lag.
Creo que la comunidad tiende a poner en juicio todo lo que dice y hace Microsoft, cuando hasta ahora, cada cosa que ha hecho o planteado ha sido honesta (acertado y desacertado). Incluso para las decisiones malas han dado marcha atrás antes de implantarlas porque nos las han contado tal cual, sin trampa y sin ocultar nada (mal contado, mal expresado y mil cosas más)Nuhar escribió:Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.
El caso es que estais o estabais diciendo que hay cosas que son imposibles que darían lag y bla bla bla, y en ese video yo al menos no lo noto, y lo poco que se de animacion del poco tiempo que llevo estudiando 3D, yo diría que si que esta ayudando a calculo de físicas y a renderizar. Entonces, ¿estais equivocados (hablo en general) o en este video hay trampa?
Simplemente quiero saber como se explica lo del video.
Yo espero una aplicación de cloud computing potente para Quantum Break. De hecho pienso que las escenas que nos han enseñado en la que estalla una bomba y saltan miles de cristales, o la escena de destrucción del puente, son in-game con offload de físicas en la nube (y de ahí la reciente demo que ha enseñado MS sobre físicas en la nube)
he E3 trailer is running on a devkit powered by our brand new game engine Northlight. You can even see a glimpse of the engine logo at the beginning of Sam's and Ozz's TwitchTV segment (starts at 31 min).
I'm not an expert, but I'd guess that a devkit more powerful than the actual console would be kinda silly.
