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. :)
Please log in or register to post a reply.
it actually paints it to the disk.
i plotted some axis aligned boxes, and painted a few, this is coming
along… csg isnt implemented yet, they are just voxelized into each
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.
Hmm… such simple scene must compress to few kilobytes. You compression
algorithm is quite bad.
It’s because those simple-looking boxes are actually enormous voxel
…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
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
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.
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.
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 :)
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.
just stuffing around…
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.
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.
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
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 :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.
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.
just to prove it heres a screen, but its got bugs yet, but nothing i
now ill be painting on proper complex geometry, should look heaps
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