#44 y hacer el doble de llamadas de renderizado
#60 No he dicho que no tenga usos en varios de campos, sólo digo que en lo personal y hablando aquí de videojuegos no me gusta que las compañías tiren a la realidad virtual.
#63 Pues eso que por cada camara tiene que realizar el renderizado, no renderizas la imagen y la cortas en dos. Y cada renderizado tiene sus respectivas llamadas de renderizado de los distintos objetos en pantalla renderizando practicamente todos 2 veces. Cada una de esas llamadas supone ciertos cálculos y transformaciones en el espacio para que todo se vea como debe desde esa posicion, no es una cuestion de reutilizar, por ejemplo un reflejo sera distinto visto desde 2 puntos distintos, una sombra tambien variara un poco, un destello, etc..
Que si que en Memoria puedes tener el mismo numero de elementos y el acceso a texturas y otros datos esta cacheado pero tienes que dibujarlos dos veces desde dos posiciones ligeramente distintas.
Desconozco si hay algun hack o shortcut que agilice el proceso, que algunos datos sean comunes o no para las dos camaras, pero si no lo existe el coste es significantemente mas alto que con una sola cámara.
En realidad es bastante sencillo de entender, tienes dos cámara en dos puntos distintos, esa es la cuestión. Puede parecer que por que están muy cerca una de la otra y la imagen es parecida el procesamiento es menor que si se tratara de posiciones alejadas pero en realidad practicamente dependerá de la cantidad de polígonos en pantalla y el proceso es el mismo esten las camaras pegadas o separadas. Eso si, te ahorras muchos cálculos redundantes seguro pero no creo que sean el cuello de botella.
Ya te digo eso sin conocer si han inventado algún super metodo super eficiente.
#63 Aquí he encontrado algo de info de un hack para el oculus que parece que los objetos que están muy lejos (>60m) y en los que no se aprecia el desplazamiento se reutilizan en ambos ojos
https://developer.oculusvr.com/forums/viewtopic.php?f=33&t=4155
#64 A ver, los calculos de fisica son UNICOS por frame (1 frame incluye las 2 mitades) y son los que dicen en q posicion esta cada objecto. Luego se pide que se renderize 960x1080p desde un origen y en una direcion con un FOV dado y despues se pedire que renderize otros 960x1080p desde otro origen y direcion y el mismo FOV.
Tienes razon que habra que doblar los calculos de reflejos pero las sombras son las mismas independientemente del punto de vista, ergo, solo hay que hacer los calculos de sombra 1 vez. Claro que habra que hacer calculos previos para saber de donde hasta donde tienen que calcular las sombras (eso ya entra en optimizacion de motor grafico), pero suponiendo el mismo grado de optimizacion, el rendimiento deberian ser SIMILAR.
#66 Si fisicas van aparte normalmente en otro thread. Las sombras puede que tengas razon.
Lo que yo me refiero es a las render/draw calls, renderizas dos veces la escena aunque reutilices algunas cosas, eso tiene un impacto de entre 10% al 50%. Eso quiere decir que es posible incluso acabar con la mitad de fps con visión stereoscopica. Tu calculas la sombra y toda la iluminacion en el espacio 3d pero tienes que transformar y dibujar en el espacio de la camara
Aqui hay algo mas de informacion y parece que hablan de los distintos metodos de renderizar en 3d stereoscopico: http://developer.download.nvidia.com/whitepapers/2010/3D_Vision_Best_Practices_Guide.pdf
Si buscas como estoy haciendo veras que la gente asegura el 3d stereoscopico tiene un impacto en el rendimiento en PC en juegos o demos que prueban, no es que me lo este inventando. En PS4 pasara lo mismo y por algún lado habrá que cortar: o dejarlo a menos fps pero aun a un decente framerate o reducir en poligonos o suavizados, etc. Eso no quiere decir que aun asi no sea capaza de correr juegos increíbles a nivel gráfico pero el limite se tendrá que rebajar.
Fuentes:
https://forums.geforce.com/default/topic/535572/test-drive-unlimited-2-severe-performance-drop-in-3d-vision/
https://forums.geforce.com/default/topic/497645/lower-fps-with-3d-vision-enabled-fps-drops-by-about-50-when-enabled/
https://forums.geforce.com/default/topic/464789/performance-hit-with-3d-vision-vs-3d-vision-discover/
http://3dvision-blog.com/forum/viewtopic.php?f=9&t=1923
https://developer.oculusvr.com/forums/viewtopic.php?f=26&t=5568
#67 Ojo que ese documento de nvidia es de Estereoscopía 3D en el que renderizas 2 frames completos y luego tienes unas gafas para diferenciar los frames - siendo en el caso de nvidia gafas con shutters que sincronizan con la tele. En ese 3D, obtener 60 fps REALES necesita que tengas 120 fps (o, lo que es casi lo mismo, 60 fps de 3840x1080p - digo casi porque los 2 frames son enviados con 8 ms de diferencia mientras que en el caso de VR ambos frames son enviados al mismo tiempo, ya que los unen en un mismo frame).
Si el impacto entre 2D normal y lo que tu hablas es de 1050%, el impacto en VR sera de 1050% teniendo en cuenta que la imagen 2D seria en 960x1080.
Entiendes la diferencia?
#69 Pero no hablo de eso compi, o creo que no nos entendemos. Si la resolucion puede importar algo a la hora de renderizar pero que tienes que renderizar dos cámaras una para cada ojo o hacer hacks para mostrar un 3D que no es del todo completamente fiel perdiendo por ejemplo el 3d en los objetos muy lejanos.
Da igual que al final la imagen la muestres en una sola pantalla separada por la mitad, has renderizado la escena desde dos posiciones distintas en el espacio 3D y eso conlleva un coste por las transformacion entre los distintos espacios (del world space al de la camara), que no todo es fisica o sombras o numero de pixels
Si en una escena tienes 100 poligonos, estas renderizando 200 aunque los metas en menor resolución.
Pero bueno no se igual hasta me estoy equivocando XD
#70 Mira vamos a decirlo de otro modo:
Tienes el juego a 1920x1080 y luego tienes el juego en 960x1080. El juego en 960x1080 NO tendra el doble de fps porque habria que hacer el doble de calculos de fisica (en los que se incluye sombras e iluminacion) PERO al tener 2 frames consecutivos que son en el mismo tiempo se puede ahorrar la MAYORIA de los calculos de fisica para el segundo frame por lo que el framerate en 960x1080 CUANDO se ahorra esos calculos de fisica seria cerca del doble - no va a ser el doble porque no todos los calculos de fisica son validos para ambos frames.
Para nvidia 3d vision estas usando 1920x1080@120hz y para VR estas usando 1920x1080@60.
Olvidate de que son 2 prespectivas diferentes, las sombras tambien requieren que renderizes el frame desde 1 prespectiva diferente y no por eso un juego sin sombras te va al doble de fps que un juego con sombras.
pd: Si doblaras los poligonos solo por calcular las sombras, noveas.
#71 Creo que seguimos sin entendernos pero bueno es normal. yo me remito a la informacion no solo del nvidia 3d visión pero también del oculus y al final dependera del software (por ejemplo CryEngine usa un hack para la vision stereoscopica donde clona el frame y utiliza informacion adicional para transformarlo y el rendimiento es solo 1-2% menor por lo que puedo leer "they don't render two separate perspectives but rather clone one frame and take the already existing depth information from the GPU's back buffer to manipulate the view shift.").
Tu sigues hablándome de sombras, físicas o resolución y yo intento hablarte del proceso de dibujar una escena 3D desde dos puntos distintos.
No es que dobles los poligonos, es que los dibujas 2 veces.
Olvidate de sombras o fisicas por un momento: Imaginate un cubo estatico con una sola luz incidiendo, no hay sombras activas ni nada mas en la escena, tienes 2 cámaras. Tendrás que dibujar el cubo dos veces, una desde cada perspectiva no?
Ahora imaginate que en vez de un cubo tienes 2. El thread de dibujo llamara para la camara A a la funcion de dibujado del cubo 1 y luego del cubo 2, y después para la cámara B hará las mismas llamada. Tienes 4 llamadas a draw, ese metodo o funcion puede ser muy rapido (quiza 1ms) pero nunca es 0.
Vale imagínate que yo decido dibujar tantos cubos como sea posible hasta llegar al limite minimo de 30 fps, eso quiere decir que si por ejemplo tardo 2ms en ejecutar draw de un cubo, tengo que llamarlo como maximo 16,6 (si no me fallan las matematicas) o lo que es lo mismo dibujar 16,6 cubos simultaneamente. Vale ahora imaginate que tengo 2 camaras... puedo decidir dibujar la mitad de cubos en pantalla y mantener 30 fps o las 16,6 llamadas a draw o puedo llamar 16.6x2 y afectar al framerate. Ves a donde quiero llegar?
Es un ejemplo muy básico y seguramente en un juego grande el cuello de botella no este ahi y hay muchos mas factores pero el concepto es el mismo.
#72 Pero es que no es asi que funciona. El ordenador dibuja el espacio tridimensional y despues dibuja una serie de vectories que pasan desde el origen. Normalmente hay 1 origen y tantos vectores como pixeles. En este caso la cantidad de vectores es el mismo pero el origen es otro.
Y las sombras se calculan igual, si es sombras en calidad alto cojen tantos vectores desde el foco de luz como pixeles tengas, si es en medio cojen 1/4 de los vectores y si es en bajo cojen 1/16 de los vectores.
No estas dibujando mas poligonos por cada origen que tomes.
Es lo mismo que me digas que tienes que dibujar 3 triangulos iguales para saber la distancia que tiene cada lado.
#73 Si pero no... yo también recuerdo haberlo hecho así (raytracing) en la asignatura de computer graphics pero creo recordar que el rendimiento es pobre si tienes que calcular para cada pixel un ray desde el origen y comprobar si colisiona con un objeto, hoy en dia creo que se usan otros métodos pero igual me equivoco y estoy metiendo la pata
Pero no importa, a lo que voy es que tu "lanzas" un ray desde el pixel 0,0 por ejemplo. Una vez colisiona ese vector con el cubo, tendrás que leer la textura del cubo + calcular la transformación para que ese pixel coja el color que corresponde con respecto a la posición desde la que miras y la posición del objeto. Eso varia completamente según la posición, si tienes dos ojos (o camaras) para el vector 0,0 tendrás distintos colores y tendrás que calcularlos por separado en cada frame. Por lo tanto si tienes un cubo y es visible desde las dos camaras, cada camara tendra que calcular el color de sus pixeles y ese proceso requiere:
Comprobar colisión desde esa posición.
Si colisiona con el cubo:
---> leer textura + transformar
Y el numero de llamadas depende del numero de objetos visibles en escena y no de pixeles (al menos si tienes una resolución minimamente decente que un cubo no ocupe un pixel) si acaso mas bien del fov.
Yo me voy a basar en mi experiencia en Unity3D donde por cada cada objeto que hay en escena (visible) se hace una llamada a Draw y aunque ese objeto sea una misma mesh pero tenga 2 texturas distintas (que no estan en el mismo fichero) se realizan 2 llamadas a Draw para el mismo objeto y por cada camara y frame. Por eso si tienes una mesh con muchas mini texturas en distintos archivos es menos eficiente que si tienes una textura mas grande que incluye las mini y haces unwrap
Por eso si tienes un cubo y dos cámaras dibujas el cubo dos veces aunque luego lo quieras meter todo en 40x20, aunque por cada cámara haya un espacio de 20x20 tu estas dibujando el numero de cubos que hay en la escena 2 veces y metiendolo en ese cuadradito tan pequeño.. Y eso en el caso sencillo, imaginate que ese cubo tiene transparencia o refracción o algún tipo de bump...
Lo de las sombras yo sigo sin creer que es tan fácil del todo, pero no por que no te quiera creer, es que ya he experimentado problemas con sombras dinámicas en Unity en modo 3d stereo y tenias que desactivarlas por los artifacts que aparecian pero puede ser cosa de Unity. Ej: http://forum.iz3d.com/viewtopic.php?p=25871&sid=0ab25126b6225a2ba199ceec6f8f6336
Y con este tocho lo dejo aquí, yo estoy convencido de que afecta al rendimiento, igual que afecta oculus u otros sistemas aunque hagas render SBS pero bueno ya lo veremos en un futuro o quizás no lo notemos quien sabe.
Pues... parece que la prensa está encantada con el trasto, ahora falta ver si Sony no se columpia con el precio, no hacen un downgrade de la ostia (clásico ya estos días), y así termina siendo un VR low budget para iniciarse en el mundo de las VR y de paso le hace una publicidad inmensa a OR, algo que sin duda saldremos ganando todos.
#78 Cuando jueges a Infamous, hablamos de downgrade por parte de Sony.
(Clasico de estos dias..)
#79 Nada más faltaba que Infamous recibiera un downgrade, ni que fuera algo nunca antes visto xD. Te veo tan sonyer, que se te ha borrado la mente.
#80 Y a ti te veo muy hater con Sony sin motivo.
Tu mismo acabas de decir que la prensa esta encantada y hablas de downgrade cuando por parte de Sony todavia no hemos visto ningun downgrade.
#81 El dowgrande es general, no he dicho que sea parte de Sony, es un comentario generalista sin más. Te veo muy afectado.
Yo también pago las mensualidades de Sony, pero no me pongo la venda como un kassie de la vida tio.
#82 No, el downgrade es de estudios incompetentes, que venden algo que no pueden ofrecer sin ni siquiera acercarse a ello.
Pero lo que es Sony Computer Enterteiment 10/10.
Tiene pinta de ser el tipico periferico que compras por novedad y luego lo dejas tirado pillando polvo, a 30 fps que iran muchos juegos no se yo si el invento ira bien
#86 Nah no van a ir a 30 fps eso seguro. La calidad grafica no se cual sera pero a menos de 60 fps te hace vomitar. Asi que por suerte los juegos que saquen deberan estar preparados desde el principio para ser compatibles.
#87 el problema es que si el aparato necesitara sus propios juegos sera como el eye toy o la pistola de la ps2, cacharos muy chulis pero aparte de un par de juegos buenos mal contados nada, teniendo en cuenta la resolucion y los fps de los juegos de ps4 dudo que los grandes juegos puedan usarlas sin que den mareos y demas problemas, mas que un competidor de oculus terminara siendo un periferico mas como el move
