sparse voxel octree painting

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 12, 2011 at 20:16

it might be a little too early to make a big fuss about, but ive just got painting working on my “infinite voxels” engine. (after a huge gpu headache, you might have seen a few vain posts from me about technical details recently) unlimited detail makes me sick tho, so i shouldnt really use infinite or unlimited to describe it.

face it, detail is limited by the storage capacity of the hard drive, who cares if you can render it all, its got nothing to do with it.

so then ive got to get voxel csg working, then ill come back with something better than unlimited detail, hopefully. :) 100% unique painted geometry, should be pretty cool.

im planning to give it away for free, see what happens. :)

voxelspainted.png

17 Replies

Please log in or register to post a reply.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 12, 2011 at 23:34

paintuz.png
it actually paints it to the disk.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 19, 2011 at 10:27

i plotted some axis aligned boxes, and painted a few, this is coming along… csg isnt implemented yet, they are just voxelized into each other.
boxeslr.png
but it actually looks like its gonna be pretty damn cool :)
I want to be first to get to a working id tech 6 engine. hehe

that souped selection of boxes is 30 meg, but thats completely uncompressed, it would be about 5 meg if it was huffman encoded and a few other tricks.

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Aug 21, 2011 at 11:58

Hmm… such simple scene must compress to few kilobytes. You compression algorithm is quite bad.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Aug 21, 2011 at 16:11

It’s because those simple-looking boxes are actually enormous voxel arrays.

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Aug 21, 2011 at 18:33

…with the same values in each cell and regular repetitive pattern. They must compress to near zero compared with uncompressed representation. Otherwise compression algorithm is bad. Especially Huffman works badly in case of one value have high probability (say 0.9+).

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 22, 2011 at 00:09

Glad to get some attention from a few comments, ill be working on compression later… Smiley, Ill be compressing as much as I can, if you are right and I can get it to a few kilobytes for a small setting like that id be really happy… but to tell you the truth 5 megabyte seems appropriate, thats 2 bits positional data and 2 bits colour information, I think. but its only an estimated target… right now im storing it like a point cloud with full byte list -> “x y z r g b”, so it comes to 30 meg…

I might be counting wrong, you may be right Smiley. It might be less than 5 meg, it could be 2 even, but I havent implemented compression yet, just theorized it a little.

Im working more on this now… ill be posting more soon.

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Aug 22, 2011 at 08:47

4 bits per point is obviously too much. It must be small fraction of bit per point (say 0.001). There is where badness of Huffman algorithm lie: it cannot assign fraction of bits to values.

Do you have AAB voxels or points at arbitrary positions? In the latter case create hierarchy by grouping points with similar parameters. In the former case hierarchy come naturally (octree). Then store differences between current and parent value per point. In case of color it will be zero in most cases and compress very well.

Also think about lossy compressing. It can be in order of magnitude smaller than lossless.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 22, 2011 at 12:31

Im storing in a neighbourhood fashion, each voxel has possibly 6 neighbours, so i store 6 bits per voxel, about. Also to get 4 bits per vxoel, im only allowing 12 bit colour, just to keep the store down.

Just to add, your bold statements I wish were valid, but I really doubt to get it below 4 bit.

PS If what you say was true there would be no disk problem with this method! Maybe I need you Smile on my team :)

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Aug 22, 2011 at 23:01

Well, basically you doesn’t use compression at all, just store all values for all voxels.

For example, of 2\^6 possible combinations only few have frequent occurrence. Assign few bits for this combinations. Also I suggest using octree hierarchy instead of neighbourhood. I think it can help for color/normal storage and automatically give low-res mipmaps. For color storage read about gif/jpeg compression algorithms.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 24, 2011 at 05:35
8e9aaea714077ea62a0c7f81cfb7672a
0
Razor 101 Aug 28, 2011 at 04:32

Nice! I’ve started playing around with something similar, though I’m not as far along as you. What approach are you using, is it the raycasting I’ve seen elsewhere or something different?

Personally I’m trying a form of rasterization. It’s not exactly fast so far, but maybe expecting one core of my laptop to render per pixel geometry at more than 2fps was a little optimistic.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 28, 2011 at 05:07

oh yeh razor, it needs gpu accelleration, even im only going 8-15 fps on a gtx 480. (thats with turning points into cubes per point). But I figure get a 590 onto it and it should blow it away.
Yes, im just rastering.

8e9aaea714077ea62a0c7f81cfb7672a
0
Razor 101 Aug 30, 2011 at 14:13

You’re no doubt right about needing hardware acceleration. I’ll attempt to switch to cuda or opencl when I’m more happy with the algorithm. I’m not sure how to make it that parallel without losing a lot of the efficiency though.

Just to make you look awesome, this is what I have:

Rasterized.png

Full of artefacts and not even storing color data. Uses about 1gb of memory, but only because every non-leaf node has 64bit pointers to all the children. Objects become see through close to the camera because you can see between the atoms :P But I have made some speed improvements, that scene keeps above 5fps now, though admittedly that is at 512x512 res. Hopefully I can find a couple more tricks up my sleeve.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Aug 30, 2011 at 17:01

hey… awesome.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Sep 13, 2011 at 16:59

hey good news Razor, ive just got csg implemented!!! well see if i can get something totally sick out of it. :)

Give me a couple of days, ill have a really nice screenshot!

Next thing tho, after I have another little play… will be to import models directly from 3d coat into it, then i should be able to get something really really nice.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Sep 13, 2011 at 17:19

just to prove it heres a screen, but its got bugs yet, but nothing i cant fix.
csgr.png

now ill be painting on proper complex geometry, should look heaps better.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Sep 14, 2011 at 00:12

modest beginnings, i cant tackle a proper environment (i actually tried, it was a miserable failure, wont even bother you with what it looked like) without the necessary plotting tools and selections etc… stay tuned :)

littlepiece.png