Re: Billboard Performance -Reply

New Message Reply Date view Thread view Subject view Author view

Alejandro Saez (cano++at++krusty.engr.sgi.com)
Thu, 23 Oct 1997 16:13:14 -0500


On Jul 29, 12:58pm, Charles Paik wrote:
> Subject: Re: Billboard Performance -Reply
> Thanks for the suggestions.
>
> My trees are currenly modeled very similar to Billboards. They are quads
> with an texture of a tree. They are not billboards because they do not
> rotate with the view of the eye. Instead, my trees are modeled with 2
> intersecting quads. From above, it looks like an X. This gives the trees
> a 3-D look. Even though they are really 2D. They are very similar to
> billboards, but they have an extra quad, and they do not rotate.
>
> I do not have transformations for my trees. The quads are individually
> placed. (At least that's how I think the database was developed from
> my best interpretation of the database.)

What do you mean by "individually placed" a clone still has to be individually
placed (by means of a transformation) but it's still a clone. What are you
using to place the trees?

>
> App and Cull stages are extremely light relative to my Draw Stage.
> I suppose making the trees billboards, will reduce the number of
> polygons by 1/2 since I will not need the intersecting quad.
>

that's correct you'll reduce the polys by have which can be really something
specially in this draw intensive situation.

> But my real question of dicussion on this topic is: if the trees were
> modeled similarly (for example, the trees are both textures on a quad), is
> there a significant performance advantage using a billboard approach?
> And what are the key issues?

Let me see if I get it, you want both X forming quads to be a billboard? If yes
you aren't getting any performance improvement for the draw stage and also
imposing an overhead to the app stage. Besides having to update each tree's
orientation (this goes in the app stage) I would guess you are also adding an
extra matrix before the glBegin/glEnd loop describing the tree geometry thus
also imposing an overhead in the draw stage.
>
> And my ultimate question would be: what would be a good trick for
> drawing a ton of trees?
>
I'll tell you everything I can think of :I would say, go for billboards using
only one quad the way Angus describes in his excellent page... I would add an
LOD to eliminate far away copses (specially if it is a ground simulation) and
also check what is eating your draw time meaning :try it without textures, it
could be the textures in which case I would check the min/mag filters being
used for the trees.

 Not very likely... but I think if your tree texture uses many alpha levels
(like in the tree's border) then in a ground simulation with a dense bush made
out of these trees being looked at from outside, there could be a depth
complexity issue, I say not very likely because usually the alpha channel for
trees is just fully transparent or fully opaque. Also regarding textures, I
want to use this oportunity to ask if anyone knows if texture size and
rasterization time are somehow related, if there is such a relation then using
a big texture (even if it fits in TRAM) for these tons of trees *could* make
your application become fill limited. I say "could" because actually I don't
know of such a thing.

> Thanks for all the feed back thus far.
>
>

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Santa Maria 2560
E-mail: asaez++at++silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 107 		Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:46 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.