This demo marks the beginning of the SDF era in the demo scene. If you watch most demos from 2009 they still use solid geometry. elevated showed the superiority of just using fragment shaders for everything. By 2009 the GPUs where fast enough to do SDF and people had come up with the idea of ray marching.
"Elevated" does not use a SDF, it is based on a grid mesh displaced with a vertex shader.
Iq, the main author of "Elevated" is indeed best known for popularizing SDFs in the demoscene, but for that particular intro, the SDF raymarching trend had already started and he wanted to do something different.
Well, not really, even its readme file mentions previous work. Look no further than iq's previous demos, for example. Also, anyone who is interested knows when the phrase “zero polys and shaders” was sung.
However, “Elevated” had great visuals, great music, captivated people, and at the same time was a 4 kilobyte demo. It became a milestone instantly, as told by cheering on live video. And it became natural for 4K demos to implement everything in a shader to eliminate the rest of the code and be competitive on the new level of visual performance.
Using SDFs and other pure maths to build these kinds of demos makes me wonder why we don't just build a whole game this way.
Why not go one step further and just skip the geometry pipeline altogether? Most of the stuff I see on shadertoy has absolutely nothing to do with triangles.
Claybook[0] uses SDF throughout. I don't think any of the game is conventional poly-based geometry.
Having built with both SDF and conventional geometry, it's much easier to find excellent 3D modellers than it is to find people who can build with SDF though.
> it's much easier to find excellent 3D modellers than it is to find people who can build with SDF though.
Maybe we simply need to develop a more intuitive domain-specific language for artists to work at this level of abstraction? The benefits of working this way are incredible to me... Just in that one presentation you find quotes like:
> Runtime performance not dependent on brush count
> O(1) particle<->SDF collision detection
> Perfect LOD
From what I understood it should be. If you look at the source code there is music.asm with what seems to be tables of data describing the music data and synth.asm with synthesizer interpreting it.
Crinkler, the compressing linker, is really interesting. This link inadvertently shows the file_id.diz for Crinkler rather than anything relevant to the rest of Elevated; but honestly I always found the Crinkler stuff to be fascinating.
It is a very impressive pice of technology. The crazy part is the decompressor. It is ~200 bytes of handwritten x86 assembler, tuned for code smallness over 15 years. If you go to the release page, you see every time the shaved one or two bytes of of it. It’s also interesting how compression is done. They do only care about output size, not compression time. So it is possible that you just wrote a couple of KB of GLSL and the compressor takes 12 hours to squeeze that into your 4k demo.
Source code can also be viewed online via https://madethisthing.com/iq/Elevated , which is a platform made by one of the demo developers to share code.
Man that little "downloads in the past 30 days" tracker is cool. (HN made it a hockey stick.) It'd be cool if every indie/amateur website had that in lieu of the old "webcounter".
It has a many aspects one would want from a good universe.
Infinite detail. But not "boring". The digits of PI have infinite detail too, but when you don't know the algorithm itself, they probably look just random. Which would be boring. But the Mandelbrot set exhibits many nice patterns one can learn and reason about.
The algorithm that creates the Mandelbrot set can probably be implemented in less than 400 bytes.
This thread is quite interesting, if the universe is that simple does that imply a complex runtime? Because DC itself should probably be taken as part of the universe here as well as the OS and the hardware it all runs on.
So then the question becomes what is the absolute minimal hardware and software configuration that you could use to generate a mandelbrot?
> if the universe is that simple does that imply a complex runtime?
There is a tradeoff to be made between (algorithmic) information specified as a program/software versus an interpreter/hardware http://www.hutter1.net/publ/ctoex.pdf
One easy way to make our universe is to run all possible programs (even if you don't think our universe is computable, we would still end up running simulations which are indistinguishable to arbitrary precision). We can even apply an anthropic argument to this: that the vast majority of programs are not universes conducive to containing life, but we must necessarily find ourselves in one which is.
My feeling is that there is no such thing as a "minimal configuration" when it comes to universes.
Because there is no way to evaluate how "minimal" a configuration is.
No matter which elementary property you assume the universe to have, one would have to ask "Is that a complex thing?". Is gravity complex? Is an electron complex?
This reminds me of all the episodes of Closer to Truth[1] about the question "Why is there something rather than nothing?" He's absolutely relentless with that question, over two decades now, asking every single famous philosopher, mathematician and scientist he can find. Here's one from around Season 3 around 2009[2], another from season 12[3] a few years ago and so on.
This question is maybe the deepest of them all. What a great project, can't wait to check these videos out.
My understanding of an answer I've heard is along these lines:
If there is truly nothing then that means there are also no bounds/limits/rules, which means there is nothing stopping everything from being. Out of nothing comes the boundless cornucopia of existence, from complete lack of constraints that is nothingness.
Not what I really believe (I would rather have some data for that kind of thought/belief), given all the wierdness of reality, I tend to joke more and more often that we live in a simulation. This one (demo) is a beauty - always on the lookout for some exceptional demos. ^^
I like to imagine the outside universe has no computational limits. When you write code there, you can init an array of 10*1000 elements and have a loop that does heavy math over every pair of them, but it still runs instantly.
Elevated is one of the most atmospheric, cinematic demos I've ever seen, and the fact that it takes only a fraction of the disk space of the icon used to represent it in the file-manager is ridiculous.
Demos of this caliber are like F1 cars from 60 years ago: a single genius, or small team, creating something totally beyond the reasonable expectations of everyone who is familiar with the technology in question.
I really hope it continues to be possible for this art form to exist.
The most impressive for me, in a slightly different way, is A Mind is Born, because it manages to do some simple but impactful sound and video in 256 bytes, on a Commodore 64:
I was at a film festival, and saw a short film about AI or something. The film used just the music for the end credits! I told the director i appreciated the reference, and he was amazed someone recognised it.
My most favourite demo of 2000 was "Heaven 7" by Exceed [0]. That someone could do smooth raytracing (of course with many tricks, but still...) was mindblowing for me.
Ah man you just took me back to middle school. The 90s and the 2000s were such happy times in my life. Everything Farbrausch produced evokes such happy memories.
For whatever reason I became obsessed with this lesser known demo called g-cube and watched it a lot in 2011.
When I watched the '.the .product', my perspective about the computers have shifted dramatically and permanently. I became an high performance programming (not in HPC sense) enthusiast, and decided that performance and optimization matters.
That path brought me to HPC, efficient and high performance programming and showed me how thinking about writing efficient code made a difference.
Yes, you can't arrive to demoscene level wizardy in every application/tool you write, but optimizing the obvious and then some changes things a lot.
Thinking about it again, possibly coming from C64 and early x86 hardware already primed me to "do more with less" mindset already, but '.the .product' get the things rolling.
Thankfully for the graphics the very person who did the graphics in this Elevated demo is very generous with their time. Inigo Quilez has many instructional videos on his channel in how to code procedural graphics from the very beginner to the advanced. I link a couple of examples. You can watch the more advanced video even as a beginner but trying yourself is easier at the beginner level.
Indeed his videos are amazing. My recommendation though would be to start with the "beginner" video -- which is completely 2D but at least gets some ideas across. Then watch https://www.youtube.com/watch?v=PGtv-dBi2wE which isn't his but introduces how you get 3D out of fragment shaders. Finally just drink from the firehose -- https://www.youtube.com/watch?v=Cfe5UQ-1L9Q is fantastic, yes it's five hours but worth it. (Definitely come into that familiar with the idea of raymarching though... the first few minutes start off super basic but it goes to eleven real quick.)
I appreciate the recommendation to start with JS, I'm actually trying to avoid targeting the browser as much as possible with my projects, with the exception of things actually returning hypertext or that I get for free via wasm or something else.
The Book of Shaders looks quite interesting however, thank you for the link!
I'd encourage you to reconsider that. Using WebGL lets you skip over a lot of tedious initialization. Or, even better, using a platform like shadertoy.net lets you skip all the JS as well and just write shaders.
Using these tools doesn't mean your final project has to be JS-based as well. It just happens to be a convenient way to focus on specific aspects of the project.
Specific to this demo, Inigo Quilez did a breakdown back in 2009 called 'behind elevated' for Function 2009 but I can't find it on his site today. Maybe it's there. But here's the archive link to the pdf.
The same may have been said about most other technologies introduced. The fact that a Windows .exe can do a lot more because it has access to DirectX doesn't invalidate the effort made in a demo of the same size made for the C64. There simply are different categories.
I don't think they'll be much ruining going on. The people who make these demos use everything they can get their hands on, as long as it helps with cool visuals, a great soundtrack, and sandal executable size. In terms of how they get there everything seems to be allowed and even expected. And if one of those things is a trained network, so be it. Many groups have their own custom tools or even one-offs for only one demo.
If with "this beast" you mean Inigo Quilez, he worked at Pixar for a while, made shadertoy, and teaches the world maths via shadertoy, his own website and his yt channel. So he's doing pretty well I'd say
Just in case you're interested, there's an FPS made with similar techniques, called .kkrieger. The game itself if <96kB, and won the team a competition in 2004.
