Re: [Plib-devel] Work outstanding.

[Steve B. <sjb...@ai...>]

Wolfram Kuss wrote:
> 
> Gil wrote:
> 
> >>Why not use PPE? [...]
> >
> >Well, the attraction with perfly is that it really doesn't do anything
> >apart from load and display models.  [...] Hopefully, puFly will have
> >enough in it that people can use it as a basis for their own first
> >tinkerings
> 
> Ok. But I still think it should take as much from PPE as possible.
> For example, I think the viewing can be used 100%.
> With other features, we could modularize the stuff that puTrace or
> puView or however you would call it into seperate files so that there
> is no duplication of effort.

But why?   Wouldn't you just use PPE for viewing models?  Why would I
want a separate program.

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

Perfly is about four things rolled into one - which is the entire
problem with it:

1) It's a viewer.  You built a model and want to see what it
   looks like in Performer - then you load it into Perfly and
   you can twirl it around using the mouse - turn wireframe,
   texture, lighting, etc on and off, etc.

2) It's a sample program - designed to teach newbies how to
   use Performer.

3) It's a starting point for projects that use Performer.

4) It's a test suite for debugging Performer.  When you find
   a bug in Performer, the first thing the developers say is
   "Can you reproduce your bug by adding some of your code
   into Perfly?"

...however, because of these things, it's become too bloated
to serve as a useful teaching program - too complex to help
much with debugging - too hard to use to make a good viewer -
and WAY too nasty to make a good starting point for new
projects.

1) I contend that PPE is our viewer - you can already use it
   for that with GREAT success.  It's a done deal.

2) Sample programs need to be written - lots of little ones,
   each showing off just one or two features at most.

3) We need one good 'skeleton application' that has all the
   things a basic application needs.

4) Right now, I don't think we need a test suite because
   PLIB is OpenSourced - and we rather hope that "with many
   eyes, all bugs are shallow".

> Probably it would be best to
> have the performance monitor both in the engine and the modeler.

It'll *have* to be in SSG because that's where the statistics
are gathered.  We might want to do as Performer does and write
a fancy graphics statistics display function and dump that into
our 'SSG Utilities' library.  That way, you gather stats using
a standard SSG library call - and either display them yourself
or call 'ssguDisplayStatistics ( ssgStatistics *stats )'.

Making it that easy will allow PPE to show stats WHILST the model
is being built...and for games to show stats to the developer with
a minimum of fuss.  You can also write them to disk - use them to
drive fancy load-balancing routines, etc, etc.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net