Hilo de detalles y curiosidades de N64

PABEOL escribió:Mi mente ultrapotente acaba de calcular que cada cubo son seis polígonos.

No tengo ni idea de cuántos cubos hay en la demo "de Minecraft" de Tiny3D, pero yo no le echaría más de 1000 en lo que se ve.

¿No serían eso 6000 polígonos? A ver si alguien puede explicar dónde está la magia.

En los motores 3d hay diferentes niveles de discriminación de polígonos. En las consolas de esta época convertir los vértices de 3d a 2d y luego pintarlos era un proceso muy costoso así que se intentaba discriminar lo máximo posible cualquier de esas fases.
Se solía discriminar en este orden:

1) Estructuras de datos espaciales: seguro que por ejemplo has oído hablar alguna vez de BSP, que lo usaban los juegos de ID. En la demo de Tiny utiliza BVH. Todos esos nombrajos son maneras diferentes de organizar el espacio. Imagínate el mapa de “Hyrule Field“ de OOT visto desde arriba, y tú decides dividir todo el mapa en un cuadrante de 8x8, si estás en la mitad del mapa mirando al norte, pues por ejemplo puedes descartar la mitad del mapa (todos los cuadrantes que están el sur). De esa manera no has tenido que ir mirando cada polígono de cada cuadrante. Solo con saber que no se veía el cuadrante ya te vale para descartar todo lo que tenía asociado.
BVH, BSP o los Octrees dividen el espacio de otra forma, pero la función a la hora de renderizar es más o menos la misma (descartar muchos polígonos a la vez).

2) Frustum culling: Esto es básicamente descartar lo que está fuera del campo de vista de la cámara en 3d. En el ejemplo anterior si estabas mirando al norte es posible que algún cuadrante de los del norte que estuviese por los lados, quedase fuera del campo de vista de la cámara y también se puede descartar. La cámara tiene una distancia de lejos y otra de cerca, así que el Frustum Culling también puede descartar polígonos que estén más lejos que X si así lo desean. El Frustum Culling también se puede usar para descartar bloques (cuadrantes en el ejemplo de OOT) del paso anterior.

3) Backface culling y Screen clipping: Backface culling es descartar los polígonos que no están mirando a la cámara y screen clipping es descartar los que están fuera del rectángulo 2d de la pantalla (es como el frustum culling pero ya en 2d)

Lo que se suele contar como polígonos renderizados en un juego es los que quedan después del 3) que son los que se acaban mostrando en pantalla.
En la demo de Tiny te está mostrando los que quedan después de 1), por eso te puede dar la impresión de que salen más de los que hay luego en pantalla. Además, hiciste bien los cálculos de cuantas caras tiene un cubo, pero como n64 solo trabaja con triángulos cada cara la tienes que dividir por 2, ósea cada cubo son 12 triángulos.

¡Gracias! Pues con 12 polígonos por cubo, si hay 1000 cubos ya nos salen 12.000 polígonos visibles (aunque yo sigo sin ver 1000 cubos a no ser que haya docenas de cubos enterrados que también cuenten).

Lo de las técnicas esas ya lo había pillado, aunque no sabía que había una separada para descartar también los cuadrantes... curioso.

¿Esto en la época lo hacían los juegos de 5ª generación o no?

PABEOL escribió:¡Gracias! Pues con 12 polígonos por cubo, si hay 1000 cubos ya nos salen 12.000 polígonos visibles (aunque yo sigo sin ver 1000 cubos a no ser que haya docenas de cubos enterrados que también cuenten).

Lo de los 1000 cubos lo dices por algún comentario específico? El número que te sale a la izquierda, por ejemplo al principio pone 4072, te indica que esos son los triángulos que han pasado el test del BVH (parece una enfermedad ), pero puede ser que un grupo de 500 cubos que esté a la derecha haya pasado el test, pero se descarte en otra fase más adelante. Esos números son solo orientativos.

PABEOL escribió:Lo de las técnicas esas ya lo había pillado, aunque no sabía que había una separada para descartar también los cuadrantes... curioso.

Eso es un ejemplo básico que te he puesto, la demo lo que hace es agrupar objectos por el volumen que ocupan y encapsularlos en volúmenes mayores, y así sucesivamente, no es una división uniforme. Con el test intentan descartar un volumen grande y si lo consiguen saben que todos los volúmenes por debajo están fuera (en la thumbnail del video se ve un poco los volúmenes de agrupamiento)

PABEOL escribió:¿Esto en la época lo hacían los juegos de 5ª generación o no?

Los BSP se usaban ya desde principios de los noventa en juegos. Muchos juegos de la 5ª generación ya usaban división por cuadrantes uniformes (prácticamente Octrees). No tengo constancia de ningún juego que usara BVH en esa época (el primero que me viene a la cabeza es Super Mario 64 DS) pero es bastante probable que los usasen ya que es una técnica que se inventó a mediados de los 70. A veces se usan para otras cosas como detectar collisiones.

Ah, vale, es que había leído algo de cientos de miles de polígonos en esa demo y no lo veía nada claro, obviamente.

Pues a lo tonto, ese paisaje con unos 300 y pico cubos les ha quedado bastante chulo. A mí el Minecraft no me gusta por su jugabilidad, pero ese tipo de gráficos demuestran que la fidelidad gráfica está sobrevalorada. El Katamari es otro ejemplo.

Hola, mirando de actualizar mi SD de N64 acabo de ver que en los amantes del CD hay un Portal 64 por si alguno le interesa cazarlo.

Edit: Probado y confirmo que funciona de maravilla. Tiene texto y voces en castellano. Permite desactivar el desentrelazado o configurar la distancia de renderizado de los portales, pero incluso al máximo la penalización en rendimiento es más que aceptable.

SuperPadLand escribió:Hola, mirando de actualizar mi SD de N64 acabo de ver que en los amantes del CD hay un Portal 64 por si alguno le interesa cazarlo.

Edit: Probado y confirmo que funciona de maravilla. Tiene texto y voces en castellano. Permite desactivar el desentrelazado o configurar la distancia de renderizado de los portales, pero incluso al máximo la penalización en rendimiento es más que aceptable.

He estado probando un rato, es una pena que no pudiese continuarlo, tiene margen de mejora en los gráficos, sobretodo iluminación (no tiene de ningún tipo) y las texturas se podrían mejorar, eso sí, no entiendo por que le a metido un dithering tan marcado.

Salud.

@dirtymagic el dithering lo noté, pero pensé que era culpa de usar RGB

@SuperPadLand
Yo tengo conectado pr compuesto la N64 y es muy notorio, al nivel de Lilat Wars que es otro que también es super marcado.

Salud.

dirtymagic escribió:@SuperPadLand
Yo tengo conectado pr compuesto la N64 y es muy notorio, al nivel de Lilat Wars que es otro que también es super marcado.

Salud.

Supongo que ello ayuda con la tasa de relleno no? Me suena que en PS1 en Silent Hill se abusó también de ello por ese motivo. La conversión es muy buena y fiel, ya sólo las físicas de usar los cubos son increíbles.

El creador está haciendo algo propio? Porque de lo que aprendió de este proyecto imagino que podrá sacar un juego muy bueno para N64

SuperPadLand escribió:Hola, mirando de actualizar mi SD de N64 acabo de ver que en los amantes del CD hay un Portal 64 por si alguno le interesa cazarlo.

Es el juego ya para ejecutar o hay que parchear, etc?

@Dr Sabroson Es la ROM ya preparada.

@SuperPadLand Si que está haciendo un juego, pero no tiene nada que ver con Portal.


Salud.

Dr Sabroson escribió:

SuperPadLand escribió:Hola, mirando de actualizar mi SD de N64 acabo de ver que en los amantes del CD hay un Portal 64 por si alguno le interesa cazarlo.

Es el juego ya para ejecutar o hay que parchear, etc?

Listo y cocinado. Yo no sé compilar.

@dirtymagic está muy verde todavía, pero pinta bien. A ver en que queda

Una curiosidad de GoldenEye que no sé si es muy conocida. Yo lo vi por primera vez hace unos años (quizás dos o tres) en una conferencia que hizo David Doak, uno de los desarrolladores (el que puso su cara para el Dr. Doak del nivel de Facility).

En el nivel de Egyptian se encuentra el enemigo Baron Samedi que regresa de entre los muertos cada vez que acabas con él. La misión termina cuando lo matas por tercera vez, pero en la cinemática final se le ve persiguiendo a Bond y riendo con su maléfica carcajada mientras la imagen se funde a negro.
Pues resulta que si uno es lo suficientemente astuto puede conseguir esto -> https://youtu.be/pSPoQ9OqAEM?si=KzGVW38JFQIf9iT7&t=120

Cuando lo vi por primera vez solté una carcajada todavía más sonora que la de Baron. Ocurrió lo mismo en el vídeo aquel de la conferencia, que al público también le pilló por sorpresa.

Pues hoy he ido a buscar el vídeo original o al menos uno que se le pareciera y lo que he encontrado me ha hecho soltar una carcajada todavía más grande. Me pregunto si Doak o cualquiera de los desarrolladores sabían que esto era posible. Yo he tardado 27 años en saberlo (bueno, desbloqué Egyptian en el 2000, así que 24 años). -> https://www.youtube.com/watch?v=dJLyTDD ... l=ItsReddd
Es mucho más sencillo que el anterior, pero no se me habría ocurrido en la vida. El otro quizás sí.

¿Alguien más conocía alguna de estas formas de interactuar con el Baron Samedi? ¿Qué otras cosas descubristeis muchos años más tarde en juegos de Nintendo 64? Yo tengo algunas más.

@Sogun es increíble lo que la gente puede rascar de un juego cuando le gusta hasta encontrar fallos o cosas como estás 🤣

La N64 corriendo el Delfino plaza del Mario Sunshine:

EMaDeLoC escribió:La N64 corriendo el Delfino plaza del Mario Sunshine:

Funciona 20fps mas rapido que en GC... tal vez hay margen para ponerle una pizquita de mega textura hasta bajar a los 30fps.

Como me gusta esto

Señor Ventura escribió:

EMaDeLoC escribió:La N64 corriendo el Delfino plaza del Mario Sunshine:

Funciona 20fps mas rapido que en GC... tal vez hay margen para ponerle una pizquita de mega textura hasta bajar a los 30fps.

Como me gusta esto

Antes de ir por ese camino habrá que mirar de meter el agua y sus físicas más todos los NPC del pueblo, monedas y otros objetos y, sino recuerdo mal, faltan unos islotes que se ven a lo lejos. Aparte de que el modelo de Mario debería llevar la mochila de agua aparte y otras cosas.

Es una nintendo 64, se trata de mover lo esencial con la mayor calidad posible.

Las monedas y otros detalles menores no se van a apreciar muy bien, y pueden costar rendimiento. Si por la misma porción de rendimiento puedes ponerle mejores texturas a eso, sería preferible.

Vamos, que no se trata de decir que es como una gamecube porque eso no es posible, pero por lo que tengo leído diría que igual para el agua se pueden hacer cositas sin demasiado coste tambien.

La calidad de las texturas es suficiente para la resolución con la que va renderizar que es 320x240, subirle más en calidad de textura, es posible que ni se aprecie en consola original, lo digo por experiencia, con las texturas que hago yo, que en Blender y emulador se ven nítidas y en consola apenas se aprecia el detalle 😅, estoy en el mismo barco que SuperPadLand, es preferible que le meta , lo que le hace ser un juego, que una presentación con más "calidad" en el que sólo te paseas.
Salud.

Señor Ventura escribió:Es una nintendo 64, se trata de mover lo esencial con la mayor calidad posible.

Las monedas y otros detalles menores no se van a apreciar muy bien, y pueden costar rendimiento. Si por la misma porción de rendimiento puedes ponerle mejores texturas a eso, sería preferible.

Vamos, que no se trata de decir que es como una gamecube porque eso no es posible, pero por lo que tengo leído diría que igual para el agua se pueden hacer cositas sin demasiado coste tambien.

A ver lo repito con otras palabras adaptadas a tu logica: Si se trata de mover lo esencial entonces las megatexturas aquí no pintan nada. Hay cosas mucho más esenciales que poner antes: objetos, npc, mejorar el agua, etc.


No sé que obsesión has cogido con las megatexturas, la demo técnica está genial, pero si la pruebas verás que lo que estás pidiendo no tiene ni pies ni cabeza.

@SuperPadLand Ya, pero es lo que me gustaría. No se trata de hacer lo que hace una gamecube, tendrás que calcular y dibujar menos, y sobre todo no se trata de recrear un nivel jugable, sino una demo visual.

Ese nivel con el nivel de detalle de la megatextura imagino que no debería ser posible, me refiero a usar ese mismo principio para, efectivamente, subir la calidad de las texturas, pero no hasta aquel nivel enfermizo de la demo. El propio autor dijo que para juegos de mundo mas abierto no sería posible, pero si lograr un aumento de detalle.

Señor Ventura escribió:@SuperPadLand Ya, pero es lo que me gustaría. No se trata de hacer lo que hace una gamecube, tendrás que calcular y dibujar menos, y sobre todo no se trata de recrear un nivel jugable, sino una demo visual.

Ese nivel con el nivel de detalle de la megatextura imagino que no debería ser posible, me refiero a usar ese mismo principio para, efectivamente, subir la calidad de las texturas, pero no hasta aquel nivel enfermizo de la demo. El propio autor dijo que para juegos de mundo mas abierto no sería posible, pero si lograr un aumento de detalle.

Por supuesto, pero como demo que intenta representar lo más fielme posible el juego de GC se le debe dar prioridad a intentar meter todos los elementos posibles del original. A mi no me dices nada con una demo de una palmera de Isla delfino con megatextura, me dices más con algo como lo de esta demo, pero metiéndole los NPC primero y a partir de ahí si es posible el agua, las frutas de los puestos, etc. Vamos es que lo normal en este tipo de demos es el camino contrario: mirar hasta donde habría que recortar para portear el original, meter megatexturas es el sentido contrario y además, salvo que haya algo mejor que esa demo técnica, en un escenario abierto puedes pasar fácilmente a 5fps metiéndolas. Ten en cuenta que la demo no va a 50 estables, en muchas zonas según la camara ya no logra mantener los 30. El tema de las megatexturas necesita un juego diseñaso con ello en mente y dónde el framerate no sea importante, algo como hizo la propia demo: juego en primera persona, por instancias pequeñas y que trate de observar con calma y donde no moleste el salto que pegan las texturas para cambiarla la calidad según la distancia de la cámara. Algo como Myst o Shadowgate o en juegos como Mario y Zelda limitarlo a cuando entras en un entorno pequeño como las tiendas o edificios de Hyrule. Pero creo que la primera persona le sienta mejor porqué en tercera persona tener el personaje con megatextura ya va a tirar y no vas a tener el personaje principal sin megatextura y el escenario sí, desentonaría bastante un Link borroso y un muro con rugosidades. Aparte de que en tercera persona no puedes observar bien esos detalles, en primera persona puedes mirar bien todo, etc.

Por otro lado, suponiendo que sea para usar en consola y setup original recordemos que esto implica una res máxima de 480i por RF o RCA en CRT. Ponle un mod RGB y 240p, pero más allá de eso es desperdiciar. No quiero caer en Yoshin que te convierte una MD en un Pentium IV gracias al RF y CRT, pero quitando las exageraciones tenía algo de razón en lo que indicaba.


Edit: @dirtymagic @EMaDeLoC la ROM para probarla no la ha compartido no?

@SuperPadLand Por el momento no, pero dice que sacará una demo de su mod de SM64 que vendrá con la plaza Delfino.

Menejos de partículas con Tiny3D:

https://youtu.be/H5RBmAH1WFU

doblete escribió:Menejos de partículas con Tiny3D:

https://youtu.be/H5RBmAH1WFU

Cada partícula representa una lágrima de los escocidos con Nintendo.

La clave estará en su cpu, supongo... el caso es que según va añadiendo partículas en tiempo real va bajando la tasa de frames, y dices "ah claro, lógico", pero cuando deja sumarle partículas el rendimiento se vuelve a estabilizar.

50 mil partículas a mas o menos 30 fps es una salvajada, osea es que no hemos visto eso ni en la siguiente generación, pero es que encima da la sensación de puede con mas. Y luego la tasa de relleno...

¿Que brujería es esta?.

Las particulares son generadas desde el RSP, mediante el modo COPY, el cual solo permite renderizar cuadrados, triángulos no se que problemas da. Los cuadrados por lo visto es algo mucho más simple de renderizar que los triángulos, menos puntos de indicar, y en modo COPY tiene una tasa de rellenos 4 veces mayor que el mayormente utilizado 1-cycle.

Está implementando que estas particulas puedan llevar texturas.

Realmente, esto ya lo hizo hace tiempo, hay un video que impresiona, porque las partículas parecen que tienen volumen. El caso es que creo que el código antiguo estaba dentro del ucode tiny3D y ahora lo ha aislado y esta limpiándolo.

celgadis_84 escribió:Las particulares son generadas desde el RSP, mediante el modo COPY, el cual solo permite renderizar cuadrados, triángulos no se que problemas da. Los cuadrados por lo visto es algo mucho más simple de renderizar que los triángulos, menos puntos de indicar, y en modo COPY tiene una tasa de rellenos 4 veces mayor que el mayormente utilizado 1-cycle.

Está implementando que estas particulas puedan llevar texturas.

Realmente, esto ya lo hizo hace tiempo, hay un video que impresiona, porque las partículas parecen que tienen volumen. El caso es que creo que el código antiguo estaba dentro del ucode tiny3D y ahora lo ha aislado y esta limpiándolo.

Si no se pueden usar triángulos que aplicaciones podría tener en un juego? Por ejemplo, se podrían redondear de alguna forma para simular nieve, lluvia, polvo? Evidentemente en un juego con estilo gráfico cubico como minecraft o cubivore también valdría.

@SuperPadLand
Ójala se pudiese, pero no permite distorsionar el rectángulo, es un fast-path del RDP para renderizar lo que comúnmente se conoce como “sprites”, no se puede usar para polígonos.

Su uso era principalmente para HUD, Sprites en juegos 2d, menus etc… Este fast-path es el que me imagino que usaba Conker (el usuario) con Libdragon para sus demos.

Tampoco funcionan cosas como blending, z-buffer (aunque puedes dar un valor de profundidad para todo el quad) ni gouraud. Permite transparencias (no semi-transparencias) así que puedes ponerle por ejemplo un círculo blanco relleno sobre el rectángulo dejando lo detrás transparente si quieres hacer cosas como partículas de nieve.

@Misscelan
Sí, usaba fill, copy y 1-cycle en mis demos 2D.
--

En el test de partículas imagino que está usando fill (la función más rápida), son de 1 solo color, se puede llevar un control de cada partícula y su color, actualizando en cada frame como hace con las llamas, que empiezan amarillas y se van poniendo rojo oscuras según suben, a mi me vale la verdad, a tamaño pequeño ni se notaría, incluso algo más grande, si van cambiando de forma/color y son cuantiosas queda bien.

El copy para texturizar, no me queda claro que tipo de implementación quiere hacer a nivel 3D, los rectángulos verticalmente si que se pueden redimensionar, horizontalmente en principio causa artefactos, si eso fuera bien entonces podría poner cualquier tamaño 2D de cara a pantalla, en perspectiva ya sería otra cosa, yo usaba copy para los tiles del scroll o cualquier cosa que no necesitara alpha, proyección, etc.

Luego están todas las limitaciones que comentas, no soporta tinte RGB ni nada del color combiner, pero puedes usar paletas para crear algunos efectos, para los copos de nieve imagino que tendría que recurrir a una textura (problemas) de al menos 2 colores, el transparente y el sólido, o quizás aplicar una máscara de color transparente o alguna primitiva sobre el rectángulo, pero para eso igual sale más a cuenta ir directamente a cycle.

Otra idea es formar pequeños dibujos con rectángulos fill, si los agrupas como si fueran 1 pixelaco, puedes crear cosas de 4x16 por ejemplo, como hierba y que en realidad no sea una textura, sino pues eso, bloques de diferente color y no gastar tampoco demasiado en cálculo, porque van continuos.

La demo de las partículas es muy espectacular, pero me cuesta encontrar usos prácticos debido a sus limitaciones. Sin semitransparencias pierde mucha flexibilidad, aunque se puedan aplicar texturas con píxeles transparentes. Un efecto de nieve es lo primero que se viene a la mente, como ya habéis comentado. Una ventisca gigantesca que te impida ver a a dos palmos con las partículas reaccionando a físicas de viento (aunque fuesen precalculadas, como las olas en Wave Race 64) sería algo digno de ver.
En el vídeo se ven intentos de hierba 3D, pero cuando intenta poner algo denso el framerate baja bastante. Me gustaría ver cómo se comportaría si en lugar de 3 partículas por brizna utilizase 1 con textura.
El efecto de la llama desluce si el humo no tiene semitransparencia.
El número de partículas en COPY es impresionante. Me pregunto si sería lo suficientemente alto en 1-CYCLE para conseguir efectos de esta magnitud con mejor rendimiento.

Factor 5 presumía de tener un motor que movía una burrada de partículas sin afectar al rendimiento, pero luego en sus juegos los efectos climatológicos eran bastante feos. Perfect Dark les pasaba la cara por la mano.
La lluvia en Perfect Dark incluso tenía físicas contra algunas superficies.
Aquí a 60 fps donde las rachas de viento quedan todavía mejor.
La nieve también estaba muy bien con copos de distintos tamaños y viento variable

------

En otro orden de cosas, me he topado con dos vídeos de James Lambert enseñando cómo programar en Libdragon. Son directos que no aparecen en la sección de 'Vídeos' de su canal. No sé si hará más. Ni siquiera los he visto aún porque no he programado en mi vida.
https://www.youtube.com/watch?v=dJe6noy ... mesLambert
https://www.youtube.com/watch?v=lp2kvxE ... mesLambert

Ya ha implementado las partículas con texturas y la verdad es que es bastante espectacular.
Las llamas las ha texturizado con un humo casi calcado al de Okami.
Las hierbas con una especie de triángulo.
A ver si lo cuelga en su canal de Youtube, por ahora se puede ver en discord.

A raíz del hilo polémico de estos días, hubo un usuario que argumento una cosa que me gustaría ver si alguien tiene info más detallada, el argumento es que OoT tenía muy baja calidad de texturas y que todo era un borrón que dificultaba ver el juego, etc y que se notaba que al juego le faltaba más tiempo de desarrollo para mejorar esto y que puede comprobarse en Majora's Mask que ya tiene mucha mejor calidad de texturas y nitidez.

Ya sé que lo primero es mentira, al menos para el estandar de 1998, pero en relación a la mejora gráfica entre OoT y MM ¿Alguno puede arrojar datos concretos? Geometría, calidad de texturas, etc?

SuperPadLand escribió:A raíz del hilo polémico de estos días, hubo un usuario que argumento una cosa que me gustaría ver si alguien tiene info más detallada, el argumento es que OoT tenía muy baja calidad de texturas y que todo era un borrón que dificultaba ver el juego, etc y que se notaba que al juego le faltaba más tiempo de desarrollo para mejorar esto y que puede comprobarse en Majora's Mask que ya tiene mucha mejor calidad de texturas y nitidez.

Ya sé que lo primero es mentira, al menos para el estandar de 1998, pero en relación a la mejora gráfica entre OoT y MM ¿Alguno puede arrojar datos concretos? Geometría, calidad de texturas, etc?

El motor es el mismo, si acaso, puede que se beneficie de tener más RAM para tener más personajes diferentes a la vez, puede que algo más de distancia de dibujado y un mayor uso de texturas de 2 pasadas para dar nitidez en no sólo el suelo de la campiña y uso de texturas de 64*64* 16 colores, que en Oot creo que no se usan, ya que la textura a color más grande es de 64*32* 16 bits y luego de escala de grises los usan de 64*64 y de intensidad MM usa varias de 128*32 y sólo una de 128*64, mientras que en Oot de estas últimas , utiliza varias en la torre de Ganondorf.

Salud.

celgadis_84 escribió:Ya ha implementado las partículas con texturas y la verdad es que es bastante espectacular.
Las llamas las ha texturizado con un humo casi calcado al de Okami.
Las hierbas con una especie de triángulo.
A ver si lo cuelga en su canal de Youtube, por ahora se puede ver en discord.

No se te olvide ponerlo por aquí, que da curiosidad.

Video de partículas con texturas
https://youtu.be/ulyNfc03UIo?si=69wARt2oMRNYROcx

Menuda salvajada de test.