Okay, I have been working voxels under opengl over the last few days. I can get 7 million voxels on a screen at a time at 70fps, but the strange thing is that if I reboot my machine, load borland builder 5 (and the project) and then run the program, the first time always runs at 20 to 30 fps. After I quit it once, it runs fine again at 70fps and constantly afterwards. I am using WinME for the platform (and have maxmem running). Another question is that when I cycle through the voxel modes, textured voxels seem to drop 5fps if I cycle away from them (I think this is to do with my code though, but I will sift through it and find it hopefully). Last question is about the glVector3fv against glVector3f (pointer to array, vs direct values). When I use glVector3fv instead of glVector3f, the program runs fine (same fps) except for the first couple of seconds (between 2nd second and 5th or 6th second) it slows down by about 10fps. Does anyone know/have had troubles with glVectorXfv functions and this lag effect? If so does anyone have any idea how to stop it? PS - if it helps I am running at full screen at 1024x768 using a gforce 2 and 1g athlon with 512 mb sdram, and as stated above with winme, maxmen and borland builder 5 pro. Thanks in advance. Beer - the love catalyst

You''re a better person than I am.

7 Million, wow... you should be rich.


I gain performance with the *fv, no loss. There''s something wrong with your OpenGl anyway, it wouldn''t surprise me if all those problems were related to the initialisation...

probably is. I haven't really done much opengl stuff (in any depth) for a probaby a year or so now (maybe 2, possibly 3).

Well my initialisation is basically standard windows setup. I haven't been using the Builder stuff as I noticed that when I wrote a small http program (was scripting 3d views and stuff) which had OpenGL in a window, it gave out to many exceptions all the time so I said screw it and went back to the old way. The above engine was using the setup from a program I wrote a long time ago. I will see if I can port the voxel stuff to the standard builder setup and see if I get the same probs.

PS - I am not sure if terravox does it (is that your engine?) but I use compressed voxels.

Basically, the slow stuff in the program is that if you have a loop such as
for(px=0;px<256;px++)
for(py=0;py<256;py++)
for(pz=0;pz<256;pz++);
it slows it down like buggery. If I just add the above code in the program and I loose around 10 fps. Compressing the voxels and decomressing on the fly makes it run like a daemon with a pitchfork up his arse (don't suffer the delay from the loops, and the overall effect was around twice the frame rate).

Also, if you render cubes around each of your voxels, don't render non-visable sides. ie; the ones that have some other voxel against it.


Oops - forgot the sig - highly important
Beer - the love catalyst

Edited by - Dredge-Master on December 13, 2001 12:50:05 PM

PS - nice site Alex (AI-Depot)

Beer - the love catalyst

Yeah, terraVox is my engine. It does landscapes only, and that allows a hell of a lot of optimisation... see my tutorial on flipCode. I don''t call it compression, but heightfield mipmapping. Which is LOD for voxels essentially.

7 million, that''s 192x192x192 resolution voxelisation? How many polies is that? (I don''t use them in tV).

The only poly''s I set it to use are GL_FLAT quads and textured quads. Alot of the texture stuff was vector and normal stuff I had written a long time ago. Thanks to it the thing has some decent speed. Actually thanks to uni (university) and those darn maths subjects (which btw I failed quite a few times - but less than most people) I was able to write them to be faster than all the stuff on the net.

I am writing my own lighting code for it, as since the polys are too small they can''t use the Open graphics lighting, so that slowed it down.

When using polys they are just a cubes around each voxel location. I also have scaled gl_point voxels that (unless you have a darn small model or are really close) look the same as the gl_flat quads.

After timing it (7 fps counters for the different sections) all the overhead is in the code, not the rendering of the quads which proves that the GeForce II was a good investment.

Oh yeah, I recompressed the voxel image in another layer and gained 10fps on textured voxels.

I got that glitch with the glXXXXfV functions sorted out btw, so it doesn''t lag at the start.

The reboot problem is still there, but I can live with that at the moment.



Plans for it now
- currently working on software lighting
It only works on lights along one axis though, so I will probably have to spend a few more hours on it. Afterwards glass and shadows is to follow - simple ray tracing stuff.
- after that works I am going to wack in a detailed "utah teapot"
- then wack in a gui so you can move the lights around.

Hard part is those bloody lights. The way I wrote it has the polar co-ordinates (used for the normals) in weird orientations so I have to go through and change it all.


I will have a look at your article now Alex. I appear to have waffled on for long enough.

Seeya.
James

PS - I stuck in more ram (640mb now). Tthis thing is taking around 160mb of memory or so at the moment. Small sacrifice for the speed atleast.


Beer - the love catalyst

Nice artical.

Did you know that Ken Silverman''s KVX engine is 6DOF? I worked on it a few years ago for a game and some wrote utils for it. Bloody awesome little thing. 100fps on a 120x120x80 voxel at the highest LOD in 1024x768 on a P100 with a 2D card.

If it was written for win32, I would have never started this little voxel project. Oh well, the days of MSDOS are behind me.


Beer - the love catalyst

Well that blows goats... Got the lighting working (real time) except now the frame rate has dropped to 13 fps for a 256 diameter sphere.

Going to rewrite the lighting code when I get some more time... extremely annoying though about the performance hit.


Beer - the love catalyst