Jump to content
  • Advertisement
Sign in to follow this  
SuperVGA

How do i turn a point into a quad?

This topic is 2750 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
A geometry shader could do it, at the cost of some extra overhead (which may well wipe out any performance gains). Instancing can also do it, again with some overhead.

That 60 FPS figure looks suspicious though. Maybe you are being too picky with performance; you might just have vsync enabled and in reality have lots more headroom than you think you do. Also bear in mind that fillrate, not vertexes, is the real killer with particles, and that saving on GPU performance will realise very few real-world gains for CPU operations. So benchmark your program first and make sure that this is actually a CPU bottleneck before proceeding.

Share this post


Link to post
Share on other sites
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. :D

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...

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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. wink.gif

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! smile.gif

Share this post


Link to post
Share on other sites
im not making a voxel game, but a block game :P
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 :P ?
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")

Share this post


Link to post
Share on other sites
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. :D -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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!