Comment by satnhak | Hacker News Reader

Comment by satnhak | Hacker News Reader

Parent Full thread

Should also include be under 25 and have lots of time to dedicate to it. I've always been interested in the idea of graphics programming and a few years ago I started teaching myself vulkan. Not sure quite how long I spent in total, 6 months of free evenings, maybe a bit less. I'm close to having a rendering framework. But it's one of those things where the further you get with it the more you realise how little you know. You feel like you're sort of happy with how things work and then you discover, no that's not the right architecture. I guess it's basically the mathematics of applied lighting. That's what your doing. The rest of it is the plumbing. Oops, why do my spotlights shine straight through the cube? Oh, I need to calculate shadows. Spend a couple of weeks working out how to get that into the render pipeline. But it is a lot of "fun" if you're into that sort of thing.

Sadly, Vulkan is really painful way of learning graphics programming. Doing almost anything requires large amounts of boilerplate. Almost everything you need to do, for example to make shadows, requires just 10x more code than the technique fundamentally requires.

For learning graphics programming, in my opinion, writing software renderers is much more enjoyable path. Code is less, the code you write touches fundamental and not boilerplate. Downside is that code will be slower as you will lose HW acceleration.

Not necessarily, some folks advocate that with modern compute APIs we are better doing "software" rendering, but on the GPU.

By the way, this is what renders like OTOY Octane do.

Sadly you can't access RT cores with CUDA, you need to use a graphics API like Vulkan or D3D12. You can make a fast ray tracing based renderer using pure GPU compute, but it'll still be slower than using RT cores.

And even with GPU compute, you benefit from HW acceleration with the HW texture unit.

Not everything is about ray tracing, and still it beats any software rendering, while being able to use mostly regular C++.

I would classify GPU compute based rendering as software rendering though. My original comment was written with that in mind. This is a semantic discussion though which is IMO not super important.

If you do GPU-based software rendering, I would highly advice using RT instead of raster for visibility. It's simpler and likely also faster. But HW acceleration there also beats compute, in both, although you can achieve good results without acceleration too.

Reply on news.ycombinator.com