Brainval (brainval++at++ehome.encis.es)
Thu, 11 Jun 1998 13:30:36 +0400
Steve Baker wrote:
> There are two possibilities that I can think of:
>
> 1) You are probably pixel-fill limited. Increasing the
> screen area covered by the object increases the number
> of pixels - decreasing the speed *if* that is the
> limiting factor on performance.
>
The cow is a very simple object, with no transparency nor textures.
I do not think that it can reach the fill limit.
In fact, with the same size (Getting full screen ), it takes the same
time in our app, than perfly.
> 2) (Long-shot) Performer can automagically adjust the
> level of detail of objects depending on field of
> view and screen resolution. It's *just* possible
> that the level of detail has been cranked up when
> the FOV is resized such that a bunch more polygons
> are being drawn.
The statistics do not show any LOD in perfly nor in our app.
And the stress is under minimum too.
> I very much doubt that it's (2).
Me too.
> So, why does Perfly do this and not your application?
> Well, perhaps your application chooses a different (and
> perhaps faster) pixel format - such that even with the
> larger screen, you are still not fill limited.
>
> What are the timings from your application in the
> wide and narrow FOV cases?
In our application the time is always the same: 4.4 ms. (While we see
the whole object).
If we only see a portion then the timing decreases, because of the
culling (CULL- VIEW), while in perfly, the time grows. (And I do not
understand why.)
Thanks again.
And still any suggestion will be really helpfull.
Hector Viguer.
Brainstorm Multimedia.
Software development.
e_mail: brainval++at++ehome.encis.es
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:32 PDT