Source code for 4kb demoscene production “Elevated” released
files.scene.org
files.scene.org
Binary: https://files.scene.org/view/parties/2009/breakpoint09/in4k/...
Video: https://www.youtube.com/watch?v=jB0vBmiTr6o
Everything you see and hear is procedurally generated by the 4096 byte executable, in real time. It still blows my mind 7 years after release...
I'd say this is quite an achievement anyway when I know I'd use more space than that just to store a single jpeg or mp3 sample.
"If you can't do it better, shut up" is a stupid argument.
Some pretty incredible things have been done there.
Let's you experiment with and compose different shaders.
This actually seems like it'll be much better for the job.
I'd love to see ISF export added too: https://www.interactiveshaderformat.com/spec
https://www.shadertoy.com/view/MdX3Rr
(iq is him.)
Alas, it doesn't run on this Chromebook...
...I had the thought a possible frontier in demoscene is make your own hardware out of discrete components to run your demo.
The MOnSter 6502 would count - http://monster6502.com/
Unofficially, you can find this particular talk here: http://on-demand.gputechconf.com/gtc/2016/video/S6860.html
fr-041: Debris [2], and kkrieger [3] (the 96kb FPS) are particularly worth checking out for the uninitiated.
[1] https://github.com/farbrausch/fr_public
EDIT: We can be generous and say 40kb for sake of adding more colours / etc.
It's the pigeonhole principle; there are only a few long videos possibly encodable as short programs because there are only a few short programs in the first place. To get compression performance, one has to target an ever smaller subset of possible videos, which eventually starts becoming an AI-complete problem.
Is it really? Could a human meaningfully distinguish between 2^4096 different 4 minute videos?
A five-word sentence with 1000 options per word isn't 5^1000 but only 1000^5 = 10^15. If we break the movie into 5-second blocks we get 48 of them in a 4-minute movie so (10^15)^48 = 10^720 different movies, which is not bad but we're still 10^513 away. There are a lot more variations we could consider - different actors, costumes, sets, framing, color grading etc. and I think it's plausible that we could come up with enough features. Heck if you talk twice as fast, you could get (10^15)^(48*2) = 10^1440. But it's a lot bigger than I made it out to be.
Although disappointing, you seem to have the correct answer for my question.
The only thing I have to give this function, is the height/width ratio, some other ratio that define how large "corner holes" are in the LST configuration, the amount and relative position of windows and door, the starting point and NSEW direction for inside walls, and with all that, I could create a house of a story building with an inside. Of course it's not finished yet, and there isn't furniture of details, but you see that in theory, you can use procedural generation as a compression tool for human-designed structures, that no machine learning algorithm or autoencoder could really achieve.
If you associate this kind of algorithm into a well made openstreetmap database (think vector tiles which are used for GPS software), you could also recreate the whole world in 3D, with enough details to make a game that would not require that much disk memory. Recreating the roads, fences, parks, rivers, vegetation, elevation etc is difficult because it require a lot of tuning and geometry tricks, but it's very cheap in term of cpu cycle and disk.
The folks at outerra have begun making an actual software that lets you browse the entire planet in 3D. You can zoom in real time from space to 1cm. They don't have cities yet though, but they are planning for it. I want to make a game using such ambitious ideas, but it's not easy...
The Kolmogorov Complexity of a video (or any other data) is the size of the shortest program which outputs that video then halts. This 4k executable is similar in spirit, but also follows strict rules about efficiency: Kolmogorov complexity places no time limits on that shortest program, whereas this program must output pixels fast enough to make the video realtime.
The practical answer is no. There is an unimaginable amount of possible 3:30 minute vidoes—far more than the number of possible 4kb or even 40kb files.
To be fair, most of those possible vidoes are just noise. We don't have to be able to compress those because people don't care if one video of noise is different from another. We also don't have to reconstruct the video perfectly: as long as it looks more or less the same, the audience is happy. (This is called "lossy compression".)
But even with these caveats, there is no realistic method for compressing realistic 3:30 minute videos that well on a computer. We likely can't do all that much more than current compression algorithms without a different set of tradeoffs. (Like being better at some videos but worse at others.)
That said, a big part of how compression works is by relying on information already present when decompressing. This demo relies on having a particular kind of chip with certain capabilities (ie a CPU and a GPU) and presumably some standard library functions... etc.
How well could we "compress" videos if we had more information available when decompressing? Here's a fun thought experiment: what if we had a model of a human mind? We could then feed in a pretty sparse description and have the model fill in the details in a natural intuitive way. It would be very lossy, but the results would be compelling.
And you know what? That's a decent mental model of how speech works! If you just look at information content, spoken words are not very dense. But if I describe a scene you can imagine it almost as if you're seeing a video. This works because we both have the same sort of brain as well as shared experiences and intentions.
You can think of speech as incredibly effective—but also rather lossy—compression.
Your thought experiment sounds more like a "codec" than a procedural generation. I guess it is an arbitrary line given that we are using CPU, etc. But the bigger the decompressing "model" the further away from true 4k compression we are.
For example, if you can only tell something was lossy by directly comparing two instances of the same video during playback, then that's probably good enough in most situations.
It occurred to me that we could compress the hell out of written works by translating them into some super dense language, and ultimately only retain the basics of the meaning/concepts/some of the writing style. Then can re-translate that back to whatever language we want to read it in.
For compressing pictures or videos, there could be some similar translation to a much more compact representation. Would probably rely on ML heavily though.
But, yes, at some level there is an idea of a dna seed and a process to create something much more profound, we as humanity haven't come close to cracking that, though.
For example, and output of all zeros, or the source for a a random number generator itself, or a zipped archive of a work of Shakespeare.
It's fun to think about anyway.
zeo-x-s/cdak
http://prostheticknowledge.tumblr.com/post/73734927255/cdak-...
Beautiful soundtrack from Lassi Nikko (tpolm/orange) and crazy cool raymarching shader work from unc (quite)
shadertoy version with VR support:
http://www.pouet.net/prod.php?which=67106 / https://www.youtube.com/watch?v=qRVTI2y0BBg
That is mind blowing.
Leaves quivering on a branch, realistic flames, realistic humans!
The water wasn't quite right but still.
The flames are very simple particles, the flame effect is probably the simplest particle effect you can do. The particle scene is blurred though before rendering the human figure, so the irregularities are not that visible.
The humans are simple black+white cutouts (they might be even stored as a single bit per pixel) with a small "light edge" on the side (most likely applied as an effect and not part of the data). It isn't very visible in the YouTube video because the compression smears a bit the scene, but if you run the demo locally you'll easily see it.
The intro isn't that high tech (compared to other intros of course), but Conspiracy are masters of presentation - the scene with the humans, leaves, mountains, house, etc wouldn't look as good as they do if it wasn't for the color grading, the camera motion and framing, the post processing and even the sequence the scenes are presented.
https://www.youtube.com/watch?v=JZ6ZzJeWgpY
The scenes with the moon being peppered with impacts (3:31) and what appears to be storms on Jupiter are beautiful.
Fermi Paradox was also dioramas, but: Each one had had some engaging event happening, or at least well directed camera movements that exposed new visuals to the viewer over time or show-cased the full 3d nature of each scene. Additionally each scene had at least one well done graphics effect. The music was almost movie quality and in a few parts nicely synched up with the visuals.
i've submitted it previously: https://news.ycombinator.com/item?id=7739599
It's great that it's open source now! That means if someone's really motivated, they can update it to run on modern environments (by no longer keeping it 4 KB), even OS X, etc.
Hats off to Inigo and others.
http://www.iquilezles.org/www/material/function2009/function...
https://www.reddit.com/r/programming/comments/4msf41/elevate...
https://news.ycombinator.com/item?id=11837687
(I think there are others, but I can't find them now.)
Maybe it was some bot, but that's an odd bot.
It could be a bot tactic to build accounts with karma that can later be used for astroturfing, using proven comments from elsewhere. Maybe governments and organized astroturfers have automated that sort of thing more than we think.
Watchful users can help out with this a lot. If you or anyone notice comments being cross-posted in the future, please alert us at hn@ycombinator.com.
> With cinematic look, like taken with a real camera. We had some dissagreements here
> • I absolutelly wanted to avoid the CG look - the danish part of the team wanted something sharp and shinny
> • I wanted a hand-held TV camera - they wanted a sts04 like smooth lovely cameras
> • I wanted a realistic scenery - they wanted more action in the scene..
And exploiting impressionism as a compression technique:
> The idea is NOT to render perfect snow, but to draw something that evoques snow, and let the viewer’s brain to trick the viewer.
Edit: just read your other comment about real challenges in the C64 subset of the demoscene. That's like "You set a record in a 1600m race? For a real challenge, set a record in a marathon." It's just arbitrarily moving the totally legitimate goalposts to a different challenge because you prefer it.
It would be impossible since pixel shaders didn't exist until the 2000's ;-)
As for software rendering: Since a pixel shader is essentially a program executed for every pixel, it's trivially portable to the CPU: Just turn it into a function and call it for every pixel on the screen. Making it fast is another matter altogether though.
Lmao. You got me there.
"Just turn it into a function and call it for every pixel on the screen. Making it fast is another matter altogether though."
I was imagining it took up many MB of memory and massive cycles even on a multicore CPU. Suddenly, one faces tough decisions about organization, resolution, primitives, techniques used, algorithms, and so on. Gets really, really hard to make tiny and fast stuff without that GPU doing heavy lifting. :)
Pointing at the GPU as a particular cheat or a make-easy button is not relevant to the conversation, in this light. Having a Gravis Ultrasound was also a cheat back in the day ;) It's all fairly arbitrary stuff, and in the end, the point is to present something cool running on the hardware and within the nominal restrictions, even if you get tricky to do so.
Another good, detailed perspective on it. Appreciate it. I'll especially agree with the part I quoted. :)
[1] https://people.csail.mit.edu/ericchan/bib/pdf/p289-hanrahan.... [2] http://www.cs.unc.edu/~olano/papers/pxflshading.pdf [3] http://www.cs.unc.edu/~pxfl/papers/high-speed_rendering.pdf
BOOM! I knew it was going to be huge. That's a beefy GPU + 300MB in RAM + pregenerating. I'd have... made sacrifices to have that even in the Half-Life 1 days. :)
I mean, sure, but think about how big 4KB is, the tricks that are being used to create the scenes are crazy hacks using default Windows sound files and literally anything the executable can reference on the cheap.
Procedural content generation is really expensive (in general), but that's the beauty of it. You find a way to abstract the content into an algorithm, and then you can reduce the size of the assets, but you pretty much always need to pay the price somewhere.
But hey, I understand the sentiment, I wish Slack didn't consume 2 GB of RAM on my machine.
It does just about everything on the GPU. All the CPU does is repeatedly render two triangles and play music: https://news.ycombinator.com/item?id=8070879
Here it has been adapted to WebGL: https://www.shadertoy.com/view/MdX3Rr
Edit: I'm wrong about the two triangles. From the .nfo-file:
for those wondering, this a (too) low density flat mesh displaced with
a procedural vertex shader. there arent any texturemaps for texturing,
instead texturing (and shading) is defferred and computed procedurally
in a full screen quad. this means there is zero overdraw for the quite
expensive material at the cost of a single geometry pass. then another
second full screen quad computes the motion blur. camera movements are
computed by a shader too and not in the cpu, as only the gpu knows the
procedural definition of the landscape.Tricks could have long-term benefit given any emerging FOSS GPU is more likely to be like one of the older ones given complexity of new ones. I'd clone one like SGI's Octane ones they used to do movies on with mere 200MHz processors. Meanwhile, similar tricks might let one squeeze more out of the existing, embedded GPU's in use. Maybe subset a PC GPU in demoscenes like one of the smartphone GPU's. Yeah, that's got some interesting potential.
The .exe is 4K (it has been compressed using Crinkler), not the application's RAM requirements. The game .kkrieger for example is a 96K .exe, but uses several hundred MB of RAM when run.
Also, the strict size requirements can interfere with execution speed. From the .nfo again:
believe it or not, this was running at 30 fps in a gefoce 7900 at some
point, but size optimizations forced us to ask you for a pretty decent
graphics card, like a geforce 8800gtx or hd4850. please, make sure you
have d3d9_33.dll somewhere there. also, you only need windows xp.So, I think there's potential for GPU subsets or CPU/GPU tradeoffs to make for interesting opportunities for people to show off brilliance.
Since the demo was originally entered in the 4K competition at the Breakpoint 2009 demo party, it had to run on the computer designated to run the competition's entries. So it's not like it could require an arbitrarily powerful GPU.
Although the compo computer was pretty beefy for the time: https://breakpoint.untergrund.net/2009/compos_pc.php
" Intel Core2Quad at 2.66GHz, 2GB of RAM, with a NVidia GeForce 295 GTX with 2x896MB of VRAM. "
Double CPU and more GPU than what I'm writing this on but half the RAM. Beefy indeed. .exe size is still impressive and all given what they're doing.
I remember overhearing a conversation in the Sun cafeteria about how the Aviator flight simulator only had one-half of a 3d model of the airplane, and it just reflected it to get the other half. They complained that was cheating, but that's just how it is!
Btw, I'd probably have left off Space Invaders for exact reason you mentioned. Curious to know what you find to be most impressive demo on that system, though.
Yes, there is massive amount of power available but it's not easy to use effectively. You need a different mental model how things work, there's very little shared state and all the algorithms used have to match the model of computation.
Using the GPU almost exclusively, generating everything procedurally is a massive accomplishment and much more difficult than "normal" CPU+GPU programming or using just the CPU.
I do not share your view that this would be somehow less impressive because it uses the GPU.
My points of comparison are what they're doing vs what it's designed to do with what vs what other people do with that and other hardware. It looks great with lots of efficiency. I'll give them that. It's just way less impressive to me given they're using a powerful graphics card to mostly do what it's designed to do plus their innovation.
> It's just way less impressive to me given they're using a powerful graphics card to mostly do what it's designed to do ...
This demo isn't at all what the GPU is "designed to do". The all-procedural graphics is way different from drawing artist-generated 3d models from memory while being orchestrated by the CPU. While it is more commonplace today, this demo was pioneering work in "all GPU" procedural graphics.
Which people used to do things they weren't designed for at all in so-called GPGPU work. The results defaulted on really, clever work. It's why I brought it up.
"The all-procedural graphics is way different from drawing artist-generated 3d models from memory while being orchestrated by the CPU. While it is more commonplace today, this demo was pioneering work in "all GPU" procedural graphics."
This is where I likely slipped up. I forgot how old this one was. I retract that claim then.
Just because the tools are more capable doesn't mean the challenge is any less real or the result less impressive.
I think farbrausch was one of the major groups who did this sort of thing https://github.com/farbrausch/fr_public
Models are just serialized polygon meshes. We've been using models for demos for way longer than DX/OGL have existed. They're just another tool in the box which you can use (if you want to).
Using DirectX or OpenGL nowadays is like using the CPU: it's just part of the stack. They are probably lower level than you think: using DX/OGL isn't just doing something like drawModel(model, x, y, z), it's way lower level than that.
This demo in particular is not very different from old school demos. Back in the day we had interruptions, now we have API calls, but in the end shaders are just code. Elevated uses D3D to execute them in the GPU but that's all. And the synthesizer is apparently coded in ASM.
Even if you really miss the old school platforms there are still demos produced for them, often pushing the limits of what can be done.
Check http://www.pouet.net/ for lots of impressive demos.
Additionally, please correct me if I'm wrong, older demos didn't have nice graphics apis to call. They had to create and store what's given for free by Apis these days into their binary. I think the Amiga did have some 3d stuff?
With opengl with a handful of lines you could get a spinning cube with lighting. So much more work had to be put into older demos to get to the same point. On top of that, the demo writers really had to know the hardware well, and diving into undocumented behavior. A lot more was being calculated on the cpu back then too.
I haven't been on pouet.net in a while but I will look at newer demos.