plib-devel

Re: [Plib-devel] Quaternions in plib

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

Sam Stickland wrote:
> 
> Well, it appears it was my code that was broken - not plib.
> 
> This evening I took the tux on a pedestal example and adjusted it so you can
> fly around tux using quaternions, and it all works fine.  I nearly got
> carried away and changed it so you could fly tux about - but then I
> remembered it's susposed to be a simple example.
> 
> As it uses the tux data files should I place it in examples/src/tux or
> examples/src/quaternions and set the model and texture paths to ../tux/data?
> I prefer the later myself, but that's me.
> 
> If I get the time I'll write a small article to go with the exampe source.
> 
> Incidently why does sgCoord store euler angles?  Aren't eulers evil? :)  I
> would had expected an (x, y, z) vector and a quaternion.

Eulers *are* evil in the inner workings of a program - but they are a NECESSARY
evil on the outer edges of the code - where user input comes in, etc.  Hence,
a library that purports to support 3D programming in a fairly general way
should support Eulers, Matrices *and* Quaternions...which PLIB does.  I rather
draw the line at the fourth common method: "Translation+look-at-popint+vertical
axis"...but I guess we should probably add some sort of support for that too.

If you actually read my FAQ entitled "Eulers are Evil", you'll see that it
actually ends up using Eulers in the final "Here is how to do it" example.

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

[Plib-devel] ssgLoad3ds portability

[Troy Y. <tro...@ho...>]

I suppose that this is probably of most interest to Dave
but there may be others of you that are potentially coding
yourselves into the same boat.

I managed to get the SG and SSG libraries compiled on
HPUX 10.20 on a C180 class workstation.  The HP is *very*
particular about having certain things start on word
boundaries.  I had to make the following changes to
ssgLoad3ds.cxx to get it to run without coring and to
correctly load a model.  These particular changes were
made to the version of this file distributed in plib 1.1.11 -
I don't know if additional changes are necessary for the most
recent version.

Most of the changes relate to how get() is used.  Instead
of passing a pointer that might not be on a word boundary
to get(), data is copied from the input buffer into a local
temporary variable of the correct type and the address of
that variable is passed to get().  Rather than list every
change, I'll give an example and a list of functions
effected.

Original:

static int parse_uscale( char **p, unsigned long length )
{
  texture_scale[ num_materials - 1 ][0] = get((float*)*p);
  return PARSE_OK;
}

Becomes:

static int parse_uscale( char **p, unsigned long length )
{
  float  lTmpFloat;

  memcpy((void *) &lTmpFloat, (void *) *p, sizeof(float));
  texture_scale[ num_materials - 1 ][0] = get(&lTmpFloat);
  return PARSE_OK;
}

Other functions effected:
parse_vscale(): 1 instance   (line 261)
parse_uoffst(): 1 instance   (line 267)
parse_voffst(): 1 instance   (line 273)
parse_rgb1():   3 instances  (line 305, 306, 307)
parse_shininess(): 1 instance (line 348)
parse_transparency(): 1 instance (line 356)
parse_vert_list(): 4 instances (line 422, 428, 429, 430)
parse_smooth_list(): 1 instance (line 445)
parse_face_list(): 7 instances (line 504, 515 - 518, 541, 542)
parse_map_list(): 3 instances (line 565, 571, 572)
parse_face_materials(): 2 instances (line 628, 653)
parse_chunks(): 2 instances (line 732, 733)

There are several casts that must be modified.
(line 423, 440, 503, 566, 627)

I also had to fix a small problem with one of the get()
functions.

Original:

static float get(float *f) {
  if (is_little_endian)
    return *f;
  else {
    unsigned long p = (unsigned long)*f;
    endian_swap(&p);
    return p;
  }
}

Fixed:

static float get(float *f) {
  if (is_little_endian)
    return *f;
  else {
    float lTmpFloat = *f;
    endian_swap((unsigned long *) &lTmpFloat);
    return lTmpFloat;
  }
}

After all that, I've also attached the file with my mods and
an output of diff.

Let me know if you need anything else.

Troy.

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

Re: [Plib-devel] Re: KobayashiMaru & plib

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

Wolfram Kuss wrote:

> He did this only when the scene or the camera changed, and rendered
> the complete models once everything was static. The program was
> similar to PPE and he could draw the 3D-cursor without rendering the
> rest (when drawing the 3d-cursor, he saved the pixels underneath).
> Anyway, I guess THIS method (not LODs though) is slightly outdated.

It's not even legal in OpenGL.  When you do a 'swapbuffers', the contents
of the back buffer are "undefined" - which means that you can't rely on
the previous image still being there...which indeed it isn't on some
machines.


> >Let me tell you about Tux-A-Quest-for-Herring.
> >
> >It was the first *ever* 3D game for Linux.
> 
> Yes - a very interesting thing. I would probably have contributed if I
> had heard about it beforehand, but I was not in the linux community.

I didn't really publicise it until it was more or less playable.

I have a lot of fun working on these games - and to start with, I
don't *want* help...that just increases the hassle factor and reduces
the fun.

Once the game is basically working, it would be nice to get help - but
I no longer have illusions about that.

Oliver and I had just finished playing Mario'64 (yep - all 120 gold stars)
and were disappointed that there wasn't any more.  We fondly imagined
that if we built a good game 'engine' and a couple of demo levels, we
would have hundreds of OpenSource level designers building new levels.

Hence we'd end up with a game we could play *forever* without ever
getting to the end.

Well, I'm less naive now!
 
> >I got:
> >
> >  150,000 people visiting the web site over the first 12 hours.
> >   15,000 people downloaded it in the first 12 hours.
> >    1,500 emails complaining/complimenting/thanking me for TuxAQFH
> >          within the next week or so.
> >   ...one year later...
> >      150 people are subscribed to the Tux mailing lists.
> >       15 people have *ever* offered to help with artwork/music/models.
> >      1.5 (OK...2 actually) other people have actually contributed
> >          *anything* to Tux *ever*. One piece of unusable music - and a
> >          couple of unusable models.  No significant chunks of code at all.
> >    *NONE* of those things has ever been useful enough to distribute with
> >          the game.
> 
> Wow, that's even worse than I thought :-(.

Yes - it's kinda depressing.

What suprises *me* is that there are LOTS of contributors to PLIB and
LOTS of people working PPE - but *nobody* wants to contribute to the
games.  I expected the reverse.  Games are fun to write - and do great
things for one's ego and popularity - I'd have thought there would be
WAY more contributors than for a boring support utility library.

Well - I guess not!

> It seems many want to start
> a new project (see all the modelers on Sourceforge) and few want to
> contribute to the project of other people :-(.

I guess that's it.  Perhaps people contribute to PLIB so that they can
write their own games.

That's a little unfortunate because it makes it hard to write really
complex games when only one person is involved.

> >Remember - it took 100 people working full-time 5 years to create
> >Mario'64.  You have about three times that amount of work.  You should
> >be finished in about 1500 years.
> 
> Well, out of the 100 people there are many managers, advertisement
> people, manual writers etc.

True - but still, at least a third of that effort must have been
programmers, musicians and artists...so 500 man-years then!

> But of course it is not possible to compete with the commercial games
> writers except MAYBE under the best conditions (many knowledgable
> contributors with much time and motivation that work together well)
> or of course by programming simple games that work because of the
> idea, a la Tetris.

I have a personal hatred of Tetris.  The last time I counted, there
were 23 versions for Linux - of which about 20 were a complete waste
of human effort!

  Blocks CXHextris Columns fscktris Ltris CrystalSpace-Tetris
  GTetris JTetris Jetris Stax Quadra Tetrinet TwinTRIS VGA-Tetris
  XBlockout XJefris XJewel XTrojka Xemeraldia Xinsane Xpuyopuyo
  Xtet42 Xtris

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

Re: [Plib-devel] PLIB developers needed.

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

Christian Mayer wrote:

> > ...and then remove them anyway!
> 
> I doubt that there is a need to remove it. There is a need for the other
> code to be made const consistent.

BUT IT DOESN'T COMPILE ON AT LEAST ONE C++ IMPLEMENTATION.

> It's *very* important for a library to be const correct!

It's **MUCH** more important that it **COMPILE**!

> There might be
> const correct programs that want to use the library.

There are also programs what would like to actually compile without fatal
errors.

> But as soon as a const correct program wants to use non const correct
> functions it's very likely that the compilation brakes.
> The other way round usually works.

It didn't even get through the ul.h header.  There was no other code
involved apart from standard UNIX headers prior to that point. Also,
the program compiles just fine under Linux - so there isn't
anything wrong with my code.

We are looking at a use of 'const' that is in a more recent C++ spec
than IRIX supports (this is just like the declaration-inside-a-for-loop
issue for MSVC).

If we want our code to be portable, we have to forgo some of the
fancier features of C++ in order to get through the lowest-common-denominator
of all C++ compilers.
 
> As I was writing a const correct FGFS extension (BalloonSim IIRC) it
> wouldn't compile as I was heavily using SG. I had the choice to cast all
> the consts away or make SG const correct. I did the later (and thus had
> to fix half of SSG) as there's no point i casting the consts away. Why
> should I use them otherwise?

I understand that.
 
> PS: const correctness is quite easy to understand once you tried. (Steve
> it shouldn't take you more than 10 minutes). After you've used it a few
> times (with paying full attention) it comes automatically.

OK - I understand - that's not the point.  A program that compiles
just fine under Linux/g++ doesn't compile under IRIX/C++ - and that's
utterly intolerable.

Am I supposed to be somehow consoled that although my program is
completely unusable, it's wonderfully const-correct.  NO!  Const
is a very small part of making programs that work - I've managed
to write and debug millions of lines of code without it.

Programming is a practical skill - it's all about getting a job done.
A feature that prevents me from compiling is infinitely worse than
the teeny-tiny *theoretical* bug it's trying to correct.

Portability is more important to PLIB than const-correctness.

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

Re: [Plib-devel] PLIB developers needed.

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

> Dave McClurg wrote:
> 
> Steve wrote:
> >  I tried to compile PLIB on an SGI machine at work - and your
> > 'const-ification' of the clock
> > routine stopped it from compiling on the IRIX compiler.

> #1 means you can't change what foo points to.  You already use this heavily in SG.

Sure - that makes sense.

> #2 means that the class method getSomething cannot change its instance.

Ah!  I see.

> I really thought 'Type getSomething () const' was a very portable and standard
> idiom.  Could you check the SGI documentation on that?

I don't have documentation that's *that* detailed.  But the code flat-out
won't compile.  Hard errors - not just warnings.  Simply deleting the 'const'
was enough to make it compile.

>  If needed, I will remove the 'const' methods as you advise.

'fraid so.  I use PLIB on SGI's quite a bit these days - and it's
rather embarassing when my very own *portable* library won't compile
on the computer on my desk!

You may have wondered why I don't use 'const' a whole lot - maybe you
realise why!  I loath and detest "creeping const" - where const's have
to be put in and taken out continually to get the program to compile.
AAARRRGGGHHHH!  The few (very few) bugs they save you from are certainly
not worth the hassle.  C (and hence C++) is a great language because it
DOESN'T treat the programmer like a small child.  You are allowed to make
mistakes - and in exchange get to be all-powerful.

Like I said in my last post - C++ was a *great* language in the very
first release - everything added to it since then has been a downhill
slide.

C + classes + overloaded functions + virtual functions ... was
all I ever wanted!

The only addition that I'd make to the original C++ language would
be:

   type *x ;

   ....

   delete x ;

...should do an implicit "x=NULL;"

But I can live without it!

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

Re: [Plib-devel] PLIB developers needed.

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

Sam Stickland wrote:
>
> I believe the revised ANSI C++ scoping rules now forbid declaration of variables in a for statement, completely.  But this is fairly
> recent, so different compilers are still tolerating it in different ways.

*WHAT* ??!?

That's insane.
 
> The scoping for this sort of declaration was always cloudy at best, so it's probably for the best.

Not really.  In the first C++ spec, it said (quite clearly) that the scope was as
if you'd declared the variable immediately before the 'for' loop.  It was realised
by everyone that this was a bad decision - and Bjarne said so in the 'ARM' (Annotated
Reference Manual) - but he decided not to wreck all those existing programs by
changing the language to correct his error.

When ANSI first looked at the problem, they decided that it was better to have the
language "right" - even if that did cause some initial pain.  The pain was dealt
with by *everyone* except Microsoft...

And now you are telling me that they are *both* wrecking the language *and* pissing
off a million programmers?

Geeze.  That's a *terrible* decision.
 
> Bottom line - don't do it.

Well, that was always the bottom line for portable code...but I had hopes that
one day Microsoft would either *DIE* or fix their fscking compiler and we could
all get on with life.

Ack!

They should really have left the C++ spec as it was rather than keep tinkering
with it.  IMHO, just about everything that's happened to C++ since Bjarnes'
first implementation has been a BAD mistake.

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

Re: [Plib-devel] PLIB developers needed.

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

Paul Bleisch wrote:
> 
> >From: Dave McClurg [mailto:Dav...@dy...]
> >Subject: RE: [Plib-devel] PLIB developers needed.
> >
> > for private functions, use all_lower_case unless they would
> > pollute the name space in which case you should use _xxMixedCase
> > (note the leading underscore).  if a variable pollutes the name
> > space, use _xxMixedCase.
> 
> Note that this technically goes against the portability aspect
> of PLIB as identifiers in the global and std:: namespaces starting
> with '_' and '__' are reserved for the implementation in ANSI C++.

Yes - but the alternative isn't very pretty either.

> I know it is used by alot of code and I do it too, but I thought
> it should at least be known.  I get killed by it everytime I
> write a header file:
> 
> #ifndef __Foo_h__
> #define __Foo_h__
> #endif

Exactly.

...and in practice, it's very portable and saves a lot of other problems.

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

Re: [Plib-devel] Work outstanding.

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

Gil Carter wrote:
> 
> At 09:25 AM 8/10/00 +0100, you wrote:
> >Gil wrote:
> >
> > >puTrace
> >
> >Sounds great! Obviously, the more info on bottlenecks there is, the
> >better. For example, it would be GREAT to know how much
> >texture-swapping there is going on, but I doubt this can be done
> >portably?
> 
> Over to Steve for this one, but I suspect that with a little user
> assistance (eg. "How much texture memory does your board have"), we can
> probably have a stab at guessing how much texture swapping from main memory
> to texture memory is occurring.

Well, there isn't a direct way to do either of those things.

You can ask OpenGL if a texture is resident though - so you could
start loading 1k x 1k textures and asking each one whether it's
resident or not - and when they stop being resident - you have a
*reasonable* idea of how much memory there is.  However, real hardware
can be VERY subtle - and the question may not actually be answerable.

 * On SGI ONYX machines, there are two BANKS of texture. When a map
   loads, the odd numbered MIPmaps go in one bank and the even numbered
   into the other.  It's possible to run out of texture memory in one bank
   and still have plenty in the other - so although *theoretically* you have
   free texture memory, your map won't be resident on the hardware.

 * 3D hardware may have on-chip texture cache, on-board texture RAM, AGP
   texture RAM and main memory texture RAM.  These represent a continuum
   of performance.  When you ask "how much memory is there" - you really
   need to ask "how much memory is there that can be accessed at better
   than 150 nanoseconds"... Some Intel i810 boards have NO TEXTURE MEMORY
   AT ALL...getting it all from AGP and using a tiny texture cache.  How
   many bytes should they return as texture memory size?

 * Some cards (GeForce, Voodoo-5 and S3 for example) have texture compression.
   Since you don't know in advance how much your map will compress, there is
   no way to answer the question "how many texels will my card hold?"

Since this question is unanswerable in a portable manner, OpenGL doesn't
attempt to answer it.

As for swapping, what I've done in the past is to check the glAreTexturesResident()
function to find out what textures are resident from frame to frame - if the
answer ever changes then you are swapping textures...but if it doesn't change,
that doesn't tell you that it *didn't* swap because something may have
swapped out and then swapped back in again a dozen times during the frame!

So, these are NOT good questions to ask!

> Anybody know if you can monitor AGP transactions to pick this kind of thing
> up?

Nope - and in any case, that wouldn't be portable because not all cards
use AGP - and lots of things other than textures go across the AGP.
 

> > >puFly
> >
> >Why not use PPE? It has several windows, a hierarchial view, great
> >viewing via mouse or keyboard or commands (for example, "view
> >everything"). It allows you to edit the model while seeing the
> >performance. Of course PPE can load all plib stuff, since it is build
> >on plib.

I agree. PPE has everything you could possibly need in a viewer.
 
> Well, the attraction with perfly is that it really doesn't do anything
> apart from load and display models.

Neither does PPE right now!   :-(

But seriously - if you are not actually in the process of editing a model,
all PPE does is to call ssgCullAndDraw in a tight loop on your model.  It's
perfect as a perfly equivelent for PPE.

>  Perfly's ability to change the rendering parameters is very nice...

PPE can do that.  Turn on and off lighting, shading, texture, wireframe, etc.

> and keeping it as a simple but powerful
> program means that the source stays compact - compact enough to go with the
> standard examples tarball for PLIB.

Well, I don't think it would be all that much of a stretch to assume that
since PPE is free, it'll become as ubiquitous as (say) GIMP - so everyone
who uses PLIB will already have it.  If that's the case, why bother with
another tool?  It's just a waste of disk space.

Having said that, you could write such a thing very easily and dump it
into PLIB-examples if you wanted to.  I don't feel a strong need to do
that.

> The real win with this is that people can build puFly and load up models
> very easily.  The code will be compact enough that people can see how to
> not only use the loaders, but also exercise all of the rendering
> methods.

That's why we have example programs - certainly.

However, Perfly is a mess because it's had anything and everything
slurped into it.  A bunch of simple single-function examples is
generally more instructive IMHO.

If you really want an example of how to put something together using
all the tools, just download TuxKart - it's only 4,000 lines of code.

>  Hopefully, puFly will have enough in it that people can use it as
> a basis for their own first tinkerings - I know I'm still using the
> original tux-on-a-box program as my starting point for experiments!

Yep.

Michael Jones (one time manager of the Performer project) told me that
he quite regretted making Perfly *so* complete because everyone just
hacked Perfly instead of writing appropriate programs from scratch.
You'd be amazed at the number of commercial Performer applications that
are just Perfly with a few hundred lines of code added.
 
> >We could create a new window for puTrace output.
> 
> 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.

Well, I'm not sure 'puTrace' is the right name here. 'ssgStatistics'
might be a better thing to imagine.  Having good rendering statistics
would be a VERY good thing for PPE.
 
>  >[autmatical docs]
> 
> >I am not against them. But I think we need a handcrafted doc for the
> >users of plib as well. For example, you have to give an overview of
> >plib.This fits nowhere in the code.

Yes, I agree.

> Very true.  I guess you can draw the distinction between a programmer's
> guide and an API reference - the API reference is automagically updated
> from source comments, while the programmer's guide is a more static
> document which gets updated when major new features get added.  I'm a big
> fan of nice docs, and I'm more than happy to put the effort into them
> provided other people can point out my errors :-)

Yes.

I dislike documentation embedded in code files because it makes the code
VERY hard to read...it's hard to see the three lines of code for the 30
lines of documentation.  Also, good documentation contains examples - and
I *really* hate having code buried inside comments inside *real* code
because it makes it virtually impossible to 'grep' code and search for
things without tripping over the stoopid examples.

Finally, the order of items in (say) a header file is the order that
makes sense when programming - that's rarely the order that makes for
a readable document.

And all of this is for what?  To avoid having two files?

I'm not very convinced.

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

[Plib-devel] VRML Loader issues

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

At 10:12 AM 8/10/00 -0700, you wrote:

>here's my current code:
><http://www.pond.net/~davem/stuff/blender_import/>http://www.pond.net/~davem/stuff/blender_import/ 
>
>
>i just got started with it so you can start over if you want. i was going 
>to use the ssgParser class in ssg. the WRL files in test_wrl.zip come from 
>exporting the blender examples.  they should be useful regardless of your 
>approach

They are - especially as they are in VRML1, not VRML2 as I was 
expecting.  After VRML1->VRML2 conversion, there are syntax problems with 
them immediately - test1.wrl uses a transform node with negative scaling, 
which is illegal but accepted by "good" browsers.  Hmm....

To provide a little background for my involvement, I offered to write a 
lex/yacc parser for the later VRML97 standard.  The plan was to just 
support static geometry and textures - no sound, movies, animations, 
events, scripting, Java etc.  The parser should read any valid VRML97 file 
without barfing, but will only actually populate an SSG scenegraph with 
geometry and textures.

(Chris St. John has a partially complete parser/loader for VRML97 based on 
an ANTLR grammar, but he hasn't finished it yet.  He recently mentioned 
some good "gotchas" which I'll refer to in my work.)

There has also been a call for VRML1 support, as many CAD packages (and 
Blender) export this.  VRML1 is very similar to the Open Inventor file 
format, but it's quite a different language to VRML 97 - IOW, the '97 
parser won't read it.

Since there would currently be a path to get VRML1 into PLIB via a 
VRML1->VRML2 converter and the VRML97 loader, my initial plan was to get 
the VRML2/VRML97 parser done and then come back to VRML1.  With Blender's 
apparent export of VRML1, this might bump VRML1 support up the priority list.

So what do people think - VRML1 or VRML97 first?

Gil

PS. If you're interested VRML2 and VRML97 are basically identical

RE: [Plib-devel] Work outstanding.

[Paul B. <pbl...@di...>]

Perfly is also "the ultimate judge" on whether a particular feature
of Performer has been tested.  If it is in Perfly, you can almost
guarantee the Performer team has looked at it.

A friend has said that it only took him a few tries to realize that
you don't start from scratch with Performer, you start with Perfly.

(Note I am not suggesting that PFly become some sort of uber-example.)


Paul


> -----Original Message-----
> From: Gil Carter [mailto:g.c...@ca...]
> Sent: Thursday, August 10, 2000 10:41 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] Work outstanding.
> 
> 
> 
> > >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
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] puTrace and puFly

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

Hi,

In our little chats about my proposal for puTrace and puFly, there are a 
number of things which have dawned on me:

* puTrace and puFly are perhaps misnomers - perhaps they should be called 
PTL (PLIB Trace Library) and PFLY instead
* PTL is really two components - the measurement of rendering stats and 
their display.
* Since PLIB is comprised of more than just SSG, there's more to measure 
than just graphics performance - what else do people want to measure?
* Should PFLY seek to exercise *everything* in PLIB - joystick and sound 
also?  Currently, it's just targeted toward benchmarking SSG and using PUI 
to disply results, but it might be handy to have a known-good app for 
letting people debug sound and joystick problems in their own code.

If you guys can offer me some advice, I'll write up a more formal 
requirements analysis for both bits and post it for review.

Gil

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

Re: [Plib-devel] Quaternions in plib

[Alexander R. <a_r...@in...>]

Hi,
> 
> 
> ----- Original Message -----
> From: "Amit Bakshi" <am...@de...>
> To: <pli...@li...>
> Sent: Thursday, August 10, 2000 5:30 PM
> Subject: Re: [Plib-devel] Quaternions in plib
> 
> 
> >
> > Because it's overkill. You don't need to use quaternions for everything.
> > The only thing I use them for is for interpolation keyframed animations.
> > For camera controls , eulers work fine; have been for years.
> 
> But if you have a camera that can move on all three axes, then it's going to
> screw up pretty quickly.  I can't believe that these sort of cameras are all
> that rare (any space/flight sim for example).  Quaternions have the
> advantage that they don't need to be reorthoganised _ever_, and from my
> prespective four floats is a damn site better than twelve for network
> transmission (OK, so it's a naive implementation - you could get away with
> transmitting a single unsigned int if you used a lookup table.  Again
> quaternions would be quicker to lookup).
> 
> Sam


I have neither knowledge of net-related problems,
nor have I designed the net part of my game yet well enough,
bu I think that this is irrelevant !


The speed of the game played through the net does not depoend
on the size of the data transferred at each frame, but 
on the time the packet needs to go from joystick to client engine to 
client net,
there to the internet to some distant server (TIME! is lost), into the servers engine,
and then back to the clients.

if the delay time gets to great, game hangs or so
But you can't improve delay time

But I really have to admit that I dont
kniow what I'm talking about, cause I am a novice in Net stuff
as well as in 3D.
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

I've just downloaded ACE...


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] Quaternions in plib

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Amit Bakshi" <am...@de...>
To: <pli...@li...>
Sent: Thursday, August 10, 2000 5:30 PM
Subject: Re: [Plib-devel] Quaternions in plib


>
> Because it's overkill. You don't need to use quaternions for everything.
> The only thing I use them for is for interpolation keyframed animations.
> For camera controls , eulers work fine; have been for years.

But if you have a camera that can move on all three axes, then it's going to
screw up pretty quickly.  I can't believe that these sort of cameras are all
that rare (any space/flight sim for example).  Quaternions have the
advantage that they don't need to be reorthoganised _ever_, and from my
prespective four floats is a damn site better than twelve for network
transmission (OK, so it's a naive implementation - you could get away with
transmitting a single unsigned int if you used a lookup table.  Again
quaternions would be quicker to lookup).

Sam

Re: [Plib-devel] KobayashiMaru 0.2.9 for BeOS

[Alexander R. <a_r...@in...>]

Hi,

> Alexander Rawass wrote:
> 
> > KobayashiMaru 0.2.9 has now been compiled for Beos5
> > and is available from my Homepage.
> > 
> > I had to patch plib-1.3.0 to compile plib - Beos
> > doesn't seem to have a glXContext , so you just have to put some
> > #ifndef BEOS
> > in puInit and ssgInit,
> > it simply works without this glXContext - check.
> 
> It won't work if your application opens two or more OpenGL windows
> (like PPE for example).
> 
> There *must* be some kind of equivelent function to tell OpenGL
> which
> window to render into from now on.

At least, they dont have glx.h, maybe one should try bglXContext

> Since you are probably the *only* BeOS user right now - it's down

No, I'm not.
I just got Beos5 on CD some time, extracted it to this 500MB windows
file, and had a look at it.
I was just curious how much 'unix' would I find, so I compiled Kobayashi
Maru easy (with plib-1.1.x), and I have still lying it around,
but it's great act, and I don't have a good working environment there.

> to you to find out what and fix it!
> 
> Thanks!  It's good to hear of success under BeOS.

For me, I'll call myself an ignorant and say 'BeOS is just Unix without X'



Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] Quaternions in plib

[Amit B. <am...@de...>]

Because it's overkill. You don't need to use quaternions for everything.
The only thing I use them for is for interpolation keyframed animations.
For camera controls , eulers work fine; have been for years.

As long as you know the limitations of eulers, you should be fine. 

----- Original Message ----- 
From: "Michael Kurth" <neg...@ea...>
To: <pli...@li...>
Sent: Thursday, August 10, 2000 5:25 PM
Subject: Re: [Plib-devel] Quaternions in plib

> Thats good to hear. I fixed the Quaternions many months ago and made a small
> demo of a cube that spun. The spinning could toggle between eular angles and
> quaternions. It wasn't using any other part of PLib except the math library
> so I never sent it in. But it's good to hear someone else has finally used
> the Quaternion code for *something*. I'd really like to know why more people
> aren't using quaternions for camera control.

Re: [Plib-devel] Quaternions in plib

[Alexander R. <a_r...@in...>]

Hi,
> 
> Well, it appears it was my code that was broken - not plib.
> 
> This evening I took the tux on a pedestal example and adjusted it so you can
> fly around tux using quaternions, and it all works fine.  I nearly got
> carried away and changed it so you could fly tux about - but then I
> remembered it's susposed to be a simple example.
> 
> As it uses the tux data files should I place it in examples/src/tux or
> examples/src/quaternions and set the model and texture paths to ../tux/data?
> I prefer the later myself, but that's me.
> 
> If I get the time I'll write a small article to go with the exampe source.
> 
> Incidently why does sgCoord store euler angles?  Aren't eulers evil? :)  I
> would had expected an (x, y, z) vector and a quaternion.

a) DONT USE EULER ANGLES AT ALL!
b) use either direction vectors as I do, or quaternions, construct
   the transformation matrix yourself, BUT DONT USE EULER ANGLES!
c) you can calc direction vectors/quaternions to euler angles, that
   is safe, the other way round is 'unsafe'
d) It cost me a month , exactly this
e) have a look at the math help page on kobayashimaru.sourceforge.net
f) DONT USE EULER ANGLES!

I expect SpaceThing and KobayashiMaru very similar, have a look at
ssgUtil.cxx and spaceobject.cxx:PitchShip/MoveShip/setTransform

will give ypou the code you need.


Alex



-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] Quaternions in plib

[Michael K. <neg...@ea...>]

----- Original Message -----
From: Sam Stickland <sa...@sp...>
To: <pli...@li...>
Sent: Thursday, August 10, 2000 11:57 PM
Subject: [Plib-devel] Quaternions in plib


> Well, it appears it was my code that was broken - not plib.
>
> This evening I took the tux on a pedestal example and adjusted it so you
can
> fly around tux using quaternions, and it all works fine.  I nearly got
> carried away and changed it so you could fly tux about - but then I
> remembered it's susposed to be a simple example.

Thats good to hear. I fixed the Quaternions many months ago and made a small
demo of a cube that spun. The spinning could toggle between eular angles and
quaternions. It wasn't using any other part of PLib except the math library
so I never sent it in. But it's good to hear someone else has finally used
the Quaternion code for *something*. I'd really like to know why more people
aren't using quaternions for camera control.

[Plib-devel] Quaternions in plib

[Sam S. <sa...@sp...>]

Well, it appears it was my code that was broken - not plib.

This evening I took the tux on a pedestal example and adjusted it so you can
fly around tux using quaternions, and it all works fine.  I nearly got
carried away and changed it so you could fly tux about - but then I
remembered it's susposed to be a simple example.

As it uses the tux data files should I place it in examples/src/tux or
examples/src/quaternions and set the model and texture paths to ../tux/data?
I prefer the later myself, but that's me.

If I get the time I'll write a small article to go with the exampe source.

Incidently why does sgCoord store euler angles?  Aren't eulers evil? :)  I
would had expected an (x, y, z) vector and a quaternion.

Sam

RE: [Plib-devel] PLIB developers needed.

[Loring H. <ls...@cs...>]

> This is almost what I did!
> The difference is that when I checked out the files again under
> my userid using cvs/ssh, I only checked out the three files that
> were being changed.  And, I only committed the three files that
> were changed.  Could this make a difference?

possibly - I usually commit and update by directory (cvs commit, not cvs
commit file1 file file2 or cvs update, not cvs update file file2).

> If I commit *all* of plib, is cvs clever enough to only commit the files
> that are actually changed?

Yes

Loring

Re: [Plib-devel] PLIB developers needed.

[<Va...@t-...>]

Gil Carter wrote:
> 
> >Linux people: Please don't do this:
> >
> >     for ( int i = 0 ; i < 10 ; i++ ) whatever ;
> >     for ( int i = 0 ; i < 20 ; i++ ) whatever ;
> >
> >(Although it's perfectly legal C++ - MSVC barfs on it - I forget
> >  about this *every* time - sorry Windoze dudes!)
> 
> But to credit Leath Muller (I think), this will fix that problem:
> 
>      { for ( int i = 0 ; i < 10 ; i++ ) whatever ; }
>      { for ( int i = 0 ; i < 20 ; i++ ) whatever ; }
> 
> But it's daggy and isn't something you'd write given a choice :-)


Yup it fixes it. That's because in MSVC and in ANSI the i have a
different scope.

CU,
Christian

Re: [Plib-devel] PLIB developers needed.

[<Va...@t-...>]

Steve Baker wrote:
> 
>  I tried to compile PLIB on an SGI machine at work - and your 'const-ification' of the clock
> routine stopped it from compiling on the IRIX compiler.
> 
> You had:
> 
>   class ulClock
>   {
>     ...
>     public:
>       ...
>       int getSomething () const { return something ; }
>       ...
>    } ;
> 
> The 'const' seemed to do *bad* things to the SGI compiler.
> 
> Could you remind me what exactly a 'const' right there actually *does*?

Others have already answered that, but I think one point is missing:

This const tells the compiler that ulClock won't be changed by calling
getSomething().

That can cause performance benefits as the compiler can optimize better.
It could e.g. inline that function.
It's also very good for the structure of the code as it prevents any
unwanted access to the data. 
So you can get the excessive type checking at compile time and no subtle
bugs during run time. This gets extremely important when you are using
pointers.
 
> ...and then remove them anyway!

I doubt that there is a need to remove it. There is a need for the other
code to be made const consistent.

It's *very* important for a library to be const correct! There might be
const correct programs that want to use the library.
But as soon as a const correct program wants to use non const correct
functions it's very likely that the compilation brakes.
The other way round usually works.

As I was writing a const correct FGFS extension (BalloonSim IIRC) it
wouldn't compile as I was heavily using SG. I had the choice to cast all
the consts away or make SG const correct. I did the later (and thus had
to fix half of SSG) as there's no point i casting the consts away. Why
should I use them otherwise?

CU,
Christian

PS: const correctness is quite easy to understand once you tried. (Steve
it shouldn't take you more than 10 minutes). After you've used it a few
times (with paying full attention) it comes automatically.

Re: [Plib-devel] Work outstanding.

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: "PLIB-devel" <pli...@li...>
Sent: Wednesday, August 09, 2000 9:54 PM
Subject: [Plib-devel] Work outstanding.

>   * Sam Stickland posted a patch to allow PUI menu's to be resized.  I
havn't
>     had time to deal with that (sorry Sam)...but since he now has CVS
access, I
>     guess he can do it himself now.

I added this change now - I'll document it tomorrow.

Sam

Re: [Plib-devel] PLIB developers needed.

[Wolfram K. <w_...@rz...>]

Loring wrote:

>I have write access to a sourceforge project and I want to be able to switch
>between anonymous CVS and CVS writing.

But did you do the initial checkout anonymously?
I think thats the point.

>Loring

Bye bye,
Wolfram.