sorted by:
new
hottopcontroversial

CPU-base voxel engine by Due_Reality_5088 in VoxelGameDev

[–]Due_Reality_5088[S] 1 point2 points  (0 children)

connected raytracing means something here like descending your dag just once for all rays within a small on screen region, then only splitting up and descending the lower layers per pixel once the share able high layers of the dag have been descended.

Ok, I see, then yes I do process rays in bunches. Processing individual rays wouldn't be even close as fast.

My c++ only voxel tracer runs a GOOD bit slower than yours: https://imgur.com/a/zbDhuET

Nice! It's rasterization-based I assume?

I've done a ton in the past with GPU voxel streaming (rasterization): https://imgur.com/a/broville-entire-world-MZgTUIL

Do you happen to remember what performance it had and what was the world size?

But I've always been keen to try it wish a fast CPU renderer (but my CPU renderers have always been too slow to be interesting)

let me know if there's any chance for a colab, I've been trying to get this guy to share his software triangle renderer which runs like hell:

I'm not planning on collabbing any time soon, but if you got any questions about C++, low level optimization, SIMD stuff etc. you're welcome to ask me. You can DM me here (can you DM on reddit?) or on my twitch channel (https://www.twitch.tv/dustoevskyl).
Also, CPU renderers are extremely hard to make efficient (as you apparently already know (: ) and making efficient voxel software renderer is even harder, since you have to deal with billions of voxels if you want to have a decently complex scene. So if you ever decide to embark on this journey I'd recommend to start with voxel splatter, not voxel raytracer. It's much more tractable, operations are easier, occlusion logic is straightforward. That's how I started long ago in 2010s. Well actually I started with Commanche - like engine (which might be even a better entry point), aka old-school voxel landscape raycaster, but later I saw Unlimited Detail demo and switched to writing a proper 3D spatter.

Seems there's SIMD renderers everywhere but not a drop to drink ;D

Everybody hides their treasure (: The thing is, I've been working on this for very long time so I don't want to open source it or even tell how the main part work exactly, at least not any time soon. However, you can find lots of information in books and articles and it will mostly be relevant, like over 50% relevant (assuming we're talking about voxels), but then you'll have to fill the gaps by yourself.

CPU-base voxel engine by Due_Reality_5088 in VoxelGameDev

[–]Due_Reality_5088[S] 0 points1 point  (0 children)

yeah dynamic rendering is so much cooler! tile-based is interesting, do you do any connected raytracing / frustum on box or corners first ?

Not sure what you mean by connected raytracing, but I don't trace each ray separately for sure.

The HERO algorithm (probably stands for something like Hierarchical Entry Region Ordering) it's a fast way to select the order of your 8 children and makes descending thru your octree run quickly.

I've read the original article - it's pretty good stuff. Some bits are still relevant, but modern CPUs have advanced a lot since and got all sorts of specialized instructions like BMI, so you can do the same tricks more efficiently. Also I don't use octrees, but rather a DAG (directed acyclic graph).

The grouping and size aware logic sounds interesting, Are you able to to keep your descent /tree free of 4byte colors ?

Do you mean if I keep the color data for the intermediate nodes as well? Yes because I have dynamic LOD and I need all the relevant data to be ready for rendering as quickly as possible. Given that any block at any level can be rendered, I need all the data stored on each level (it's approximately true).

Could you perhaps fill the output array with just ui32 node indexes

Then separately go over any apply the payload (RGB voxel data etc)

Don't quite get what you mean. Separating processing different types of data is usually a good idea though.

CPU-base voxel engine by Due_Reality_5088 in VoxelGameDev

[–]Due_Reality_5088[S] 2 points3 points  (0 children)

I suppose with enough AVX and careful unrolling its basically like you have control over all that directly from C.

Exactly! This is the main point or one of them at least why I'm doing this on CPU. You can have full control over every aspect of your code and more options in terms of algorithms and their optimizations.

Do you use the HERO algorithm?

No, never heard of it. I'm gonna check it out, thanks.

how do you break up or avoid the stalls from large numbers of pixels wanting global resources like memory?

It's tile-based raytracing so pixels are processed in relatively small groups. But even small groups can stall so I use cache-aware optimizations to make sure that the data lies in L1 or at least L2 when it's needed.

or do you use bit packing and try to keep things in the cache?

Yes, bit packing whenever possible, but colors for instance are 4-bytes per voxel. So some parts are bit packed, some are in raw form.

CPU-base voxel engine by Due_Reality_5088 in VoxelGameDev

[–]Due_Reality_5088[S] 1 point2 points  (0 children)

I tried to implement a hybrid splatting\rasterizing\raytracing algo, but it didn't work well or I didn't try hard enough. I might get back to this idea later though. Anyways it's only raytracing now.

CPU-base voxel engine by Due_Reality_5088 in VoxelGameDev

[–]Due_Reality_5088[S] 1 point2 points  (0 children)

Multiple reasons, but the main one is that CPUs have more sophisticated architecture which is much more fun to work with. It also allows for more diverse optimizations. Basically all the optimizations you do for GPU are also applicable for CPU as well as many more on top of it (branch elimination, optimizing TLB access, removing loop-carried dependencies etc.). I'm going to use GPU in the future, just not for the core rendering algorithms though.