rouncer at August 12th, 2011 16:16 — #1
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.
rouncer at August 12th, 2011 19:34 — #2
it actually paints it to the disk.
rouncer at August 19th, 2011 06:27 — #3
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.
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.
smile_ at August 21st, 2011 07:58 — #4
Hmm... such simple scene must compress to few kilobytes. You compression algorithm is quite bad.
reedbeta at August 21st, 2011 12:11 — #5
It's because those simple-looking boxes are actually enormous voxel arrays.
smile_ at August 21st, 2011 14:33 — #6
...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+).
rouncer at August 21st, 2011 20:09 — #7
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.
smile_ at August 22nd, 2011 04:47 — #8
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.
rouncer at August 22nd, 2011 08:31 — #9
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
smile_ at August 22nd, 2011 19:01 — #10
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.
rouncer at August 24th, 2011 01:35 — #11
razor at August 28th, 2011 00:32 — #12
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.
rouncer at August 28th, 2011 01:07 — #13
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.
razor at August 30th, 2011 10:13 — #14
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:
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 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.
rouncer at August 30th, 2011 13:01 — #15
rouncer at September 13th, 2011 12:59 — #16
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.
rouncer at September 13th, 2011 13:19 — #17
just to prove it heres a screen, but its got bugs yet, but nothing i cant fix.
now ill be painting on proper complex geometry, should look heaps better.
rouncer at September 13th, 2011 20:12 — #18
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