plib-devel

Re: [Plib-devel] ssg states followup

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

"Curtis L. Olson" wrote:
> 
> Steve,
> 
> I think I stumbled on the answer to my previous question ... just call
> my_state->force() ... right?
> 
> Hmmm, it's even there in the docs, fancy that.

*ouch*!!  :-)

> Ok, one more question.  Is it legal to use ssgSimpleStates to control
> *all* the states that you can glEnable and glDisable?  I'm thinking
> about things like GL_FOG, GL_DEPTH_TEST, GL_CULL_FACE, etc.

No - I had great heartache over that.  I decided to stick to those
states that you are likely to want to set and unset rapidly in a
'typical' application.  That keeps to a minimum the amount of state
*testing* for each leaf node as it's rendered.

It would be a pretty weird application that needed to switch
Fog and Depth-test on a per-leaf-node basis.

Of course GL_CULL_FACE is set per ssgLeaf node - so you don't want
to mess with ssgState's for that.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] ssg state question

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

"Curtis L. Olson" wrote:
> 
> Steve,
> 
> There are several places in my program where I'm rendering things
> outside of the ssg scene graph.  These other sections require various
> opengl state changes.
> 
> What I'd like to do is create ssgSimpleStates to encapsulate these
> changes so I can use ssg's lazy state evaluator technology.  My goal
> is to bury _all_ opengl state changes inside of ssgSimpleStates.
> 
> Is there a way apply an ssgSimpleState without having it attached to
> an ssgEntity and thus be automatically applied during
> ssgCullAndRender() ?

Yep - you can call:

   mystate -> apply () ;

...to apply the state 'lazily' (ie to set only those things that
SSG *thinks* need to be changed) - or if you are deep ing
state-hell:

  mystate -> force () ;

...to force SSG to set every single itty-bitty state element to
this state's setup.

You also might want to check out the new ssgContext stuff.  It's
in the new online manual.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] ssg states followup

[Curtis L. O. <cu...@in...>]

Steve,

I think I stumbled on the answer to my previous question ... just call
my_state->force() ... right?

Hmmm, it's even there in the docs, fancy that.

Ok, one more question.  Is it legal to use ssgSimpleStates to control
*all* the states that you can glEnable and glDisable?  I'm thinking
about things like GL_FOG, GL_DEPTH_TEST, GL_CULL_FACE, etc.

Thanks,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] ssg state question

[Curtis L. O. <cu...@in...>]

Steve,

There are several places in my program where I'm rendering things
outside of the ssg scene graph.  These other sections require various
opengl state changes.

What I'd like to do is create ssgSimpleStates to encapsulate these
changes so I can use ssg's lazy state evaluator technology.  My goal
is to bury _all_ opengl state changes inside of ssgSimpleStates.

Is there a way apply an ssgSimpleState without having it attached to
an ssgEntity and thus be automatically applied during
ssgCullAndRender() ?

Still trying to dig my way out of opengl state hell.

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] Direct X file format

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

Sylvan wrote:

>[...]
>and not nearly as complicated as it might seem from reading the docs;
>once you start implementing a loader you'll see its pretty easy
>(especially the binary format).

Yes I think so too, I think it is quite straight forward.

It is very hard to say how many people use it:
I had a short look on the internet and didnt find any *.x file.
However, this is not too surprising, since AFAIK no editor
generates *.x. I was beta-tester (or should I say alpha-tester :-))
of one, but it failed.
However, on Windows it MIGHT be common for people
writing games in their spare-time to use direct-x retained mode and
to load *.x. You can use microsofts free converter to convert them
from *.3ds.

BTW, I looked in my mdi_edit-code and it uses the API
to load/save *.x, so thats not portable. I think I also have
delphi-code that "manually" writes ascii-*.x files. However, I 
have enough on my plate now.

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] Direct X file format

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

Sylvan Clebsch wrote:
> 
> Dave McClurg wrote:
> >
> > You are correct, API calls you make to read/write them.
> > Documentation on the specficiation was hard to find.
> 
> actually, no. use the contents tab in MSDN and try:

For anyone who doesn't have the MSDN Library CD:

http://www.microsoft.com/directx/dxm/help/d3drm/oview/xfileFormat.htm#xfilefrm_Introduction

CU,
Christian

Re: [Plib-devel] Direct X file format

[Sylvan C. <si...@si...>]

Dave McClurg wrote:
> 
> Would you consider contributing your .x loader to SSG?
> It would be easier than starting from scratch.

i'd love to, but trust me, it won't help any more than the docs will :)
its written for my scene graph, not ssg (like i said, i'm afraid i don't
use ssg, sorry), and is tightly woven in with the way i handle meshes in
memory. it even relies on a file system abstraction layer that isn't
appropriate at all for plib :) really though, it wasn't much work, and
the docs were very clear.

-s

Re: Re: [Plib-devel] Direct X file format

[Dave M. <dp...@ef...>]

Sylvan Clebsch Wrote:

>i wrote a .x loader for my scene graph in a couple hours. i'm afraid i
>don't use ssg so i didn't write a loader for that; it shouldn't take
>more than a day for someone familiar with ssg who has the MSDN docs.

Would you consider contributing your .x loader to SSG?
It would be easier than starting from scratch.

Re: [Plib-devel] Direct X file format

[Sylvan C. <si...@si...>]

Dave McClurg wrote:
> 
> You are correct, API calls you make to read/write them.
> Documentation on the specficiation was hard to find.

actually, no. use the contents tab in MSDN and try:

MSDN, platform SDK, Graphics and Multimedia Services, Microsoft DirectX,
DirectX Foundation, Direct3D Retained Mode, DirectX File Format.

its a complete spec, for both ascii and binary formats. actually, the
file format is ok, not the greatest, but pretty good for what it does.
and not nearly as complicated as it might seem from reading the docs;
once you start implementing a loader you'll see its pretty easy
(especially the binary format).

> I couldn't find anything portable or opensource out there for X 
> format. Anyone else?

i wrote a .x loader for my scene graph in a couple hours. i'm afraid i
don't use ssg so i didn't write a loader for that; it shouldn't take
more than a day for someone familiar with ssg who has the MSDN docs.

-s

[Plib-devel] dynamic image loaders

[Dave M. <dp...@ef...>]

>> Do either of the current formats BMP or SGI (bw) support that?
>
>Yes - SGI format images support alpha, you can choose between
>intensity/alpha and r/g/b/alpha formats.
>Use SGI format - it does alpha just fine.

Thanks

>What's really needed is some dynamic loading of image loaders...

Won't PPE need that soon?

[Plib-devel] Direct X file format

[Dave M. <dp...@ef...>]

>> >Something also should consider is supporting the X format - the native
>> >Direct3D format... perhaps in a one way direction only ;-)
>> 
>Is it documented anywhere on the web?   I've found that most
>M$ file formats are poorly documented because people generally
>read or write them with a Win32 API call...is that the case here?

I have DirectX 7 on my machine and I looked at the samples.

You are correct, API calls you make to read/write them.
Documentation on the specficiation was hard to find.

Also, many DirectXFormat files are binary and the ascii
syntax looks nice but is complex enough to make me cringe.

I couldn't find anything portable or opensource out there for X format.
Anyone else?

--Dave

[Plib-devel] file access wrappers

[Dave M. <dp...@ef...>]

>What I would *consider* doing would be:
>
>1) Write a file name mangling function that converts UNIX-style
>   file names to the 'native' file name format.
>
>2) Write wrappers for fopen/dirent to use that standard that
>   give the appearance of all systems accepting either UNIX-style
>   or native file name/path conventions.
>
>That's maybe an evening's work with very little maintenance needed
>after that - versus a fairly major chunk of effort.
>

Thanks. I'd appreciate that.

If the wrapper is in a seperate module then the app can redefine
them to use whatever resource management is appropriate.

--Dave

Re: [Plib-devel] PLIB/PPE loaders/writers

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

Steve Baker wrote:
> 
> I didn't even know this 'X' format existed.  Is it widely used?

Dunno. I just know that it exists and I've seen a modeler for it a long
time ago.

> Is it documented anywhere on the web?   I've found that most
> M$ file formats are poorly documented because people generally
> read or write them with a Win32 API call...is that the case here?

I dunno about the web. But let me have a look in my chrystal ball (the
MSDN Library CD):
I see a section that says:

---
The Microsoft® DirectX® file format is an architecture- and context-free
file format. It is template driven and is free of any usage knowledge.
The file format may be used by any client application and currently is
used by Microsoft® Direct3D® Retained Mode to describe geometry data,
frame hierarchies and animations. 

The rest of this section will deal with the content and syntax of the
file format. The file format uses the extension .x when used with the
DirectX Software Development Kit. 
---

I also see a a section that says:

---
This document specifies the file format introduced with Microsoft®
DirectX® 2. A binary version of this format was subsequently released
with DirectX 3, which is also detailed in this reference. 

The DirectX file format provides a rich template-driven file format that
enables the storage of meshes, textures, animations, and user-definable
objects. Support for animation sets allows predefined paths to be stored
for playback in real time. Instancing and hierarchies are also
supported. Instancing allows multiple references to an object, such as a
mesh, while storing its data only once per file. Hierarchies are used to
express relationships between data records. The DirectX file format is
used natively by the Microsoft® Direct3D® Retained Mode API, providing
support for reading predefined objects into an application or writing
mesh information constructed by the application in real time. 

The DirectX file format provides low-level data primitives, upon which
applications define higher-level primitives through templates. This is
the method by which Direct3D defines higher-level primitives such as
vectors, meshes, matrices and colors. 

This document details the API-independent features of the file format
and also the method by which Direct3D Retained Mode uses the file
format. It includes the following topics: 

DirectX File Format Architecture 
Appendix A: Templates 
Appendix B: Example 
Appendix C: Binary Format 
Appendix D: The Conv3ds.exe Utility 
---

I guess that everybody can get those informations through the M$ MSDN
web page (http://msdn.microsoft.com ?) by downloading the DirectX SDK

CU,
Christian

[Plib-devel] Quaternion Development Direction

[Negative0 <neg...@ea...>]

Hello,

 I submitted a few changes to Steve to fix the Quaternion code. I had
emailed the list before asking for help, then I realized that there was
several errors in the sg libraries Quaternion routines. Off the top off my
head I remember 4 errors (sgNormalizeQuat, sgInvertQuat, sgMultQuat,
sgSlerpQuat), but I have far more drastic changes in mind that can't be made
until we find out how many people it will impact. I'd like to point out that
nobody could possibly be using Quaternions (correctly) at this point, so the
impact should be nil.

First:
 The other calls in sg all use float arrays, so making function calls simply
uses the variables name. But the quats, being structs, need the address
assignment operator. If sgQuat were an array of floats as well it would make
all the sg function calls similar in syntax and you would avoid situations
like:  sgMakeMat4( matrix, &quat ),  by using an array of floats it would be
sgMakeMat4( matrix, quat )


Second:
 By making it an array of floats it matches the sgVec3 definition and
becomes ambiguous in some of the function overloading. My personal take on
the function overloading is what I was taught. Don't overload dissimilar
functions. sgMakeQuat( quat, vec ) and sgMakeQuat( quat, axis, angle ) may
appear to be similar enough because they both make a quat, but they're not.
They do totally different things to get a quat. However
gAngleAxisToQuat( quat, angle, axis )  and  sgAngleAxisToQuat( quat, angle,
x, y, z )  ARE similar enough because its the same operation (in fact the
x,y,z form wraps a call to the axis form). As another example, all the
functions that convert a quat *could* be forced into a sgConvertQuat(...)
naming scheme, but that would constrain the syntax and make adding new
functions harder.


Here's a list of the proposed functions, parameter order, and naming scheme:

#define SGfloat GLfloat
#define sgFloat GLfloat

typedef sgFloat sgQuat[4]

sgQuatToEuler( sgFloat yaw, sgFloat pitch, sgFloat roll, sgQuat quat )
sgEulerToQuat( sgQuat quat, sgFloat yaw, sgFloat pitch, sgFloat roll )

sgQuatToAngleAxis( sgFloat angle, sgVec3 axis, sgQuat quat )
sgAngleAxisToQuat( sgQuat quat, sgFloat angle, sgVec3 axis )

sgQuatToAngleAxis( sgFloat angle, sgFloat x, sgFloat y, sgFloat z, sgQuat
quat )
sgAngleAxisToQuat( sgQuat quat, sgFloat angle, sgFloat x, sgFloat y, sgFloat
z )

sgQuatToMatrix( sgMat4 matrix, sgQuat quat )
sgMatrixToQuat( sgQuat quat, sgMat4 matrix )

sgMakeIdentQuat ( sgQuat dst )
sgSetQuat ( sgQuat dst, const sgFloat w, const sgFloat x, const sgFloat y,
const sgFloat z )
sgSetQuat( sgQuat dst, const sgVec4 src )
sgCopyQuat ( sgQuat dst, const sgQuat src )

sgNormalizeQuat ( sgQuat dst, const sgQuat src )
sgNormalizeQuat ( sgQuat dst )

sgInvertQuat ( sgQuat dst, const sgQuat src )
sgInvertQuat ( sgQuat dst )

sgMultQuat ( sgQuat dst, const sgQuat a, const sgQuat b )
sgPostMultQuat ( sgQuat dst, const sgQuat q )
sgPreMultQuat ( sgQuat dst, const sgQuat q )

sgRotQuat ( sgQuat dst, const sgFloat angle, const sgVec3 axis )
sgRotQuat ( sgQuat dst, const sgFloat angle, const sgFloat x, const sgFloat
y, const sgFloat z )

sgSlerpQuat( sgQuat dst, const sgQuat from, const sgQuat to, const sgFloat
step )


You'll notice that I have actually killed every sgMakeQuat call which is
different than the way sgMat4 and sgVec3 (etc) work.


If everyone thinks this is too different, or takes the sg library in the
wrong direction, that's fine. I'll make sure Steve has the patches needed to
make the sg Quaternions work. But if people like the syntax and change, then
let the list know and I can send in all of the changes.

-negative0

Re: [Plib-devel] ssgImageLoader

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

Dave McClurg wrote:
> 
> I would like to have textures with alpha so I can do
> non-rectangular buttons mapped to panels.
> 
> Do either of the current formats BMP or SGI (bw) support that?

Yes - SGI format images support alpha, you can choose between
intensity/alpha and r/g/b/alpha formats.

BMP does not seem to.

> If not, the only way I can think of doing this cleanly is to
> derive from ssgImageLoader and install my "new"
> image loader into SSG.  That way I can allow my
> new image loader to load PNG files and link with libpng.

Adding PNG support would be great - but it's a complex format
and I'd have to link libpng and zlib - which would increase the
number of dependancies that PLIB would have - which is not a
popular thing to do.

What's really needed is some dynamic loading of image loaders...
but anyway....
 
> Any alternatives?

Use SGI format - it does alpha just fine.
 

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] PLIB/PPE loaders/writers

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

Wolfram Kuss wrote:
> 
> Va...@t-... (Christian Mayer) wrote:
> 
> >Something also should consider is supporting the X format - the native
> >Direct3D format... perhaps in a one way direction only ;-)
> 
> Yes, I personally would like that, as I can read/write *.x in Mdi_edit
> :-).

I didn't even know this 'X' format existed.  Is it widely used?

Is it documented anywhere on the web?   I've found that most
M$ file formats are poorly documented because people generally
read or write them with a Win32 API call...is that the case here?

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] LoadASE problem.

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

Dave McClurg wrote:

> Steve will design something he is comfortable with for PLIB
> but I do think something like VFS is needed functionality

Ehem?!?  Steve wasn't planning on doing anything of the sort!

I'm really not too keen on going to all the trouble of
writing a full-blown file-system-inside-a-file, it's
more work than I want to do - and I wouldn't use it because
I'm utterly unconvinced that it's needed.

What I would *consider* doing would be:

1) Write a file name mangling function that converts UNIX-style
   file names to the 'native' file name format.

2) Write wrappers for fopen/dirent to use that standard that
   give the appearance of all systems accepting either UNIX-style
   or native file name/path conventions.

That's maybe an evening's work with very little maintenance needed
after that - versus a fairly major chunk of effort.

If I *was* going to write a file-system-in-a-file, I'd use
the existing 'tar' format since all the issues of storing
everything necessary for a file system into a single byte
stream has already been solved.  It would also allow you
to create and extract files from these virtual file systems
using 'tar' and have things like file permissions and ownerships
preserved.  The sources for tar are out there - and they port
onto absolutely every platform and address things like
byte ordering between heterogeneous machine 'endianness'.

I *certainly* wouldn't attempt to invent a new 'tarball'-like
format.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] ssgImageLoader

[Dave M. <dp...@ef...>]

I would like to have textures with alpha so I can do
non-rectangular buttons mapped to panels.

Do either of the current formats BMP or SGI (bw) support that?

If not, the only way I can think of doing this cleanly is to
derive from ssgImageLoader and install my "new"
image loader into SSG.  That way I can allow my
new image loader to load PNG files and link with libpng.

Any alternatives?

//current image loader
ssgImageLoader defaultImageLoader;
ssgImageLoader* _ssgImageLoader = defaultImageLoader;
//and make some of ssgImageLoader functions virtual

--Dave

Re: Re: [Plib-devel] LoadASE problem.

[Dave M. <dp...@ef...>]

>>attached virtual file system proposal (similar to CS vfs)
>
>Sounds good. Perhaps we could have it in lib 1.3 or 1.4 or whatever.
>What happens when you write a file and have a searchpath consisting
>or several directories? What happens when you read and the file
>exists in several places?
>

in CS (crystal space) where i took VFS from--

  // Look through all RPathV's for file or directory
  for (int i = 0; i < RPathV.Length (); i++)

so it goes through the real paths in mount order until
the operation succeeds.

this handles read-only archives (write fails) and multiple copies
of same file (takes first one).

Steve will design something he is comfortable with for PLIB
but I do think something like VFS is needed functionality

--Dave

Re: [Plib-devel] LoadASE problem.

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

Dave McClurg <dp...@ef...> wrote:

>attached virtual file system proposal (similar to CS vfs)

Sounds good. Perhaps we could have it in lib 1.3 or 1.4 or whatever.
What happens when you write a file and have a searchpath consisting
or several directories? What happens when you read and the file
exists in several places?

>--Dave

Bye bye,
Wolfram.

Re: [Plib-devel] PLIB/PPE loaders/writers

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

Va...@t-... (Christian Mayer) wrote:

>Something also should consider is supporting the X format - the native
>Direct3D format... perhaps in a one way direction only ;-) 

Yes, I personally would like that, as I can read/write *.x in Mdi_edit
:-).

On the one hand I HATE Direct3D, at least version 3, the only version
I programmed with. Just to tell it "I want to start rendering"
costs 50 (in words: fifty) kilobytes of source. At least at the time,
there was nowhere where you could get the complete code.
I used it because the Voodoos at the time didnt do OpenGL. The full
opengl was always just a few months away :-(.
On the other hand, the direct-3d-retained-mode format (".x") is quite
nice and quite easy.
Also, there are VERY few (I think: 1) converters that can convert 
from AND into *.x.

>CU,
>Christian

Bye bye,
Wolfram Kuss.

Re: [plib-devel] ASE load/save

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

Dave McClurg wrote:

> ASE supports vertex colors and ssgLoadASE passes them to ssgVtxTable
> if they are found.  But vertex colors are optional and may not be present.
> 
> So... is a fix needed and if so what should be done?

Well, it goes back to the various ways to represent colours in OpenGL
(and hence in SSG).

A quick review:

1) You can glDisable(GL_LIGHTING) and whatever glColor you put on
   the vertex will apply - anything put in glMaterial (or
   ssgSimpleState) will be ignored.

2) You can glEnable(GL_LIGHTING) and glDisable(GL_COLOR_MATERIAL)
   and whatever colours you put into the glMaterial will apply -
   anything put in glColor will be ignored.

3) You can glEnable(GL_LIGHTING) and glEnable(GL_COLOR_MATERIAL)
   and set glColorMaterial() to diffuse, ambient, specular, emission
   OR both diffuse and ambient - in which case glMaterial will be
   used for everything else and glColor will set the component named
   in glColorMaterial.

The last of these is the one *I* use pretty much all the time...but
that's not a certainty for all applications.

Now, to add to the complications, SSG uses LAZY state changes.
That means that if for some reason a particular state doesn't
care what setting it has for a particular OpenGL operation - then
ssgState won't bother to set it (or even initialise the variable).

Hence, if (for example) GL_LIGHTING is disabled, then we won't
bother to set the material colours.

So, I guess what your material output routine has to do is to
check if GL_LIGHTING is enabled for this state - and not emit
an ASE material lighting setup if it's glDisabled.

Similarly, if glColorMaterial is enabled and set to (say)
GL_SPECULAR - then there isn't going to be a valid specular
colour in the ssgState - and the ASE material can have any
old junk in it.

Since you told me that ASE has both material colours and
per-vertex colours, it must have a similar set of rules
to OpenGL.

This is all awfully familiar.  There is a complicated set
of OpenGL colour rules - and no way to represent them in
some file formats.  That makes loaders possible - but
writers almost impossible to get right.  So you do the
best you can and document the limitations.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] ssgVtxTable question

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

"Curtis L. Olson" wrote:
> 
> Steve,
> 
> When creating an ssgVtxTable, is it legal for the calling application
> to keep track of the color array (for instance) and periodically
> modify it to dynamically change the color of the object?

Yes! Absolutely.

The only thing you have to be careful about is that if you move the
vertices around then there is a risk that you'll move one or more
vertices outside the bounding sphere of the object - with potentially
dire consequences.  You can fix that by telling SSG to recompute
the bounding sphere:

   my_leaf_node -> dirtyBSphere () ;

..."dirtying" the bounding sphere doesn't force it to be immediately
recomputed - but instead this will be delayed until the node is actually
a candidate for display...it's much more efficient to do this when
there are multiple leaf nodes being changed each frame.

The alternative is to set up a large enough bounding sphere at the
start of the game to contain all of the possible positions of the
vertices in the mode.

Anyway, colours, normals and texture coordinates don't suffer
from this problem...you can just change them at will.

> Also, can you point me to an example of creating an ssgState that does
> smooth interpolations between the vertex colors, but is intended for
> use without lighting and lets me set the colors explicitely with the
> ssgColourArray ...

Just disable lighting - and it'll just do exactly what you want.
Make sure glShadeModel is GL_GOURAUD.
 
> (I'm thinking sky-dome object here ...)

Yep.

> Thanks,
> 
> Curt.
> --
> Curtis Olson   University of MN, ME Dept.       Flight Gear Project
> Twin Cities    cu...@me...                  cu...@fl...
> Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] ssgVtxTable question

[Curtis L. O. <cu...@in...>]

Steve,

When creating an ssgVtxTable, is it legal for the calling application
to keep track of the color array (for instance) and periodically
modify it to dynamically change the color of the object?

Also, can you point me to an example of creating an ssgState that does
smooth interpolations between the vertex colors, but is intended for
use without lighting and lets me set the colors explicitely with the
ssgColourArray ...

(I'm thinking sky-dome object here ...)

Thanks,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] webpage typo

[Dave M. <dp...@ef...>]

webpage typo at http://plib.sourceforge.net/
the descriptions for Mailing lists are switched
for announce and devel