quesa-develop

texture alpha: premultiplied or not?

[James W. <ja...@fr...>]

Back in 2004, there was some discussion here about the fact that the 
Interactive Renderer essentially assumes that ARGB textures use 
premultiplied alpha, and questioning whether it ought to be an option. 
Yesterday I changed the OpenGL renderer to assume non-premultiplied 
alpha, but now I'm wondering if that was too rash.

The QD3D manual doesn't seem to give any hint whether alpha should be 
premultiplied or not.  I believe there was a claim in 2004 that 
QuickDraw 3D did use premultiplied alpha, but I can't confirm that 
today.  When I loaded an ARGB texture test in Classic Geom Test, the 
result doesn't agree with either of our renderers.

If you'd like to check it yourself, my test model is here: 
<ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It contains 2 
flat TriMeshes.  One is opaque and gray, another has an ARGB texture 
whose background has alpha = 0, color = white, intended for use as 
non-premultiplied.  The opaque TriMesh looks transparent in Classic, 
which I don't understand at all.

Anyway, in the previous discussion, it was suggested that the 
premultipled flag could be set with an object property on the renderer, 
or a new style object.  It occurs to me now that it might make sense to 
set it at the level of individual textures... maybe a new pixel type 
constant like kQ3PixelTypeARGB32Premultiplied, maybe an object property 
or custom element.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: texture alpha: premultiplied or not?

[<jo...@st...>]

On May 10, 2007, at 23:08 UTC, James Walker wrote:

> Back in 2004, there was some discussion here about the fact that the 
> Interactive Renderer essentially assumes that ARGB textures use 
> premultiplied alpha, and questioning whether it ought to be an
> option.  Yesterday I changed the OpenGL renderer to assume non
> -premultiplied  alpha, but now I'm wondering if that was too rash.

I'd say so.  :)  First, you don't want to break existing software; and
second, premultiplied alpha can be very useful in making (for example)
"glow" effects.

> The QD3D manual doesn't seem to give any hint whether alpha should be
> premultiplied or not.  I believe there was a claim in 2004 that 
> QuickDraw 3D did use premultiplied alpha, but I can't confirm that 
> today.  When I loaded an ARGB texture test in Classic Geom Test, the 
> result doesn't agree with either of our renderers.

Hmm.  That's surprising.  It's been a while, of course, but I was sure
that textures have worked the same way in Quesa as in QD3D from the
beginning.  Certainly neither I nor my artist partner (Jeff Quan) have
ever noticed the difference -- and he's even written a tutorial on the
proper use of premultiplied alpha.  That was for Meshwork users, and
was years ago, so I'd think he/we would have tested it under QD3D.

> Anyway, in the previous discussion, it was suggested that the 
> premultipled flag could be set with an object property on the
> renderer,  or a new style object.  It occurs to me now that it might
> make sense to  set it at the level of individual textures... maybe a
> new pixel type  constant like kQ3PixelTypeARGB32Premultiplied, maybe
> an object property  or custom element.

That'd be OK, but for the sort of thing I've done, it would be
overkill.  An object property on the renderer would be fine, and a
style object would be even finer.  I don't see a need to be more
granular than that.  Most objects either need to glow, or they don't --
and it's certainly not hard to premultiply some of the textures if
needed.

Best,
- Joe

--
Joe Strout -- jo...@st...
Strout Custom Solutions

Re: texture alpha: premultiplied or not?

[James W. <ja...@fr...>]

jo...@st... wrote:
> On May 10, 2007, at 23:08 UTC, James Walker wrote:
> 
>> Back in 2004, there was some discussion here about the fact that the 
>> Interactive Renderer essentially assumes that ARGB textures use 
>> premultiplied alpha, and questioning whether it ought to be an
>> option.  Yesterday I changed the OpenGL renderer to assume non
>> -premultiplied  alpha, but now I'm wondering if that was too rash.
> 
> I'd say so.  :)  First, you don't want to break existing software; and
> second, premultiplied alpha can be very useful in making (for example)
> "glow" effects.
> 
>> The QD3D manual doesn't seem to give any hint whether alpha should be
>> premultiplied or not.  I believe there was a claim in 2004 that 
>> QuickDraw 3D did use premultiplied alpha, but I can't confirm that 
>> today.  When I loaded an ARGB texture test in Classic Geom Test, the 
>> result doesn't agree with either of our renderers.
> 
> Hmm.  That's surprising.  It's been a while, of course, but I was sure
> that textures have worked the same way in Quesa as in QD3D from the
> beginning.  Certainly neither I nor my artist partner (Jeff Quan) have
> ever noticed the difference -- and he's even written a tutorial on the
> proper use of premultiplied alpha.  That was for Meshwork users, and
> was years ago, so I'd think he/we would have tested it under QD3D.

OK...

>> Anyway, in the previous discussion, it was suggested that the 
>> premultipled flag could be set with an object property on the
>> renderer,  or a new style object.  It occurs to me now that it might
>> make sense to  set it at the level of individual textures... maybe a
>> new pixel type  constant like kQ3PixelTypeARGB32Premultiplied, maybe
>> an object property  or custom element.
> 
> That'd be OK, but for the sort of thing I've done, it would be
> overkill.  An object property on the renderer would be fine, and a
> style object would be even finer.  I don't see a need to be more
> granular than that.  Most objects either need to glow, or they don't --
> and it's certainly not hard to premultiply some of the textures if
> needed.

Maybe even that's overkill.  Maybe I should just document that 
premultiplied alpha is expected, say next to kQ3PixelTypeARGB32 in the 
header docs.  As for the OpenGL renderer, I didn't like the switching 
back and forth between glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) 
and glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA), but I could go the 
other way: use premultiplied alpha even for vertex colors, and always 
use glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: texture alpha: premultiplied or not?

[Roger H. <rog...@mi...>]

On 11 May, 2007, at 00:08, James Walker wrote:

> Back in 2004, there was some discussion here about the fact that the
> Interactive Renderer essentially assumes that ARGB textures use
> premultiplied alpha, and questioning whether it ought to be an option.
> Yesterday I changed the OpenGL renderer to assume non-premultiplied
> alpha, but now I'm wondering if that was too rash.
>
> The QD3D manual doesn't seem to give any hint whether alpha should be
> premultiplied or not.  I believe there was a claim in 2004 that
> QuickDraw 3D did use premultiplied alpha, but I can't confirm that
> today.  When I loaded an ARGB texture test in Classic Geom Test, the
> result doesn't agree with either of our renderers.

You mean the interactive renderers in Quesa and QuckDraw3D are  
different?
>
> If you'd like to check it yourself, my test model is here:
> <ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It  
> contains 2
> flat TriMeshes.  One is opaque and gray, another has an ARGB texture
> whose background has alpha = 0, color = white, intended for use as
> non-premultiplied.  The opaque TriMesh looks transparent in Classic,
> which I don't understand at all.

Er, maybe I'm being thick (as usual), but alpha==0 means transparent,  
alpha ==1.0 (or 0xFF) means opaque. What's to not understand?

>
> Anyway, in the previous discussion, it was suggested that the
> premultipled flag could be set with an object property on the  
> renderer,
> or a new style object.  It occurs to me now that it might make  
> sense to
> set it at the level of individual textures... maybe a new pixel type
> constant like kQ3PixelTypeARGB32Premultiplied, maybe an object  
> property
> or custom element.

Sounds like a good idea to me, data can be imported into my programs  
so if you are going to support two types of alpha data, then the type  
needs to be bound to the data, how else could I render an image with  
a mixture of pre-multiplied and non pre-multiplied textures on many  
objects, pixmap markers, foreground and background images.

When was the concept of pre-multiplied alpha invented? After  
QuickDraw3D?

We should try to make existing data files to appear the same by  
default whenever possible.

Roger.

Re: texture alpha: premultiplied or not?

[James W. W. <os...@jw...>]

On May 11, 2007, at 4:27 AM, Roger Holmes wrote:

>
> On 11 May, 2007, at 00:08, James Walker wrote:
>
>> Back in 2004, there was some discussion here about the fact that the
>> Interactive Renderer essentially assumes that ARGB textures use
>> premultiplied alpha, and questioning whether it ought to be an  
>> option.
>> Yesterday I changed the OpenGL renderer to assume non-premultiplied
>> alpha, but now I'm wondering if that was too rash.
>>
>> The QD3D manual doesn't seem to give any hint whether alpha should be
>> premultiplied or not.  I believe there was a claim in 2004 that
>> QuickDraw 3D did use premultiplied alpha, but I can't confirm that
>> today.  When I loaded an ARGB texture test in Classic Geom Test, the
>> result doesn't agree with either of our renderers.
>
> You mean the interactive renderers in Quesa and QuckDraw3D are
> different?

Right.  At least on the one machine where I made the comparison.

>>
>> If you'd like to check it yourself, my test model is here:
>> <ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It
>> contains 2
>> flat TriMeshes.  One is opaque and gray, another has an ARGB texture
>> whose background has alpha = 0, color = white, intended for use as
>> non-premultiplied.  The opaque TriMesh looks transparent in Classic,
>> which I don't understand at all.
>
> Er, maybe I'm being thick (as usual), but alpha==0 means transparent,
> alpha ==1.0 (or 0xFF) means opaque. What's to not understand?

The fact that this particular TriMesh had no transparency color  
attribute and no texture, but looked translucent in Classic.

>
>>
>> Anyway, in the previous discussion, it was suggested that the
>> premultipled flag could be set with an object property on the
>> renderer,
>> or a new style object.  It occurs to me now that it might make
>> sense to
>> set it at the level of individual textures... maybe a new pixel type
>> constant like kQ3PixelTypeARGB32Premultiplied, maybe an object
>> property
>> or custom element.
>
> Sounds like a good idea to me, data can be imported into my programs
> so if you are going to support two types of alpha data, then the type
> needs to be bound to the data, how else could I render an image with
> a mixture of pre-multiplied and non pre-multiplied textures on many
> objects, pixmap markers, foreground and background images.
>
> When was the concept of pre-multiplied alpha invented? After
> QuickDraw3D?

I think the idea of premultiplied alpha goes back to about 1984.   
When did QD3D come out, about 1994?

Re: texture alpha: premultiplied or not?

[Roger H. <rog...@mi...>]

On 11 May, 2007, at 17:23, James W. Walker wrote:

>
> On May 11, 2007, at 4:27 AM, Roger Holmes wrote:
>
>>
>> On 11 May, 2007, at 00:08, James Walker wrote:
>>
>>> Back in 2004, there was some discussion here about the fact that the
>>> Interactive Renderer essentially assumes that ARGB textures use
>>> premultiplied alpha, and questioning whether it ought to be an
>>> option.
>>> Yesterday I changed the OpenGL renderer to assume non-premultiplied
>>> alpha, but now I'm wondering if that was too rash.
>>>
>>> The QD3D manual doesn't seem to give any hint whether alpha  
>>> should be
>>> premultiplied or not.  I believe there was a claim in 2004 that
>>> QuickDraw 3D did use premultiplied alpha, but I can't confirm that
>>> today.  When I loaded an ARGB texture test in Classic Geom Test, the
>>> result doesn't agree with either of our renderers.
>>
>> You mean the interactive renderers in Quesa and QuckDraw3D are
>> different?
>
> Right.  At least on the one machine where I made the comparison.
>
>>>
>>> If you'd like to check it yourself, my test model is here:
>>> <ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It
>>> contains 2
>>> flat TriMeshes.  One is opaque and gray, another has an ARGB texture
>>> whose background has alpha = 0, color = white, intended for use as
>>> non-premultiplied.  The opaque TriMesh looks transparent in Classic,
>>> which I don't understand at all.
>>
>> Er, maybe I'm being thick (as usual), but alpha==0 means transparent,
>> alpha ==1.0 (or 0xFF) means opaque. What's to not understand?
>
> The fact that this particular TriMesh had no transparency color
> attribute and no texture, but looked translucent in Classic.

I have opened your model on my latest product using Quesa and on an  
old G4 running OS9 and QuickDraw3D.

On the OLD machine with QuickDraw3D I see two surfaces, an opaque  
grey one and in front of it a patterned one. With the interactive  
renderer there is no transparency in either, but with the Microspot  
Renderer the white parts of the patterned surface do not appear i.e.  
they are transparent. Possibly the NuBus accelerator card and/or  
LightWorks supported transparency.

With Quesa I do not see the grey surface at all, it does not even  
affect the bounding box, which it would if it were transparent. Maybe  
my program deletes it for some reason, it does go through and deletes  
certain objects just after reading a file for backward compatibility  
with old version which left invisible junk in the file, like empty  
groups. The interactive renderer again shows the white pixels and  
once again with the Microspot renderer they are transparent.

For this file it seems that the interactive renderer is compatible  
across QD3D and Quesa, as is the Microspot renderer (not surprisingly  
as its the same source code).






>
>>
>>>
>>> Anyway, in the previous discussion, it was suggested that the
>>> premultipled flag could be set with an object property on the
>>> renderer,
>>> or a new style object.  It occurs to me now that it might make
>>> sense to
>>> set it at the level of individual textures... maybe a new pixel type
>>> constant like kQ3PixelTypeARGB32Premultiplied, maybe an object
>>> property
>>> or custom element.
>>
>> Sounds like a good idea to me, data can be imported into my programs
>> so if you are going to support two types of alpha data, then the type
>> needs to be bound to the data, how else could I render an image with
>> a mixture of pre-multiplied and non pre-multiplied textures on many
>> objects, pixmap markers, foreground and background images.
>>
>> When was the concept of pre-multiplied alpha invented? After
>> QuickDraw3D?
>
> I think the idea of premultiplied alpha goes back to about 1984.
> When did QD3D come out, about 1994?

That sounds about right, though the Metafile format was discussed  
quite a while before they told us they were developing any code. Not  
that is relevant here. If pre-multiplied goes back that far then  
Apple might or might not have used it. No help to us, but there is a  
clue in that the interactive renderer does not support Alpha, so it  
seems unlikely that they would want to divide back by the alpha to  
get the correct colour for displaying as opaque, especially in the  
case of dividing by zero.

Roger.

Re: texture alpha: premultiplied or not?

[James W. <ja...@fr...>]

Roger Holmes wrote:

>>>> If you'd like to check it yourself, my test model is here:
>>>> <ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It
>>>> contains 2
>>>> flat TriMeshes.  One is opaque and gray, another has an ARGB texture
>>>> whose background has alpha = 0, color = white, intended for use as
>>>> non-premultiplied.  The opaque TriMesh looks transparent in Classic,
>>>> which I don't understand at all.
>>> Er, maybe I'm being thick (as usual), but alpha==0 means transparent,
>>> alpha ==1.0 (or 0xFF) means opaque. What's to not understand?
>> The fact that this particular TriMesh had no transparency color
>> attribute and no texture, but looked translucent in Classic.
> 
> I have opened your model on my latest product using Quesa and on an  
> old G4 running OS9 and QuickDraw3D.
> 
> On the OLD machine with QuickDraw3D I see two surfaces, an opaque  
> grey one and in front of it a patterned one. With the interactive  
> renderer there is no transparency in either, but with the Microspot  
> Renderer the white parts of the patterned surface do not appear i.e.  
> they are transparent. Possibly the NuBus accelerator card and/or  
> LightWorks supported transparency.

That suggests that the Microspot renderer assumes non-premultiplied 
alpha.  You see, the texture in my test model was set up for 
non-premultiplied alpha... the transparent areas have alpha = 0 and 
color = white.  Therefore, a renderer that assumes non-premultiplied 
alpha should show it as completely tranparent, while a renderer that 
assumes premultiplied alpha should show it as translucent white.

> With Quesa I do not see the grey surface at all, it does not even  
> affect the bounding box, which it would if it were transparent. Maybe  
> my program deletes it for some reason, it does go through and deletes  
> certain objects just after reading a file for backward compatibility  
> with old version which left invisible junk in the file, like empty  
> groups.

My bad.  I had converted the model to ASCII form with Anatas, and 
somehow the presence of name elements prevented Quesa from loading it 
correctly.  I have re-uploaded the file without the name elements.

> The interactive renderer again shows the white pixels and  
> once again with the Microspot renderer they are transparent.

If you look closely, they are not completely opaque white in the 
interactive renderer, they are translucent.

> For this file it seems that the interactive renderer is compatible  
> across QD3D and Quesa, as is the Microspot renderer (not surprisingly  
> as its the same source code).

What's the same source code as what?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

ASCII Name and URL Elements

[Stefan H. <st...@to...>]

"Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.: 
URLElement" are not very parser friendly.

The problem is in E3FFR_3DMF_Text.c/e3fformat_3dmf_text_readobjecttype.
E3FileFormat_GenericReadText_SkipBlanks cannot read object types with 
blanks in their name. So the parser tries to handle an object "Apple".

   Stefan
   http://www.topoi.ch


>My bad.  I had converted the model to ASCII form with Anatas, and
>somehow the presence of name elements prevented Quesa from loading it
>correctly.  I have re-uploaded the file without the name elements.
...
>    James W. Walker, Innoventive Software LLC

ASCII Name and URL Elements (2nd)

[Stefan H. <st...@to...>]

Please ignore the previous mail. So once again...

"Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.: 
URLElement" are not very parser friendly.

The problem is in E3FFR_3DMF_Text.c/e3fformat_3dmf_text_readobjecttype.
E3FileFormat_GenericReadText_ReadUntilChars with argument blank = 
true cannot read object types with blanks in their name. So the 
parser tries to handle an object "Apple" and runs into trouble.

   Stefan
   http://www.topoi.ch


>My bad.  I had converted the model to ASCII form with Anatas, and
>somehow the presence of name elements prevented Quesa from loading it
>correctly.  I have re-uploaded the file without the name elements.
...
>    James W. Walker, Innoventive Software LLC

Re: ASCII Name and URL Elements (2nd)

[James W. W. <os...@jw...>]

On May 12, 2007, at 9:10 AM, Stefan Huber wrote:

> Please ignore the previous mail. So once again...
>
> "Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.:
> URLElement" are not very parser friendly.
>
> The problem is in E3FFR_3DMF_Text.c/ 
> e3fformat_3dmf_text_readobjecttype.
> E3FileFormat_GenericReadText_ReadUntilChars with argument blank =
> true cannot read object types with blanks in their name. So the
> parser tries to handle an object "Apple" and runs into trouble.

I wish Apple had published a formal grammar for ASCII 3DMF.  It is  
not clear to me how the parser is supposed to know where an object  
type ends, or how to tell the difference between a label and an  
object type.

Re: ASCII Name and URL Elements (2nd)

[Roger H. <rog...@mi...>]

On 14 May, 2007, at 00:32, James W. Walker wrote:

>
> On May 12, 2007, at 9:10 AM, Stefan Huber wrote:
>
>> Please ignore the previous mail. So once again...
>>
>> "Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.:
>> URLElement" are not very parser friendly.
>>
>> The problem is in E3FFR_3DMF_Text.c/
>> e3fformat_3dmf_text_readobjecttype.
>> E3FileFormat_GenericReadText_ReadUntilChars with argument blank =
>> true cannot read object types with blanks in their name. So the
>> parser tries to handle an object "Apple" and runs into trouble.
>
> I wish Apple had published a formal grammar for ASCII 3DMF.  It is
> not clear to me how the parser is supposed to know where an object
> type ends, or how to tell the difference between a label and an
> object type.

I agree. But here, can't we just read everything up to the colon?

Re: ASCII Name and URL Elements (2nd)

[James W. W. <os...@jw...>]

On May 14, 2007, at 2:21 AM, Roger Holmes wrote:

>
> On 14 May, 2007, at 00:32, James W. Walker wrote:
>
>>
>> On May 12, 2007, at 9:10 AM, Stefan Huber wrote:
>>
>>> Please ignore the previous mail. So once again...
>>>
>>> "Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.:
>>> URLElement" are not very parser friendly.
>>>
>>> The problem is in E3FFR_3DMF_Text.c/
>>> e3fformat_3dmf_text_readobjecttype.
>>> E3FileFormat_GenericReadText_ReadUntilChars with argument blank =
>>> true cannot read object types with blanks in their name. So the
>>> parser tries to handle an object "Apple" and runs into trouble.
>>
>> I wish Apple had published a formal grammar for ASCII 3DMF.  It is
>> not clear to me how the parser is supposed to know where an object
>> type ends, or how to tell the difference between a label and an
>> object type.
>
> I agree. But here, can't we just read everything up to the colon?

That takes you to the middle of the name element object type.  Then  
what?  It appears that in a label, the colon should always be  
followed by a line break.  So, if it's not followed by a line break,  
we continue reading up to the open parenthesis?

Re: ASCII Name and URL Elements (2nd)

[Roger H. <rog...@mi...>]

On 14 May, 2007, at 17:23, James W. Walker wrote:

> On May 14, 2007, at 2:21 AM, Roger Holmes wrote:
>
>>
>> On 14 May, 2007, at 00:32, James W. Walker wrote:
>>
>>>
>>> On May 12, 2007, at 9:10 AM, Stefan Huber wrote:
>>>
>>>> Please ignore the previous mail. So once again...
>>>>
>>>> "Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.:
>>>> URLElement" are not very parser friendly.
>>>>
>>>> The problem is in E3FFR_3DMF_Text.c/
>>>> e3fformat_3dmf_text_readobjecttype.
>>>> E3FileFormat_GenericReadText_ReadUntilChars with argument blank =
>>>> true cannot read object types with blanks in their name. So the
>>>> parser tries to handle an object "Apple" and runs into trouble.
>>>
>>> I wish Apple had published a formal grammar for ASCII 3DMF.  It is
>>> not clear to me how the parser is supposed to know where an object
>>> type ends, or how to tell the difference between a label and an
>>> object type.
>>
>> I agree. But here, can't we just read everything up to the colon?
>
> That takes you to the middle of the name element object type.  Then
> what?

 From the only two samples so far mentioned, the spaces are only in  
the first part of the name element object type. The rest is a normal  
identifier terminated by white space or any non alpha-numeric character.

> It appears that in a label, the colon should always be
> followed by a line break.  So, if it's not followed by a line break,
> we continue reading up to the open parenthesis?

A parser or any lexical analyser does not need to apply the same  
rules to a symbol in all circumstances. A label can have different  
rules to a name element object type. Any compiler can treat a colon  
in a comment differently from a colon in a statement.

Re: ASCII Name and URL Elements (2nd)

[James W. <ja...@fr...>]

Roger Holmes wrote:
> On 14 May, 2007, at 17:23, James W. Walker wrote:
> 
>> On May 14, 2007, at 2:21 AM, Roger Holmes wrote:
>>
>>> On 14 May, 2007, at 00:32, James W. Walker wrote:
>>>
>>>> On May 12, 2007, at 9:10 AM, Stefan Huber wrote:
>>>>
>>>>> Please ignore the previous mail. So once again...
>>>>>
>>>>> "Apple Computer, Inc.:NameElement" and "Apple Computer, Inc.:
>>>>> URLElement" are not very parser friendly.
>>>>>
>>>>> The problem is in E3FFR_3DMF_Text.c/
>>>>> e3fformat_3dmf_text_readobjecttype.
>>>>> E3FileFormat_GenericReadText_ReadUntilChars with argument blank =
>>>>> true cannot read object types with blanks in their name. So the
>>>>> parser tries to handle an object "Apple" and runs into trouble.
>>>> I wish Apple had published a formal grammar for ASCII 3DMF.  It is
>>>> not clear to me how the parser is supposed to know where an object
>>>> type ends, or how to tell the difference between a label and an
>>>> object type.
>>> I agree. But here, can't we just read everything up to the colon?
>> That takes you to the middle of the name element object type.  Then
>> what?
> 
>  From the only two samples so far mentioned, the spaces are only in  
> the first part of the name element object type. The rest is a normal  
> identifier terminated by white space or any non alpha-numeric character.

True... I don't know of any formal rules as to what constitutes a legal 
type name, but it would certainly be an improvement to at least handle 
the standard Apple names.

>> It appears that in a label, the colon should always be
>> followed by a line break.  So, if it's not followed by a line break,
>> we continue reading up to the open parenthesis?
> 
> A parser or any lexical analyser does not need to apply the same  
> rules to a symbol in all circumstances. A label can have different  
> rules to a name element object type. Any compiler can treat a colon  
> in a comment differently from a colon in a statement.

True, but a compiler knows it's looking at a C or C++ comment as soon as 
the comment has started.  A 3DMF parser doesn't know whether it is 
looking at a label or an object type until it has either gone past a 
colon or reached a line break or parenthesis.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

error: HiddenLine.h: No such file or directory

[Roger H. <rog...@mi...>]

Hi, I just did an anonymous checkout of the latest Quesa source and  
tried compiling the QuesaCocoa project.

It gives this error:

/Users/roger/Desktop/quesa/quesa anon 21052007/Development/Projects/ 
Mac/../../Source/Core/Support/E3System.c:53:24: error: HiddenLine.h:  
No such file or directory


Why are plug-in renderers being referenced directly inside E3System.c ?

Rayshade and QuesaCocoa

[Roger H. <rog...@mi...>]

Hi All,

After doing an anonymous checkout of the latest Quesa source I tried  
to compile Rayshade (with XCode on Mac. I want it to work with  
QuesaCocoa). It complains that Quesa/Quesa.h is missing.

I have changed the code to include Quesa.h instead and got it to  
compile but I can't get it to link.  Hundreds of link errors. Come  
back CodeWarrior all is forgiven! I've tried including the Quesa  
framework, QuesaCocoa as a sub project and dependency.

I would like to update our products to include RayShade.

Any idea what I'm doing wrong?

Roger.

Re: Rayshade and QuesaCocoa

[James W. <ja...@fr...>]

Roger Holmes wrote:
> Hi All,
> 
> After doing an anonymous checkout of the latest Quesa source I tried  
> to compile Rayshade (with XCode on Mac. I want it to work with  
> QuesaCocoa). It complains that Quesa/Quesa.h is missing.
> 
> I have changed the code to include Quesa.h instead and got it to  
> compile but I can't get it to link.  Hundreds of link errors. Come  
> back CodeWarrior all is forgiven! I've tried including the Quesa  
> framework, QuesaCocoa as a sub project and dependency.
> 
> I would like to update our products to include RayShade.
> 
> Any idea what I'm doing wrong?

I think what you should do is remove Quesa.framework and add 
QuesaCocoa.framework.

By the way, if you're looking for more realistic rendering, I'm working 
on adding shadows (as an option) to the OpenGL renderer.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: error: HiddenLine.h: No such file or directory

[James W. <ja...@fr...>]

Roger Holmes wrote:
> Hi, I just did an anonymous checkout of the latest Quesa source and  
> tried compiling the QuesaCocoa project.
> 
> It gives this error:
> 
> /Users/roger/Desktop/quesa/quesa anon 21052007/Development/Projects/ 
> Mac/../../Source/Core/Support/E3System.c:53:24: error: HiddenLine.h:  
> No such file or directory

I just updated the QuesaCocoa project.  It should work, as soon as the 
anonymous cvs is synchronized with the password-protected cvs.

> Why are plug-in renderers being referenced directly inside E3System.c ?

They're actually built in, not plug-ins.  A renderer like the cartoon 
renderer, which is a subclass of the OpenGL renderer, can't really be 
made as a separate plug-in.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

A problem with enums in XCode (2.4).

[Roger H. <rog...@mi...>]

I know this occurs in several places within Quesa, some of which I  
have fixed in my own copy, and Peter tried to explain the problem to  
you and failed. I have now found another occurrence and while it is  
fresh in my mind, I hope I can explain it clearly.

In QuesaRenderer.h there is an enum called TQ3CSGObjectID. This has a  
final value 0xFFFFFFFF to try to force it to 32 bits. It also has an  
initial value of -1. This worked fine with CodeWarrior where 'enum  
always int' took care of it all anyway (note it is not called enum  
always UNSIGNED int).

The second registration in E3Renderer_RegisterClass is:


  		qd3dStatus = Q3_REGISTER_CLASS (	kQ3ClassNameAttributeCSGID,
											NULL,
											E3CSGAttribute ) ;


This macro expands to call E3ClassTree::RegisterClass with a final  
parameter of sizeof ( E3CSGAttribute ) which is 20 in XCode (2.4) but  
is 16 on CodeWarrior.

This means that when I retrieve the value of a CSGAttribute by  
passing the address of a long, it copies 8 bytes of data into my  
'long' and  corrupts whatever comes after it in memory.

This is because E3CSGAttribute is:

class E3CSGAttribute : public E3Attribute // This is a leaf class so  
no other classes use this,
								// so it can be here in the .c file rather than in
								// the .h file, hence all the fields can be public
								// as nobody should be including this file
	{
Q3_CLASS_ENUMS ( kQ3AttributeTypeConstructiveSolidGeometryID,  
E3CSGAttribute, E3Attribute )
public :

	TQ3CSGObjectID			instanceData ;
	} ;

E3Attribute is 12 bytes long and XCode adds 8 bytes for  
TQ3CSGObjectID whereas CodeWarrior only adds 4 bytes.

Changing the final 0xFFFFFFFF to 0x7FFFFFFF cures the problem.

I have tried 0xFFFFFFFFL, 0xFFFFFFFFU and 0xFFFFFFFFUL and none of  
them cure the problem. Changing the -1 to  0xFFFFFFFFUL makes the  
field the correct size, but probably host programs would not work  
correctly, especially if they test for less than zero. 0x7FFFFFFF  
seems to me to be the best solution.

Roger.

Re: A problem with enums in XCode (2.4).

[James W. <ja...@fr...>]

Roger Holmes wrote:

> I know this occurs in several places within Quesa, some of which I  
> have fixed in my own copy, and Peter tried to explain the problem to  
> you and failed. I have now found another occurrence and while it is  
> fresh in my mind, I hope I can explain it clearly.
> 
> In QuesaRenderer.h there is an enum called TQ3CSGObjectID. This has a  
> final value 0xFFFFFFFF to try to force it to 32 bits. It also has an  
> initial value of -1. This worked fine with CodeWarrior where 'enum  
> always int' took care of it all anyway (note it is not called enum  
> always UNSIGNED int).
> 
> The second registration in E3Renderer_RegisterClass is:
> 
> 
>   		qd3dStatus = Q3_REGISTER_CLASS (	kQ3ClassNameAttributeCSGID,
> 											NULL,
> 											E3CSGAttribute ) ;
> 
> 
> This macro expands to call E3ClassTree::RegisterClass with a final  
> parameter of sizeof ( E3CSGAttribute ) which is 20 in XCode (2.4) but  
> is 16 on CodeWarrior.
> 
> This means that when I retrieve the value of a CSGAttribute by  
> passing the address of a long, it copies 8 bytes of data into my  
> 'long' and  corrupts whatever comes after it in memory.
> 
> This is because E3CSGAttribute is:
> 
> class E3CSGAttribute : public E3Attribute // This is a leaf class so  
> no other classes use this,
> 								// so it can be here in the .c file rather than in
> 								// the .h file, hence all the fields can be public
> 								// as nobody should be including this file
> 	{
> Q3_CLASS_ENUMS ( kQ3AttributeTypeConstructiveSolidGeometryID,  
> E3CSGAttribute, E3Attribute )
> public :
> 
> 	TQ3CSGObjectID			instanceData ;
> 	} ;
> 
> E3Attribute is 12 bytes long and XCode adds 8 bytes for  
> TQ3CSGObjectID whereas CodeWarrior only adds 4 bytes.
> 
> Changing the final 0xFFFFFFFF to 0x7FFFFFFF cures the problem.
> 
> I have tried 0xFFFFFFFFL, 0xFFFFFFFFU and 0xFFFFFFFFUL and none of  
> them cure the problem. Changing the -1 to  0xFFFFFFFFUL makes the  
> field the correct size, but probably host programs would not work  
> correctly, especially if they test for less than zero. 0x7FFFFFFF  
> seems to me to be the best solution.

OK, I'm convinced now.  There are only a few enumerations containing 
negative values: TQ3CSGObjectID, TQ3RaveVendorID, TQ3RaveEngineID, 
TQ3Error, TQ3Warning, TQ3Notice.  I'll fix them, though SourceForge CVS 
is broken at the moment.

Incidentally, it is not clear to me whether Xcode is in compliance with 
the standard.  The relevant sentence is: "It is implementation-defined 
which integral type is used as the underlying type for an enumeration 
except that the underlying type shall not be larger than int unless the 
value of an enumerator cannot fit in an int or unsigned int."  Each 
enumerator of TQ3CSGObjectID can fit into an int or unsigned int, but 
you can't pick just one of int and unsigned int and fit every enumerator 
of TQ3CSGObjectID into it.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: A problem with enums in XCode (2.4).

[Roger H. <rog...@mi...>]

On 24 May, 2007, at 19:41, James Walker wrote:

>
> OK, I'm convinced now.  There are only a few enumerations containing
> negative values: TQ3CSGObjectID, TQ3RaveVendorID, TQ3RaveEngineID,
> TQ3Error, TQ3Warning, TQ3Notice.  I'll fix them, though SourceForge  
> CVS
> is broken at the moment.

Good, they're the ones I had too.

>
> Incidentally, it is not clear to me whether Xcode is in compliance  
> with
> the standard.  The relevant sentence is: "It is implementation-defined
> which integral type is used as the underlying type for an enumeration
> except that the underlying type shall not be larger than int unless  
> the
> value of an enumerator cannot fit in an int or unsigned int."  Each
> enumerator of TQ3CSGObjectID can fit into an int or unsigned int, but
> you can't pick just one of int and unsigned int and fit every  
> enumerator
> of TQ3CSGObjectID into it.


Yes I see what you mean, the specifiers may have had just this  
situation in mind. However, long term I suspect int will become the  
same size as a pointer when most developers start to go to 64 bit  
addressing. As I got to C/C++ via Apple Pascal (earlier Fortran IV,  
Algol 60, BCPL and Coral 66 and a few others along the way as well as  
assembly and raw machine code), I have not used int much anyway, just  
char, short and long. I've also used word lengths of 36, 60, 24, 18,  
48, 8, 16, 32 and soon 64 bits, and bytes of 9, 3 and 8 bits, as well  
as 2's complement, 1's complement, decimal and sterling (pounds  
shillings and pence) arithmetic and three or four measurement systems  
(Imperial,  Centimeters/Grams/Second, modern Systeme International 
(SI) units as well as some US units), so I'm quite flexible.

Roger 

Re: texture alpha: premultiplied or not?

[James W. W. <os...@jw...>]

On May 11, 2007, at 12:22 PM, Roger Holmes wrote:

> I have opened your model on my latest product using Quesa and on an
> old G4 running OS9 and QuickDraw3D.
>
> On the OLD machine with QuickDraw3D I see two surfaces, an opaque
> grey one and in front of it a patterned one. With the interactive
> renderer there is no transparency in either, but with the Microspot
> Renderer the white parts of the patterned surface do not appear i.e.
> they are transparent. Possibly the NuBus accelerator card and/or
> LightWorks supported transparency.

I opened the corrected model on a G4 running OS 9.2, and saw the  
image below (assuming it comes through the mail) in the interactive  
renderer.  I'm not sure what to make of it.  It's obviously not  
ignoring the alpha channel, but the white halos suggest that maybe  
it's treating texels as fully opaque unless the alpha value is  
exactly 0.

Re: texture alpha: premultiplied or not?

[James W. <ja...@fr...>]

In parallel to this thread, I have been reading up on alpha compositing 
and premultiplied alpha, and I can see that it is reasonable to prefer 
premultiplied alpha.  It's still not completely clear how QuickDraw 3D 
handled alpha, but it does appear that the Interactive Renderer in Quesa 
assumes premultiplied alpha, and probably has always done so.

Here's what I've done:

* Changed the OpenGL renderer back to assuming premultiplied alpha.

* Added documentation about premultiplied alpha to TQ3PixelType in Quesa.h.

* Defined a new object property, 
kQ3RendererPropertyConvertToPremultipliedAlpha, which can be applied to 
the renderer object.  This causes a conversion to premultiplied alpha 
when the texture is loaded into OpenGL, and works on both Interactive 
and OpenGL renderers.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>