Hey guys!

It feels stupid to iterate across a working renderer to increase the performance even more. I figured i would need some slack for physics, particles+effects and networking later, so 60fps won't cut it.

Alright: I once did fragment shader raycasting, so i'm somewhat into glsl. I need to render lots of quads. Think minecraft. I was wondering if i could deliver point data to the card, which would then turn the series of points into 4x as many; a series of quads.

Couldn't i use a geometry shader or something. I saw somewhere that there is a very low cap of vertices to be output by the geometry shaders.

So how would i go by this? Also, please tell me if you think i'm being too picky with the performance. We're talking average gamer computer. Dual core@~2ghz, geforce series 9 gt circa.

... thanks for helping out!

Oh, i just meant by 60fps, that even though it's a reasonable aim, it won't do. I never enable vsync. Your CPU vs GPU operation argument is good, just unless i wanted to use cuda for other computations you're right, i shouldn't be so concerned.

Overdraw was my issue with polygons, and re-generation on the cpu. Mind you i'm talking a lot of quads. Again, see minecraft. But this makes me want to go back to my gpu raycasting...

60 fps isnt so bad, but please use frametime instead, as it makes more sense
if you are trying to make a more modern version of minecraft, i think you will be disappointed when it comes to FPS
im assuming that you are barely rendering cubes, but wait until you start generating, compiling and loading/writing from disk
if you arent careful with the multithreading and avoid mutexes like the plague you will have so much wait time, that the renderer will suffer
that may have been unrelated here, but just for the heads up, you can gain alot of fps by simply making sure theres enough time for the renderer to do its work
if theres too much computation elsewhere that causes time between rendering, the fps will inevitably go down alot (1/frametime), so like i said
60 fps is great, just dont expect 150 fps like in other games, because they barely have any data in comparison...

Alright, I see what you're saying with regards to frametime. Anyways, i have a 256^3 block wich is approx 50% filled with polygons. I will use frame time,
but for my current bench, i get 150fps to 400fps with the raycasting approach, and individual quads at ~100fps.

So if 60 ain't so bad, and i'm satisfied with my regeneration technique, i could just settle with this.

-I should. I should settle and move on to more interesting aspects of the development! Thanks you guys!

hmm i just got curious and calculated what i have in view, vs your 256^3

268,435,456
16,777,216

im not entirely sure that raycasting will be best for a block engine
but i dont have your details, either, like are you viewing all of the 256^3 blocks in your test?

hmm i just got curious and calculated what i have in view, vs your 256^3

268,435,456
16,777,216

im not entirely sure that raycasting will be best for a block engine
but i dont have your details, either, like are you viewing all of the 256^3 blocks in your test?

Well, raycasting is an excellent choice for a voxel engine. See Ken Silverman's voxlap, especially his cave demo is very impressive.
Using this approach, the amount of blocks to render is pointless to worry about; How much to draw depends on the resolution anyway,
and no occlusion culling is needed. The downside of this is that the 3D texture takes a lot of memory, and as it's uncompressed, RGBA8 cells in 256^3
take up 67 MB. Also, performing per-column wave surfing is difficult in a fragment shader, as the fragments are processed in parallel, and thus it's impossible
to transfer state between fragments during the same draw call. Optimizing the ray-stepping through for instance octrees requires a lot of branching on the GPU.

I get somewhat better framerates than with polygons, and only partial texture updates are required. No regeneration at all.
But for that odd case where the rays should travel across the block unobstructed, and the screen is partially covered by a solid cell close by, it get's difficult.

But sure, older cards handle quads much better, especially for lower (block) resolutions (->less surfaces), and that's too why I've been doubting the applied technique.
When projecting geometry, which i might be doing a lot, it would be sad to perform raycasting every time. Even at somewhat balanced resolutions.
And, i question whether raycasting via shaders is really the way to go yet. It really has it advantages, but it might need a little extra for high resolutions.
Using CUDA however, it might be possible to do some tricks unavailable to shaders, I wouldn't know.

As of what we each have in view and frametime+fps, comparing that is a fun idea! What dimensions are your block, and how do you render it?
-A little competition must be healthy!

im not making a voxel game, but a block game
however, it is 64^3 sectors * 16*16*8 blocks (sx, sy, sz) * (bx, bz, by)
its also full 3D so you can go down and up, unlike in minecraft
i dont know what you can do with voxels, but i assume its very limited due to the enormous amount of.. them ?
on the flipside im using precompiled blocks with raytraced lighting and what not, so i cant render real-time
massive frameskipping and pre-emptive culling (frameskipping shouldnt be confused with loss of fps, or "less accurate experience")

Oh no, it's the same really. If your blocks are stored as volume data, they are really voxels. I use frametime from now on, and you get the terms right wether you call your volumes trixels, blocks, chunks or Fred. -Minecraft is in essence a voxel game, too.. ;-)

Okay that's a lot of data! So how much space does your player take up in comparison? :-P

player is 1.7 blocks tall i think, and centroid 0.30 radius, so moving into a corner, so assume "just a little bit of movement" can be done inside only 1 block
heres an example of the view