I want to make a voxel rasterizer where each voxel is only 1 pixel but I'm debating on how to do it. Should I use a directX vertex buffer and just draw them as pointlists or would it be better to render them using a compute shader?


I'm leaning towards compute shader because I don't think graphics cards are optimized to draw points with the typical pipeline.

lol your threads crack me up. Do you have ADD?

Anyway you'll want to research 3DDDA and read laine's paper on efficient SVO rendering. You mention "pixel" but that doesn't mean much. When defining volumes you want to use terms like mm^3.

And you're right. You'll want a compute shader or even a full screen pixel shader. (Render a quad with your shader binded). You'll want to target DX10/11 which have enough computing power for this kind of task. There's tons of reading, but generally you'll be on your own. It's not a highly researched area. Good luck

I will point out that depending on the SVO format you decide on you might want to target a CPU. An i7 chip might outperform a GPU. You can write most of the SVO rendering algorithms as branchless code using conditional moves. Also SSE instructions and easy access to memory on the CPU can make programming really nice. Either way with the GPU method you'll need to stream data to buffers to render anything decently complicated.

Actually, I don't think I'm gonna use SVO, I've come up with my own data structure for storing voxels, but I could probably intertwine it with SVO if it was beneficial.

I was more wanting to just perform the world to screen transforms the typical raster way with some matrix transforms, and was thinking compute shaders would be good at that.


I know a voxel differs from a pixel, I only meant that I wanted each voxel to render as a single pixel, instead of huge blocks.

Actually, I don't think I'm gonna use SVO, I've come up with my own data structure for storing voxels, but I could probably intertwine it with SVO if it was beneficial.

This isn't always obvious but you really need to use an octree. My own format doesn't, but I haven't full tested it yet. The problem with anything other than an octree is that you lose the ability to do easy mipmapping. (Again not a highly researched area). Voxels must be mipmapped someway. If you don't use a mipmapping technique you'll get the same shiny effect that you'd see with regular texture rasterization.

Also I will point out that octree is essentially a very optimal approach. Laine's paper uses 1 mm^3 voxels. Using an octree allowed him to store all that data. There's also a huge cost rendering against an oblique plane of voxels. Octree traversal minimizes this cost. Other formats can cause you to traverse way too many voxels.

[quote name='Butabee' timestamp='1308288464' post='4824357']
Actually, I don't think I'm gonna use SVO, I've come up with my own data structure for storing voxels, but I could probably intertwine it with SVO if it was beneficial.

This isn't always obvious but you really need to use an octree. My own format doesn't, but I haven't full tested it yet. The problem with anything other than an octree is that you lose the ability to do easy mipmapping. (Again not a highly researched area). Voxels must be mipmapped someway. If you don't use a mipmapping technique you'll get the same shiny effect that you'd see with regular texture rasterization.

Also I will point out that octree is essentially a very optimal approach. Laine's paper uses 1 mm^3 voxels. Using an octree allowed him to store all that data. There's also a huge cost rendering against an oblique plane of voxels. Octree traversal minimizes this cost. Other formats can cause you to traverse way too many voxels.
[/quote]

With my data structure I can do mip mapping. Although, I'm thinking now that I should ray cast into my structure instead of rasterizing like I was planning before. I'm not sure how many traversals I'll have to do yet though.

I too havn't done a lot of testing and am still figuring things out but from what I can tell at this point I can do these things.

I think you may be right about the octree, I'll have to figure out a way to mix my storage format with it.

Well this sucks, I've got a way to store voxels with very low memory but no way to render them There's no way I can mix it with an octree.


I guess I'll see how rasterizing them goes, I haven't actually tried it yet, it might work. The problem I'm seeing with this is that I don't explicitly have voxels stored with an x,y, and z component, I have to loop through each voxel to find their position.

Hello. I created an account just for that.

Rasterizing voxels without the use of triangles isn't possible because of the hardware. You could convert all voxels to mesh first then render (meshing) but a method i'm currently investing in is simple raytracing. Nothing fancy like realistic lightings, reflections, just casting rays ortogonally from a plane in space and see which voxel it hits then print to the screen.

All you need for that is a way of representing voxeldata on the fragment shader and, well, the fragment shader.

You can easily sync the resolution so 1 voxel is 1 screen pixel, like this:

https://twitter.com/ukhenrik/status/1221252961130684418

I write a blog about this

https://www.gamedev.net/blogs/blog/4192-experimental-graphics-technology/

Where is you work?

@pabloreda Sorry for the 2 months delay. I currently couldn't be working on it a lot!

on our community GitHub and Discord server! For the general purpose nature of our engine, we research and test a lot before having concrete results. Right now I'm about to have my renderer rendering fast with some acceleration.

https://www.reddit.com/r/VoxelGameDev/comments/ff0bmh/toyvox_engine_a_one_of_a_type_approach_to_voxels/

https://github.com/HenriPK/Toyvox