Si ves el vídeo debajo sin más información, pensarás que se trata de una compleja animación que ocupa varios gigabytes y se ejecuta en potentes servidores. Nada de eso. Se trata en realidad de una animación que cogería en un antiguo disquete, ocupa solo 64 kilobytes y está generada en tiempo real únicamente a base de código.
Íñigo Quilez, ahora en Pixar, Jefe de Tecnología de Render y un maestro de las matemáticas.
#2:
#1 Buah. Ahora tiene mérito. Pero cuando ibas con un i8088 o un i80286 y 640K de Ram... eso si que era flipante. #demo_scene
#5:
#0 Acabas de descubrir la demoscene? pues la Euskal party (aka Euskal encounter) era una party scener en su tiempo y se iba allí a hacer cosas de estas.
Por cierto. Muy buena intro.
Incluso habia intros de 4KB (modestitas, claro) y luego demos mucho más elaboradas.
Para aquellos que recuerden la scene se acordarán de por qué teníamos todos una tarjeta de sonido Gravis Ultrasound y del mensaje "No GUS? No sound"
#13:
¿Es que estamos hablando de demos y nadie ha nombrado aún a Future Crew?
Panic fue genial y la Second Realíty la ponía todas las mañanas para ir completamente despierto al insti.
#25:
La Scene para mí es de lo mejorcito en programación. Quiero decir, es donde demuestra un programador que sabe programar porque las virguerías que hacen en tan poco espacio, comparado con otros es admirable.
Si queréis más, sobre todo porque han sido premiados como las mejores (en este caso de 2011):
#13 Lo de Future Crew es espectacular, sinceramente.
Salu2
#11:
#9 qué voxels ni que leches, si eso es una malla de alturas a partir de una textura generada por Perlin? Otra cosa es el render... Que antes había que hacerse el raster a pelo? Cierto. Por eso hay que comparar las demos con las que se hicieron en su mismo momento.
Y los 64kb creo que están sobrevalorados, Farbrausch siempre arrasaba en esa modalidad... Y siempre le sobraban 30 o 35kb. El punto ideal, para mi, serían 32kb.
De todas formas, meter un renderer, generar mallas o empaquetar las notas de audio, meter un sinte, postproceso... En 4k es una proeza! Queda un código de mierda... Pero la satisfacción que te llevas es la hostia no, lo siguiente.
Arriba la demoescena!
#14:
#13 Second Reality es con diferencia la mejor demo "clásica" y siempre la llevo de politono en el móvil. Un 10 para ti!
Es una gran demo. Meter música (multicanal), el engine (cálculo de luces, cámara, render, etc) y texturas, o el sistema para generarlas, en 64 KB tiene mucho mérito. La portada de Menéame son 178 KB.
#26 Algunos comprimen texturas usando métodos casi artesanales, otros las calculan en tiempo real, etc. Es un arte hacer un demo.
No sé vosotros, pero yo creo que aún guardo por ahí el primer CD que vino con la mítica PCMANIA (aún existe?) en la que venía "Second Reality". El dia que lo descubrí creo que casi frio mi 386DX-33 con 4Mb de RAM... - creo que tenía unos 12 años o así...
Por cierto, hay unos friks que lo han hecho para Commodore 64:
¿Es que estamos hablando de demos y nadie ha nombrado aún a Future Crew?
Panic fue genial y la Second Realíty la ponía todas las mañanas para ir completamente despierto al insti.
#0 Acabas de descubrir la demoscene? pues la Euskal party (aka Euskal encounter) era una party scener en su tiempo y se iba allí a hacer cosas de estas.
Por cierto. Muy buena intro.
Incluso habia intros de 4KB (modestitas, claro) y luego demos mucho más elaboradas.
Para aquellos que recuerden la scene se acordarán de por qué teníamos todos una tarjeta de sonido Gravis Ultrasound y del mensaje "No GUS? No sound"
#9 qué voxels ni que leches, si eso es una malla de alturas a partir de una textura generada por Perlin? Otra cosa es el render... Que antes había que hacerse el raster a pelo? Cierto. Por eso hay que comparar las demos con las que se hicieron en su mismo momento.
Y los 64kb creo que están sobrevalorados, Farbrausch siempre arrasaba en esa modalidad... Y siempre le sobraban 30 o 35kb. El punto ideal, para mi, serían 32kb.
De todas formas, meter un renderer, generar mallas o empaquetar las notas de audio, meter un sinte, postproceso... En 4k es una proeza! Queda un código de mierda... Pero la satisfacción que te llevas es la hostia no, lo siguiente.
La Scene para mí es de lo mejorcito en programación. Quiero decir, es donde demuestra un programador que sabe programar porque las virguerías que hacen en tan poco espacio, comparado con otros es admirable.
Si queréis más, sobre todo porque han sido premiados como las mejores (en este caso de 2011):
#8 El vídeo no hace justicia a la demo. 720p es insuficiente para ver el detalle real. Esto se debe ver o 1080p o ejecutando la demo: http://www.pouet.net/prod.php?which=62935
Es una gran demo. Meter música (multicanal), el engine (cálculo de luces, cámara, render, etc) y texturas, o el sistema para generarlas, en 64 KB tiene mucho mérito. La portada de Menéame son 178 KB.
#26 Algunos comprimen texturas usando métodos casi artesanales, otros las calculan en tiempo real, etc. Es un arte hacer un demo.
No sé vosotros, pero yo creo que aún guardo por ahí el primer CD que vino con la mítica PCMANIA (aún existe?) en la que venía "Second Reality". El dia que lo descubrí creo que casi frio mi 386DX-33 con 4Mb de RAM... - creo que tenía unos 12 años o así...
Por cierto, hay unos friks que lo han hecho para Commodore 64:
A los viejunos del lugar que se pasaban por sitios como la Euskal, ¿no mirabais raro a eso de la Campus Party cuando surgió, como preguntándoos qué pintaba una reunión así solo para jugar?
#53 Siempre necesitas algo mas.. el Sistema operativo la API que puede ser Dx, Opengl... el driver de la gráfica... pero el ejecutable final es de 64Kb (Todo incluido, texturas, modelos etc) normalmente no usan ni librerías ya que dispararía el tamaño, y todo se suele generar de forma procedural.
Por cierto creo que confundes Opengl con un motor gráfico... o eso o me he perdido la clase de efectos atmosféricos.
Demo scene, Future Crew, perlin noise, Trackers, 64k de ram, texturas procedurales? Doc hemos viajado al pasado!!! creo que estamos en mitad de los 90'.
Solo falta que alguien explique alguna batallita como la implementación del algoritmo de Bresenham en ASM y el modo X de la VGA para hacerme sentir como un viejo.
#7 si, realmente se ha ganado mucha eficiencia desde que existen las aceleradoras de vídeo que te ahorran mucho código y tal, lo que permite que en menos se pueda hacer más. No obstante hace un tiempo teníanos que currarnos los Voxel (lo que viene siendo generar paisajes como esos... o paisajes lunares...) a mano. Pero en cualquier caso 64KB siempre va a tener ventaja de esos 60KB a mayores sobre las de 4KB.
#19 si no recuerdo mal la versión final de kkrieger ocupaba 112kb. Otra proeza técnica, como su compresor de ejecutables kkrunchy (ríete tú de UPX y similares).
Respecto a que no se usen en juegos... No es del todo cierto. Para mejorar texturas que se ven muy de cerca se usan filtros etc. Por ejemplo en el Unreal Engine desde la primera versión o el el CryEngine, que siguen la misma filosofía... El problema viene con los artistas: sácales del potochof y que se apañen con una herramienta inhouse... Hay que me LOL!
#11 De Farbrausch siempre me pareció su mejor trabajo .kkrieger. Saltan a 96k pero es un juego completo, no una animación no interactiva. No sé por qué no se utiliza hoy en día la generación procedural de texturas en los juegos, y así evitar que ocupen 20-30GB en disco.
#23 Esas texturas de detalle para distancias cortas suele ser otra textura pintada, y sólo sirve para disimular falta de resolución. En Rage lo añadieron con un parche, y le da un toque de lienzo/vintage al acabado final, que algo hace. El grueso como dices es lo que han pintado los artistas. Imagina en un juego estilo Dead Space o Doom 3, qué fácilmente podrían generarse en la carga proceduralmente todos los mapas del escenario: difuso, normales, especulares, etc.
Por suerte he ido conociendo cada vez más artistas que, si bien a la hora de texturizar suelen usar herramientas tradicionales, a la hora de crear el material empiezan a escribir código de shaders o jugar con los editores de nodos, según el motor. Supongo que todo pasa por que los artistas cojan más competencias técnicas, y se pase la aversión hacia lo moderno (uno conocí que comentaba que era "hacer trampa" usar pinceles avanzados en vez del lápiz).
#1 El truco está en que utilizan OpenGL. El software tendrá 64k pero detrás está OpenGL con megas y megas de código encargado de la renderización, sombras, efectos atmosféricos, ...
Luego "sólo" es cuestión de ejecutar un algoritmo recursivo y pasarle la salida a OpenGL (o WebGL). El algoritmo recursivo puede ser algo así como el código LOGO que corría en nuestros Amstrad y Spectrum en los años 80 (http://www.calormen.com/jslogo/). A eso le sumas WebGL y ya tienes tu demo para el próximo año.
Lo que no me queda claro es si las texturas están incluidas en esos 64k o no.
Historias del abuelo: Un grupo que partía la pana a principios de los 90 era Triton. Con demos como Crystal Dream:
Estos no trataban de limitar el tamaño, pero con las máquinas de la época trataban de conseguir los efectos 3D en tiempo real más impresionantes.
Esta gente evolucionó y se metieron a hacer un juego, que nunca salió, pero que dió muchísimo que hablar, Into The Shadows. Este juego hacía gala de iluminación en tiempo real con múltiples focos de luz, y motion capture...Antes de que ID lanzara quake.
Lo dicho, el juego no llegó a salir. Uno de los inversores se esfumó con la pasta y se lió un pitoste. La compañía fue a quiebra. Pero es posible que hayais catado el fruto de esta gente. Porque muchos de los integrantes de Triton formaron Starbreeze Studios, responsables de Chronicles of Riddick, y Dark Athena. Ambos con un motor gráfico bastante potente e interesante. Más recientemente han Sacado Brothers: Tale of Two Sons, que parece que han decidido pasar del motor gráfico, tirar de Unreal Engine y contar una historia. Aún no lo he probado, pero pinta bien.
#90 a mi me suena bastante mal, pero en el comentario que mencionas contestaba a #78 diciendo que la acepción que menciona de la RAE no es equivalente a la que estamos discutiendo, que es la 30 y está marcada como vulgarismo.
Efectivamente, está "bien" dicho y puede usarse como equivalente como dices, pero al ser un vulgarismo el uso de coger con esa acepción es preferible el uso de caber... aunque claro, donde su uso esté extendido es perfectamente aceptable.
#61 toda imagen son 1's y 0's y como bien sabes, los 1's y 0's puedes tenerlos todos escritos o calcularlos mediante una función... hay algo muy útil en estos casos que se llama fractales =)
#38 no me refiero al filtro bilineal por el FSM... Me refiero a como comentaruben3d a otras técnicas: mezcla de texturas, añadir detalles de forma procedural a la textura (con los editores de nodos mediante generadores de texturas, ruido en la imagen, shaders especiales dependiendo del material... )
Los que hacen esto son programadores, no les llameis programadores a tipos que son usuarios de bases de datos y usan interfaces visuales para montar webs prefabricadas y les pagan 800€/mes en cárnicas, y cuentan los programas en "lineas de codigo" ultracomentadas
Esos no son programadores son albañiles del código
#5 CArajo, la Gravis... que recuerdos con el CD que traía
Mi primera lectora CD la compré para poder usar el que traía la Gravis...
Mi hijo la quemó dándole a un botón de la mesa a la que la tenía conectada. pena.
#61 Probablemente usan herramientas propias, y si usan programas de diseño gráfico, usaran herramientas para quitar los datos que no quieren (bueno, usar las que si...), de todas maneras fíjate que se copian muchos objetos.
Para las texturas del mármol, "puede" que usen una base fractal... o vete a saber
******** #26 Disculpad mi ignorancia, pero, ¿cómo coño es posible describir formas tan complejas en solo 64 Kb de código? ¿No hay archivos de texturas que se carguen por ahí? ********
El escene no lo conozco. Así que lo siento. ¿funciona bajo linux? ¿hay IDEs?
por ejemplo raytracing con povray. Y se puede definir por lenguaje virguerías Hay editores de archivos pov (neXt gen Pov Editor xpe) o el kpovmodeler. Además hay muchos generadores de gráficos fractales por ejem maldelbulber (etc) .
El problema no es que ocupe espacio la fuente, que realmente ocupa muy poco, el problema es que se necesita una capacidad de cálculo bestial en la máquina para representarlo a tiempo real. El algoritmo del raytracing no es precisamente rápido (calculando lo que hará cada rayo de luz, en cada superfície y cada reflejo etc) pero tiene unas salidas fotográficas
#7 De iq me soprende la capacidad que tiene de definir escenas y patrones de animación complejos matemáticamente. Parece que la animación de #0 sigue el mismo método: raymarcher en el fragment program con una escena definida por código. Hay muchos ejemplos en https://www.shadertoy.com/ (de iq), pero esa técnica demanda una GPU muy potente.
Piensa por ejemplo en la función coseno(x). Su representación "coseno(x)" no ocupa casi nada, pero dando valores a "x" en el momento en el que ejecutas resulta en INFINITOS valores (entre -1 y +1).
Ahora imagina lo que puedes hacer con sumas, restas, multiplicaciones, divisiones, seno, coseno, números aleatorios, logaritmos...
#54 Pues si te digo la verdad no tengo ni idea cuál es la diferencia entre OpenGL y un motor gráfico y qué se encarga de qué. Los cuatro pinitos que he hecho son con WebGL y por curiosidad más que otra cosa.
#87 En el sur, donde yo vivo, es exactamente lo mismo decir "no quepo en el asiento" que "no cojo en el asiento". De hecho es la primera vez que veo que a alguien le suena raro, así que imagino que esa acepción del verbo coger está más extendida de lo que te pueda parecer.
#23 ". Para mejorar texturas que se ven muy de cerca se usan filtros etc." Filtros bilineares, anda que no es viejo
Por cierto, con ese simple filtro, los juegos de Play Station se ven de lujo¹. Cierto que una TV de tubo de las antiguas, con los píxeles en forma de "corona"² no se ven tan borroso, pero en una pantalla de PC el render pixelado canta pero bien.
#78 en qué se parece la acepción de ocupar a la de coger? para mi en nada... no es lo mismo decir "no quepo en el asiento" a "he ocupado un asiento" cuyos equivalentes con el verbo coger serían "no cojo en el asiento" o "he cogido un asiento".
Si se programaran de esta manera los programas de hoy en día, como procesadores de palabras, hojas de cálculo, presentación, navegador web, el sistema operativo completo, etc, ¿cuánto ocuparían y qué velocidad de procesador se necesitaría?.
¿El sistema operativo, núcleo e interfaz gráfica, etc, funcionaría en un computador con 16 MB RAM y 100 MHz?
Disculpad mi ignorancia, pero, ¿cómo coño es posible describir formas tan complejas en solo 64 Kb de código? ¿No hay archivos de texturas que se carguen por ahí?
Para poder hacerlo, entiendo que se utilizará un programa de diseño gráfico y luego lo convertirá en un código para que tenga una descripción compacta, porque si no es para volverse mico escribiendo esto a mano.
#46 No, no, si queda claro que no van a lo fácil, pero es que tiene que ser un puto infierno escribir a mano todo eso. Hombre, son formas geométricas asequibles varias de ellas (arcos, esferas, etc), pero juntarlas todas y hacer determinados efectos tiene que ser de locos.
Se me hace un mundo describir una GUI básica en texto a pelo (para un programa Java, por ejemplo) porque es tremendamente difícil ver cómo va a quedar todo sin usar una interfaz gráfica para colocar los botoncitos, como para montarse un carajal de estos.
A lo mejor a quien esté metido en esto le parece obvio o incluso hasta sencillo hacer esto, pero yo me volvería loco intentando describir algo así en texto.
#33 ¿Y la textura de mármol de las fuentes? Es que hay un huevo de formas que no parecen triviales. Ole sus huevos.
#54#57 Hombre, eso me resulta más razonable. Mínimo tienen que usar algo por detrás como OpenGL. Lo digo siendo profano en la materia, que conste.
y todo se suele generar de forma procedural. Me imagino que será más eficiente que guardarte una textura en un archivo, pero ole sus... (cc #49)
Comentan arriba que probablemente los juegos ocuparían menos si se generaran las texturas de forma procedural, pero me imagino que sería mucho más costoso/llevaría mucho más tiempo/sería difícil reutilizarlas, ya que entiendo que si las describes proceduralmente os referís a líneas de código y me imagino que eso implicaría que para poder usarlas necesitas acceso a código fuente y que ese código te puede dejar de funcionar a la mínima de cambio.
¿Lo que ocupa 64KB son los datos que una vez ejecutados por un programa externo generan la animación... o dicho programa, que entiendo que es lo que llamais renderer tambien está incluido en los 64 Kb?
Demo con ray-tracing en opengl 4.3 en 64kb, muy impresionante, aunque el raytracing es algo difícil de mover a tiempo real así que los que no tengan una gráfica de gama alta que se abstengan de correr la demo y se conformen con el vídeo.
Ah, y en las gráficas de amd da igual cual tengas tampoco funciona.. les falta (a AMD) arreglar algunas cosas de opengl que tienen la implementación medio abandonada...
Me parece muy interesante este artículo me ha elevado mi nostalgia primigenia, yo me paré a la altura de la gamecube y ver cosas tan bonitas hoy en día... ya puedo morir tranquilo, incluso aunque me frían a negativos aquí en "menéame" que es la casa de otros pero en la que entro por el ADSL de Orange. God Save The Queen.
#55 Bueno yo tengo una partición con crunchbang (Distribución de linux) y me consume menos de 150mb, pero programar en poco tamaño no es lo mismo a hacerlo de forma optima, o al menos no siempre.
Si bien esta demo ocupa solo 64kb la memoria que utiliza después una vez comienza a generar todos los elementos es mucho mas que esos 64kb ademas y a pesar de su tamaño usa técnicas muy pesadas como el ray-tracing por lo que la potencia necesaria para mover la demo es muy elevada.
Comentarios
#5 4k? Elaborada? ELEVATED de Iq!
Íñigo Quilez, ahora en Pixar, Jefe de Tecnología de Render y un maestro de las matemáticas.
#1 Buah. Ahora tiene mérito. Pero cuando ibas con un i8088 o un i80286 y 640K de Ram... eso si que era flipante.
#demo_scene
¿Es que estamos hablando de demos y nadie ha nombrado aún a Future Crew?
Panic fue genial y la Second Realíty la ponía todas las mañanas para ir completamente despierto al insti.
#0 Acabas de descubrir la demoscene? pues la Euskal party (aka Euskal encounter) era una party scener en su tiempo y se iba allí a hacer cosas de estas.
Por cierto. Muy buena intro.
Incluso habia intros de 4KB (modestitas, claro) y luego demos mucho más elaboradas.
Para aquellos que recuerden la scene se acordarán de por qué teníamos todos una tarjeta de sonido Gravis Ultrasound y del mensaje "No GUS? No sound"
#13 Second Reality es con diferencia la mejor demo "clásica" y siempre la llevo de politono en el móvil. Un 10 para ti!
#9 qué voxels ni que leches, si eso es una malla de alturas a partir de una textura generada por Perlin? Otra cosa es el render... Que antes había que hacerse el raster a pelo? Cierto. Por eso hay que comparar las demos con las que se hicieron en su mismo momento.
Y los 64kb creo que están sobrevalorados, Farbrausch siempre arrasaba en esa modalidad... Y siempre le sobraban 30 o 35kb. El punto ideal, para mi, serían 32kb.
De todas formas, meter un renderer, generar mallas o empaquetar las notas de audio, meter un sinte, postproceso... En 4k es una proeza! Queda un código de mierda... Pero la satisfacción que te llevas es la hostia no, lo siguiente.
Arriba la demoescena!
La Scene para mí es de lo mejorcito en programación. Quiero decir, es donde demuestra un programador que sabe programar porque las virguerías que hacen en tan poco espacio, comparado con otros es admirable.
Si queréis más, sobre todo porque han sido premiados como las mejores (en este caso de 2011):
https://www.scene.org/awards.php?year=2011
#13 Lo de Future Crew es espectacular, sinceramente.
Salu2
Pedazos de demo que se hacían antes...eso si que era programar para "hombres".
#0 ¿cogería? Madre de Dios.
#27 el código que lo renderizó en tiempo real ocupa 64 kb. La captura en vídeo ocupa como cualquier otro vídeo de características similares.
Qué tiempos la demoscene.
Y qué flashback de pronto #13 #25 Future Crew, eran la ostia. La de veces que habré ejecutado esta cosa:
#8 El vídeo no hace justicia a la demo. 720p es insuficiente para ver el detalle real. Esto se debe ver o 1080p o ejecutando la demo: http://www.pouet.net/prod.php?which=62935
Es una gran demo. Meter música (multicanal), el engine (cálculo de luces, cámara, render, etc) y texturas, o el sistema para generarlas, en 64 KB tiene mucho mérito. La portada de Menéame son 178 KB.
#26 Algunos comprimen texturas usando métodos casi artesanales, otros las calculan en tiempo real, etc. Es un arte hacer un demo.
#20 Fast Tracker 2 que mítico
#13 #14 #21 #25 #32
No sé vosotros, pero yo creo que aún guardo por ahí el primer CD que vino con la mítica PCMANIA (aún existe?) en la que venía "Second Reality". El dia que lo descubrí creo que casi frio mi 386DX-33 con 4Mb de RAM... - creo que tenía unos 12 años o así...
Por cierto, hay unos friks que lo han hecho para Commodore 64:
A los viejunos del lugar que se pasaban por sitios como la Euskal, ¿no mirabais raro a eso de la Campus Party cuando surgió, como preguntándoos qué pintaba una reunión así solo para jugar?
Y mira que yo como mucho componía .MODs
Yo en menos de 1k puedo hacer un programa que muestra un corto con renders en 3d. Allá va:
#!/bin/sh
mplayer http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_surround.avi
Demoscene en Menéame!
Vivir para ver... por cierto, AMIGA RULEZ!! Aún tengo grabadas a fuego las melodías de Desert Dream de Kefrens.
#12 para nuestra desgracia la RAE lo acepta... panda de paletos aceptadores de almóndigas y cederrones... al menos es un vulgarismo.
30. intr. vulg. caber. Esto no coge aquí.
Normal, con un maquinón de 64Kb de RAM. Así cualquiera.
#13
todavía se me ponen los pelos de puntaSigo sin explicármelo, no tengo tiempo ahora de leer el artículo que citan al final, pero aún así creo que me seguirá pareciendo increíble.
Este tipo de demos se aprecian mejor desde el propio ejecutable[1], más que en un video de YT. [1] http://www.pouet.net/prod.php?which=62935
#53 Siempre necesitas algo mas.. el Sistema operativo la API que puede ser Dx, Opengl... el driver de la gráfica... pero el ejecutable final es de 64Kb (Todo incluido, texturas, modelos etc) normalmente no usan ni librerías ya que dispararía el tamaño, y todo se suele generar de forma procedural.
Por cierto creo que confundes Opengl con un motor gráfico... o eso o me he perdido la clase de efectos atmosféricos.
Demo scene, Future Crew, perlin noise, Trackers, 64k de ram, texturas procedurales? Doc hemos viajado al pasado!!! creo que estamos en mitad de los 90'.
Solo falta que alguien explique alguna batallita como la implementación del algoritmo de Bresenham en ASM y el modo X de la VGA para hacerme sentir como un viejo.
#7 si, realmente se ha ganado mucha eficiencia desde que existen las aceleradoras de vídeo que te ahorran mucho código y tal, lo que permite que en menos se pueda hacer más. No obstante hace un tiempo teníanos que currarnos los Voxel (lo que viene siendo generar paisajes como esos... o paisajes lunares...) a mano. Pero en cualquier caso 64KB siempre va a tener ventaja de esos 60KB a mayores sobre las de 4KB.
#19 si no recuerdo mal la versión final de kkrieger ocupaba 112kb. Otra proeza técnica, como su compresor de ejecutables kkrunchy (ríete tú de UPX y similares).
Respecto a que no se usen en juegos... No es del todo cierto. Para mejorar texturas que se ven muy de cerca se usan filtros etc. Por ejemplo en el Unreal Engine desde la primera versión o el el CryEngine, que siguen la misma filosofía... El problema viene con los artistas: sácales del potochof y que se apañen con una herramienta inhouse... Hay que me LOL!
#26 Puedes generar texturas de forma procedural. Busca "perlin noise" en google.
BITCH PLEASE
#11 De Farbrausch siempre me pareció su mejor trabajo .kkrieger. Saltan a 96k pero es un juego completo, no una animación no interactiva. No sé por qué no se utiliza hoy en día la generación procedural de texturas en los juegos, y así evitar que ocupen 20-30GB en disco.
http://web.archive.org/web/20110717024227/http://www.theprodukkt.com/kkrieger
64K son más que suficientes para cualquier programa...
#23 Esas texturas de detalle para distancias cortas suele ser otra textura pintada, y sólo sirve para disimular falta de resolución. En Rage lo añadieron con un parche, y le da un toque de lienzo/vintage al acabado final, que algo hace. El grueso como dices es lo que han pintado los artistas. Imagina en un juego estilo Dead Space o Doom 3, qué fácilmente podrían generarse en la carga proceduralmente todos los mapas del escenario: difuso, normales, especulares, etc.
Por suerte he ido conociendo cada vez más artistas que, si bien a la hora de texturizar suelen usar herramientas tradicionales, a la hora de crear el material empiezan a escribir código de shaders o jugar con los editores de nodos, según el motor. Supongo que todo pasa por que los artistas cojan más competencias técnicas, y se pase la aversión hacia lo moderno (uno conocí que comentaba que era "hacer trampa" usar pinceles avanzados en vez del lápiz).
#1 El truco está en que utilizan OpenGL. El software tendrá 64k pero detrás está OpenGL con megas y megas de código encargado de la renderización, sombras, efectos atmosféricos, ...
Luego "sólo" es cuestión de ejecutar un algoritmo recursivo y pasarle la salida a OpenGL (o WebGL). El algoritmo recursivo puede ser algo así como el código LOGO que corría en nuestros Amstrad y Spectrum en los años 80 (http://www.calormen.com/jslogo/). A eso le sumas WebGL y ya tienes tu demo para el próximo año.
Lo que no me queda claro es si las texturas están incluidas en esos 64k o no.
Chuck Norris hace eso con un bit.
Historias del abuelo: Un grupo que partía la pana a principios de los 90 era Triton. Con demos como Crystal Dream:
Estos no trataban de limitar el tamaño, pero con las máquinas de la época trataban de conseguir los efectos 3D en tiempo real más impresionantes.
Esta gente evolucionó y se metieron a hacer un juego, que nunca salió, pero que dió muchísimo que hablar, Into The Shadows. Este juego hacía gala de iluminación en tiempo real con múltiples focos de luz, y motion capture...Antes de que ID lanzara quake.
Lo dicho, el juego no llegó a salir. Uno de los inversores se esfumó con la pasta y se lió un pitoste. La compañía fue a quiebra. Pero es posible que hayais catado el fruto de esta gente. Porque muchos de los integrantes de Triton formaron Starbreeze Studios, responsables de Chronicles of Riddick, y Dark Athena. Ambos con un motor gráfico bastante potente e interesante. Más recientemente han Sacado Brothers: Tale of Two Sons, que parece que han decidido pasar del motor gráfico, tirar de Unreal Engine y contar una historia. Aún no lo he probado, pero pinta bien.
#90 a mi me suena bastante mal, pero en el comentario que mencionas contestaba a #78 diciendo que la acepción que menciona de la RAE no es equivalente a la que estamos discutiendo, que es la 30 y está marcada como vulgarismo.
Efectivamente, está "bien" dicho y puede usarse como equivalente como dices, pero al ser un vulgarismo el uso de coger con esa acepción es preferible el uso de caber... aunque claro, donde su uso esté extendido es perfectamente aceptable.
#56 Alpine Linux ocupa incluso menos, con µslibc. Y vuela comparada con otras distros, incluso Arch.
Es de las pocas que arrancaría hoy en día en 32 mb de RAM.
Por cierto, echo de menos a sistemas como BeOS.
¿Donde estaríamos ahora si no fuera por la malicia de MS para hundir a ese sistema?
#61 toda imagen son 1's y 0's y como bien sabes, los 1's y 0's puedes tenerlos todos escritos o calcularlos mediante una función... hay algo muy útil en estos casos que se llama fractales =)
#10 Se llaman vídeos =P
#38 no me refiero al filtro bilineal por el FSM... Me refiero a como comentaruben3d a otras técnicas: mezcla de texturas, añadir detalles de forma procedural a la textura (con los editores de nodos mediante generadores de texturas, ruido en la imagen, shaders especiales dependiendo del material... )
#26 #69 PovRay ahora está disponible bajo OpenSource, así que aprovechad
#61 Suscribo lo que #66, perlin noise suele ser la respuesta para estos casos.
Los que hacen esto son programadores, no les llameis programadores a tipos que son usuarios de bases de datos y usan interfaces visuales para montar webs prefabricadas y les pagan 800€/mes en cárnicas, y cuentan los programas en "lineas de codigo" ultracomentadas
Esos no son programadores son albañiles del código
#26 "entiendo que se utilizará un programa de diseño gráfico"
¿porque? ¿Porque es mas fácil? ¿Te parece una gente que va a lo fácil?
Muy buena pero no supera la referencia: elevated by Rgba
para bajar la intro de 4K http://www.pouet.net/prod.php?which=52938Ya que habláis de Elevated... aquí tenéis una versión OpenSource del autor (iq) en un solo shader: https://www.shadertoy.com/view/MdX3Rr
Bueno, en general Shadertoy merece la pena verla entera...
(#35 ya mencionó Shadertoy, no lo había visto )
#5 CArajo, la Gravis... que recuerdos con el CD que traía
Mi primera lectora CD la compré para poder usar el que traía la Gravis...
Mi hijo la quemó dándole a un botón de la mesa a la que la tenía conectada. pena.
#61 Probablemente usan herramientas propias, y si usan programas de diseño gráfico, usaran herramientas para quitar los datos que no quieren (bueno, usar las que si...), de todas maneras fíjate que se copian muchos objetos.
Para las texturas del mármol, "puede" que usen una base fractal... o vete a saber
********
#26 Disculpad mi ignorancia, pero, ¿cómo coño es posible describir formas tan complejas en solo 64 Kb de código? ¿No hay archivos de texturas que se carguen por ahí?
********
El escene no lo conozco. Así que lo siento. ¿funciona bajo linux? ¿hay IDEs?
por ejemplo raytracing con povray. Y se puede definir por lenguaje virguerías Hay editores de archivos pov (neXt gen Pov Editor
xpe) o el kpovmodeler. Además hay muchos generadores de gráficos fractales por ejem maldelbulber (etc) .El problema no es que ocupe espacio la fuente, que realmente ocupa muy poco, el problema es que se necesita una capacidad de cálculo bestial en la máquina para representarlo a tiempo real. El algoritmo del raytracing no es precisamente rápido (calculando lo que hará cada rayo de luz, en cada superfície y cada reflejo etc) pero tiene unas salidas fotográficas
#5 Y los mods que se curraban para estas intros. Qué tiempos :")
#7 De iq me soprende la capacidad que tiene de definir escenas y patrones de animación complejos matemáticamente. Parece que la animación de #0 sigue el mismo método: raymarcher en el fragment program con una escena definida por código. Hay muchos ejemplos en https://www.shadertoy.com/ (de iq), pero esa técnica demanda una GPU muy potente.
Lo sorprendente sería que fuesen capaces de hacerlo en código impuro y en tiempo irreal.
#62 Una textura la puedes generar en milisegundos sin problemas. Y si haces uso de aceleracion grafica, aun mas rapido.
#61 ¿Y la textura de mármol de las fuentes?
Tambien se sacan a partir de ruido perlin.
Tiene mucha más gracia si se ejecuta en tu PC en lugar de ver el video:
http://erleuchtet.org/~cupe/permanent/hg-the_timeless.zip
#26 matemáticas puras y duras.
Piensa por ejemplo en la función coseno(x). Su representación "coseno(x)" no ocupa casi nada, pero dando valores a "x" en el momento en el que ejecutas resulta en INFINITOS valores (entre -1 y +1).
Ahora imagina lo que puedes hacer con sumas, restas, multiplicaciones, divisiones, seno, coseno, números aleatorios, logaritmos...
#42 macho... déjame adivinar. Estás en primero de carrera y te crees que sabes discernir entre un "programador de verdad" y un "falso programador"
Esta increíble animación de 64 kilobytes es puro código en tiempo real
Aun está por ver el código que se ejecuta en tiempo diferido...
todavía recuerdo las de "Future Crew" como la Second Life, de 1993
http://www.pouet.net/prod.php?which=1216
Con un engine de hoy en dia necesitas 500mb para hacer eso
#54 Pues si te digo la verdad no tengo ni idea cuál es la diferencia entre OpenGL y un motor gráfico y qué se encarga de qué. Los cuatro pinitos que he hecho son con WebGL y por curiosidad más que otra cosa.
Buah. Ni me carga.
Mariconadas. Todo mariconadas.
Tunel 3D En 256 bytes de ensamblador puro, sin aceleradoras, ni librerías ni trampas: http://www.pouet.net/prod.php?which=3397
#87 En el sur, donde yo vivo, es exactamente lo mismo decir "no quepo en el asiento" que "no cojo en el asiento". De hecho es la primera vez que veo que a alguien le suena raro, así que imagino que esa acepción del verbo coger está más extendida de lo que te pueda parecer.
Si solo ocupa 64kb... ¿Porque me tarda en cargar el video de youtube casi 1 minuto?
Ya era hora que la Demoscene llegase a portada!
#23 ". Para mejorar texturas que se ven muy de cerca se usan filtros etc." Filtros bilineares, anda que no es viejo
Por cierto, con ese simple filtro, los juegos de Play Station se ven de lujo¹. Cierto que una TV de tubo de las antiguas, con los píxeles en forma de "corona"² no se ven tan borroso, pero en una pantalla de PC el render pixelado canta pero bien.
1. http://blogmageia.files.wordpress.com/2011/08/pcsxr_019.jpg
2. http://e.cdn-hardware.com.br/static/books/hardware/cap10-28_html_m59964a64.jpg
#37 Yo con menos, simplemente haz click: http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_surround.avi
Las órdenes que se envía al renderizador serán mínimas pero ejecutarlas corre a cargo de ese programa que, por supuesto, ni ocupa ni consume solo 64K.
#19 Justo venía a poner ese ejemplo. Tenían un "vídeo" de 64kb y ese juego que has enlazado tú de 96kb.
#19 #72 Otras, acabo de mirar las fechas y de eso hace ya casi 10 años. Pfff... dios, cómo pasa el p tiempo.
#36 No me funciona en Windows 8 ¿?
#18 También la RAE indica para coger 8. tr. Tomar u ocupar un sitio u otra cosa. Están las butacas cogidas. Pero no lo califica de vulgarismo.
Han llamado los 80/90, quieren sus demos de vuelta.
#78 en qué se parece la acepción de ocupar a la de coger? para mi en nada... no es lo mismo decir "no quepo en el asiento" a "he ocupado un asiento" cuyos equivalentes con el verbo coger serían "no cojo en el asiento" o "he cogido un asiento".
Dios mio, Scene en meneame, hay mucho potencial! concurso scene de meneame o party de meneame!
#90 Pregunta eso en Mexico….
Es fascinante, pero por pedir, en lugar del vídeo estaría bien poder tomar el código y ejecutarlo desde el navegador.
#24 "Desde el navegador"
Si fuera flash o JS si, pero lo dudo mucho....
Si se programaran de esta manera los programas de hoy en día, como procesadores de palabras, hojas de cálculo, presentación, navegador web, el sistema operativo completo, etc, ¿cuánto ocuparían y qué velocidad de procesador se necesitaría?.
¿El sistema operativo, núcleo e interfaz gráfica, etc, funcionaría en un computador con 16 MB RAM y 100 MHz?
Disculpad mi ignorancia, pero, ¿cómo coño es posible describir formas tan complejas en solo 64 Kb de código? ¿No hay archivos de texturas que se carguen por ahí?
Para poder hacerlo, entiendo que se utilizará un programa de diseño gráfico y luego lo convertirá en un código para que tenga una descripción compacta, porque si no es para volverse mico escribiendo esto a mano.
#27 Probablemente estés troleando, pero por si acaso... aquí tienes el ejecutable (imagino que para windows).
http://erleuchtet.org/~cupe/permanent/hg-the_timeless.zip
Ataque de nostalgia brutal! los mods, el pixel art, las demos :3___
#46 No, no, si queda claro que no van a lo fácil, pero es que tiene que ser un puto infierno escribir a mano todo eso. Hombre, son formas geométricas asequibles varias de ellas (arcos, esferas, etc), pero juntarlas todas y hacer determinados efectos tiene que ser de locos.
Se me hace un mundo describir una GUI básica en texto a pelo (para un programa Java, por ejemplo) porque es tremendamente difícil ver cómo va a quedar todo sin usar una interfaz gráfica para colocar los botoncitos, como para montarse un carajal de estos.
A lo mejor a quien esté metido en esto le parece obvio o incluso hasta sencillo hacer esto, pero yo me volvería loco intentando describir algo así en texto.
#33 ¿Y la textura de mármol de las fuentes? Es que hay un huevo de formas que no parecen triviales. Ole sus huevos.
#54 #57 Hombre, eso me resulta más razonable. Mínimo tienen que usar algo por detrás como OpenGL. Lo digo siendo profano en la materia, que conste.
y todo se suele generar de forma procedural. Me imagino que será más eficiente que guardarte una textura en un archivo, pero ole sus... (cc #49)
Comentan arriba que probablemente los juegos ocuparían menos si se generaran las texturas de forma procedural, pero me imagino que sería mucho más costoso/llevaría mucho más tiempo/sería difícil reutilizarlas, ya que entiendo que si las describes proceduralmente os referís a líneas de código y me imagino que eso implicaría que para poder usarlas necesitas acceso a código fuente y que ese código te puede dejar de funcionar a la mínima de cambio.
#15 gracias por el aporte pero no me funciona en windows 8.1
Para demos buenas las de ZX Spectrum, con un hardware limitadísimo
#81 mi gráfica es Nvidia GeForce GT 220, supongo que es gama baja entonces.
#4 Han hecho una versión para Android: requiere un mínimo de 2GB de RAM y 8 núcleos. Pero el usuario no tiene que preocuparse de cerrarla eh!
#12 ¿Ein?
¿Lo que ocupa 64KB son los datos que una vez ejecutados por un programa externo generan la animación... o dicho programa, que entiendo que es lo que llamais renderer tambien está incluido en los 64 Kb?
En cualquier caso increible
Demoscene, tiene decadas.
#41 Las texturas se pueden generar.
Demo con ray-tracing en opengl 4.3 en 64kb, muy impresionante, aunque el raytracing es algo difícil de mover a tiempo real así que los que no tengan una gráfica de gama alta que se abstengan de correr la demo y se conformen con el vídeo.
Ah, y en las gráficas de amd da igual cual tengas tampoco funciona.. les falta (a AMD) arreglar algunas cosas de opengl que tienen la implementación medio abandonada...
Me parece muy interesante este artículo me ha elevado mi nostalgia primigenia, yo me paré a la altura de la gamecube y ver cosas tan bonitas hoy en día... ya puedo morir tranquilo, incluso aunque me frían a negativos aquí en "menéame" que es la casa de otros pero en la que entro por el ADSL de Orange. God Save The Queen.
#55 Bueno yo tengo una partición con crunchbang (Distribución de linux) y me consume menos de 150mb, pero programar en poco tamaño no es lo mismo a hacerlo de forma optima, o al menos no siempre.
Si bien esta demo ocupa solo 64kb la memoria que utiliza después una vez comienza a generar todos los elementos es mucho mas que esos 64kb ademas y a pesar de su tamaño usa técnicas muy pesadas como el ray-tracing por lo que la potencia necesaria para mover la demo es muy elevada.
#57 Mírate esto por encima... es bastante esclarecedor.
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html
#68 #77
Creo que solo funciona en Nvidia en cualquier gama media alta que soporte Opengl 4.3 y con los drivers actualizados (337 o superior).
AMD tiene opengl medio abandonado y no funcionara o presentara errores, en intel no lo se pero si funciona el rendimiento seguramente sea malo.
bastante cutre para el nivel de hoy en dia...