plib-devel

Re: Re: [plib-devel] ASE load/save

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

>> Using the save.cxx SSG example with loading the tuxedo.ac and saving it
>> then as tuxedo.ase I get
>> 
>> ...
>> *MATERIAL_AMBIENT -431602080.000000 -431602080.000000 -431602080.000000
>> *MATERIAL_DIFFUSE -431602080.000000 -431602080.000000 -431602080.000000
>> ...
>> 
>> in all materials. This doesn't lok right (it looks like some unitialized
>> floats). Is that correct?
>
>Doesn't look good to me - I think the problem is rather subtle.  Those
>certainly are uninitialised variables - but I think the REASON is that
>the ssgState probably had those colours set with a "don't care" flag -
>implying that the ambient and diffuse colours are coming from the
>polygon colour (using glColorMaterial) - meaning that those colours
>are just plain WRONG.
>
>What the correct fix is - I'm not sure - depends on the ASE file format.

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?

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)