Skip to content
Hallway
0:00 / 0:00

#claybook#signeddistancefields#raytracing

DD2018: Sebastian Aaltonen - GPU based clay simulation and ray tracing tech in Claybook

Digital Dragons

10K subscribers • 5 videos on Hallway

YouTube
  • Recommended by 3 people: 3 in engineering communities.
  • A classic. People kept recommending it from 2021 to 2026.
  • Presented by Sebastian Aaltonen, co-founder of Second Order
  • May be out of date. Uploaded 8 years ago, in an area where tools change fast.

Advanced. Deep dive for people who know the field.

28K views8 years ago3 recommendations

Graphics and audioGame developmentRenderingGPUs, shaders and CUDA

Sebastian Aaltonen details the GPU-based clay and fluid simulation, signed distance field modeling, and ray tracing techniques used in Claybook.

Second Order is a new Finnish indie game company formed by two ex-Ubisoft industry veterans. Their first game, Claybook, packs lots of innovative technology, including a GPU-based clay and fluid simulator, fully deformable world and characters, signed distance field modelling, and ray traced visuals. Sebastian will discuss how this technology was created, what kind of optimizations and tricks were needed to hit 60fps with the game’s ray traced visuals and simulation on current generation consoles, and how their non-standard renderer and simulation technology was integrated on top of Unreal Engine 4.

Why it's here

3 people recommend this

What people say. Recommended as a prime example of polygon-free rendering and complex signed distance field simulation in games.

u/corysamain r/gameenginedevs • Recommends

On “New and unusual engine types”

Dreams is the stand-out example of a new type of engine https://www.mediamolecule.com/blog/article/alex_at_umbra_ignite_2015_learning_from_failure_video Teardown is doing a great job of voxel physics https://www.rockpapershotgun.com/how-teardown-made-a-great-game-from-destruction Claybook is a polygon-free game link to this video https://ubm-twvideo01.s3.amazonaws.com/o1/vault/gdc2018/presentations/Aaltonen_Sebastian_GPU_Based_Clay.pdf https://www.lexaloffle.com/pico-8.php and the like are modern takes on retro game dev. Retro game dev is getting easy enough that some people are making their own NES-like consoles https://www.gamedeveloper.com/design/building-a-homebrew-video-game-console FPGA dev…
17View on Reddit

u/mahalisin r/gameenginedevs • Recommends

On “Is there any algorithm or game engine that can render highly complex SDF (or other mathematical representation) scenes?”

As /u/Separate-Change-150 says, Dreams is kind of **the** canonical example of this. There’s a great talk up somewhere about the development trajectory they took. Another one that shipped was Claybook, which its developer gave a GDC talk about( link to this video One reason there are so few shipped examples is that SDFs and other implicit-surface representations are pretty hard to make “real game”-sized content with. Raymarching is expensive, and scales badly with scene complexity and screen resolution. Tons of people have started on SDF-based engines for some of the same reasons you are, and run into perf or authoring issues that they decided were insurmountable. It’s far from a dead end, and there…
9View on Reddit

u/turtle_dragonflyin r/gameenginedevs • Recommends

On “Sharp edges in editable SDF terrain -- practical alternatives to Marching Cubes / Transvoxel?”

You're welcome! Also, these tech talks might be of interest to you. they're in my article I linked, but just putting here to be sure you see 'em. * Dreams 2015 SIGGRAPH * corresponding presentation PDF * Claybook 2018 tech presentation
2View on Reddit

u/warampedin r/GraphicsProgramming • Mentions

On “Composite scene SDF from mesh SDFs”

These references may help! link to this video And (forgive the ugly url) https://ubm-twvideo01.s3.amazonaws.com/o1/vault/gdc2018/presentations/Aaltonen_Sebastian_GPU_Based_Clay.pdf
7View on Reddit

u/LiJaxin r/GraphicsProgramming • Mentions

On “SDF Rendered Game Engine”

Hi there, in the video posted above and in previous SDF Renderers I've made, my draw calls have simply been a single a single fragment shader pass with a big list of Shape information passed in as a UBO. And then in the fragment shader when I do a raymarch, I iterate over the list of shape information, and do my combining there, with combination functions which are discussed here. As for performance, I do preprocessing of shapes to get a bounding box in the CPU so I can do culling, as well as optimized my shader to avoid any extra condition statements I don't need, since that seems to be the killer. Unfortunately even with all that, if I start getting up to 40+ shapes, my performance sta…
1View on Reddit