Re: your posting on pf mailing list ...

New Message Reply Date view Thread view Subject view Author view

Andrew Walker (awalker++at++multigen.com)
Thu, 18 Jul 1996 11:04:01 -0700


Shankar

The number was derived from experience. The problem with rich data sets
for realtime simulations is that they aren't very consistent. You have
trees with one texture and ground with another. When your application
determines which polygons are in the display list they are attributed
with many different colors, textures, and normals. The more you can get
these polygons to group together spatially and by similar attributes the
more you can get down the graphics pipeline within the given time
interval (20ms).

If you could make a compelling world where all of the polygons where the
same color and all shared the same texture and vertex normals you would
come closer to the benchmark polygon per second numbers published by the
hardware manufacturers.

Andy

Shankar Swamy wrote:
>
> andy,
>
> several months ago you said in a posting on the performer mailing list
> that: example: 2 CPU, 2 RM4 will draw approx. 2000 to 4000 polygons per 30th
> of a second)"
>
> ... I picked it up from there and always used it and quoted it. I should
> say that always seems to work with my calculations. WHat I need now
> is how you arrived at that number? Is that an emperical observation, or
> is there a formula?
>
> Thanks for your help,
>
> - shankar

-- 
Andrew R. Walker			awalker++at++multigen.com
Member of Technical Staff		( 408 ) - 556 - 2627 DIRECT
MultiGen Inc.				( 408 ) - 261 - 4100 MAIN
550 S. Winchester Blvd. Suite 500	( 408 ) - 261 - 4101 FAX
San Jose, CA 95128                      http://www.multigen.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:53:11 PDT

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