Hacker News Reader

Comment by zokier | Hacker News Reader

I might ask here; RTX has been out for 2.5 years, has there been any cool demos (in the demoscene sense) that use RTX in an interesting way? Because I can't recollect any, but then I have been following the scene pretty loosely lately.. I would have imagined its a tech that some coders would be very interested in.

View on HN

There is already a lot of raytracing in the demoscene, no need for RTX.

RTX accelerates ray intersection on a typical scene from a video game. But demos are usually not typical scenes, instead using mathematical models like signed distance fields that work differently.

There are other issues: you need compatible hardware, it is not well supported by OpenGL if at all, there may be too much overhead for 64k or less intros.

Personally I don't see how to take advantage of it in a way that opens new options, but maybe someone else will do. After all, it is something the scene is good at.

Demos outside of small sized intros usually still work with traditional mesh geometry, so RTX could have been helpful at least there. It's just not that many people are doing big demos anymore.

For small intros it's almost as you say -- RTX is mostly uninsteresting and not that helpful for current status quo at least on the surface. However, while SDFs are do indeed provide a relatively cheap and intuitive way to specify your scene spatially to allow ray tracing and GI approximation with varying degrees of fakiness, they confine you to a rather limited abstract geometry stlye. Anything beyond yet another repeated-rotated-cube-with-cutouts-fractaled-to-death is rather uncomfortable to pull off and is also usually very slow (see iq's incredibly realistic works). That's why most of the intros from last 10+ years look rather similar.

Also, I've been recently playing with Vulkan ray tracing extensions and turns out it's not that hard to pull off. There's a considerable upfront cost (Vulkan being verbose as it is), but it's totally manageable, around maybe 10-20k compressed. The entire PoC intro with music was about 60k, and I haven't even started optimizing it for size. It had also been compressed with "just" UPX (apparently ray tracing extensions work only in 64-bit mode, so more sophisticated compressors are out of the question). I've heard that recent work on native 64bit compressor from Ferris removed another 16k from it, so there's definitely a lot of room for actual content in 64k+rtx.

Are you the same provod[1] that's adding Vulkan and rtx support to Xash3D/Half Life 1?

[1]https://www.twitch.tv/provod

yes

I was fearing that Vulkan might be bit verbose for small intros (like e.g. 4k)... Do you happen to know if DirectX (DXR) is as bad these days?

i don't know a thing about modern directx :D (the intros i work on are almost always developed on linux and only then ported to windows for official/party release)

Vulkan is just overkill for 4k, apart from music most 4k's these days is just a 1(sometimes 2) shaders with a TINY OpenGL/d3d loader stub to kick them off (basically compile the shaders, and setup and render a quad over the full screen).

I was playing around with mesh-gen for 4k back in 2010 and you'd eat up most of your budget before even rendering, this is why SDF based raymarching reigns supreme for 4k intros (and are quite popular for larger categories as well).

Yeah, only reason I was thinking of Vulkan is that afaik it (and DXR) is the only way to use RT cores at all. Not for the other fancy stuff that big game engines need and use (complicated state/resource management etc).

And I'd be kinda surprised if you couldn't do something interesting with RT cores even in size-limited formats (possibly more in 64k than 4k though), even if maybe not quite the way nvidia intended.

I'm not sure there's an obvious way to (ab)use RT cores for something not directly RT-related. I don't know about DXR, but Vulkan RT API is rather high-level. You never see RT cores directly, you can just produce an opaque Acceleration Structure objects, handles to which can be used as an input into some shader functions. The way these ASes are built is rather rigid, and you never see what's inside (i.e. there's no actual guarantee that they're implemented using a BVH of sorts). Shaders are also directly RT-specific, i.e. you can only ask questions like "what will I hit if the ray is cast from this point into that direction". There's no API to e.g. traverse an AS manually, although you can get your hands on non-nearest hits if you want (for e.g. transparency).

You can sensibly use RT APIs together with raymarching. There is a notion of custom geometry that's specified using bounding boxes. When ray hits one, it's your responsibility to compute an exact intersection manually in the shader. This can definitely help with complex scenes with a lot of very different sdf objects that don't intersect much.

But yeah, in that case you'd still have to pay the Vulkan price first. I might experiment with what can be the size-chepest way to get vk rendering.

Reply on news.ycombinator.com