[pixelpoet]

I'd rather just directly raycast against a nicely compressed hierarchical representation than create horrendous amounts of triangle geometry and rasterise that. The code would be absolutely tiny, and not mostly a bunch of calls into someone else's code.

But, you know, gotta do the OpenGL / DirectX / whatever vanilla API thing... that's what graphics programming is, isn't it...

[eddd-ddde]

Would you happen to have a sample / example of this technique? I'd like to explore it.

[pixelpoet]

It's just normal old raycasting through a voxel grid a la Amanatides and Woo: http://www.cse.yorku.ca/~amana/research/grid.pdf https://github.com/cgyurgyik/fast-voxel-traversal-algorithm/...

Casting the rays from the camera will be nice and coherent, plus you probably get much better and easier shadowing using ray casts compared to shadow maps.

[amoss]

How does it handle dynamic scenes? The work by the OP looked like it took an update to the VAO/VBO if the chunk changed. What's the cost of rebuilding the acceleration structure here if the scene is updated?

[pton_xd]

That's the future but raycasting currently has some major drawbacks... namely that everything looks like a noisy mess when you look around.

Curious if anyone has plotted GPU compute increases against display resolution + update frequency increases? When do the two lines cross?

[zooi]

I'm fairly certain that pixelpoet is referring to direct raycasting, not raytracing (light transport simulations). These aren't noisy.

[pixelpoet]

I got nice and downvoted for it too, serves me right.

The noisy / Monte Carlo one is path tracing (which I've been doing since age 15 or something and commercially for over a decade), and that's indeed not what I meant but I guess all the expert gfxcoders at HN have done the efficiency analysis versus rasterisation.

Meh, I always have to remind myself how bad it is here for gfx stuff, might as well have been discussing cryptocurrency...