so, this is the issue:
I have scenes on which I am using real-time lighting and shadows
(particularly, using shadow volumes);
the scenes are of "moderate" complexity, namely in that the framerates are
good when there is no real-time lighting, but when using real-time
lighting
the framerates are not so good (ok, more specifically, I am currently
using
the Quake-1 maps for testing).
thus far, I have already used approaches like frustum culling, BSP
building,
only casting shadows for the "most effective" 8/12/16 light sources, as
well
as omitting geometry that is too far from the light source, ... with some
success. these are used to reduce the amount going out to the video card,
which currently seems to be the main limiting factor (actually, just
pu****ng
out the raw geometry for the map drops the framerate to 20 or 25 fps or so
for many maps, and with real-time lighting framerates are typically
between
10 to 15 fps, with shadowing making little difference below 8 lights,
dropping to maybe 7-10 fps for 12 lights, and 4-8 fps for 16 lights).
note that for the remaining lightsources, where there can be up to several
hundred per map with the Quake-1 maps (on a few maps I had somewhat pruned
this down, say, 90 rather than 250 lights, but there is a limit to this).
in these tests, I am typically dealing with between around 1000 to 4000
brushes, 6000-24000 faces, probably avg 30000-120000 rendered polygons
(base
geom + avg 3 lights/face), with a max 288000-1152000 shadow polygons for 8
light sources, or 432000-1728000 for 12 lights, ommitting current culling
approaches...
I have typically been using direct-lighting, using the BSP tree and
sphere-queries to only draw geometry reached by the specific lights (the
brightness being used to calculate the effective radius), with additional
checks being to eliminate lights and geometry outside the frustum. these
are
still drawn using layering and gouraud shaders to avoid an obvious
"lighting
jump" (formerly, I had used plain vertex-lighting for the remaining
lightsources and geometry, but couldn't get the lighting to match exactly,
resulting in sudden obvious jumps in brightness and appearance), this
being
followed by noting that GL lights and the shaders could be used with
minimal
framerate impact.
so, I am thinking at this point an occusion culling scheme is needed.
I am mostly just requesting general info here (I don't need either code or
libraries, and would actually rather avoid them).
particular hopes:
it need not be real-time, but should be hopefully fast (an entire scene in
less than 5 or 10 seconds would be ideal);
hopefully, it should mesh fairly well with my existing design if possible
(aka: something I would not need to spend too much time implementing).
for specific reasons, I am building the maps at run-time, and the map
geometry may be altered at runtime, with the BSP being dynamically rebuilt
in response (I am hoping to use the same 3D engine both as the main engine
and as a mapper). visibility culling is likely to be an optional stage in
the mapper case (something that can be done to see how the thing will
perform in the actual engine), but may be performed on map load for the
engine (or, if needed, 'caching' may be an eventual option for faster
loading).
my last attempt at occlusion culling was based on numbering all of the
nodes
and leaves in the BSP, and then keeping a set of visibility bitmaps. these
bitmaps were built by trying to coarsely iterate over the volume occupied
by
each node/leaf, and linetracing to points in each other node/leaf,
re****ting
visible if any traces pass, and re****ting invisible if no traces pass.
however, this approach is terribly slow, and thus far has failed to work
correctly (either correctly omitting hidden geometry, or reliably showing
visible geometry). so, maybe if there is some good way to avoid some "teh
huge" number of linetraces, that would be good (admitted that there could
be
a problem with my current linetracing code, but even if it were working,
it
is likely to continue being rather slow...).
ideally, if the algo can effectively cull shadows and lightsources as
well,
that is better (at present, I am using 'general' rules for ommiting them,
namely sphere of influence and calculating how shadows would be cast
relative to the frustum, however still a lot more is left in than is
ideal,
which even with visibility lists could still take multiple levels of
checks).
misc:
I have a BSP tree for the map;
this BSP is currently brush-based, rather than polygonally based (the
brushes are around, in any case).
it is likely that I will add a secondary purely polygon-based BSP (or
attach
polygons to the existing BSP), mostly for the sake of further optimizing
rendering (and also for the sake of doing proper inter-brush CSG clipping,
which is also currently lacking, as well as allowing for faster
linetracing).
however, I am likely to keep using the brushes for shadow volumes, me
thinking that using clipped polygonal geometry is likely to be a lot more
expensive here (the total number of shadow polygons being higher, and thus
further hurting framerate).
of course, once I had a polygon-based BSP, I could probably build and make
use of ****tals for the visibility calculations, which are at least a lot
faster than line-traces (although in the past I had difficulty making
****tals work right either, but oh well...).
then again, it is another problem that I currently draw a shadow-volume
per
polygon (a typical cubic brush thus drawing 36 shadow-polygons per light).
I
had read about using edges, but I am unsure how one would render in the
end
caps in this case (apparently mandatory for the depth-fail approach), me
also feeling unsure how the end-caps could be figured in less time than
just
drawing a closed volume per face.
note: though it would seem sensible that volumes for backfaces could be
left
out, but from what I can tell they are still needed or else the shadow
doesn't come out right (as well as leaving out the front and end caps). I
am
left unsure about the performance of higher poly-count models (such as
characters and objects), which would likely need special meshes just for
shadows (probably also used for physics as well, where for skeletal models
the mesh is bound to the skeleton using only single-bone per-vertex, and
each per-bone segment is approximated with a convex hull, which could also
be used for shadows).
any comments?...
|
