Saturn es mas potente en 2D que Dreamcast?

A-Jensen escribió:@radorn Yo hablo de wire frame real, en un plano 3D con poligonos que se puedan texturizar como lo es PSX, Saturn, N64, etc, independientemente de como sea mapeado.

Lo único que falta es que me tergiverses diciendo que hacer un triangulo en una cartulina es un juego 3d... Madre mia...

Vas a tener que definir a qué llamas tu "wire frame real" para explicarme por qué los wireframes de Elite en, por ejemplo un ZX Spectrum o un BBC Micro no son "reales" y darme ejemplos de wireframes que si sean "reales". ¿Os dais cuenta de que nada de lo que estamos hablando aquí es "real"?

A lo de la cartulina no te respondo porque sinceramente no se de donde te lo sacas ni qué intentas decirme con ello.
Y no es por malmeter, pero ¿te das cuenta de la contradicción que supone decir "plano 3D"?

@EMaDeLoC No acepto tu comparación entre lo que yo he explicado y llamar "foto" a un cuadro por ser, supuestamente, tan fotorealista que se vuelva indistinguible de una fotografía.

La definición de fotografía excluye cualquier forma de gráfico sintetizado. Tiene que provenir de la captura de rayos de luz reflejados por un objeto del mundo real. Luego sobre esa fotografía se pueden aplicar diversas técnicas de manipulación o retoque, o "photoshop", momento en el cual hay que especificar si esas manipulaciones se han realizado sobre la captura original.

Un renderizado de gráficos 3D por ordenador es algo sintético por definición, una rejilla de pixels con valores de color obtenidos a partir del mapeo de una serie de elementos gráficos en una rejilla poligonal transformada en perspectiva. Insisto que no encuentro ningún motivo de peso para hacer una diferenciación entre "3D" o "no 3D" por el método usado para rellenar esas "celdillas" con valores de color, porque, desde un punto de vista práctico, esa es la diferencia entre los "sprites" de saturn y su capacidad para ser mapeados en función de una rejilla 3D transformada a perspectiva, y los mas ortodoxos triángulos de PS1 o N64.

Los sprites de Saturn nacieron con la INTENCIÓN de ser usados para juegos 2D y sus capacidades fueron optimizadas para ese uso, pero luego encontraron la forma de adaptar ese método para rellenar de pixels una rejilla aleatoria de cuadros proyectados en un plano obtenidos de la transformación de una rejilla 3D. Los triángulos de PS1 y N64 fueron diseñados para su uso en este tipo de situaciones desde el principio, y sin duda están mejor diseñados para esa tarea.
Pero, como ya he dicho antes, y va la tercera o cuarta, llegados a este punto del proceso, AMBAS SITUACIONES son 2D: Un framebuffer es una superficie 2D, yl os elementos primarios que se dibujan sobre este son polígonos 2D, por mucho que provengan de un cálculo de transformación 3D, y encierran una zona específica de ese framebuffer entre 3 o 4 aristas, y otro proceso rellena los pixels esa zona con valores de color provenientes de un bitmap o otra instrucción de color (flat, gouraud, etc). La correción de perspectiva o cualquier otro refinamiento, son un método para simular tridimensionalidad en un plano bidimensional, pero no son "3D", ni el mayor refinamiento de uno justifica llamar al otro "2D".

La forma en que comparas mi equiparación entre métodos de rellenado de pixels con llamar "fotografía" a un cuadro por ser "muy realista" es falaz. Ni N64 ni PS1 son fotografía siendo Saturn un cuadro. Precisamente lo que yo digo es que TODAS SON CUADROS. No hay diferencia en esencial entre un método y otro de rellenar de pixels una celdilla de un framebuffer. Las diferencias entre los métodos de PS1, N64 y Saturn son de refinamiento y adecuación al uso pretendido. Has perdido perspectiva obcecándote con llamar sprite al método de Saturn como si eso lo convirtiese en algo esencialmente diferente a lo que hacen un polígono. Al final todos ellos hacen "lo mismo": Rellenar de píxels un área aleatoria de una pantalla BIDIMENSIONAL. Acuarela, óleo, cera, lapiz, tinta, un sello, un aerógrafo...

@SuperPadLand @EMaDeLoC He leído los cuatro, son muy buenos, aunque, sobre todo los de David Gamiz, son bastante técnicos. A grandes rasgos te quedas con la enorme (e innecesaria) complejidad de Saturn, lo cual conlleva una dificultad adicional para programarla, sumada a la poca ayuda prestada por SEGA sobre todo al principio. Y efectivamente, para mi también, que no es una máquina 3D pura y lo más increíble que es que al final funcione y de buenos resultados.
En los artículos de David, destaca juegos que sobresalen en diversos apartados y apunta formas de mejorarlos para intentar llegar a los niveles de PS1. Me los voy a leer otra vez, por que al final me resulta muy curioso el cómo iluminar y/o sombrear un sprite. También me interesa saber la capacidad final a la hora de mover Sprites de Saturn. Puesto que siempre se la cita como una bestia 2D y por lo visto no llega al nivel del system24 y PS1 podría estar muy, muy cerquita (siempre que obviemos los planos que es capaz de mover el VDP2).

Un saludo, menos crispación chicos, que esto es un foro en el que aportar.

radorn escribió:La definición de fotografía excluye cualquier forma de gráfico sintetizado. Tiene que provenir de la captura de rayos de luz reflejados por un objeto del mundo real. Luego sobre esa fotografía se pueden aplicar diversas técnicas de manipulación o retoque, o "photoshop", momento en el cual hay que especificar si esas manipulaciones se han realizado sobre la captura original.

Fíjate que es lo que he dicho:

EMaDeLoC escribió:Por tus argumentos y dado que el resultado es lo bastante fiel a lo que sería una foto, habría que llamarlo "foto"... Pero no deja de ser un dibujo.

Lo que quiero decir es que efectivamente lo que vemos de un juego de Saturn como Sega Rally es un 3D convincente, pero no esta dibujado con técnicas 3D sino 2D. El resultado es muy bueno, por supuesto, pero sigue siendo 2D.
Espero que así se entienda lo que quiero decir.

Y fíjate en lo que me dices tú:

radorn escribió:Pero, como ya he dicho antes, y va la tercera o cuarta, llegados a este punto del proceso, AMBAS SITUACIONES son 2D: Un framebuffer es una superficie 2D, yl os elementos primarios que se dibujan sobre este son polígonos 2D, por mucho que provengan de un cálculo de transformación 3D, y encierran una zona específica de ese framebuffer entre 3 o 4 aristas, y otro proceso rellena los pixels esa zona con valores de color provenientes de un bitmap o otra instrucción de color (flat, gouraud, etc). La correción de perspectiva o cualquier otro refinamiento, son un método para simular tridimensionalidad en un plano bidimensional, pero no son "3D", ni el mayor refinamiento de uno justifica llamar al otro "2D".

Resulta un poco contradictorio que especifiques qué debe ser foto... Pero el concepto 3D sea lo bastante amplio como para agrupar técnicas 2D que imiten 3D. O que ambas situaciones son 2D por el framebuffer y sin embargo ambas sean 3D aunque una use técnicas meramente de 2D...
Es decir, yo entiendo perfectamente que no partimos de un "3D real", que el framebuffer es un superficie 2D donde dibujamos unos elementos para obtener una sensación tridimensional. Lo que yo digo es que no es lo mismo una técnica que otra. No es lo mismo un sprite deformado que un triángulo en un espacio tridimensional. No es lo mismo hacer una foto que un dibujo hiperrealista. No es lo mismo una acuarela que un oleo... Aunque en todas las situaciones obtengamos un buen dibujo tridimensional.
Yo no niego en ningún momento que el resultado final no sea bueno. No es perfecto, pero el 3D de PS1 o N64 tampoco lo es. Lo que digo es que esta dibujado usando 2D con esteroides en vez de un 3D básico.
Y tranqui, que yo entiendo tu punto de vista, solo es que no lo comparto.

Otro trocito de vídeo explicando la diferencia entre rasterizar un triángulo tridimensional y pintar un sprite deformado:


Explica perfectamente el bajo rendimiento de la Saturn al pintar repetidas veces el mismo pixel, repitiendo los accesos a memoria (acceder a píxeles individuales en memoria supone un coste alto de rendimiento).

@sgonzalez Tal vez no llegue al system24, pero en 2D no deja de ser impresionante lo que hace:

@EMaDeLoC

Sin duda está bastante por debajo del system 32 por lo que veo:



Ya sé que la versión de Saturn tiene coches poligonales (unos pocos sprites más en pantalla), pero es que la recreativa casi tiene el doble de distancia de dibujado. Por eso os comentaba que PS1 igual podría quedarse muy cerquita de las capacidades 2D de Saturn, siempre que se obvie el VDP2 para manejar planos.

El System 32 le da mil vueltas a Saturn en lo que a 2D se refiere, infinito numero de sprites en pantalla, rotaciones de color sin cambiar la paleta, transparencias, efectos de zoom, scaling y rotacion, multiples resoluciones de pantalla, etc etc...o sea, el paquete completo, mientras sea 2D system 32 puede hacerlo todo.

@sgonzalez Bueno, fue de los primeros juegos en salir en la Saturn, no estaría del todo optimizado. Con Daytona USA sacaron versión mejorada.
Pasa en todas las consolas. De los primeros a los últimos títulos de PS1 y N64 hay un buen salto de optimización.
Lo que quiero decir es que la versión de consola no tiene porqué ser un ejemplo de la diferencia de rendimiento entre Saturn y system32.

Puede que en realidad Sega pensase más en el 3D que en el 2D a partir de Mega CD, porque hace un tiempo leí una review del 32X en ese sentido, y resulta que en gráficos 2D es un addon un poco decepcionante para lo que se podría esperar (o al menos para lo que yo presuponía), y al margen de Doom, sus otros 3 juegos clave son poligonales.

Otra cosa es que Sega se quedase algo corta con Saturn frente a PSX en algunos aspectos, y sobre todo frente al model 2, en este último caso aun después de añadir la segunda cpu; pero el propósito 3D poligonal parece más o menos claro.

yo diria que saturn es mas compleja que dreamcast en arquitectura de hardware.

no entiendo negar a estas alturas que sega diseño saturn pensando mucho mas en juegos 3D que 2D. 3D era el tren al que habia que subirse y 2D era "lo que se venia haciendo desde hace años" y en ese momento no se le veia mas recorrido que el que ya habia tenido (lo cual se demostró erroneo, pero qué sabiamos todos en 1994).

y a ese tren se subieron todos. sega, nintendo, los fabricantes para componentes de PC... todos.

de hecho el predominio actual de fabricantes como sony o nvidia, viene de ahi.

A veces me pregunto si Sega estaba al tanto de la revoluciòn que fue Quake, creo que no, siendo un juego occidental, y un fps...para IBM PC en principio.....Mac despues, 2 plataformas que no tenían mucha gravitación en el mercado de juegos de Japón,

aunque Saturn llego antes, y viendo el exito que tenian sus arcades tridimensionales, debieron haberlo previsto, debieron haber licenciado el NV1 para acoplarlo a Saturn.

Y es que para mi el dilema que Sega tenia en ese momento era que no tenian ningun hardware economico con buen rendimiento en 3D para adaptar a una consola de sobremesa, STV aparecia como su unica opción, y Model 2 era carisimo de producir, luego con Dreamcast casi cometen el mismo error, si bien Naomi era bastante mas economico debieron haber esperado y haber llevado Naomi 2 a consola en lugar de Naomi 1.

Sega Rally es tan 3D como Rige Racer.

Bueno, en cualquier caso el título del hilo es si es más compleja en 2D que DC y lo que estamos hablando al final es que es más compleja para el 3D que sus contemporaneas. Por cierto, creo que ya ha regresado él que se inmoló.

@EMaDeLoC A ver, no me tergiverses. Lo de foto y pintura lo has sacado tu. Has querido "pintar" mi argumento como que yo estoy diciendo que "si parece una foto es una foto, porque la técnica no importa", y para ello has sacado lo de la foto y el cuadro fotorealista. Pero eso representa lo que estoy diciendo. Yo no me he contradicho.
Si explico lo que es una foto es porque para que algo sea una foto, la técnica de obtención es el elemento definitorio.
En gráficos sintéticos por ordenador la historia es muy diferente y esa analogía no es aplicable. Por eso mi conclusión es que TODO es pintura, y lo único que cambia es la técnica para rellenar los huecos, y por eso me da igual si los huecos se rellenan con cuadrados rotados y deformados sin UVs y demás, o con triángulos con corrección de perspectiva por calculo de "normales" y otra serie de refinamientos necesarios para SIMULAR un aspecto tridimensional correcto.

Tu hablas de "técnicas meramente 2D", pero es que, como ya me he aburrido de explicar, llegado el momento de rellenar con valores de color los píxels del framebuffer, TODAS lo hacen en un entorno que es totalmente 2D. La fase 3D fue antes. Ahora, una vez el triángulo o quad ya ha sido proyectado sobre las coordenadas de pantalla, ya es todo 2D. El rasterizador de triángulos de PS1 y N64 es 2D. Lo que hay son "metadatos" procedentes del paso anterior que INFORMAN de cómo se ha de deformar la textura para mejorar el ASPECTO tridimensional de la proyeccíón de la textura sobre el hueco correspondiente en pantalla. NADA MAS. No hay NADA tridimensional en esta parte del proceso. Esos "metadatos" (valores Z, normales, y posiblemente alguna cosa mas) obtenidos de la fase de transformación de coordenadas, perfectamente pueden ser proporcionados a partir de una escena 2D para obtener efectos interesantes dependiendo de la creatividad o habilidad técnica. Pero, INSISTO, el proceso de rasterización de estos elementos primarios (primitives: tris, quads) es siempre BIDIMENSIONAL... ¿porque? porque el entorno en el que se realiza, la pantalla o framebuffer, es BIDIMENSIONAL.
Los triangulos o quads son 3D en la fase de transformación, una vez transformados son proyectados sobre una rejilla bidimensional correspondiente al framebuffer, y ya dejan de ser 3D, y esto vale para Saturn igual que para PS1 y N64 y básicamente cualquier sistema 3D convencional, y no veo cómo va a cambiar eso mientras sigamos usando pantallas bidimensionales para proyectar los gráficos por ordenador.

Y hablo de esto precisamente:

EMaDeLoC escribió:Lo que yo digo es que no es lo mismo una técnica que otra. No es lo mismo un sprite deformado que un triángulo en un espacio tridimensional.

En la fase de rasterización, ese triangulo YA NO está en un espacio tridimensional. Eso fue antes.
La rasterización o pintado/rellenado/fill, de un triángulo en pantalla es un proceso tan bidimensional como un sprite. Lo único que cambia es que es una técnica mas avanzada y flexible: triángulos en vez de quads, coordenadas UV para la textura, normales y valores Z para la corrección de perspectiva, iluminación por vértices... Y muchas de estas técnicas podrían perfectamente haberse implementado en un sprite clásico, pero supongo que no vieron que fuese una inversión de tiempo, esfuerzo y dinero que mereciese la pena en ese terreno.

EMaDeLoC escribió:Lo que digo es que esta dibujado usando 2D con esteroides en vez de un 3D básico.

Nuevamente, no, el rasterizado de triángulos es tan 2D como el dibujado de sprites.

EMaDeLoC escribió:Y tranqui, que yo entiendo tu punto de vista, solo es que no lo comparto.

Lamento decirte que no. Cuando insistes en atribuirle tridimensionalidad a los triángulos durante la fase de rasterizado, análoga, y equivalente (salvando las diferencias de refinamiento), a la del dibujado de un sprite, me demuestras que no entiendes lo que estoy diciendo.

Y si me equivoco en algo de lo que estoy diciendo, y en la interpretación que le doy, que alguien me explique bién cual es mi error. Pero es que simplemente hablar de "sprites 2D" y "triangulos 3D" ni explica nada ni es a mi parecer correcto, a la luz de lo que he explicado sobre el proceso de rasterizado.

Por todo ello, vuelvo a insistir, que la Saturn no es menos 3D que PS1 o N64. Simplemente tiene un proceso de rasterizado menos avanzado y moderno, pero dado que todas tienen un proceso de transformación geométrica 3D, proyección a 2D, y rasterizado/rellenado en ese dominio, no veo ningun motivo de peso para decir que Saturn es "menos 3D" simplemente porque la técnica usada para rellenar de valores de color los píxels de un área geométrica de una pantalla BIDIMENSIONAL sea mas parecida a un sprite clásico que un triángulo moderno. AMBOS son 2D llegados a ese punto. Me repito porque creo que es importante hacerlo vista la insistencia que veo en afirmar lo contrario.

radorn escribió:

EMaDeLoC escribió:Y tranqui, que yo entiendo tu punto de vista, solo es que no lo comparto.

Lamento decirte que no. Cuando insistes en atribuirle tridimensionalidad a los triángulos durante la fase de rasterizado, análoga, y equivalente (salvando las diferencias de refinamiento), a la del dibujado de un sprite, me demuestras que no entiendes lo que estoy diciendo.

Si, te entiendo perfectamente. El que no me entiende eres tú: la rasterización del triángulo implica usar algoritmos que tengan en cuenta los 3 ejes de coordenadas para calcular la posición de cada pixel del triángulo o de la textura. El sprite en cambio solo deforma la imagen para meterla en la región que se ha especificado.

Pero en fin, veo que empiezas a tomartelo a la tremenda y mejor paro. Desde luego no es mi intención tergiversar tus palabras de ninguna manera, pero resulta confuso defender el 3D basandote en que el uso de frame buffer es 2D como el de PS1 o N64... Y yo no voy por ahí, por lo que se dibuja en el frame buffer, ahí se guarda el resultado, no es el proceso en sí ni los diferentes algoritmos de cada método.
Aparte, esto ya entra en un bucle sin fin. A ti te parece que la Saturn es 3D completo y yo digo que no. Pues ya esta, cada uno con su opinión.

@EMaDeLoC Es que tu crees que el triángulo sigue estándo en 3D cuando el rasterizador lo procesa y no es así.
Tu crees que todo queda reducido a 2D solo cuando queda pintado en el framebuffer, pero lo cierto es que la bidimensionalización es anterior.
Antes de ser calculados los valores del color, el triángulo ya ha dejado de estar representado por coordenadas en un espacio 3D para estar representado por un sistema de coordenadas 2D análogo al del framebuffer, y esto es con lo que trabaja el rasterizador para ir pixel por pixel para calcular el color.
El rasterizador puede tener "pistas" o metadatos asociados a la superficie en su totalidad, los vértices o incluso los pixels individuales: Hablo de valores Z, normales, y otras virguerías en sistemas mas avanzados. Pero ese triángulo o quad ya ha dejado de ser 3D ANTES incluso de ser pintado.
Es por eso que digo que me da igual la técnica de rellenado, porque llegados al paso anterior al coloreado, ya es todo 2D.
No queda reducido a 2D solo cuando queda pintado en el framebuffer, si no que ya lo es ANTES.

¿entonces,die hard arcade,sega rally,nights,burning rangers,panzer dragoon saga....no son juegos en 3d?

@crazy2k4 Si me lo preguntas a mí, te responderé que SÍ, son 3D. Tan 3D como cualquier otro juego 3D de cualquier otra plataforma contemporánea.
Si le preguntas a otros, pues te dirán que en geometría si, pero en renderizado no... pero, huelga decir a estas alturas, que esa es una apreciación que no comparto.

crazy2k4 escribió:¿entonces,die hard arcade,sega rally,nights,burning rangers,panzer dragoon saga....no son juegos en 3d?

Es irónico que el Burning Rangers luzca un buen entorno 3D, pero en cambio los efectos de agua no parecen muy destacables.

radorn escribió:Tu crees que todo queda reducido a 2D solo cuando queda pintado en el framebuffer, pero lo cierto es que la bidimensionalización es anterior.
Antes de ser calculados los valores del color, el triángulo ya ha dejado de estar representado por coordenadas en un espacio 3D para estar representado por un sistema de coordenadas 2D análogo al del framebuffer, y esto es con lo que trabaja el rasterizador para ir pixel por pixel para calcular el color.
El rasterizador puede tener "pistas" o metadatos asociados a la superficie en su totalidad, los vértices o incluso los pixels individuales: Hablo de valores Z, normales, y otras virguerías en sistemas mas avanzados. Pero ese triángulo o quad ya ha dejado de ser 3D ANTES incluso de ser pintado.

Eemmm... Nop. El triángulo sigue siendo 3D, es el rasterizador el que lo convierte en 2D y de ahí al frame buffer (por eso es un rasterizador). El proceso no se realiza antes. Por eso una aceleradora 3D es una aceleradora 3D: le pasas la geometría, las texturas asociadas a cada superficie y ella se encarga de la conversión a 2D. Si el proceso se hiciera antes la aceleradora recibiría solo información bidimensional de formas y lo que hay que pintar dentro... Que no es por hacer la coña pero es muy parecido a lo que sería un motor de sprites. Y claro, no trabajan así.
Piensa por ejemplo en como al RCP de la N64 se le pasa la geometría y las texturas y te devuelve el frame buffer y el z-buffer. El z-buffer es una escala de grises de la profundidad de cada pixel del framebuffer. Esa información se tiene que calcular a partir de geometría, no puedes calcularla de objetos bidimensionales. Si el RCP trabajase como dices tú se le pasaría directamente unos triángulos bidimensionales, unas texturas y un z-buffer, y eso no ocurre.
Contrasta eso por otro medio, que me parece que va por ahí tu confusión. Yo tampoco he sabido explicarme bien.

crazy2k4 escribió:¿entonces,die hard arcade,sega rally,nights,burning rangers,panzer dragoon saga....no son juegos en 3d?

Son 3D de forma interna, pero los gráficos se dibujan mediante técnicas avanzadas sobre sprites, que son fundamentalmente en 2D.
Que no se te caiga el mundo por eso, solo se trata de la forma en que trabaja la consola en una parte del proceso. Lo importante es que el juego sea bueno y se vea bien.

Para ver si puedo arrojar un poco de luz al asunto y no desmerecer a nadie quiero entender que lo que dice @EMaDeLoC es que las técnicas para rasterizar en Saturn no se pueden considerar 3D ya que un sprite es siempre 2D y lo que hace es la consola es deformarla para simular ser tridimencional.

¿Que más dará que internamente la Saturn no sea una máquina 3D? Si con sprites es capaz de mostrar entornos tridimensionales y darnos su correspondiente jugabilidad yo me doy por contento ¿Es qué no alcanza con eso? Yo lo considero todo un logro de cómo se supo aprovechar y si no salieron más juegos y cesó antes de tiempo no fue culpa de eso, al menos en exclusiva. Sega tenía muy dañado su nombre y Sony la clavó en aquella época, incluso Nintendo lo pagó en sus carnes.

Gracias @EMaDeLoC por tan fantásticas explicaciones.

@EMaDeLoC No. Confundes que el paso de 3D a 2D previo al rasterizado no tenga que ser explicitado en el motor, con que el rasterizador, o la parte del mismo que produce los pixels, no haga un paso previo de 3D a 2D ANTES de pintar los píxels.
El proceso se hace, incluso si en una implementación este queda oculto y se suma todo en una unica "pincelada" de cara al programador.
Antes de pintar, el triangulo o quad 3D deja de estar en coordenadas tridimensionales a ser una simple forma vectorizada en dos dimensiones. Y sin ese paso previo, no se puede pintar un solo pixel, ni un wireframe ni nada.
El paso puede quedar ocultado, pero está ahí. Todos los rasterizadores lo hacen.

En el caso de N64 que mencionas, primero mandas la geometría y texturas en forma de displaylists y uno de los primeros pasos es la transformación de coordenadas de modelo a coordenadas de camara teniendo en cuenta la rotación deformación y animaciones de los distintos modelos. Una vez hecho eso, se producen los comandos de dibujo para el RDP, y si, este, primeramente, toma triangulos que aún son 3D, y de ahí deriva el Z-buffer y las normales de los vértices, y con esta inforamción es capaz de generar los triangulos vectorizados en 2D sobre una rejilla de coordenadas análogas a las del framebuffer, que, entonces y solo entonces, pueden ser rellenados con los colores de la textura.

Aunque el paso quede oculto, está ahí. En el momento de pintar, todo es ya 2D, y por eso digo que es irrelevante separar a la Saturn en este aspecto.

Esto es como el modelo de red de siete capas OSI. TODOS los sistemas de red tienen o pueden ser explicados en función de esas 7 capas, aunque no las incluyan explícitamente de forma accesible por el usuario ni el programador, si no que algunas pueden quedar enterradas o relegadas a un proceso interno opaco. Eso no quiere decir que no estén ahí de una forma u otra.

Repito, EN TODO RENDERIZADOR 3D, al menos los de esa época y hasta hace muy poco, llega un punto en que el triángulo o quad no es mas que un vector 2D que ha de ser rellenado con colores. En ese sentido, que saturn lo haga con cuadrilateros sin UV, sin corrección de perspectiva y sin normales y sin muchas otras cosas, me parece irrelevante como para decir que sus graficos no son "3D" o solo a medias.

EDITO: Para resumir y con la nueva parte. Todas las consolas pintan pixels sobre figuras geométricas que ya están en 2D. En unos sistemas este paso queda automatizado porque ese paso de 3D a 2D lo hace el hardware o una librería, y, en otras lo tiene que que hacer el programador del motor gráfico. Al final el paso se hace, de un modo u otro. Definir la tridimensionalidad o no de los gráficos por la parte que queda expuesta al programador desvirtua la verdadera naturaleza del proceso.

crazy2k4 escribió:¿entonces,die hard arcade,sega rally,nights,burning rangers,panzer dragoon saga....no son juegos en 3d?

Lo son, pero logran el efecto 3D mediante técnicas 2D al igual que Doom o Super Mario Kart. Evidentemente Saturn lo hace muchísimo mejor que esos dos ejemplos.

eknives escribió:¿Que más dará que internamente la Saturn no sea una máquina 3D? Si con sprites es capaz de mostrar entornos tridimensionales y darnos su correspondiente jugabilidad yo me doy por contento ¿Es qué no alcanza con eso? Yo lo considero todo un logro de cómo se supo aprovechar y si no salieron más juegos y cesó antes de tiempo no fue culpa de eso, al menos en exclusiva. Sega tenía muy dañado su nombre y Sony la clavó en aquella época, incluso Nintendo lo pagó en sus carnes.

Gracias @EMaDeLoC por tan fantásticas explicaciones.

Claro que alcanza con eso, pero no está de más saber como funcionaba la máquina y aceptar que buena parte de su fracaso viene de esto. Para lograr un 3D similar al de PSX había que transformar sus funciones 2D para que representaran un 3D lo cual era un quebradero de cabeza y comía recursos del sistema. Y sigue siendo un verdadero enigma porqué SEGA sacó una Saturn no enfocada primero al 3D y de forma secundaria al 2D; siendo esta compañía una pionera del 3D desde tiempos de recreativas 2D que simulaban 3D hasta los primeros juegos poligonales, que lo petaron con Virtua Racing al punto de sacarlo para Megadrive, sacaron el 32X pensando en ofrecer juegos 3D en una consola 2D, etc. Imagino que la historia será la de siempre: SEGA América y SEGA Japón mirando quien la tiene más larga.

@SuperPadLand se puede leer en mi comentario, yo agradezco las explicaciones y de hecho estoy encantado de saber por fin el porqué se consideraba una máquina 2D. Y supongo que no poder portar fácilmente desarrollos de otras máquinas 3D hizo que a Saturn empezaran a llegar menos juegos porque eran un desarrollo casi desde cero para una máquina que había vendido poco, porque por ejemplo, PS2 siempre se tuvo como otro infierno a la hora de desarrollar juegos pero era lo que vendía y dónde había que estar, nunca estuvo corta de software pese a esos mismos problemas. Lo de hacer una máquina 2D... igual los arcades 3D de Sega no estaban funcionando tan bien como nos pensamos y en Japón los 2D seguían pegando fuerte, quien sabe.

@eknives estaría bien saber cual era más complicada para su época si Saturn frente a PSX y N64 o PS2 frente a DC,GC y Xbox. Lo que dices de Japón puede encajar con que la consola allí vendiese tan bien.

SuperPadLand escribió:

crazy2k4 escribió:¿entonces,die hard arcade,sega rally,nights,burning rangers,panzer dragoon saga....no son juegos en 3d?

Lo son, pero logran el efecto 3D mediante técnicas 2D al igual que Doom o Super Mario Kart. Evidentemente Saturn lo hace muchísimo mejor que esos dos ejemplos.

Con un sistema 2D como Doom o Mario Kart ni se podrían usar técnicas como el sombreado Gouraud, ni podrías tener superficies superpuestas, porque para ello necesitas calcular coordenadas en tres dimensiones. Y el hecho de hacer eso es lo que hace que sea 3D y no el sistema de texturizado usado.

Dudo mucho que juegos como Daytona USA o Burning Rangers usen trucos 2D para similar todo su entorno poligonal 3D.

Me parece que estáis confundiendo el suelo de Virtua Fighter y otros juegos de lucha, donde sí se usaban planos 2D, con otros juegos de Saturn que lucen entornos 3D que no parecen otra cosa que mallas poligonales normales.

Si juegos poligonales hay hasta en Mega Drive, y sin chips siquiera.. no creo que para Saturn un entorno poligonal sea gran cosa, como para pensar que no puede y que sus juegos poligonales no lo son.

@gynion @jnderblue @SuperPadLand

No, no son "trucos" de apariencia 3D como en Mario Kart o Doom. Eso también lo explicó @EMaDeLoC antes muy bien. Esos juegos no existen en un entorno 3D de ninguna clase. Esos juegos se desarrollan en un entorno 2D que luego, mediante adaptaciones que simulan perspectiva, adquieren un aspecto tridimensional, sin que de forma alguna los recursos que los componen tengan propiedades tridimensionales.
Los juegos tridimensionales poligonales de Saturn funcionan dentro de un entorno de coordenadas tridimensionales de pleno derecho. Lo que él y yo debatimos es acerca del último paso donde esa rejilla de vértices y aristas se traduce a un dibujo en pantalla con aspecto de perspectiva.

Su argumento lo podeis leer, pero mi resumen de lo que el dice, poniendo las cosas en el sitio que yo creo que deben tener, es que, como en Saturn, el motor gráfico programado por el desarrollador tiene que encargarse de todo el proceso de proyectar ese entorno tridimensional sobre el plano bidimensional de la pantalla y, manualmente, rellenar de pixels las celdillas resultantes con un tipo de mapeo consistente en técnicas propias de un sprite y no de un triángulo moderno, él concluye que el rasterizado es 2D y no 3D.

Yo, por el contrario, defiendo que los rasterizadores supuestamente capaces de trabajar directamente con "triangulos 3D" de sistemas con graficos 3D mas estandarizados como son PS1 y N64, en realidad, también se ven obligados a trabajar en 2D en el momento justo de dibujar la pantalla, y que no hay diferencia esencial, en este aspecto, entre lo que se hace en Saturn y lo que se hace en las otras. Afirmo que, aunque los chips gráficos de PS1 y N64 aceptan triángulos con coordenadas 3D, el rellenado de pixels del área correspondiente de la pantalla requiere del paso previo de proyectar ese triangulo a 2D y perder esa tercera dimensión, y que SOLO ENTONCES, se procede a pintar los pixels con la textura o el recurso gráfico que corresponda. El hecho de que estos sistemas se encarguen de ese paso automáticamente, y no lo tenga que explicitar el programador, no hace a Saturn, que sí tiene que explicitarlo, "menos 3D" que las otras.

Un triángulo 3D no puede pintarse directamente sobre un framebuffer o pantalla, primero hay que proyectarlo como vector 2D y LUEGO lo pintas. Ese paso lo puedes hacer de forma explícita o dejarselo al hardware si este lo puede hacer. Saturn no puede, PS1 y N64 si.

Los pasos son los mismos, es solo una cuestión... "burocrática": ¿Qué papeleo hay que rellenar? ¿A qué ventanilla tengo que llevarlo? ¿qué parte hago yo y que parte hace la administración por mi?, etc.
El paso de 3D a 2D previo al coloreado en Saturn es explícito, mediante el uso de "sprites" mientras que en N64 y PS1, y básicamente cualquier otro renderizador minimamente moderno, queda automatizado y obviado como paso explicito que el programador deba realizar. Pero hacerse, se hace.
Y, por esta razón, defiendo que Saturn no es en ninguna medida, "menos 3D" que las otras. Todas tienen que rellenar regiones bidimiensionales con valores de color. La textura no se aplica sobre el polígono tridimensional y luego va al framebuffer, si no que primero hay que proyectar una "sombra" del polígono sobre las coordenadas del framebuffer y LUEGO rellenarlo de colores.

@radorn

Eso ya es muy, muy de programador; no solo en términos, sino en importancia. Es decir, por lo que dices, es evidente que al programador parece que le tiene que resultar relevante esa diferencia entre Saturn y N64/PSX, ya que le obliga a dar ciertos pasos; pero el espectador al fin y al cabo no se va coscar de nada, viendo entornos 3D en las tres consolas. Dejando al margen las consecuencias de la dificultad de programación, que no sé hasta dónde llegarían en concreto por esto.

Que se diga el scaling o los juegos tipo Doom frente a los polígonos, vale, porque se nota fácilmente la artificialidad de lo primero, y las limitaciones de lo segundo frente a entornos poligonales; pero ya entrar en las diferencias en el proceso de renderizado o rasterización, cuando al final lo que acaba en pantalla y en nuestros ojos jugando es lo mismo... lo veo bastante rebuscado. Una cosa puede ser técnicamente cierta, pero a su vez algo rebuscada, y esta tiene pinta de eso; por lo menos, de cara al espectador.

@gynion No solo es que tu no veas la diferencia como jugador (lo cual es un poco discutible, pues algunas diferencias si se pueden ver, pero bueno), es que, al final, hay una serie de procesos que son necesarios para que, partiendo de una serie de puntos y aristas ordenadas en unas coordenadas 3D y una serie de imágenes asociadas a los espacios entre ellas, puedas obtener una imagen bidimensional que represente un a vista en perspectiva de dicha escena.
El error conceptual aquí, a mi parecer, es pensar que un sistema 3D puede tomar un polígono en su representación de coordenadas tridimensionales y generar pixels en el framebuffer sin que haya un paso intermedio, en el que ese polígono pasa a una representación bidimensional, siendo este paso previo a que los pixels correspondientes de la pantalla sean rellenados con valores de color. Sencillamente eso no se puede hacer. Es un paso que tiene que darse, no te lo puedes saltar. Que lo haga el programador diseñando ese proceso en el motor gráfico, o que lo haga el hardware de forma transparente y sin intervención, no cambia el hecho de que este paso necesariamente tiene que darse. Es un paso esencial para el renderizado, tanto en Saturn como en cualquier otro renderizador del que yo haya oído hablar.

@gynion @radorn Yo mismo he dicho antes que pensaba que la Saturn era completamente 3D hasta que miré su arquitectura.

En cuanto al paso de conversión del 3D, sigo en lo mismo: no es el mismo proceso proyectar un triángulo en la superficie 2D del framebuffer, que deformar un sprite hasta que encaje en una región concreta del frambebuffer.
La diferencia no es solo a nivel de programación, también es artística: no puedes meter transparencias en sprites deformados porque se corrompen al pintarse varias veces el mismo pixel con distintas partes del sprite; debido a lo anterior las sombras has de hacerlas por un rellenado de región de píxeles negros intercalados y las transparencias en sprites sin deformar; no puedes crear efectos de environmental mapping (reflejos) por hardware porque no puedes manipular las coordenadas de la textura y te toca hacerlo por software; no puedes aplicar sombreado gouraud y a la vez fusionar el color con el fondo sin crear fallos gráficos; has de crear bitmaps específicos con deformidad si quieres usar el truco del sprite deformado hasta parecer un triángulo (lo que aumenta el trabajo y desperdicia espacio)...

Y repito, no se trata de hacer de menos a la consola, solo de describir una parte del proceso gráfico. Ya le hubiese gustado a PS1 tener un resultado tan bueno en un juego de coches cuando salió el Sega Rally de Saturn. Recuerdo haber probado por primera vez ese juego en un Pryca y pensar que era exacto al arcade. Obviamente no lo es pero como port en la Saturn, de 10.

Dice mucho que una máquina "2D" te ofrezca un resultado superior a la competencia 3D:


En fin, por ahí han puesto enlaces desgranando mucho mejor la arquitectura y vídeos de un programador del Sonic R contando sus trucos. Ya que cada cual vea cual explicación le convence más.

Yo es que no sé cómo alguien puede pensar que no es lo mismo un Sega Rally que un Rige Racer, un Virtua Fighter que un Tekken, un Quake que un... bueno, que un Quake jeje. A partir de ahí, cualquier información sobre los entresijos de cada máquina o los trucos que utilizaba cada programador me parece super interesante.

Eso sí, afirmar por ejemplo, que el juego que marcó un antes y un después en la lucha 3D no es 3D... pues como que no.

Realmente interesante la explicación de por que Saturn no puede hacer transparencias, he leído mucha información desde hace años y nunca había leído una explicación tan clara sobre este tema, a pesar de no haber tenido Saturn su arquitectura única y super compleja me parece muy interesante, debido a los miles de trucos que se tuvieron que sacar los programadores para hacerla mínimamente viable al 3D, haciendo auténticos milagros.

@Lautrec+ No confundas los originales con los ports de Saturn. Cada máquina funciona a su manera. Seguro que para portar el Doom a SNES o Megadrive no pudieron usar las mismas técnicas que en PC.

A mi me parece que la DC en 2D era una bestia,Satuen era buena,pero no se si Garou por ejemplo habria salido igual que en DC.

EMaDeLoC escribió:Y repito, no se trata de hacer de menos a la consola

Se que no estás diciendo eso. Lo has negado varias veces y yo nunca te lo he achacado. Esa no es la cuestión.

EMaDeLoC escribió:En cuanto al paso de conversión del 3D, sigo en lo mismo: no es el mismo proceso proyectar un triángulo en la superficie 2D del framebuffer, que deformar un sprite hasta que encaje en una región concreta del frambebuffer.
La diferencia no es solo a nivel de programación, también es artística: no puedes meter transparencias en sprites deformados porque se corrompen al pintarse varias veces el mismo pixel con distintas partes del sprite; debido a lo anterior las sombras has de hacerlas por un rellenado de región de píxeles negros intercalados y las transparencias en sprites sin deformar; no puedes crear efectos de environmental mapping (reflejos) por hardware porque no puedes manipular las coordenadas de la textura y te toca hacerlo por software; no puedes aplicar sombreado gouraud y a la vez fusionar el color con el fondo sin crear fallos gráficos; has de crear bitmaps específicos con deformidad si quieres usar el truco del sprite deformado hasta parecer un triángulo (lo que aumenta el trabajo y desperdicia espacio)...

Bueno, pero es que esto ya es otro debate distinto. Ahora estás hablando de refinamiento y flexibilidad, de cuestiones artísticas y demás. Ahí está claro que la Saturn tiene carencias y problemas. Pero, por mucho que sigas empeñado en que esto hace que la Saturn "no sea totalmente 3D", en realidad, la tridimensionalidad de su sistema gráfico no se ve afectada. Mi argumento nunca ha sido que Saturn pueda hacer todo lo que hacen las demás sin diferencia. OBVIAMENTE hay diferencias, lo llevo diciendo todo el tiempo. Mi objeción es que no estoy en absoluto de acuerdo en que los gráficos de Saturn "no sean completamente 3D" solo porque tenga que colorear los pixels de la proyección vectorial en 2D de los polígonos con un sprite encajado con calzador, en vez de con técnicas de rasterizado mas modernas pensadas específicamente para ese propósito. Y esto es, una vez mas, por que todas las técnicas de rellenado/coloreado/rasterizado de todos los sistemas, al final, se ven reducidas a esencialmente lo mismo: Pintar con colores los pixels contenidos en una región geométrica de un framebuffer que ha sido delimitada por un paso anterior del proceso de transformación y proyección.

Repito que no hay una diferencia conceptual, ni esencial, si no que todo se reduce a una cuesitón de refinamiento y flexibilidad, no de "tridimensionalidad", por mucho que digas que solo es falta de tridimensionalidad en el dibujado.
Podemos argumentar que Saturn fue inicialmente creada pensando en juegos principalmente 2D, y que las técnicas de dibujado son perfectamente adecuadas para ese uso, pero el hecho de que esas técnicas se hayan adaptado, de manera cruda, a un uso tridimensional, no hace a los gráficos menos tridimensionales, porque los otros sistemas, al final del proceso, también se ven reducidos a pintarrajear dentro de una casilla bidimensional que les viene dada del paso anterior. Y en eso, de verdad, no veo como puedes argumentar que una es "mas 3D" y otra "menos 3D".

Si nos empeñamos en decir que el dibujado de Saturn es 2D, entonces tamién tenemos que decirlo de las otras, porque en este sentido la diferencia es de forma y no de fondo. O son todas o ningun. En este aspecto, todas ellas hacen Lo Mismo (tm) porque los gráficos 3D funcionan así... TODOS ELLOS.

Cambiando de tema: A pesar de que las técnicas de Saturn son claramente menos avanzadas y mas "crudas", a mi me gusta mucho el resultado visual que dan cuando se hace buen uso de ellas. Si bien a Saturn no le vino bien de cara a los desarrolladores, y, de rebote, comercialmente, lo cierto es que nos ha dejado juegos con un aspecto visual único que no hubieramos tenido de otro modo. A mi, al contrario que a muchos hoy en día, me resultan interesantes de ver estos gráficos esforzados, con pixels gordos, con polígonos gigantes, donde ves de forma muy directa lo que ha hecho el artista gráfico, el programador, y los esfuerzos por crear unos efectos resultones y unos diseños atractivos.
Ahora, con todos los avances en hardware y herramientas, con dos clics puedes hacer una superficie reflectante, un efecto de agua, o fuego, o brillos y luces, etc etc... y no es que eso esté mal, pero se pierde una cosa que alguien llamó una vez "arte a partir de la adversidad". Grant Kirkhope, antiguo compositor de Rare en juegos como GoldenEye o la saga Banjo-Kazooie, preguntado sobre su proceso de composición y las dificultades para hacer música en estos sistemas dijo que, debido a las limitaciones del hardware, no puedes zafar poniendo efectos impresionantes y capas y capas de harmonía y cosas así, si no que tienes que romperte los cuernos y hacer una "melodía jodidamente buena", que funcione aunque el sonido no sea el último grito. Melodías MIDI con limitaciones en cuanto a número de voces simultáneas y soundbanks de entre 500K y 2MB. Eso es todo lo que tienes. ¡Hazme una banda sonora!. Ya ni hablemos de la musica chip.

Pues eso.

Lautrec+ escribió:Eso sí, afirmar por ejemplo, que el juego que marcó un antes y un después en la lucha 3D no es 3D... pues como que no.

Es en 3D y el desarrollo original no fue en Saturn.

@EMaDeLoC

Ya te digo que puede ser técnicamente cierto, que eso no lo pongo en duda, pero lo sigo viendo rebuscado. Lo que explicas son detalles que sólo me parece acertado contemplar en el caso de querer explicar por qué Saturn no puede mostrar transparencias, reflejos o sombras como PSX, o por qué los programadores podían tener más problemas con Saturn, pero me resulta rebuscado si se usa para argumentar sobre el por qué Saturn es 2D y no 3D. Está muy cogido con pinzas.

@EMaDeLoC no, si yo no confundo nada. ¿No seréis otros los confundidos? Lo que digo es que Virtua Fighter de Saturn es 3D, al igual que decenas de juegos de la consola. Y negarlo es que no tiene el menor sentido.
@SuperPadLand Conozco la historia de Virtua Fighter perfectamente. El de Saturn es exactamente igual de 3D que el de recreativa.

Dentro de poco los polígonos tampoco serán 3D a no ser que sea a través de un casco de VR.

guillian-seed escribió:Dentro de poco los polígonos tampoco serán 3D a no ser que sea a través de un casco de VR.

Este debate apunta más bien al Ray Tracing, por lo que veo.

Lautrec+ escribió:@EMaDeLoC no, si yo no confundo nada. ¿No seréis otros los confundidos? Lo que digo es que Virtua Fighter de Saturn es 3D, al igual que decenas de juegos de la consola. Y negarlo es que no tiene el menor sentido.
@SuperPadLand Conozco la historia de Virtua Fighter perfectamente. El de Saturn es exactamente igual de 3D que el de recreativa.

Nadie ha negado que sea en 3D, de lo que estamos hablando es de como genera el efecto 3D la Saturn.

guillian-seed escribió:Dentro de poco los polígonos tampoco serán 3D a no ser que sea a través de un casco de VR.

En los cascos VR puedes reproducir juegos 2D con efecto 3D

SuperPadLand escribió:

Lautrec+ escribió:@EMaDeLoC no, si yo no confundo nada. ¿No seréis otros los confundidos? Lo que digo es que Virtua Fighter de Saturn es 3D, al igual que decenas de juegos de la consola. Y negarlo es que no tiene el menor sentido.
@SuperPadLand Conozco la historia de Virtua Fighter perfectamente. El de Saturn es exactamente igual de 3D que el de recreativa.

Nadie ha negado que sea en 3D, de lo que estamos hablando es de como genera el efecto 3D la Saturn.

SuperPadLand escribió:

guillian-seed escribió:Dentro de poco los polígonos tampoco serán 3D a no ser que sea a través de un casco de VR.

En los cascos VR puedes reproducir juegos 2D con efecto 3D

En realidad eso no es 3D, se llama estereoscopía.

emerald golvellius escribió:A mi me parece que la DC en 2D era una bestia,Satuen era buena,pero no se si Garou por ejemplo habria salido igual que en DC.

Habiendo RAM suficiente Saturn puede mover cualquier cosa que salga de una Neogeo, Garou en Saturn podria incluso haber salido en su resolución original a 224p 15khz, cosa que no se ve en la versión Dreamcast.

@SuperPadLand sí que lo habéis negado. Desde decir literalmente que la saturn es 2D mientras que las otras son 3D, hasta que Sega Rally es un Super Mario Kart más potente. Y esto último es que me parecio que clamaba al cielo y por eso dije algo tan obvio como que Sega Rally es tan 3D como Rige Racer.

A partir de ahí pues no sé que sobre mi "capacidad de comprensión", insinuaciones veladas sobre clones de no sé quien, aires de superioridad... y ahora resulta que Saturn es totalmente 3D y no se ha escrito lo que se ha escrito. Pues vale.

chinitosoccer escribió:

emerald golvellius escribió:A mi me parece que la DC en 2D era una bestia,Satuen era buena,pero no se si Garou por ejemplo habria salido igual que en DC.

Habiendo RAM suficiente Saturn puede mover cualquier cosa que salga de una Neogeo, Garou en Saturn podria incluso haber salido en su resolución original a 224p 15khz, cosa que no se ve en la versión Dreamcast.

Pero esto sería un poco trampa, la Saturn es la que fue y tiene la RAM que tiene, si con la que trae más la expansión no llega pues no puede mover cualquier cosa de NeoGeo; cosa que a lo mejor Dreamcast sí.

@EMaDeLoC ¿O sea que saturn simula las 3d mediante sprites deformados según el punto de vista de la cámara? Ostias no me extraña que dijeran que era dificil programar juegos para esa maquina.

@Dark_Crystal El sprite cuadrado se deforma para encajar en los vértices de un rectángulo proyectado sobre las coordenadas 2D de la pantalla que corresponden a la vista en perspectiva del quad 3D original. En Saturn esta parte es "manual", desde el punto de vista del programador, ya que lo tiene que programar el motor gráfico para que se encargue de esa tarea. En las máquinas con "autentico 3D", es lo mismo, pero con triángulos, y no hay que hacerlo manualmente, si no que tu le das el triángulo en las coordenadas 3D de la cámara y el renderizador automatiza el proceso de proyectarlo sobre una rejilla de coordenadas 2D correspondientes al framebuffer y, solo entonces, aplica la textura sobre ese hueco poligonal que ya está en dominio bidimensional.
Al menos en N64 es así. No se lo suficiente de PS1 para poder decir si también automatiza el proyectado 3D a 2D o si hay que hacerlo manualmente. En cualquier caso, en estas dos últimas, son triángulos y al menos tienen coordenadas UV para estirar la textura, cosa que el rasterizador de Saturn no puede hacer nativamente.

Me convence más la explicación de @radorn

Dark_Crystal escribió:@EMaDeLoC ¿O sea que saturn simula las 3d mediante sprites deformados según el punto de vista de la cámara? Ostias no me extraña que dijeran que era dificil programar juegos para esa maquina.

Eso con el SDK desarrollado por Sega era lo de menos, y tampoco es una complicación severa de por sí ya que el hardware se encarga de deformarlo. El problema era sacarle potencial a los chips. Algunos eran una tortura en ensamblador, como el que sale en este vídeo:

No entiendo la discusión sobre si Saturn es 2D y 3D, en el momento que el VDP1 tiene capacidad de dibujar quads en 3D mediante comandos del VDP1 es una máquina preparada para las 3D. Con pipeline de transformación e iluminación para esos quads etc.
Otra cosa es que las capacidades 2D se puedan aplicar a escenas 3D para mejorarlas porque la Saturn tenía también capacidades 2D cosa que PSX no y tenia que hacerlo mediante polígonos simulando 2D.
La Saturn es una mezcla entre 2D y 3D, pero no es 2D exclusivamente y muestra 3D a través de 2D. Esta preparada para las 3D.

Sacarle más potencia a la Saturn aprovechando sus capacidades 2D para hacer cosas 3D no significa que sea 2D.