Re: [Plib-devel] Work outstanding.

[Gil C. <g.c...@ca...>]

> >I hadn't thought of puTrace being used inside PPE.  Given that PPE is a
> >modelling package not a gaming engine, is this something you would really
> >need to do?  Obviously it's possible, but I'm not really clear on what you
> >would use it for; I'm open to comments on this.
>
>So am I ;-), I unfortunately never had the opportunity to use
>something like perFly. But I asumed that it is something for the
>developer or artist, not the end user?

Developers, not artists.  Most people seem to use it to check that their 
own apps aren't doing something silly when rendering, or to see how 
different rendering method looks in practice or is implemented in 
source.  It's also a nice sanity check that your build environment works, 
and it's a whizzy little demo app which comes free with the distribution.

>Probably it would be best to
>have the performance monitor both in the engine and the modeler.
>In the engine for the developer, so that he can see the performance
>where it matters, with sound and ai etc going on.
>In the modeler, the developer can quickly make changes, for example
>that car model is too slow - lets try it with opaque windows.

Ok, but keep in mind that you're not just measuring how long it takes to 
render your car - you're really benchmarking the performance of PPE as 
well.  Even though PPE is underpinned by PLIB, if you're developing models 
for a game, your game engine is really the place to benchmark.

Maybe PPE could have a "preview" mode which goes fullscreen with no menus, 
and just renders the current model with trace enabled to give you an idea 
of what type of performance you'll get in a standalone app.  There are 
issues of still having all of the other OpenGL resources consumed to keep 
PPE alive in background, but at least you're not rendering four views of 
the model plus the user interface at each frame :-)

Gil