Re: Billboards vs. Cross Trees

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Tue, 23 Jun 1998 14:52:07 -0700

Steve Baker wrote:
>
> On Tue, 23 Jun 1998, Jimmy Moore wrote:
>
> > Both affect the cull pretty much the same.
>
> Perhaps - I thought billboards were still a little worse because you
> can't pfFlatten them - but with all the newer pfSprite stuff, that
> could well have changed.

This would depend on the scene graph.

>
> > Cross trees hit your draw harder because you are essentially drawing
> > 8 triangles vs. 2 for billboards.
>
> Well, if you flag the polygons of the cross trees so that GL doesn't
> have to backface cull them, then you only need 4 triangles.
>
> If you are not horribly fill limited (and certainly at longer ranges),
> you can go to two triangles for a cross tree and just one for the Billboard
> (the point of the triangle being buried slightly underground and the top
> of the triangle sized to be large enough to encompass the crown).
>
> The nastiest things about both kinds of trees is that they don't T-mesh
> at all well. If you can cope with it, it's much better to go with modelling
> clumps of trees (at least at longer ranges).
>
> > Billboarded trees look better and don't hit your draw as hard, but
> > you have to spend time in the app rotating them toward your eyepoint.
>
> (I think that happens in CULL - or now, with pfSprites and GL_SGIX_sprite
> extensions to OpenGL, it's probably happening down in the geometry engine)
>
> > What I am interested in knowing is:
> > 1. Has anybody documented performance differences between Billboards
> > vs. Cross trees?
> > 2. Has anybody tried using a billboard as the highest level of detail
> > for a cross tree and would this be a feasible solution?
>
> If anything, you need to do the reverse. The problem with billboarded
> trees is that you can see them spinning as you get close to them - especially
> in a wide field of view - or if you are in some kind of aircraft and
> can look down on them from above...go into a steep dive and do a 360 roll
> and see what I mean!

Agreed, but there's still some value in what's being suggested, ie
reducing the processing load for _many_ trees. The example at
www.dorbie.com does this by round robining the tree updates for
distant blocks and using a non localviewer bilboard vector for
a block based on range. Also it round robins updates on near blocks.

An addityional exposed feature is the use of groups of trees and
GL_QUADS primitive for efficient dispatch to hardware inside a
single glBegin glEnd pair. And reduced pfFrustum culling overhead.

Depending on how you build your scene graph you might find it
difficult to accrue these benefits otherwise.

>
> Rendering good trees in a large enough quantity to be convincing
> is a really hard problem - it can be done - but it takes a LOT of
> sneaky tricks.
>

Yep, the sneakier the better.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 


For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
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:34 PDT

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