Release / [PATCH] included (was: Re: [Plib-devel] [BUG] & non-virtual methods (that should be virt ual))

[Jan R. <slo...@gm...>]

Am Mon, 27 Mar 2006 07:55:47 -0600 schrieb Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...>:

> 	I am all in favor of finally removing the deprecated widgets.
> Perhaps after that (and any new changes that people have waiting in the
> wings?) we should make a new release of PLIB.  There hasn't been one for a
> couple of years.

That would be great. I'd really like to use the new scrollable list
widget in CRRCsim. Like in FG we currently maintain our own
scrollable list code in our CVS.

But before, could maybe someone apply the patch I submitted to this list
on 2005-12-18 (fixes loading of .x files in SSG)? I've attached it for
your convenience.

List of all changes:

1.) When loading an .x file, all materials will be stored in
a globalMaterialList, but the materials are never added to the
LoaderWriterMesh. I've added a fix to ssgLoadX.cxx that adds the
created SimpleStates to the mesh.

2.) Second bugfix is for the mesh handler itself. There's a global
variable currentDiffuse that holds the most recent diffuse colour
found by the ASCII parser. Now when composing the final SSG branch,
all leafs not containing a colour array will be set to this
variable's value. This is, in fact, the colour that was defined last
in whatever file we were parsing. But this is wrong, the right
diffuse colour is located in the SimpleState that is used to draw
the leaf. Therefore we have to create the colour array with that
value. To understand the effect of this bug, here's what I experienced
while bug-hunting: I used a .x airplane model which contained 5 materials.
All materials but the last one were opaque, only the last (used to draw
the propeller disc) was 80% translucent. This caused the whole model
to look 80% translucent because the model did not contain any per-vertex
or per-face colour values, only the colours defined by the materials
(and the GL_COLOR_MATERIAL mode).

3.) I've encountered a lot of .x files that feature a texture
coordinate array which is formatted

...
u1;v1;
u2;v2;
...

instead of

...
u1;v1;,
u2;v2;,
...

The current parser won't work without the commas. My fix removes the
comma-check and makes the parser simply search for the next float
value.

I've tested all fixes with my own application and with the pview example.

Thanks in advance!
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de