From: Heiko S. <aei...@ya...> - 2008-12-15 17:00:16
|
> > No, the cost of blending is proportional to the area > blended on the screen, > > so a > > few large sprites vs. many small sprites should cost > about the same. It is > > true > > that it takes longer to sort a large number of > sprites, but I'm not worried > > about the sorting cost at this point. Theory vs praxis ;-) I just tested it- no, more sprites = less fps > > > I've got a patch for trees using VBOs, performance > gains are impressive, > allowing > thight forests with "coverage/=10" (obj.cxx) > (before hitting the win32 3G > limit in around 80 tiles, lol). > My idea was to adapt that VBO patch to cloud rendering, > using index > buffers. The > vertex-packs (v,n,tc) are static and the index buffers have > to be > recalculated > every frame (as in the quicksort above). Ideally one may > just calculate > a static vertex-pack buffer for the whole cloud layer after > it's generated > and either just draw indexed on that one huge vbo per > cloud, or even better, > collect the indexes for each cloud, without drawing > anything, > and then in a posterior renderbin draw that whole-layer > indexbuffer > in a single rendercall (well, more than one glFunc, mapping > the > vbos takes some calls). If I arrive at some results > I'll post a patch :) im > doing > more than one thing atm. > Sounds very promising! HHS |