https://youtu.be/il-TXbn5iMA

[boggo@mastodon.gamedev.place]

@datgame Looks very cool. I'm using similar techniques in my Fluff tool which gives me confidence I'm doing the right things.

[morten_skaaning@mastodon.gamedev.place]

@aeva @lritter @datgame what was the limiting factor BTW? Too expensive to convert the sdf to triangles? Too expensive to ray march directly? Too expensive to evaluate the sdfs, even if only evaluating them at sparse grid points?

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame there's no fast way to render them directly, so you end up in this endless search pattern of different intermediary representations and optimization tricks. Because it is easy to get to "interactive speeds", you have this deceptive feeling that you've almost cracked the code. Worse, you know it is possible to make work because people have shipped games built around SDFs

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame they're expensive to evaluate, so that means they're expensive to ray trace. sparse evaluation always loses information in ugly ways unless you recurse to some significant depth. there's fast(ish) meshing methods, but they look fugly, and usually need to be run at a high density.

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame I had some promising results by letting the results of ray tracing persist as point clouds, but maximally efficient point cloud rendering is another unsolved rendering problem, and there's a pile of unsolved problems this creates like how to animate things, invalidate caches, culling, and so on and also it requires some aesthetic compromises that limit its broader usefulness https://mastodon.gamedev.place/@aeva/113104448301517076

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame and by promising results I mean I got a very simple static test scene running at 120hz in a renderer that was specifically designed to be adaptive to any target refresh rate by decoupling the point genesis and shading from the swap chain cadence

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame I'm presently uncertain whether I will return to this project. I started doing a deep dive into the audio system, and I think I'm going to instead pursue smaller game ideas to help me prove out the audio synthesis stuff, but once I've done that if I return to this game idea, I'm likely to scrap the renderer and build something around meshes and mixed 2D / 3D for scope reasons

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame it turns out as a individual who works a stressful and demanding full time job, has a limited budget to hire help for side projects, had a lacking math education, is not charismatic enough to attract volunteer contributors, and has a growing number of disabling health problems and medical mysteries,

idk, someone else can go chase those signed distance windmills

[aeva@mastodon.gamedev.place]

@morten_skaaning @lritter @datgame these days with the world being what it is, I'm feeling much less motivated to make stuff that is likely to need fancy high end hardware. why bother when virtually any GPU pulled out of the trash in the past 20 years or so has a fill rate that would make Pythagoras weep tears of pure ecstasy. I don't need advanced math to make pretty graphics, I've got a fucking art degree

[lritter@mastodon.gamedev.place]

@aeva @morten_skaaning @datgame my experiments covered all stations aeva passed. SDF is technically impressive but only practical in offline / sparse realtime application. per frame root finding is wasteful when you already know where the roots are. baking is practical but can only afford to update a few objects per frame, and it's a chonk algo with a sampling limit.

the engine in the video, i doubt that it leaves much gpu frame time to support the rest of a game.