> > 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
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
