PDA

View Full Version : Reduce fragment operations



Nvveen
06-25-2011, 12:33 PM
Hi all,

First off, let me explain how my rendering works. I'm trying to do a nice voxel engine that renders low resolution models. Think of 32^3 for a dwarf. I'm doing that like this: First, a 3d texture is generated, where each pixel represents a voxel. Then, a VBO is composed of (3n*2) quads, where n is the size in pixels of the texture, in the dwarf's case 32. This means, 64 quads (front and back) for each axis, x, y and z. Each quad, or slice, in each direction is positioned at that slice's position in the texture. The quad is then textured according to it's location. With proper blending, the end result makes it seem as though thousands of seperate voxels are displayed, while only needing 192 quads, or 384 triangles.

Rendering is very fast; however, if I'm rendering a 100 unique models, and I try to zoom in, the frametime decreases drastically. Parsing the results through gDEBugger, and I've found that the rastering is the main bottleneck here, which I can understand. I'm not yet using frustum culling, so if I'm zooming in, every one of those 100 models has 384 triangles it needs to shade with texels, and I can see how this slows down the rendering.

My question then is this, is there a way to skip fragments that are occluded? I.e., texels that are on parts of the quad that are obscured because they reside in the model? I've tried a few different variations of using the geometry shader, and having it cull triangles when each slice itself is subdivided into 32x32 quads (and each quad is textured to 1 pixel in the 3d texture), but for some reason, whatever I do with the GS, it always slows down the program to an unacceptable level.

Hope my description of the rendering engine is sufficient. Thanks in advance,

Nvveen.

mhagain
06-25-2011, 03:50 PM
Frustum culling will help a LOT here, and should be the very first thing you do before you look at any other form of optimization.

Standard backface culling (if you're not already using it) will also be useful and will eliminate tris before they get to the fragment shading stages.

I don't think there's anything useful you can do with a geometry shader, and attempting to cull on a finer level than per-model will be too much CPU overhead.

So, confirm you're using backface culling and implement frustum culling, and that should be all you need.

Nvveen
06-26-2011, 01:29 PM
Backface culling is already implemented. However, even with one object, zooming in until the entire dwarf is filling the screen causes the frametime to increase to 20 ms, hardly optimal.

mhagain
06-26-2011, 02:57 PM
Definitely go for frustum culling then, it's what you need before you do anything else.

Nowhere-01
06-27-2011, 07:00 AM
Umm...Just a noob thought...Isn't rendering voxel data as quads a bad technique? I mean, imagine the big scene, with many objects covering all the screen. Maybe i'm wrong. but i think it will fail even without lighting/effects. If i were implementing something like that, i'd just draw a quad covering all the screen and rasterize all data on it's surface using GLSL. Yes, you'll need to do all work yourself, even basic optimizations. That's hard way, but it should be much faster.

tksuoran
06-29-2011, 03:41 AM
Frustum culling won't help here. Fillrate is the issue here. You are trying to render maybe 100 times near-fullscreen with blending. This is (very) bad.

You could consider different rendering strategy, at least for objects that take significant fraction of screen space. You could process the voxels and collect opaque faces which are facing towards empty voxel, and then render those only.