quesa-develop — Mailing list for Quesa development

Re: Announcing shadow rendering feature

[Daniele C. <dca...@in...>]

If compile with mac os x I haven't problem. The new Renderer with 
shadows seem work well, with windows xp I have some problem.
If I try to download with wincvs I don't download all file (For example 
Folder Hidden Line missing).
It is not a big problem because I can use file download into mac os x.
When I compile with visual studio 2005 there is an error: 'INFINITY' 
undeclared identifier.
Can you help me?





James W. Walker ha scritto:
> On May 31, 2007, at 1:29 AM, Daniele Cavallini wrote:
>
>   
>> It is very interesting I would like to try it soon. Can I already
>> download it by cvs?
>>     
>
> Yes.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

Re: Announcing shadow rendering feature

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

On May 31, 2007, at 1:29 AM, Daniele Cavallini wrote:

> It is very interesting I would like to try it soon. Can I already
> download it by cvs?

Yes.

Re: Announcing shadow rendering feature

[Daniele C. <dca...@in...>]

It is very interesting I would like to try it soon. Can I already 
download it by cvs?
If it isn't possible when will be?
Thank's
Daniele
James Walker ha scritto:
> Description
>
> The Quesa OpenGL renderer now has an option to render shadows.   It 
> produces sharp-edged shadows from any directional, spot, or point light 
> that has its cast-shadows flag set to kQ3True.  It respects the 
> casts-shadows style but not the receive-shadows style.  Translucent 
> objects do not cast shadows, nor do lines or points.
>
> Rendering with shadows can be requested by setting an object property on 
> the renderer object:
>
> 	TQ3Boolean	theFlag = kQ3True;
> 	Q3Object_SetProperty( theRenderer, kQ3RendererPropertyShadows,
> 		sizeof(theFlag), &theFlag );
>
> This option can be used with or without the per-pixel lighting option. 
> It is not intended to work with orthographic cameras.
>
>
> Hardware Requirements
>
> In order to render with shadows, your OpenGL drawing context must:
>
> 1. Be able to have a stencil buffer at least 8 bits deep, as well as a 
> depth buffer.  (This is usually not a problem.  One case where it fails 
> is the Windows software renderer.)
>
> 2. Support either OpenGL 2.0 or the GL_EXT_stencil_two_side extension.
>
> It is preferable, but not essential, to have the extensions 
> GL_EXT_stencil_wrap and GL_NV_depth_clamp as well.
>
>
> Warnings
>
> The algorithm sets the "yon" value of your camera range to infinity.  To 
> prevent surprises, it would be a good idea to set "yon" to infinity 
> yourself. While it is true that you get the best depth resolution when 
> hither is as large as possible and yon is as small as possible, it is 
> much more important to make hither as large as possible.
>
> If you are using Quesa on Windows, beware that Windows does not allow 
> setting the pixel format of a window more than once.  This means that if 
> you start rendering without shadows, and then attempt to turn on 
> shadows, it will fail, because you will not be able to get a stencil 
> buffer.  You can work around this problem by explicitly requesting a 
> stencil buffer from the start, using 
> kQ3DrawContextPropertyGLStencilBufferDepth.
>
>
> Performance
>
> Shadows require a multi-pass rendering algorithm.  The first pass 
> handles ambient light and non-shadow-casting lights, assuming there are 
> no more than 8 of them.  Then for each shadow-casting light, there is a 
> stencil marking pass followed by a lighting pass.  Naturally, this will 
> be slower than a single-pass algorithm.  There is even more of a speed 
> hit if you combine per-pixel lighting with shadows, since each lighting 
> pass will be slower.
>
> Naturally, you can improve performance by designating some lights and 
> some objects as not casting shadows.  It also helps to use the Remove 
> backfacing style when feasible, and to ensure that your TriMeshes supply 
> face normal vectors.
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

Re: Announcing shadow rendering feature

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

Jose' Cruanyes wrote:

>> It is not intended to work with orthographic cameras.
> 
> in that case, it fails or just is ignored?

To tell the truth, I didn't test it.  It probably fails.

>>   One case where it fails is the Windows software renderer.
> 
> So it's not suitable for printing... or there is a way to render on  
> the GPU for printing?

There is an option I recently added to render offscreen contexts using 
framebuffer objects, when the GPU supports FBOs.  See 
kQ3DrawContextPropertyAcceleratedOffscreen.  I have not yet used that on 
Windows, so I cannot swear it is bug-free.

>> Warnings
>>
>> The algorithm sets the "yon" value of your camera range to  
>> infinity.  To
>> prevent surprises, it would be a good idea to set "yon" to infinity
>> yourself. While it is true that you get the best depth resolution when
>> hither is as large as possible and yon is as small as possible, it is
>> much more important to make hither as large as possible.
> 
> doesn't it restore the yon after the loop? so I've to restore it when  
> switching renderers... one of mine works better with an small range...

OK, I just added code to restore yon at the end of the frame.


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

Re: Announcing shadow rendering feature

[Jose' C. <cru...@ce...>]

> Description
>
> The Quesa OpenGL renderer now has an option to render shadows.   It
> produces sharp-edged shadows from any directional, spot, or point =20
> light
> that has its cast-shadows flag set to kQ3True.  It respects the
> casts-shadows style but not the receive-shadows style.  Translucent
> objects do not cast shadows, nor do lines or points.
>


Great News!!!


> It is not intended to work with orthographic cameras.

in that case, it fails or just is ignored?

>
>   One case where it fails is the Windows software renderer.

So it's not suitable for printing... or there is a way to render on =20
the GPU for printing?


>
>
> Warnings
>
> The algorithm sets the "yon" value of your camera range to =20
> infinity.  To
> prevent surprises, it would be a good idea to set "yon" to infinity
> yourself. While it is true that you get the best depth resolution when
> hither is as large as possible and yon is as small as possible, it is
> much more important to make hither as large as possible.

doesn't it restore the yon after the loop? so I've to restore it when =20=

switching renderers... one of mine works better with an small range...



Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Announcing shadow rendering feature

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

Description

The Quesa OpenGL renderer now has an option to render shadows.   It 
produces sharp-edged shadows from any directional, spot, or point light 
that has its cast-shadows flag set to kQ3True.  It respects the 
casts-shadows style but not the receive-shadows style.  Translucent 
objects do not cast shadows, nor do lines or points.

Rendering with shadows can be requested by setting an object property on 
the renderer object:

	TQ3Boolean	theFlag = kQ3True;
	Q3Object_SetProperty( theRenderer, kQ3RendererPropertyShadows,
		sizeof(theFlag), &theFlag );

This option can be used with or without the per-pixel lighting option. 
It is not intended to work with orthographic cameras.


Hardware Requirements

In order to render with shadows, your OpenGL drawing context must:

1. Be able to have a stencil buffer at least 8 bits deep, as well as a 
depth buffer.  (This is usually not a problem.  One case where it fails 
is the Windows software renderer.)

2. Support either OpenGL 2.0 or the GL_EXT_stencil_two_side extension.

It is preferable, but not essential, to have the extensions 
GL_EXT_stencil_wrap and GL_NV_depth_clamp as well.


Warnings

The algorithm sets the "yon" value of your camera range to infinity.  To 
prevent surprises, it would be a good idea to set "yon" to infinity 
yourself. While it is true that you get the best depth resolution when 
hither is as large as possible and yon is as small as possible, it is 
much more important to make hither as large as possible.

If you are using Quesa on Windows, beware that Windows does not allow 
setting the pixel format of a window more than once.  This means that if 
you start rendering without shadows, and then attempt to turn on 
shadows, it will fail, because you will not be able to get a stencil 
buffer.  You can work around this problem by explicitly requesting a 
stencil buffer from the start, using 
kQ3DrawContextPropertyGLStencilBufferDepth.


Performance

Shadows require a multi-pass rendering algorithm.  The first pass 
handles ambient light and non-shadow-casting lights, assuming there are 
no more than 8 of them.  Then for each shadow-casting light, there is a 
stencil marking pass followed by a lighting pass.  Naturally, this will 
be slower than a single-pass algorithm.  There is even more of a speed 
hit if you combine per-pixel lighting with shadows, since each lighting 
pass will be slower.

Naturally, you can improve performance by designating some lights and 
some objects as not casting shadows.  It also helps to use the Remove 
backfacing style when feasible, and to ensure that your TriMeshes supply 
face normal vectors.

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

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

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.

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 ?

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

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

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

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

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

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

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

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