VOXELS! (blitz max)

Community Forums/Showcase/VOXELS! (blitz max)

Nate the Great(Posted 2010) [#1]
WARNING: SINCE IT USES LOTS AND LOTS OF VOXELS, THIS CODE TAKES UP JUST OVER A GIGABYTE OF RAM, DONT RUN IF YOU HAVE LESS THAN 2 GIGS OF RAM.
If anyone has any idea how voxels are normally done to not take up a gig of ram, please dont hold it back.

so I saw the voxel thing in general discussion and made my own, the colors are 2 bit colors because for some reason a billion 2 bit colors fills up ram pretty fast and making them even a little bigger bogs it down too much.

I made all the formulas on the spot, They seem to work but they do get things a little out of proportion. It takes a while to generate the random voxel maze of boxes and it is very messy code but it works and it works quite efficiently for rendering up to a billion voxels.

edit: ok it places voxels randomly so it averages 600 million.
controls:
arrows for x,y movement
a/z for z axis movement



edit: new full color code with not quite as impressivly massive demo
edit:updated again with spheres now to show it does more than colored boxes



Here is the multithreaded code if you like, its slow though




_Skully(Posted 2010) [#2]
Ok that just made my laptop overheat and shut-down LOL


Nate the Great(Posted 2010) [#3]
lol sorry, how much ram do you have? I have 2 gigs of ram and run vista which is a memory hog and its actually pretty speedy.. I never had it shut down or overheat before though :o


ImaginaryHuman(Posted 2010) [#4]
I'll have to check this out later when I get back to my own computer.

Shouldn't the line

(r Shl 2 + g Shl 2 + b)

be

(r Shl 2 | g Shl 1 | b) ?


Nate the Great(Posted 2010) [#5]
hmm what is the difference in my case it does this...

in binary

r = 11
g = 10
b = 01

11 shl 2 = 1100

1100 + g = 1110

shl 2 = 111000

111000 + b = 111001

11 10 01

is this wrong?


ImaginaryHuman(Posted 2010) [#6]
Oh. Maybe the order of precedence changes my interpretation of what happens. I suppose you are right if red is shifted left by 2 places and then green is added and then the total is shifted left by 2. I was interpreting it to mean r shl 2 is added to g shl 2 which would be wrong. This is why I put extra brackets around stuff to make it clear what's happening, lol


Armitage 1982(Posted 2010) [#7]
It's pretty speedy until you see some black area.
Then I suppose it's normal to be a little slow on my XPS M1330 :)


Dabhand(Posted 2010) [#8]
Spot on, very impressive! :D

Dabz


BlitzSupport(Posted 2010) [#9]
Worked here -- not particularly quick, but I always like seeing voxels in action!


Leon Drake(Posted 2010) [#10]
i have to say that was pretty awesome. wasn't too slow but definitely cool


Nate the Great(Posted 2010) [#11]
hehe I made a calculator version in TIBasic...its dead slow... talk about being bored ;)

@IH oh I see what your change above did, you were just making sure there were no order of operations quirks.

I wish I had some way to run this on the gpu and do pixel per pixel with more colors for the voxels and maybe add instancing. I guess CUDA might work although I might just multithread it in bmax ;)

I let my screen saver come on by accident with it running and it just crashed because it didnt have enough RAM Perhaps I dont need 1000,1000,1000 arrays.


Tachyon(Posted 2010) [#12]
Love it! This program could be the poster child for BlitzMax's threaded capabilities. How hard would it be to divide the screen into 4 quadrants and assign each quadrant it's own thread? I'd like to see some of my cores get used. :)


Nate the Great(Posted 2010) [#13]
hey Tachyon,

Im not sure if you saw the colored sphere demo, I edited it as you posted,

Glad you love it but I cannot get threading to work efficiently enough! I will redownload the latest blitzmax and try again though.

If the screen is divided in quarters I could have it render in smaller pixel chunks too :)


beanage(Posted 2010) [#14]
No idea whether thats good news or bad; on my desktop system i got 11 fps in threaded mode. I think its good considering the amount of voxels and the processing unit.

Though there seems to be a horrible amount of projection error in your little software voxel renderer (thats what it is, right?) i really appreciate the way it tries something experiemental! Excited to seeing some more progress on this! Or maybe you just wanted to do a marching cubes implementation... anyway the output can only be more awesome than this!


Nate the Great(Posted 2010) [#15]
well thats more than I get in threaded mode but you should really try the non threaded version, it works at 20-30 fps for me :)

and yeah there is some pretty bad projection error with rotating the camera 0 degrees and with thin layers of voxelso, It cant be very precise though (fewer steps per pick) because its not on the gpu,its just the cpu drawing 2d colored boxes on the screen. :), plus its bearable for me as it is rare that things will line up right to cause these projection errors.

and no I dont plan on doing marching cubes, that would just convert it to polygons.

also with this number of particles/sides of shapes it would require a ton of optimization if it is even possible to render this in polygons The number of particles has no effect on the speed with this system, the distance of the line picks does though.

I seriously recommend trying the middle program, I like it the best personally.


Blitzplotter(Posted 2010) [#16]
Mmm, I've got an excuse to install Blitz IDE on my new whizz bang computer, hopefully the voxels won't cause a bang though!


Noobody(Posted 2010) [#17]
The demos are real fun to play with, the second code with the spheres and boxes looks pretty cool.

I had a glance at your code and have a few suggestions:
- It seems that you are currently doing some kind of raymarching. This causes the projection errors because it doesn't necessarily touch all the grid cells the ray passes through. A faster and better alternative would be 3D DDA. The article is written for use in raytracing, but it works for voxel rendering as well.

- I would place the content of the 'voxel2' function in the code it is currently called from, because function calls can be quite the overhead when doing per-pixel operations.

- I'm not sure if the DrawImage method you currently use is faster, but you might try using a pixmap to do the pixel manipulations. DrawPixmap is slow, but writing pixels to a pixmap is really fast if you use the pixmap pointer.

- Try doing tri-linear interpolation between the voxels, it really smooths out the image. That way you can render smooth spheres even at lower grid resolutions.

- As for memory compression, you might want to choose octree grids. They are slower than a normal array, but memory is only used where there are voxels, meaning that empty spaces don't take up memory.


I did something similar a while ago for volume rendering. There are also rays traversed through the grid to find an intersection, but it doesn't stop at the first voxel, but goes all the way through and composites the voxels according to the rendering equation. I used it for 3D smoke code back then (smoke emitted at the center is pushed back by wind):

(excuse the bragging ;) ) You might want to look into volume rendering, it's pretty interesting.

Have you ever thought about using a shader for rendering? It shouldn't be that hard to write, the only difference is using a volume texture instead of an array. I'm not sure if the texturing unit interpolates between voxels (meaning in all 3 dimensions) or just between the pixels of the same layer in volume textures. The latter could give artifacts, but in that case you could just turn interpolation off.


Nate the Great(Posted 2010) [#18]
thanks for the suggestions noobody, Im afraid I dont quite 'get' shaders yet :/ like how they work and all. Volume rendering looks cool but I think I will just move along as I just did this to see if I could make a voxel rendering system work decently in a completely 2d environment.


Noobody(Posted 2010) [#19]
Since I couldn't put my mind off voxel rendering, I wrote a voxel renderer in GLSL and BlitzMax on yesterday's and today's evening. The colors aren't what you'd call eye-pleasing, but other than that, it's quite okay. The model is the free-to-use CT-scan of the Stanford terracotta bunny. The data I used is 512x512x512 voxels big and uses 128mb of memory.

Runs in realtime at 1024x768 on a HD4890.



Nate the Great(Posted 2010) [#20]
nice, does it rotate or is it static, I assume you used volume rendering, right?


Noobody(Posted 2010) [#21]
Movement and rotation on all 3 axes is no problem.

The shader still does regular voxel raycasting (stop at first voxel meeting the conditions), but I'm planning on extending it to volume rendering to render the other CT scans that are available on the Stanford website. But before that, texturing (perlin noise?) and shadows would be nice.


Nate the Great(Posted 2010) [#22]
thats awesome, would you mind telling what black magic you used to get shaders to work in blitz max, I am not much of a graphics guru and they never work quite right for me. :/


Noobody(Posted 2010) [#23]
There's no black magic involved ;)

But it really isn't that hard. I read a great GLSL tutorial which is unfortunately only available in german, but any tutorial will do; the same procedures used in C/++, Delphi, etc. will also work in BlitzMax, since all the OGL-commands are available in the Pub.OpenGL module.

To ease the use of shaders I wrote a crude shader class a while ago that I always use when I'm messing with shaders. I can post it once I'm back home, if you want.


ImaginaryHuman(Posted 2010) [#24]
In the original program at the top of this thread, why are you using an image and DrawImage to render what looks to be a colorless textureless rectangle? It would be faster to do Plot (untextured), even faster to do multiple glVertex calls inside a single glBegin/glEnd loop, and even faster still to use a glDrawArrays().


Nate the Great(Posted 2010) [#25]
@IH

well plot is pretty slow and I wanted more than one pixel, its a bit blocky, and drawimage is 10x faster than drawrect on my machine at least, I think I mentioned before, I suck at open gl, I dont think i've ever writen a program that used it althought I think I should learn it eventually.


DareDevil(Posted 2010) [#26]
pleace send a demo file for test your code :)
bye


Noobody(Posted 2010) [#27]
I added a procedural perlin noise texture, a better normal and intersection interpolation, phong shading as well as shadows. It's pretty much where I wanted it to be (well, except for the black/grey grain that appears where normals are impossible to calculate).

Still running at realtime at 512x512x512 voxels, 1024x768 pixels on a HD4890.


Now that I'm using perlin noise, shader model 4.0 is required. Also, the voxel model is .rar-ed still 60mb big, so downloading that would take a while. I guess I'll be making different quality versions for people with a bad internet connection and/or a not-so-high-end graphic card.


Nate the Great(Posted 2010) [#28]
nice, it would add some realism if the bunny was textured like a bunny tho


DareDevil(Posted 2010) [#29]
very good result :)

the demo?

what fps?

the shader code?

thk!!!


Nate the Great(Posted 2010) [#30]
daredevil-who are you talking to?

everyone - looks like i wont be programming for at least a week, i bent my left hand ring finger the wring way at a 90 degree angle in soccer so it takes forever to type one handed and i misss a lot of letters ;)