ria8651
commented
7 months ago hello, thanks for reaching out.
i think this would work but isn't very good for parallelization. for this to be most useful you'd have to do rasterization between raytracing passes and then find what pixels still need to be rendered incurring a massive performance cost. I'm also not sure how you'd figure out what pixels need to be raytraced as even if a pixel is rasterized there could be a closer voxel (assuming you have LOD).
however, hybrid raytracing and rasterization can be very fast the other way around. in alex I rasterize my chunks then ray trace their interior. because there are no decisions (everything is rasterized) it's very parallelizable, so the idea of a hybrid system is quite a good one.
So I have a potential optimization, if you want to mix rasterization and raytracing, So when you hit a voxel using raytracing you should draw all of the visible faces of that voxel using rasterization do your usual depth comparisons, skip pixels that already have a voxel face drawn on them for raycasting, except for the edges, because of anti aliasing. (use a sobel edge filter)
The reason I think this might work is that any other visible voxels aren't going to be entirely smack dab on the voxel you've drawn, they're going to be slightly offsetted, larger, or entirely not visible, and using the depth comparison you can draw them in the correct order anyway, letting you skip raytracing to each and every pixel, only ones that haven't been drawn to yet.
This method should work as long as you rasterize every part of the voxel that should be visible.
I'm going to make a diagram in blender for this, of course transparent voxels still need the full raycasting treatment, until the ray hits a solid, anyway.
Look at this line of cubes, try and find a scenario where one cube entirely covers up another when it's not supposed to. Make new screenshots even, show a scenario where one cube that's supposed to be drawn would be covered up due to it's pixels already being taken entirely.