quesa-develop — Mailing list for Quesa development

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 28-Sep-04, at 9:03 PM, James W. Walker wrote:

> Frank Condello <dev...@ch...> wrote:
>
>> Which case was that? I can't seem to render anything properly with
>> the current code. Triangles pop unpredictably at the slightness
>> change in the viewport... From my perspective, your centroid code is
>> the lesser of two evils :)
>
> IIRC it was the case of a single box.

I just spent a few minutes playing with your test app, and ya, the 
current method seems to handle a single box better (there are still 
errors though). But add a couple more boxes and it fails miserably - I 
still think your centroid method is much better for a general purpose 
sort.

I guess I'd just like to see a better generic sort in there for now, so 
we can tweak special cases from a good starting point, rather than 
trying to work with an algorithm that's breaks more often that not. 
Dealing with built-in primitives shouldn't be too hard. For convex 
polyhedra like a box, you can assume any triangle with it's normal 
facing away from the camera must be behind any triangle facing the 
camera. You can use this fact to influence the ordering even if the 
centroid calculation says different.

Frank.

Re: Question on transparent camera transformed objects.

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

Frank Condello <dev...@ch...> wrote:

>Which case was that? I can't seem to render anything properly with
>the current code. Triangles pop unpredictably at the slightness
>change in the viewport... From my perspective, your centroid code is
>the lesser of two evils :)

IIRC it was the case of a single box.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Patch for bug #901422 (CLAMP_TO_EDGE)

[Frank C. <dev...@ch...>]

Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that  
checks for CLAMP_TO_EDGE and uses it when available for texture shaders  
that have a kQ3ShaderUVBoundaryClamp setting. The original report is  
here:  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=901422&group_id=45158&atid=442052>

On a similar note; Is there a better way to submit patches? Do you guys  
prefer some sort of diff tool output? If so, please let me know...

Thanks,
Frank.

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 28-Sep-04, at 6:13 PM, James W. Walker wrote:

> Frank Condello <dev...@ch...> wrote:
>
>> James: Has there been any progress with your new sorting algorithms?
>> I would very much like to see your fast centroid method checked in.
>
> I wasn't sure that we had a consensus that it was the right thing to  
> do, since in at least one case the centroid method looks worse than  
> the current method.

Which case was that? I can't seem to render anything properly with the  
current code. Triangles pop unpredictably at the slightness change in  
the viewport... From my perspective, your centroid code is the lesser  
of two evils :)

> Also, you proposed ideas of accumulating transparent triangles in  
> chunks, rather than one big heap, where different chunks can have  
> different sorting methods.  I liked the idea, but haven't found the  
> time/energy to actually implement it.

Well, if you check in some new sorting code I might be persuaded give  
you a hand with that part. I think for the time being it would be nice  
to fix or at least improve upon the following transparency issues:

<http://sf.net/tracker/index.php? 
func=detail&aid=989156&group_id=45158&atid=442052>
<http://sf.net/tracker/index.php? 
func=detail&aid=967773&group_id=45158&atid=442052>
<http://sf.net/tracker/index.php? 
func=detail&aid=973022&group_id=45158&atid=442052>
<http://sf.net/tracker/index.php? 
func=detail&aid=967958&group_id=45158&atid=442052>

Then we can work on speeding things up - though at this point your code  
appears to be faster than the current method anyway.

Frank.

Re: Question on transparent camera transformed objects.

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

Frank Condello <dev...@ch...> wrote:

>James: Has there been any progress with your new sorting algorithms?
>I would very much like to see your fast centroid method checked in.

I wasn't sure that we had a consensus that it was the right thing to 
do, since in at least one case the centroid method looks worse than 
the current method.  Also, you proposed ideas of accumulating 
transparent triangles in chunks, rather than one big heap, where 
different chunks can have different sorting methods.  I liked the 
idea, but haven't found the time/energy to actually implement it.

Surely, if we just wait long enough, the video card wizards will find 
a way to handle transparency automatically. :-)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

[ quesa-Bugs-895106 ] Colours have no effect on textured geometry

[SourceForge.net <no...@so...>]

Bugs item #895106, was opened at 2004-02-11 15:03
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895106&group_id=45158

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Colours have no effect on textured geometry

Initial Comment:
Diffuse/Transparency colours have no effect on textured geometry.

The QuickDraw3D behaviour is to modulate colors on geometry 
using a null shader, otherwise it is ignored. Quesa should probably 
support this behaviour as the default, but allow Phong/Lambert lit 
geometry to modulate colours via an extended API.

----------------------------------------------------------------------

Comment By: Frank Condello (pox)
Date: 2004-02-21 02:49

Message:
Logged In: YES 
user_id=171509

Some testing with the GeomTest app shows that TriGrid and Triangle 
geometries actually do respect vertex colours when textured.

Although blending works on those geometries, the behaviour is 
backwards to that of QD3D (geometry lit Phong/Lambert blend colours, 
null shader does not). This seems to be intended looking at the 
ir_texture_set_state function however.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895106&group_id=45158

[ quesa-Bugs-895092 ] Edge and point fill styles may render textured.

[SourceForge.net <no...@so...>]

Bugs item #895092, was opened at 2004-02-11 14:44
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895092&group_id=45158

Category: None
Group: None
Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Edge and point fill styles may render textured.

Initial Comment:
Edge and point fill styles are textured if an object has a texture 
shader further down the pipe. e.g. A display group containing an 
edge fill style and a trimesh should render with color info only, but 
a texureshader in the trimesh's attribute set will override the fill 
style's texture state.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895092&group_id=45158

[ quesa-Bugs-905678 ] Texture filtering needs improvements

[SourceForge.net <no...@so...>]

Bugs item #905678, was opened at 2004-02-27 03:16
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=905678&group_id=45158

Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Joe Strout (jstrout)
Summary: Texture filtering needs improvements

Initial Comment:
Here are the common filtering options in OpenGL.

// Nearest (Quesa's "kQATextureFilter_Fast" setting)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_NEAREST);

// Linear (Quesa's "kQATextureFilter_Best/Mid" setting)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR);

// Bilinear (Not supported in Quesa)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_NEAREST);

// Trilinear (Not supported in Quesa)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_LINEAR);

Bilinear and Trilinear are commonly the only options most scene 
graphs/games support, yet neither is supported in Quesa.

Fixing this requires a few changes:

1). The "qualityFilter" member in the "TQ3CachedTexture" struct 
can't be defined as a single GLuint. It either needs min/max 
values, or should possibly be a "TQ3TextureFilter" name instead, 
that can be used as a hint when uploading the texture (but that 
means changing how and where the TQ3TextureFilter is translated 
into something OpenGL can use).

2). Mipmaps should be generated when not present in a texture 
shader for filter modes that require them. This will more closely 
match the QD3D behaviour. but also allow mips to be easily 
excluded by using a Fast/Mid filter setting.

3). Quesa needs additional TQ3TextureFilter names, and the 
meaning of existing names should be altered. I'd recommend 
something like this to maintain compatibility:
kQATextureFilter_Fast = Nearest
kQATextureFilter_Mid = Linear
kQATextureFilter_Best = Bilinear
kQATextureFilter_Trilinear = Trilinear


----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-15 19:06

Message:
Logged In: YES 
user_id=439944

Bilinear is currently supported (kQATextureFilter_Mid with mip-maps), 
but the existing texturing filtering options do need rethought - the 
existing options were picked up from RAVE and so use the kQAxxx_yyy 
naming convention.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=905678&group_id=45158

[ quesa-Bugs-967765 ] Bad view transformations for transparent objects

[SourceForge.net <no...@so...>]

Bugs item #967765, was opened at 2004-06-06 16:54
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967765&group_id=45158

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad view transformations for transparent objects

Initial Comment:
Transparent vertices warp and eventually shoot off into infinity 
when approaching the camera/hither plane. This is likely a problem 
with the  transforms used in ir_geom_transparent_add. See 
attached CFM Mac OS X application for an example.

----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 2004-07-11 22:13

Message:
Logged In: YES 
user_id=433183

I believe that the TransTest sample application illustrated 3 bugs,
which may have confused some people looking at this bug:
1. flash over the whole screen when the boxes get close to the hither 
plane
2. Distortion of textures with alpha
3. Depth-sorting problems causing flickering of individual triangles.
Changes I made today to IRTransparent.c and IRPrefix.h seem to have
fixed (1) and (2).  I added bug 989156 to record bug (3).

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-15 20:00

Message:
Logged In: YES 
user_id=439944

Trying to attach example app.

----------------------------------------------------------------------

Comment By: Frank Condello (pox)
Date: 2004-06-06 16:57

Message:
Logged In: YES 
user_id=171509

Well that didn't work - grab the test application here: <http://
webhome.idirect.com/~frankco/rb/TransTest.sit>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967765&group_id=45158

[ quesa-Bugs-895106 ] Colours have no effect on textured geometry

[SourceForge.net <no...@so...>]

Bugs item #895106, was opened at 2004-02-11 15:03
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895106&group_id=45158

Category: None
Group: None
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Colours have no effect on textured geometry

Initial Comment:
Diffuse/Transparency colours have no effect on textured geometry.

The QuickDraw3D behaviour is to modulate colors on geometry 
using a null shader, otherwise it is ignored. Quesa should probably 
support this behaviour as the default, but allow Phong/Lambert lit 
geometry to modulate colours via an extended API.

----------------------------------------------------------------------

Comment By: Frank Condello (pox)
Date: 2004-02-21 02:49

Message:
Logged In: YES 
user_id=171509

Some testing with the GeomTest app shows that TriGrid and Triangle 
geometries actually do respect vertex colours when textured.

Although blending works on those geometries, the behaviour is 
backwards to that of QD3D (geometry lit Phong/Lambert blend colours, 
null shader does not). This seems to be intended looking at the 
ir_texture_set_state function however.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895106&group_id=45158

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 28-Sep-04, at 1:52 PM, James W. Walker wrote:

> Peter Michelsen <Pet...@mi...> wrote:
>
>> I tried this but it had no effect as the objects are
>> transparent..... and I guess ( from testing ) use the last style
>> illumination style set in the submit loop. ( does this sound right
>> or am I way of base? ).
>
> That seems right.  Quesa saves the illumination style with each  
> transparent primitive, but only uses it to decide whether to use  
> specular highlights.  That is, it distinguishes Phong and Lambert  
> illumination from each other, but does not consider NULL illumination.  
>  This should probably be filed as a bug, if it hasn't been already.

I pointed this bug report out earlier in the thread:

[ 967773 ] Lighting state isn't respected on transparent objects
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=967773&group_id=45158&atid=442052>

Simple fix really, but some other states can be merged into a state  
cache as well, like fog, orientation, and fill - setting those for each  
polygon is a waste. I can put together a fix but was kinda waiting to  
see an update to IRTransparent.c first, since the sorting code has  
proven to been unusable for my purposes.

James: Has there been any progress with your new sorting algorithms? I  
would very much like to see your fast centroid method checked in.

There are also some related fixes that would help bring the  
transparency renderer up to snuff:
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=973022&group_id=45158&atid=442052>
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=967958&group_id=45158&atid=442052>

Frank.

[ quesa-Bugs-967765 ] Bad view transformations for transparent objects

[SourceForge.net <no...@so...>]

Bugs item #967765, was opened at 2004-06-06 16:54
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967765&group_id=45158

Category: None
Group: None
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad view transformations for transparent objects

Initial Comment:
Transparent vertices warp and eventually shoot off into infinity 
when approaching the camera/hither plane. This is likely a problem 
with the  transforms used in ir_geom_transparent_add. See 
attached CFM Mac OS X application for an example.

----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 2004-07-11 22:13

Message:
Logged In: YES 
user_id=433183

I believe that the TransTest sample application illustrated 3 bugs,
which may have confused some people looking at this bug:
1. flash over the whole screen when the boxes get close to the hither 
plane
2. Distortion of textures with alpha
3. Depth-sorting problems causing flickering of individual triangles.
Changes I made today to IRTransparent.c and IRPrefix.h seem to have
fixed (1) and (2).  I added bug 989156 to record bug (3).

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-15 20:00

Message:
Logged In: YES 
user_id=439944

Trying to attach example app.

----------------------------------------------------------------------

Comment By: Frank Condello (pox)
Date: 2004-06-06 16:57

Message:
Logged In: YES 
user_id=171509

Well that didn't work - grab the test application here: <http://
webhome.idirect.com/~frankco/rb/TransTest.sit>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967765&group_id=45158

Re: Question on transparent camera transformed objects.

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

Peter Michelsen <Pet...@mi...> wrote:

>I tried this but it had no effect as the objects are
>transparent..... and I guess ( from testing ) use the last style
>illumination style set in the submit loop. ( does this sound right
>or am I way of base? ).

That seems right.  Quesa saves the illumination style with each 
transparent primitive, but only uses it to decide whether to use 
specular highlights.  That is, it distinguishes Phong and Lambert 
illumination from each other, but does not consider NULL 
illumination.  This should probably be filed as a bug, if it hasn't 
been already.

What platform(s) are you targeting?  If all you need is Mac OS X, 
then I would suggest not doing the selection stuff inside Quesa, but 
using a transparent overlay window.  That way, the Quesa content does 
not need to be re-rendered as the selection rectangle changes.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Resolved bug reports

[Frank C. <dev...@ch...>]

I've gone ahead and closed a few of my bug reports - reasons below:

[ 905678 ] Texture filtering needs improvements
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=905678&group_id=45158&atid=442052>
Fixed - The current code is sufficient for now and fulfills the bug  
report as it works very closely to how QD3D handles things, but as Dair  
states in that report there are better ways to go about it (i.e. per  
texture). I'll likely open another report regarding this in the future,  
but for now it works.

[ 895106 ] Colours have no effect on textured geometry
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=895106&group_id=45158&atid=442052>
Fixed - Now works identical to QD3D.

[ 895092 ] Edge and point fill styles may render textured.
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=895092&group_id=45158&atid=442052>
No longer reproducible - I think this may have been fixed as a side  
effect of fixing bug #895099  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=895099&group_id=45158&atid=442052>

[ 967765 ] Bad view transformations for transparent objects
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=967765&group_id=45158&atid=442052>
Fixed - This bug was left open since it discussed poor sorting as well,  
but that has it's own report now:  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=989156&group_id=45158&atid=442052>

Frank.

[ quesa-Bugs-895092 ] Edge and point fill styles may render textured.

[SourceForge.net <no...@so...>]

Bugs item #895092, was opened at 2004-02-11 14:44
Message generated for change (Settings changed) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895092&group_id=45158

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Edge and point fill styles may render textured.

Initial Comment:
Edge and point fill styles are textured if an object has a texture 
shader further down the pipe. e.g. A display group containing an 
edge fill style and a trimesh should render with color info only, but 
a texureshader in the trimesh's attribute set will override the fill 
style's texture state.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895092&group_id=45158

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 28-Sep-04, at 1:09 PM, Peter Michelsen wrote:

> On 28 Sep 2004, at 17:13, Frank Condello wrote:
>
>> On 28-Sep-04, at 11:09 AM, Peter Michelsen wrote:
>>
>>> I have setup all the objects needed to create this effect, including  
>>> four polygons with; an attribute of diffuse gray colour ( 0xAFFF)  
>>> and an attribute of transparency colour ( 0xAFFF ) and no other  
>>> attributes.
>>>
>>> Now the problem, as the camera rotate around the polygons colour  
>>> changes. The reason is that the polygons are real 3D objects in  
>>> Quesa space so are effected by the sun light. ( tested by turning  
>>> the sun off e.g. the directional light ).
>>>
>>> We normally overcome this problem by submitting objects before the  
>>> view light style is added but as the polygons are transparent this  
>>> trick does not work.
>>
>> It's probably safer to put that geometry into a display group with a  
>> null shader, but depending on which version of Quesa your using you  
>> may be seeing this bug:  
>> <http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=967773&group_id=45158&atid=442052>
>
> I tried this but it had no effect as the objects are transparent.....  
> and I guess ( from testing ) use the last style illumination style set  
> in the submit loop. ( does this sound right or am I way of base? ).

That's correct-  the illumination of the last solid object is errantly  
maintained for the entire transparent pass. The bug report linked above  
includes a bit of a workaround if your're using the CVS source.

Frank.

Re: Question on transparent camera transformed objects.

[Peter M. <Pet...@mi...>]

On 28 Sep 2004, at 17:13, Frank Condello wrote:

> On 28-Sep-04, at 11:09 AM, Peter Michelsen wrote:
>
>> I have setup all the objects needed to create this effect, including  
>> four polygons with; an attribute of diffuse gray colour ( 0xAFFF) and  
>> an attribute of transparency colour ( 0xAFFF ) and no other  
>> attributes.
>>
>> Now the problem, as the camera rotate around the polygons colour  
>> changes. The reason is that the polygons are real 3D objects in Quesa  
>> space so are effected by the sun light. ( tested by turning the sun  
>> off e.g. the directional light ).
>>
>> We normally overcome this problem by submitting objects before the  
>> view light style is added but as the polygons are transparent this  
>> trick does not work.
>
> It's probably safer to put that geometry into a display group with a  
> null shader, but depending on which version of Quesa your using you  
> may be seeing this bug:  
> <http://sourceforge.net/tracker/index.php? 
> func=detail&aid=967773&group_id=45158&atid=442052>
>
> Frank,
>
>
Hi Frank,

I tried this but it had no effect as the objects are transparent.....  
and I guess ( from testing ) use the last style illumination style set  
in the submit loop. ( does this sound right or am I way of base? ).

Peter.

>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Question on transparent camera transformed objects.

[Peter M. <Pet...@mi...>]

On 28 Sep 2004, at 16:58, James W. Walker wrote:

>
> On Sep 28, 2004, at 8:09 AM, Peter Michelsen wrote:
>
>> Now the problem, as the camera rotate around the polygons colour 
>> changes. The reason is that the polygons are real 3D objects in Quesa 
>> space so are effected by the sun light. ( tested by turning the sun 
>> off e.g. the directional light ).
>>
>> We normally overcome this problem by submitting objects before the 
>> view light style is added but as the polygons are transparent this 
>> trick does not work.
>>
>> Any ideas on overcoming this.
>
> How about submitting it with a NULL illumination shader?
> --


I have tried this and yes it works but affects all transparent objects 
not just the selection boxes..... which is a bit of a problem. ( 
Changing styles between submitting had no effect either. )

Can NULL illumination shader be submitted as an attribute to an object 
and not a style for the view ?

Please note: I also tested adding the NULL illumination shader added to 
the display group in which the objects are grouped and this had no 
effect on stopping the light data mixing. We are now using the latest 
CVS version of Quesa.

Thanks for the info.

Peter.


> <http://www.jwwalker.com/>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 28-Sep-04, at 11:09 AM, Peter Michelsen wrote:

> I have setup all the objects needed to create this effect, including  
> four polygons with; an attribute of diffuse gray colour ( 0xAFFF) and  
> an attribute of transparency colour ( 0xAFFF ) and no other  
> attributes.
>
> Now the problem, as the camera rotate around the polygons colour  
> changes. The reason is that the polygons are real 3D objects in Quesa  
> space so are effected by the sun light. ( tested by turning the sun  
> off e.g. the directional light ).
>
> We normally overcome this problem by submitting objects before the  
> view light style is added but as the polygons are transparent this  
> trick does not work.

It's probably safer to put that geometry into a display group with a  
null shader, but depending on which version of Quesa your using you may  
be seeing this bug:  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=967773&group_id=45158&atid=442052>

Frank,

Re: Question on transparent camera transformed objects.

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

On Sep 28, 2004, at 8:09 AM, Peter Michelsen wrote:

> Now the problem, as the camera rotate around the polygons colour 
> changes. The reason is that the polygons are real 3D objects in Quesa 
> space so are effected by the sun light. ( tested by turning the sun 
> off e.g. the directional light ).
>
> We normally overcome this problem by submitting objects before the 
> view light style is added but as the polygons are transparent this 
> trick does not work.
>
> Any ideas on overcoming this.

How about submitting it with a NULL illumination shader?
--
<http://www.jwwalker.com/>

Question on transparent camera transformed objects.

[Peter M. <Pet...@mi...>]

Hello all,

Sorry to be bugging the list but I would like some help on a problem 
with transparent camera transform objects.

First a little background, I am trying to simulate the selection box 
used by Apple in Preview, that is one white box then one black box and 
finally a light gray transparency elsewhere.

I have setup all the objects needed to create this effect, including 
four polygons with; an attribute of diffuse gray colour ( 0xAFFF) and 
an attribute of transparency colour ( 0xAFFF ) and no other attributes.

Now the problem, as the camera rotate around the polygons colour 
changes. The reason is that the polygons are real 3D objects in Quesa 
space so are effected by the sun light. ( tested by turning the sun off 
e.g. the directional light ).

We normally overcome this problem by submitting objects before the view 
light style is added but as the polygons are transparent this trick 
does not work.

Any ideas on overcoming this.

Is there an attribute that can be added to stop direction, point and 
ambient light data being mixed with objects that have transparent 
colour attributes?

Thanks in advance for any help.

Peter. 

[ quesa-Bugs-1032785 ] DrawContext mask image initialisation

[SourceForge.net <no...@so...>]

Bugs item #1032785, was opened at 2004-09-23 02:44
Message generated for change (Comment added) made by bork3d
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: bork3d (bork3d)
Assigned to: Nobody/Anonymous (nobody)
Summary: DrawContext mask image initialisation

Initial Comment:
A "malloc debug: double free" occurs in 
Q3Bitmap_Empty. 
The pointer to be freed is garbage due to an uninitialised 
field in a TQ3MacDrawContextData structure declared on 
the stack. This can be fixed where the DrawingContext is 
initialized in e3drawcontext_mac_new().

/* E3MacDrawContext_New is being called without the 
mask image field explicitly set, causing problems in 
Q3Bitmap_Empty.
 * Callers _do_ however set maskState to kQ3False, 
so respect a valid mask image if maskState is kQ3True
 */
if (instanceData-
>data.macData.theData.drawContextData.maskState == 
kQ3False)
  instanceData-
>data.macData.theData.drawContextData.mask.image = 
NULL;

Similar fixes should be applied to other platform specific 
DrawingContext initialisation routines, such as 
e3drawcontext_windc_new() etc


----------------------------------------------------------------------

>Comment By: bork3d (bork3d)
Date: 2004-09-23 17:22

Message:
Logged In: YES 
user_id=1126574

> If some client code calls Q3MacDrawContext_New without 
setting
> all the fields of the TQ3MacDrawContextData structure, that's 
their bug, not Quesa's 

The clients that do not initialise the mask bitmap image field are 
actually
internal Quesa calls. For example, Q3Viewer_New and 
Q3DrawContext_New

> 3drawcontext_mac_delete does check the maskState field 
before calling Q3Bitmap_Empty

That's just one path of many to reach Q3Bitmap_Empty and 
there are many code points where the maskState could be 
checked.

The scenario to trigger the bug is:
A DrawContext is created with Q3DrawContext_New
(on Mac this calls E3MacDrawContext_NewWithWindow, 
which allocates a TQ3DrawContextData structure on the stack, 
sets the maskState to kQ3False but does not initialise the 
mask.image field, which ensures the new DrawContext object's 
mask.image is garbage).
Later one replaces the mask with Q3DrawContext_SetMask()
which calls E3Bitmap_Replace(), disposing the garbage mask 
image. 

DrawContext_New takes a TQ3DrawContextData pointer as a 
parameter.
The internal callers of DrawContext_New (and also the sample 
code on which many apps are based) follow a common pattern 
that indicates an implied software contract in the use of 
DrawContext_New():
Clients initialise the maskState field to kQ3False to indicate the 
mask is not used. These clients do not explicitly set the mask's 
bitmap image field to NULL when maskState field is kQ3False and 
pass a stack declared structure that has random values in the 
TQ3Bitmap field of the TQ3DrawContextData.

The implied contract is that if the maskState is kQ3False then 
the mask bitmap will not be accessed. The clients assume that 
just setting maskState to kQ3False is sufficent. This however 
does not mean that Quesa will not access the bitmap, as there is 
at least one case where the bitmap is accessed without regard to 
the maskState flag: Q3DrawContext_SetMask() disposes of the 
old bitmap before installing a new one. This is a problem when 
the old bitmap image field is not a valid pointer.

I assert that the software contract that DrawContext_New will 
create a fully valid DrawContext object requires the mask's 
bitmap image field must initially be NULL if imageState is 
kQ3False. The clients do not explicitly set it, so 
DrawContext_New itself must enforce this condition.

The options to ensure DrawContext_New creates a fully valid 
object are:
1. Require clients must set mask.image to NULL.
2. Ensure the condition internally during DrawContext 
initialisation.

The bottleneck routines (e3drawcontext_PLATFORM_new) are 
the candidates for ensuring mask.image is NULL when the 
maskState is kQ3False.

And finally, what does QD3D do? It accepts TQ3DrawContextData 
with maskState kQ3False and garbage image pointer (witness all 
the sample code that uses this) and Q3DrawContext_SetMask() 
does not deallocate random memory. 
So the condition is enforced in QD3D.

Devil's advocate argument: what if I want to set a mask at 
initialisation but I also set the maskState kQ3False because I 
don’t want to use the mask immediately but will later use 
Q3DrawContext_SetMaskState() to toggle the use of the mask. 
The suggested fix will null the valid bitmap image and cause a 
leak.
The workaround is to use Q3DrawContext_SetMask() after 
creating the DrawContext with null mask.



----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 2004-09-23 03:27

Message:
Logged In: YES 
user_id=433183

I don't understand this.  If some client code calls 
Q3MacDrawContext_New 
without setting all the fields of the TQ3MacDrawContextData structure, 
that's their bug, not Quesa's.  Furthermore, e3drawcontext_mac_delete 
does check the maskState field before calling Q3Bitmap_Empty.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

[ quesa-Bugs-1032785 ] DrawContext mask image initialisation

[SourceForge.net <no...@so...>]

Bugs item #1032785, was opened at 2004-09-22 09:44
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: bork3d (bork3d)
Assigned to: Nobody/Anonymous (nobody)
Summary: DrawContext mask image initialisation

Initial Comment:
A "malloc debug: double free" occurs in 
Q3Bitmap_Empty. 
The pointer to be freed is garbage due to an uninitialised 
field in a TQ3MacDrawContextData structure declared on 
the stack. This can be fixed where the DrawingContext is 
initialized in e3drawcontext_mac_new().

/* E3MacDrawContext_New is being called without the 
mask image field explicitly set, causing problems in 
Q3Bitmap_Empty.
 * Callers _do_ however set maskState to kQ3False, 
so respect a valid mask image if maskState is kQ3True
 */
if (instanceData-
>data.macData.theData.drawContextData.maskState == 
kQ3False)
  instanceData-
>data.macData.theData.drawContextData.mask.image = 
NULL;

Similar fixes should be applied to other platform specific 
DrawingContext initialisation routines, such as 
e3drawcontext_windc_new() etc


----------------------------------------------------------------------

>Comment By: James W. Walker (jwwalker)
Date: 2004-09-22 10:27

Message:
Logged In: YES 
user_id=433183

I don't understand this.  If some client code calls 
Q3MacDrawContext_New 
without setting all the fields of the TQ3MacDrawContextData structure, 
that's their bug, not Quesa's.  Furthermore, e3drawcontext_mac_delete 
does check the maskState field before calling Q3Bitmap_Empty.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

[ quesa-Bugs-1032785 ] DrawContext mask image initialisation

[SourceForge.net <no...@so...>]

Bugs item #1032785, was opened at 2004-09-23 02:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: bork3d (bork3d)
Assigned to: Nobody/Anonymous (nobody)
Summary: DrawContext mask image initialisation

Initial Comment:
A "malloc debug: double free" occurs in 
Q3Bitmap_Empty. 
The pointer to be freed is garbage due to an uninitialised 
field in a TQ3MacDrawContextData structure declared on 
the stack. This can be fixed where the DrawingContext is 
initialized in e3drawcontext_mac_new().

/* E3MacDrawContext_New is being called without the 
mask image field explicitly set, causing problems in 
Q3Bitmap_Empty.
 * Callers _do_ however set maskState to kQ3False, 
so respect a valid mask image if maskState is kQ3True
 */
if (instanceData-
>data.macData.theData.drawContextData.maskState == 
kQ3False)
  instanceData-
>data.macData.theData.drawContextData.mask.image = 
NULL;

Similar fixes should be applied to other platform specific 
DrawingContext initialisation routines, such as 
e3drawcontext_windc_new() etc


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

Re: Question on GeomTest.

[Peter M. <Pet...@mi...>]

Thanks Tom,

That did the job for the top left corner but now the issue moved to the 
bottom right, which would seem more like place.

Anyway it means that my math's can be a little simpler and the 
selection rectangle works in all quadrants so I am happy.

Peter.