quesa-develop — Mailing list for Quesa development

Re: High-res printing

[Don A. <da...@do...>]

Hi Ted,

On 9-Aug-05, at 9:15 AM, Edward K. Chew wrote:

> I seem to have hit a snag in checking out quesa.  cvs gives me an  
> error when I reach the Geom Test example:
>
> cvs checkout: failed to create lock directory for `/cvsroot/quesa/ 
> quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj' (/cvsroot/quesa/ 
> quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj/#cvs.lock):  
> Permission denied
> cvs checkout: failed to obtain dir lock in repository `/cvsroot/ 
> quesa/quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj'
> cvs [checkout aborted]: read lock failed - giving up
>
> -Ted

I get the same errors.

Best Regards,
Don Agro

D o g   P a r k   S o f t w a r e   L t d .

email: da...@do...
   www: http://www.dogparksoftware.com
       iChat AV:do...@ma...

Re: High-res printing

[Edward K. C. <ek...@lg...>]

On Aug 8, 2005, at 2:07 PM, James W. Walker wrote:

> This sounds like a rowBytes limit, so it prompted me to search for  
> rowBytes usage in Quesa.  I found a bug in E3MacDrawContext.c,  
> where it was directly reading the rowBytes field of a PixMapHandle  
> instead of using GetPixRowBytes.  I checked in a fix.  So you might  
> want to check that out, and try the big-buffer method again.

I seem to have hit a snag in checking out quesa.  cvs gives me an  
error when I reach the Geom Test example:

cvs checkout: failed to create lock directory for `/cvsroot/quesa/ 
quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj' (/cvsroot/quesa/ 
quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj/#cvs.lock):  
Permission denied
cvs checkout: failed to obtain dir lock in repository `/cvsroot/quesa/ 
quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj'
cvs [checkout aborted]: read lock failed - giving up

-Ted

Re: CVS

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

Don Agro <da...@do...> wrote:

>I can no longer check out from the CVS repository...

According to the site status page on SourceForge, CVS is scheduled to 
be down for 36 hours for upgrades.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

CVS

[Don A. <da...@do...>]

I can no longer check out from the CVS repository...

Part way through it fails with the following...

- failed to create lock directory for `/cvsroot/quesa/quesa/SDK/ 
Examples/Geom Test/Geom Test.xcodeproj' (/cvsroot/quesa/quesa/SDK/ 
Examples/Geom Test/Geom Test.xcodeproj/#cvs.lock): Permission denied
- failed to obtain dir lock in repository `/cvsroot/quesa/quesa/SDK/ 
Examples/Geom Test/Geom Test.xcodeproj'
- read lock failed - giving up
- The update could not be completed because the CVS server returned  
an error. Check the warnings to see what went wrong.



Any idea what I'm doing wrong ?

Thanks,

Best Regards,
Don Agro

D o g   P a r k   S o f t w a r e   L t d .

email: da...@do...
   www: http://www.dogparksoftware.com
       iChat AV:do...@ma...

[ quesa-Bugs-902982 ] Support FSAA through arb_multisample

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support FSAA through arb_multisample

Initial Comment:
The kQ3AntiAliasModeMaskFullScreen style should be implemented 
with the arb_multisample extension where available (e.g., in 
Jaguar) rather than an ATI specific enum.

This will let us support FSAA on both ATI and nvidia cards (and will 
also be portable, unlike the ATI enum).

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

Comment By: Michael Sullivan (imikey)
Date: 2005-08-09 04:03

Message:
Logged In: YES 
user_id=836812

This was discussed recently on the quesa-develop list and it was 
successfully implemented using a different technique than what was 
described in the original bug...

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

I took a shot at getting multisampling working after reading Apple"s  
 FSAA technote (http://developer.apple.com/qa/qa2001/qa1268.html) 
and it turned out to be pretty easy.  I added the following lines in 
gldrawcontext_mac_new() just before the AGL_DOUBLEBUFFER 
attribute is set:
 
      glAttributes[numAttributes++] = AGL_ACCELERATED;
      glAttributes[numAttributes++] = AGL_NO_RECOVERY;
      glAttributes[numAttributes++] = AGL_SAMPLES_ARB;
      glAttributes[numAttributes++] = (GLint)4;
      glAttributes[numAttributes++] = AGL_SAMPLE_BUFFERS_ARB;
      glAttributes[numAttributes++] = (GLint)1;
 
 Surprisingly, that was all that was necessary despite the fact that  
 the technote stated that you needed to enable it with code such as:
 
      glEnable(GL_MULTISAMPLE_ARB);
      glHint( GL_MULTISAMPLE_FILTER_HINT_NV, GL_NICEST );
 
 As far as I can tell, multisampling is more intensive in both time  
 and memory than the GL_BLEND approach, but the results are quite  
 excellent.
 
[stuff deleted]
 
 On 31-Jul-2005, at 2:35 PM, James W. Walker wrote:
 
 > On Jul 31, 2005, at 6:33 AM, Mikey wrote:
 >
 >> The GL_POLYGON_SMOOTH code appears to be implemented by 
Quesa, but  
 >> the other two functions don"t appear to get called unless you"re  
 >> rendering transparent objects.  Just to see what would happen, I  
 >> added missing functions to my rendering code and the jaggies  
 >> finally went bye-bye.  Unfortunately, doing this introduces gaps  
 >> between triangles because it starts blending all triangle edges,  
 >> not just ones on the where it"s needed.
 >>
 >> Any ideas on how to add this type of blended anti-aliasing to 
Quesa?
 >
 > I don"t know about that type of antialiasing, but we do have an  
 > open bug, 902982, suggesting that we do antialiasing a different  
 > way, using GL_ARB_multisample.

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

 On Aug 4, 2005, at 11:58 PM, Mikey wrote:
 
 > Does that mean we need to create a new type of style that"s for the  
 > entire scene displayed in the window/full-screen?  Or should this  
 > be a draw context flag?
 
 A flag on the draw context or renderer would make more sense to me.



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

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

[ quesa-Bugs-973022 ] Specular highlights in transparent pass aren't sorted

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

Bugs item #973022, was opened at 06/15/04 00:03
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=973022&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
Summary: Specular highlights in transparent pass aren't sorted

Initial Comment:
The specular highlight pass for transparent triangles waits till all 
the transparent triangles are drawn, then blends highlights after 
the fact. The problem is, the highlights are drawn on top of 
everything in the colour buffer, so highlights on transparent 
triangles that are occluded by other transparent triangles are 
drawn full strength when they should appear to be filtered through 
the triangle in front.

A solution would be to draw each Phong shaded primitive in two 
passes when first sorted, rather than drawing the entire list of 
Phong shaded primitives as a second self-contained pass.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/08/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 07/24/05 21:38

Message:
Logged In: YES 
user_id=433183

I believe this is now fixed in CVS sources.

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

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

[ quesa-Bugs-967770 ] No fog on transparent objects

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

Bugs item #967770, was opened at 06/06/04 14:01
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967770&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
Summary: No fog on transparent objects

Initial Comment:
The fog state isn't saved when building the transparent primitive 
lists.

Note: Due to Quesa's additive blending, GL fog can't be used on 
textured transparent primitives since it will blend additively across 
the entire primitive rather than just the alpha.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/08/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 07/24/05 21:40

Message:
Logged In: YES 
user_id=433183

The fog state is now used on transparent stuff.  However I don't quite 
understand the "Note" above, so maybe I have not fixed it completely.

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

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

Re: High-res printing

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

"Edward K. Chew" <ek...@lg...> wrote:

>After trying this and that, it seems I have finally hit on a winning
>recipe.  I thought I could get away with allocating one large 11 x
>17 @ 300 dpi buffer and rendering into it in tiles no larger than
>2048 x 2048 pixels through careful manipulation of view ports and
>pane rectangles, but no joy.  Apparently, there is some kind of
>limit to the absolute dimensions of the buffer, regardless of how
>small a pane you are accessing within it.  Should you exceed that
>limit, you will see some psychedelic wraparound effects.

...

>I think this buffer size limit is more sensitive to the horizontal
>dimension.  It only seems to come up when I print in landscape
>orientation.  This is all under Tiger, incidentally.  With some
>trepidation, I plan to test the same code under Panther today...wish
>me luck!

This sounds like a rowBytes limit, so it prompted me to search for 
rowBytes usage in Quesa.  I found a bug in E3MacDrawContext.c, where 
it was directly reading the rowBytes field of a PixMapHandle instead 
of using GetPixRowBytes.  I checked in a fix.  So you might want to 
check that out, and try the big-buffer method again.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: High-res printing

[Edward K. C. <ek...@lg...>]

This is just a follow-up to my printing saga.

After trying this and that, it seems I have finally hit on a winning  
recipe.  I thought I could get away with allocating one large 11 x 17  
@ 300 dpi buffer and rendering into it in tiles no larger than 2048 x  
2048 pixels through careful manipulation of view ports and pane  
rectangles, but no joy.  Apparently, there is some kind of limit to  
the absolute dimensions of the buffer, regardless of how small a pane  
you are accessing within it.  Should you exceed that limit, you will  
see some psychedelic wraparound effects.

The solution is to allocate a small buffer just large enough to  
render one tile.  After rendering into the tile buffer, you can then  
copy it over to the appropriate coordinates within a larger page  
buffer if you like.  I tried this technique to produce a 2 x 2 page  
11 x 17 poster, and it is thing of beauty, I can tell you!  No  
noticeable artifacts along the tile edges, from what I can see.

I think this buffer size limit is more sensitive to the horizontal  
dimension.  It only seems to come up when I print in landscape  
orientation.  This is all under Tiger, incidentally.  With some  
trepidation, I plan to test the same code under Panther today...wish  
me luck!

-Ted

Re: Anti-aliasing doesn't seem to work right

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

On Aug 4, 2005, at 11:58 PM, Mikey wrote:

> Does that mean we need to create a new type of style that's for the  
> entire scene displayed in the window/full-screen?  Or should this  
> be a draw context flag?

A flag on the draw context or renderer would make more sense to me.

Re: Anti-aliasing doesn't seem to work right

[Mikey <im...@be...>]

Does that mean we need to create a new type of style that's for the  
entire scene displayed in the window/full-screen?  Or should this be  
a draw context flag?

On 5-Aug-2005, at 2:15 AM, James W. Walker wrote:

> On Jul 31, 2005, at 4:13 PM, Mikey wrote:
>
>> The technote also suggests that since multisampling eats up VRAM,  
>> it should be something that the user should have control over, so  
>> if we were to put this in Quesa, we may want to consider tying it  
>> into the quality setting in the TQ3AntiAliasStyleData structure.
>
> Actually, it does not make sense to me that full-screen  
> antialiasing was put into the antialias style. A style object is  
> supposed to be something that can apply to just part of a scene,  
> but full-screen antialiasing applies, well, to the full screen.

Re: Anti-aliasing doesn't seem to work right

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

On Jul 31, 2005, at 4:13 PM, Mikey wrote:

> The technote also suggests that since multisampling eats up VRAM,  
> it should be something that the user should have control over, so  
> if we were to put this in Quesa, we may want to consider tying it  
> into the quality setting in the TQ3AntiAliasStyleData structure.

Actually, it does not make sense to me that full-screen antialiasing  
was put into the antialias style.  A style object is supposed to be  
something that can apply to just part of a scene, but full-screen  
antialiasing applies, well, to the full screen.

[ quesa-Bugs-967773 ] Lighting state isn't respected on transparent objects

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

Bugs item #967773, was opened at 06/06/04 14:09
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967773&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
Summary: Lighting state isn't respected on transparent objects

Initial Comment:
The lighting state isn't restored when rendering transparent 
primitives.

There may already be enough information saved in the 
TQ3TransparentPrim struct to get proper lighting (in the 
"illumination" member)

Fixing this could be as simple as adding the following to 
ir_geom_transparent_render:

	if (thePrim->illumination == kQ3IlluminationTypeNULL)
		{
		glDisable(GL_LIGHTING);
		glDisable(GL_COLOR_MATERIAL);
		}
	else
		{
		glEnable(GL_LIGHTING);
		glEnable(GL_COLOR_MATERIAL);
		}
	}

...but the state should be saved between primitives and only 
changed when needed since they will likely be drawn in large 
groups that are either lit, or unlit.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/01/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 07/18/05 16:18

Message:
Logged In: YES 
user_id=433183

Fixed in CVS by a change to IRTransparent.c.

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

Comment By: Frank Condello (pox)
Date: 09/29/04 09:22

Message:
Logged In: YES 
user_id=171509

Note: If using the workaround above, be sure to enable the GL_LIGHTING 
state for the specular pass, and before IRTransBuffer_Draw returns.

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

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

[ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

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

Bugs item #1027387, was opened at 09/13/04 10:41
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027387&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quesa in CVS not compatible with Nanosaur

Initial Comment:
The version of Quesa for Windows that is in CVS does
not work with Nanosaur for Windows.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/01/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 07/17/05 23:51

Message:
Logged In: YES 
user_id=433183

I happened to have a Windows laptop at home this weekend.
(A Dell Inspiron running XP Home, to be more precise.)
I tried the same thing: Checked out fresh source, built with CW 8.3,
and tried both the debug and release DLL.  No problem at all.
So there is apparently a little more subtlety to this.

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

Comment By: Lane Roathe (raving)
Date: 07/17/05 22:21

Message:
Logged In: YES 
user_id=48487

I just checked out the latest version of Quesa from CVS and
built the Windows DLLs from the CW project using CW 8.3
under Mac OS X. (Same setup I develop Nanosaur under).

Downloaded and installed Nanosaur from:

ftp://ftp.ifd.com/pub/win/nanosaur_install.exe

Replaced Quesa.dll therein with my release build from the
project. Ran game. After the serial # dialog (choose play
demo) you get:

"Error: Q3View_StartRendering Failed!"

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

Comment By: James W. Walker (jwwalker)
Date: 07/17/05 16:55

Message:
Logged In: YES 
user_id=433183

This is too vague.   Does it crash?  Not draw anything?  Draw a particular 
geometry incorrectly?

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

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

[ quesa-Bugs-907855 ] TriMesh shading wrong when no vertex normals are present

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: TriMesh shading wrong when no vertex normals are present

Initial Comment:
(note, this issue could also be solved by bug 907849, as any 
triangles that shared vertex attributes would push us onto the 
break-down-and-push-into-tribuffer path)


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

When rendering a TriMesh with no vertex UVs in Quesa 1.6d16, the 
shading is interpolated across each triangle, as if we had vertex 
normals.  The correct appearance would be for each triangle to 
have a uniform shading, for a faceted appearance.  See attached 
sample 3DMF and picture showing the result in QD3D and Quesa.

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

OK, had a quick look at this. The problem is that the triangles in 
the TriMesh share vertices, and we don't correctly handle the case 
where a shared vertex inherits different values from the triangles 
which reference it.

The model was of a box, so if you consider two of the top/face 
triangles like:

        /|         |
     V_______
     |
  /  |
  ---|
  \  |

I.e., on triangle on the top of the box whose normal points up, and 
one triangle on the side of the face whose normal points out.

What happens at the moment is that when we're looking for the 
normal for V, we check to see if V specifies it. It doesn't, so we 
pick the first triangle which references V and use its normal. This 
then means that when the second triangle is rendered, it also 
references V and so ends up with the wrong normal (which 
produces the smoothed off effect).

The general way to handle this is to introduce new vertices into the 
TriMesh when we see that shared vertices have different parents - 
it looks like this is what QD3D was doing, as the same problem 
occurs with colours (e.g., if the top triangle was red and the side 
one was blue, you would get an all-red and all-blue triangle in 
QD3D: but we'll do a red-to-blue fade over the two triangles).


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

>Comment By: James W. Walker (jwwalker)
Date: 2005-08-01 09:05

Message:
Logged In: YES 
user_id=433183

I belieive this is now fixed in CVS for the interactive renderer.

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

Comment By: James W. Walker (jwwalker)
Date: 2005-07-27 22:51

Message:
Logged In: YES 
user_id=433183

Does this actually refer to vertex normals, not vertex UVs?

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

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

[ quesa-Bugs-902592 ] TriMesh Colours go to the wrong faces

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Tom Sanham (tomsanham)
>Assigned to: James W. Walker (jwwalker)
Summary: TriMesh Colours go to the wrong faces

Initial Comment:
Quesa 1.6d18
OS used: Windows XP (not tested on Mac)

This bug affects cube shaped TriMeshes with 8 vertices 
which specify a colour attribute per face.

I believe that the described behaviour occurs because 
the model has >1 faces referencing the same vertex.


Behaviour:
The following strange behaviour was observed:

Setting Attribute 0 controls faces 0,4,5
Setting Attribute 1 controls face 1
Setting Attribute 2 controls faces 2,6,7,8,9,10
Setting Attribute 3 controls faces 3,11
Setting Attributes 4..11 has no visual effect

The same model renders correctly under QD3D - 
attribute n controls face n for 0<=n<12.


Workaround:
An effective workaround is to build the cube with 
duplicate vertices such that no vertex is shared by two 
faces.

Example trimesh included as a 3DMF.
Best viewed with kQ3InterpolationStyleNone

.triMeshAttributeSet = 0
.numTriangles = 12
.*triangles = 
    (4,6,2) ,
    (4,2,0) ,
    (1,3,7) ,
    (1,7,5) ,
    (5,7,6) ,
    (5,6,4) ,
    (0,2,3) ,
    (0,3,1) ,
    (2,6,3) ,
    (3,6,7) ,
    (4,0,1) ,
    (4,1,5) 
.numTriangleAttributeTypes = 1
.triangleAttributeTypes =
    .attributeType = kQ3AttributeTypeDiffuseColor
    .data =
    (1,0,0),
    (1,1,1),
    (1,1,1),
    remaining 9 faces (1,1,1)
.numEdges = 0
.edges = 0
.numEdgeAttributeTypes = 0
.*edgeAttributeTypes = 0
.numPoints = 8
.*points = 
    (0,0,0),
    (1,0,0),
    (0,1,0),
    (1,1,0),
    (0,0,1),
    (1,0,1),
    (0,1,1),
    (1,1,1)
.numVertexAttributeTypes =  0
.*vertexAttributeTypes = 0
.bBox = (0,0,0) , (10,10,10) , kQ3False

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-08-01 09:03

Message:
Logged In: YES 
user_id=433183

I believe this is now fixed in CVS for the interactive renderer.

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

Comment By: James W. Walker (jwwalker)
Date: 2005-06-26 00:32

Message:
Logged In: YES 
user_id=433183

Quesa does not handle per-face colors correctly, it only uses them to infer 
vertex colors.  Therefore you get smooth color gradations when you 
expected sharp boundaries.

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

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

Re: Anti-aliasing doesn't seem to work right

[Mikey <im...@be...>]

I took a shot at getting multisampling working after reading Apple's  
FSAA technote (http://developer.apple.com/qa/qa2001/qa1268.html) and  
it turned out to be pretty easy.  I added the following lines in  
gldrawcontext_mac_new() just before the AGL_DOUBLEBUFFER attribute is  
set:

     glAttributes[numAttributes++] = AGL_ACCELERATED;
     glAttributes[numAttributes++] = AGL_NO_RECOVERY;
     glAttributes[numAttributes++] = AGL_SAMPLES_ARB;
     glAttributes[numAttributes++] = (GLint)4;
     glAttributes[numAttributes++] = AGL_SAMPLE_BUFFERS_ARB;
     glAttributes[numAttributes++] = (GLint)1;

Surprisingly, that was all that was necessary despite the fact that  
the technote stated that you needed to enable it with code such as:

     glEnable(GL_MULTISAMPLE_ARB);
     glHint( GL_MULTISAMPLE_FILTER_HINT_NV, GL_NICEST );

As far as I can tell, multisampling is more intensive in both time  
and memory than the GL_BLEND approach, but the results are quite  
excellent.

The technote also suggests that since multisampling eats up VRAM, it  
should be something that the user should have control over, so if we  
were to put this in Quesa, we may want to consider tying it into the  
quality setting in the TQ3AntiAliasStyleData structure.

On 31-Jul-2005, at 2:35 PM, James W. Walker wrote:

> On Jul 31, 2005, at 6:33 AM, Mikey wrote:
>
>> The GL_POLYGON_SMOOTH code appears to be implemented by Quesa, but  
>> the other two functions don't appear to get called unless you're  
>> rendering transparent objects.  Just to see what would happen, I  
>> added missing functions to my rendering code and the jaggies  
>> finally went bye-bye.  Unfortunately, doing this introduces gaps  
>> between triangles because it starts blending all triangle edges,  
>> not just ones on the where it's needed.
>>
>> Any ideas on how to add this type of blended anti-aliasing to Quesa?
>
> I don't know about that type of antialiasing, but we do have an  
> open bug, 902982, suggesting that we do antialiasing a different  
> way, using GL_ARB_multisample.

Re: Anti-aliasing doesn't seem to work right

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

On Jul 31, 2005, at 6:33 AM, Mikey wrote:

> The GL_POLYGON_SMOOTH code appears to be implemented by Quesa, but  
> the other two functions don't appear to get called unless you're  
> rendering transparent objects.  Just to see what would happen, I  
> added missing functions to my rendering code and the jaggies  
> finally went bye-bye.  Unfortunately, doing this introduces gaps  
> between triangles because it starts blending all triangle edges,  
> not just ones on the where it's needed.
>
> Any ideas on how to add this type of blended anti-aliasing to Quesa?

I don't know about that type of antialiasing, but we do have an open  
bug, 902982, suggesting that we do antialiasing a different way,  
using GL_ARB_multisample.

Anti-aliasing doesn't seem to work right

[Mikey <im...@be...>]

I was playing around with Geom Test and one of the things I noticed  
is that when you turn on filled anti-aliasing, nothing really  
changes: the edges of everything drawn are still jaggy.  (I recommend  
switching to a flat shaded object such as the Mesh to really see that  
nothing is changing.)

While trying to figure out what was wrong, I read in the OpenGL  
Programming Guide about the following code to enable polygon anti- 
aliasing:

    glEnable(GL_POLYGON_SMOOTH)
    glEnable(GL_BLEND);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

The GL_POLYGON_SMOOTH code appears to be implemented by Quesa, but  
the other two functions don't appear to get called unless you're  
rendering transparent objects.  Just to see what would happen, I  
added missing functions to my rendering code and the jaggies finally  
went bye-bye.  Unfortunately, doing this introduces gaps between  
triangles because it starts blending all triangle edges, not just  
ones on the where it's needed.

Any ideas on how to add this type of blended anti-aliasing to Quesa?

Re: Can Quesa change a TriMesh on its own?

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

Thanks for the feedback, guys.  I came up with a plan that I think is  
less likely to cause problems.  First, I will add APIs to explicitly  
optimize a TQ3TriMeshData or a TriMesh object.  Second, it occurred  
to me that I am really talking about optimizing for the interactive  
renderer, and a different renderer might have a different opinion  
about what is a good TriMesh.  Therefore, I will give the interactive  
renderer the job of optimizing TriMeshes on the fly.  I'll use a  
custom element to attach an optimized version to the original  
object.  Therefore if you call Q3TriMesh_GetData or  
Q3TriMesh_LockData, you will still get the original unoptimized data.

[ quesa-Bugs-907855 ] TriMesh shading wrong when no vertex normals are present

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
>Assigned to: James W. Walker (jwwalker)
>Summary: TriMesh shading wrong when no vertex normals are present

Initial Comment:
(note, this issue could also be solved by bug 907849, as any 
triangles that shared vertex attributes would push us onto the 
break-down-and-push-into-tribuffer path)


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

When rendering a TriMesh with no vertex UVs in Quesa 1.6d16, the 
shading is interpolated across each triangle, as if we had vertex 
normals.  The correct appearance would be for each triangle to 
have a uniform shading, for a faceted appearance.  See attached 
sample 3DMF and picture showing the result in QD3D and Quesa.

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

OK, had a quick look at this. The problem is that the triangles in 
the TriMesh share vertices, and we don't correctly handle the case 
where a shared vertex inherits different values from the triangles 
which reference it.

The model was of a box, so if you consider two of the top/face 
triangles like:

        /|         |
     V_______
     |
  /  |
  ---|
  \  |

I.e., on triangle on the top of the box whose normal points up, and 
one triangle on the side of the face whose normal points out.

What happens at the moment is that when we're looking for the 
normal for V, we check to see if V specifies it. It doesn't, so we 
pick the first triangle which references V and use its normal. This 
then means that when the second triangle is rendered, it also 
references V and so ends up with the wrong normal (which 
produces the smoothed off effect).

The general way to handle this is to introduce new vertices into the 
TriMesh when we see that shared vertices have different parents - 
it looks like this is what QD3D was doing, as the same problem 
occurs with colours (e.g., if the top triangle was red and the side 
one was blue, you would get an all-red and all-blue triangle in 
QD3D: but we'll do a red-to-blue fade over the two triangles).


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

Comment By: James W. Walker (jwwalker)
Date: 2005-07-27 22:51

Message:
Logged In: YES 
user_id=433183

Does this actually refer to vertex normals, not vertex UVs?

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

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

Re: High-res printing

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

On Jul 29, 2005, at 9:48 PM, Edward K.Chew wrote:

>> OpenGL has a limit on viewport size, but the exact value depends  
>> on the renderer.  Are you running on Mac or Windows?  If Mac, is  
>> it Tiger or earlier?  I seem to recall a value of 2048 on Mac pre- 
>> Tiger.
>
> I'm running in Tiger using the interactive renderer.  I should try  
> it on a Panther machine to see if there is a difference.  2048 is  
> really not that great, is it?  Apple's 30" Cinema Display can  
> supposedly hit 2650 x 1600.  I wonder if I can convince the boss to  
> buy me one for compatibility testing purposes?  ;-)

I don't think I made myself clear.  The viewport limit of 2048 was  
for the OpenGL software renderer (which is what I suppose you would  
be using for printing).  When rendering to a window, the viewport  
size is going to depend on the graphics card.

Under Tiger, I think the software renderer has a viewport size of  
around 16K.  So, if you tested on Tiger, using a recent version of  
Quesa, I don't know why you would have hit a limit at 11x17 at 300dpi.

Re: High-res printing

[Edward K. C. <ek...@lg...>]

Thank you all for your responses.

On 29-Jul-05, at 11:54 AM, James W. Walker wrote:



> OpenGL has a limit on viewport size, but the exact value depends on  
> the renderer.  Are you running on Mac or Windows?  If Mac, is it  
> Tiger or earlier?  I seem to recall a value of 2048 on Mac pre-Tiger.
>
>

I'm running in Tiger using the interactive renderer.  I should try it  
on a Panther machine to see if there is a difference.  2048 is really  
not that great, is it?  Apple's 30" Cinema Display can supposedly hit  
2650 x 1600.  I wonder if I can convince the boss to buy me one for  
compatibility testing purposes?  ;-)



> Yes, it is possible to tile an image using the camera viewport and  
> the drawContext pane.
>
>

Great!  That's what I wanted to hear.

-Ted

Re: Quesa on the Mac not synchronizing with monitor's vertical retrace

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

Mikey <im...@be...> wrote:

>Also, should we consider the possibility that someone would want to
>turn the synchronization on/off rapidly during rendering or would it
>only be set once at the beginning of program execution?

I suggest that we make it a property flag on the draw context object, 
like for example kQ3DrawContextPropertyGLTextureSharing.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Quesa on the Mac not synchronizing with monitor's vertical retrace

[Mikey <im...@be...>]

According to the OpenGL Profiler, I'm getting 60 FPS with vertical  
retrace enabled, so it doesn't seem that bad of a trade-off to  
eliminate tearing completely.

On 29-Jul-2005, at 9:02 PM, Lane Roathe wrote:

> using a separate thread would not gain anything. (However it could  
> gain
> you some with the sync turned off!). This limit is due specifically to
> syncing with the refresh rate, but in Mac OS X often is only 1/2 the
> rate. In theory you should be able to run at the refresh rate  
> (typically
> 60-75hz). The 25hz rate could also be due to running on a LCD  
> (which do
> not have refresh rates, but fake it).
>
> Typically this choice is made whenever the screen is setup, at startup
> time and whenever the screen setup is changed via prefs in the
> application/game.
>
> on Fri, Jul 29, 2005 Mikey may have said:
>
>
>> Do you think it would be possible to get around the frame rate
>> slowdown if you submit your geometry in a separate thread?
>>
>> Also, should we consider the possibility that someone would want to
>> turn the synchronization on/off rapidly during rendering or would it
>> only be set once at the beginning of program execution?
>>
>> On 29-Jul-2005, at 6:26 PM, Lane Roathe wrote:
>>
>>
>>> on Thu, Jul 28, 2005 James W. Walker may have said:
>>>
>>>>
>>>> On Jul 28, 2005, at 10:11 PM, Mikey wrote:
>>>>
>>>>
>>>>>     // Tell OpenGL to sync with the vertical retrace of the  
>>>>> monitor.
>>>>>     {
>>>>>         const GLint syncEveryFrame = 1;
>>>>>         aglSetInteger( glContext, AGL_SWAP_INTERVAL,
>>>>> &syncEveryFrame );
>>>>>     }
>>>>>
>>>>> I didn't see any reference to this sort of thing in the  
>>>>> archives so
>>>>> I'm not sure if it was omitted on purpose or if it was an
>>>>> oversight.  If it was an oversight, I'd like see about getting it
>>>>> added to the actual CVS codebase.
>>>>>
>>>>
>>>> I looked this up in Apple docs, and while they say what the switch
>>>> does, there is no discussion of pros and cons.  There must be some
>>>> cons, or Apple would have made it the default behavior, no?
>>>>
>>>
>>> Pro: limitS tearing due to drawing faster than the screen can  
>>> refresh
>>>
>>> Con: frame rate (typically 25fps max, sometimes more)