Rendering Worlds with Two Triangles on the GPU [pdf](iquilezles.org) |
Rendering Worlds with Two Triangles on the GPU [pdf](iquilezles.org) |
The Google cache version of the pdf doesn't include any images, so I put up a copy over here:
Know of any novel techniques/rehashing of old techniques that have been developed since?
http://www.pouet.net/prod.php?which=62027 (No idea what this is, but it's great)
http://www.pouet.net/prod.php?which=62974 (reverse fluid simulation)
http://www.pouet.net/prod.php?which=59613 (particles)
For 64k intros and size unlimited demos the possibilities are too many to list. Procedural mesh generation is a classic approach which has found great modern use recently:
http://www.pouet.net/prod.php?which=61204 (if you follow 1 link in this comment make it this one)
Here's a demo of someone playing around with it, complete with a Slisesix-inspired scene: http://www.rpenalva.com/blog/?p=254
This set of slides is also related: http://www.iquilezles.org/www/material/function2009/function...
People might enjoy noodling around the Geisswerks pages which have many code snippets around ray tracing; graphic demos; and so on.
Edit: I found a similar one on Shadertoy https://www.shadertoy.com/view/lsf3zr
I had no idea Iñigo Quilez's image was produced this way and I'm so glad I had the chance to see how it was made.
Thanks for posting!!
Here's an old experiment I did where the pixel shader is running on the faces of a cube http://dgholz.github.io/GLSLSphere/ The cube edges are highlighted in red so you can see them. I like green.
A Pixel shader is run when rendering each pixel of the quad. It's only input is often `time` and `resolution`.
At least in GLSL there's a global variable, `gl_Fragcoord` and provides the integer position of the pixel currently being drawn. So for example the pixel at the bottom left is gl_Fragcoord = vec2(0,0). The one directly to the right of that is gl_Fragcoord = vec2(0,1)
Given you're also passed the resolution can get a value that goes from 0 to 1 over the screen with
vec2 zeroToOne = gl_Fragcoord.xy / resolution;
Now it's up to you to use more creative math that given just gl_Fragcoord, resolution, and time write a function that generates an image.
You can play with that in your browser here, http://glsl.heroku.com and here http://shadertoy.com
In most standard 3D graphics, the CPU passes a description of the scene as polygons to the GPU, which then does two[1] shader steps - vertex and fragment[2] shading. The vertex shading works at the level of triangle vertices, effectively translating and and transforming the vertices, and then the fragment shader colors in each individual pixel.
So for a standard scene, the CPU tells the GPU: 'Right, we've got a room, with some pillars, and a monster, and a few lights, positioned like this', and then the CPU calculates what that looks like.
What Inigo is doing is that the CPU only knows there are two triangles - a quad covering the scene - so it just tells the GPU to draw a flat rectangle. The vertex shader does nothing but maintain the flat rectangle. However, because the fragment shader can be arbitrary logic, rather than just painting it with a solid color or even a texture, it is running its own simulation that involves drawing an entire scene.
----
[1] More these days with Geometry shaders, but that's another topic
[2] Sometimes called a pixel shader, although really that's incorrect - Fragment is a more accurate term
What kind of mathemagical trickery is that reverse fluid simulation?!