| |
First of all, I find your column really cool and after some weeks of
wracking my brain I have come to the point where I need some help. To
put things in context, I'm developing a 3D engine targeted for 3D
accelerator platforms and have some decisions to make regarding the
implementation. One of my main concerns is texture switching. Say I'd
want to use octrees/kd-trees/bsp or a similar mechanism. This means that
polygons are thrown at the drawing code in a seeming random fashion
(with regard to the texture they use). I did some testing and several
hundred switches are okay, but the more polygons get processed the more
switching will eventually occur (and performance will go down the
drain). A solution I may have come up with is to traverse the structure
and store the results in a preliminary structure, which is texture
sorted. Then, go ahead and traverse this structure and draw the stuff.
Obviously, this preliminary structure will be pre-allocated and not
allocated and freed for each frame. Is this aproach good enough, or do
you guys know something better? How would you handle lightmaps (to
reduce texture switching in the second texture unit)? I guess, if you
don't have the second texture unit, a second preliminary structure would
suffice... Well, what do you think about all this?
|
|
