For anyone interested in computer graphics, I find Inigo Quilez's site (https://iquilezles.org/www/index.htm) more helpful than most of the textbooks on my shelf.

These types of sites are where I too learned most of the graphics programming I know. My favorite when I was young was "The good-looking textured light-sourced bouncy fun smart and stretchy page" still available here:

* https://web.archive.org/web/20160519071801/http://freespace....

Oh my... I had been searching for that page for ages... I couldn't remember what it was called. Thanks! That old gem is gold!

Good old Hugo Elias :) When I first visited the UK in 2003 I made a trip to London to visit him, guy bought me lunch at a Thai restaurant. Quality bloke, and yes we all (graphics programmers from that generation) learnt so much from his page.

Im very interested to learn about computer graphics but the more I look into it I kinda feel its a niche field and not much strutted resource or curriculum is available. Would you have any tips on where I should start?

For 3D, the book “Physically Based Rendering” by Humphreys & Pharr is excellent. I think the entire text is free online nowadays.

The full text is available here: http://www.pbr-book.org/

The source is available here: https://github.com/mmp/pbrt-v3/

The latest text has an additional author: Wenzel Jakob

If you like some practical project I can highly recommend Day tracing in one weekend by Peter Shirley.

Great piece on iq's work on Pixar's brave that gives a sense of how unusual his approach was: https://www.cgw.com/Publications/CGW/2012/Volume-35-Issue-4-...

Inigo Quilez is such an inspiration when it comes to math, the demoscene and graphics programming in general. Hope he lives to be 120 and keeps it up.

Inigo Quilez's procedural raymarching masterpiece, "Surfer Boy":

https://www.shadertoy.com/view/ldd3DX

    // Created by inigo quilez - iq/2018
    // License Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

    // A surfer boy in the beach, disney/pixar style. I had to be very careful
    // with the complexity, otherwise the browser would crash during shader
    // compilation. I also had to split the boy in two layers because of that,
    // see below (the single pass version is smaller of course but takes 3 extra
    // seconds to compile, and renders a bit more slowly)
    //
    // This is totally painted to camera, it won't work from others perspectives.
    //
    // Common   - contains some basic stuff
    // Buffer A - renders the brackground - not super polished really
    // Buffer B - blurs the background
    // Buffer C - paints the boy, except the hand and the board
    // Image    - paints the hand and the board, and does some minimal postpro
    //
    // If you have a slow PC, you can watch it here:

https://www.youtube.com/watch?v=ya3FRzuozQ0

And Happy Jumping:

https://www.shadertoy.com/view/3lsSzf

    // Created by inigo quilez - iq/2019
    // License Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
    //
    //
    // An animation test - a happy and blobby creature jumping and
    // looking around. It gets off-model very often, but it looks
    // good enough I think.
    //
    // Making-of and related math/shader/art explanations (6 hours
    // long): https://www.youtube.com/watch?v=Cfe5UQ-1L9Q
    //
    // Video capture:

https://www.youtube.com/watch?v=s_UOFo2IULQ

    //
    // You can buy a metal print of this shader here:

https://www.redbubble.com/i/metal-print/Happy-Jumping-by-Ini...

I think it’s interesting to explore how different data representations in computer graphics are taking advantage of ever improving GPUs to enable new applications/workflows. The two I know of most are SDFs and Image-based rendering techniques like light fields, primarily as Neural Radiance Fields. Are there any other interesting ones emerging?

PS4’s Dreams is pretty advanced voxel tech. Quite a bit has been written about how it works.

I was actually looking for some resources on this but couldn't find much. Do you have any pointers? I saw Alex Evan's excellent talk from 5 years ago [1], which sparked my interest.

[1] https://www.youtube.com/watch?v=u9KNtnCZDMI

It uses SDFs as well, in both the voxel representation and in the stored operations that generate it.

Voxels, as evidenced by the recent release Teardown. NERF is pretty amazing but isn't real-time like SDF raymarching. Tetrahedral meshes are interesting as well.

One of the best Siggraph papers from last year was Monte Carlo Geometry Processing http://www.cs.cmu.edu/~kmcrane/Projects/MonteCarloGeometryPr.... It doesn't introduce a new representation, but does introduce a new way to render various representations by sampling them in a unified way

Raymarching stuff looks incredible in VR but most of the available examples are web-based and the overhead of WebGL for a technique that relies on raw GPU throughput often kills it.

Someone really needs to update this to work with current headsets and controllers: https://github.com/jimbo00000/RiftRay

(it works on the Rift last time I checked but uses the original 3DOF remove for interactions)

Valve actually used cdak (http://www.pouet.net/prod.php?which=55758) to demo their prototype headset.

It was a specially optimized version to be able to run at full framerate on the hardware of that time. I have looked for it but it doesn't seem to be available anywhere.

There is a Shadertoy version but without the optimization and last time I tried I actually had to tweak it a little to make it compile.

What overhead is that? Raymarching does rely on raw GPU throughput, but the common methods of doing it work by issuing extremely few API calls, and leaving the GPU alone to do the work.

API overhead caused by WebGL is absolutely minuscule.

Hmmm. I need to go back and check but I'm fairly sure I've had better performance from Shadertoy shaders ported to native than I've even had running them via WebVR.

Why would raymarching and VR be different from anything else and VR? What is the overhead of webgl you are talking about?

Raymarching is heavily shader dependent which shouldn't be bottlenecked by webgl at all.

I thought there were some differences in how shaders were compiled. I'm no expert on this but my understanding was always that WebGl couldn't get the same raw performance as native apps - even at the shader level.

Some of the slides here seem to support this: https://www.khronos.org/assets/uploads/developers/library/20...

What part of the slides support that? All it says is 'loss of performance on some mobile devices'.