Re: Double sided lighting performance?

New Message Reply Date view Thread view Subject view Author view

Alejandro Saez (cano++at++krusty.engr.sgi.com)
Wed, 2 Dec 1998 11:45:39 -0600

On Dec 2, 12:42am, Rob Jenkins wrote:
> Subject: Re: Double sided lighting performance?
> Simon Mills wrote:
> >
> > Hello all,
> >
> > I have a modelling question here. I'm modelling lots of girder like
> > structures as simple boxes with intensity-alpha textures to give the
> > fine detail. To be able to see the interior of the girders I can do two
> > things:
> >
> > 1. Turn off backface culling only for those polygons (I also have plenty
> > of normal polygons) and enable double sided lighting (i.e.
> > pfLightModel::setTwoSide) for the whole scene (not default so I guess
> > this incurs a performance penalty?).
> >
>
> Two sided lighting does cost you something in the transform stage of the
> pipe ( as do multiple lights and local lights ). Benchmarks can give you
> a measure of this cost but as always, they don't tell the whole story.
> If you look at the OPC List Triangle Strip numbers for Octane an example
> is:
>
> Triangle Strip (CallList, RGB, Z, 3D, smooth, 1 inf light, no specular)
> 2090000 Triangles per second in a Triangle Strip
>
> Triangle Strip (Immediate, RGB, Z, 3D, smooth, 1 inf light, 2 sided
> lighting) 1550000 Triangles per second in a Triangle Strip
>
> so something of the order of 25% overhead for an ideal strip of
> triangles, real world numbers might be different of course but it gives
> you a feel for the cost. There's no reason you can't organise your scene
> to just have 2 sided lighting on for objects that need it though, so
> change the lightmodel around those objects in a geostate just for them,
> then go back to a 1 sided model. If you minimise the light model changes
> then the cost will be OK ( doing many light model changes per frame
> would be bad ).
>
>
> > 2. Duplicate and reverse all those polygons and leave the
> > lighting/culling defaults as they are. This increases the total polygon
> > count but leaves drawing modes alone.
> >
> > Does anyone know which is the most efficient method? Or is it more one
> > of those "it depends.." type questions? It appears that the graphics
> > pipes are optimized for method #2 although at first sight method #1
> > should be faster.
> >
>
> You could run into zbuffer fighting problems which would blow that
> method. Also, the cost for 2 sided lighting is in the transform stage,
> as it the cost for having more polygons, my guess is that the overhead
> for doing 2 sided lighting on N polygons is likely to be less than the
> cost of doing 1 sided lighting on 2*N polygons. By having more polygons
> you're also increasing the likelyhood that your bottleneck could be in
> the CPU->transform stage of the pipe, ie pumping the vertices into the
> gfx.

        This is actually a question.. Shouldn't the back facing polygons be
culled away before making it to lighting calculations, or at least before
resterization (I mean, back face culling shuould mean culling polys away at
some point after they have been transformed). I'm not sure that this is like
having twice as many polygons for the whole pipe, at some point we should
benefit from doing back face culling.

> Bear in mind that all the above could be a little irrelevant if it turns
> out you're fill limited anyway :-)
>
> pfStats are you're friend here, you should be able to set up you're
> model with a geostate that has 2 sided lighting for the bits that need
> it, then measure performance with 2 sided on/off and see what the effect
> is.
>
> Cheers
> Rob
>
> > I'm modelling with Multigen II Pro with Performer 2.2 on Onyx RE2 and
> > Octane.
> >
> > Any suggestions?
> > Simon
> > ________________________________________________________________________
> >
> > Simon C. Mills
> > Modelling & Simulation Section (TOS-EMM) Tel: +31 (0)71 565 3725
> > European Space Agency (ESA/ESTEC) Fax: +31 (0)71 565 5419
> > Postbus 299, 2200AG Noordwijk e-mail: simon++at++wgs.estec.esa.nl
> > The Netherlands http://www.estec.esa.nl/wmwww/EMM
> > ________________________________________________________________________
> > =======================================================================
> > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> ________________________________________________________________
> Rob Jenkins Silicon Graphics mailto:robj++at++sgi.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
>-- End of excerpt from Rob Jenkins

-- 
------------------------------------------------------------------------
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
------------------------------------------------------------------------

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Dec 02 1998 - 06:48:50 PST

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