quesa-develop

automatic triangle strip generation

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

The new OpenGL renderer caches a triangle strip the first time it 
renders a TriMesh.  There can be a drawback, which is that if a lot of 
geometry gets rendered for the first time at the same time, there can be 
a noticeable pause while the triangle strips are being computed.  So, 
I'm thinking of adding an option to turn off the automatic strip 
computation, probably using an object property attached to the renderer 
object.  The renderer would still look for the triangle strip data, it 
just wouldn't compute a strip if one is missing.  Any opinion as to 
which behavior should be the default?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: automatic triangle strip generation

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

On 22 Feb, 2007, at 20:47, James Walker wrote:

> The new OpenGL renderer caches a triangle strip the first time it
> renders a TriMesh.  There can be a drawback, which is that if a lot of
> geometry gets rendered for the first time at the same time, there  
> can be
> a noticeable pause while the triangle strips are being computed.  So,
> I'm thinking of adding an option to turn off the automatic strip
> computation, probably using an object property attached to the  
> renderer
> object.  The renderer would still look for the triangle strip data, it
> just wouldn't compute a strip if one is missing.  Any opinion as to
> which behavior should be the default?

I think by default it should calculate and cache, just like the  
interactive
renderer.

Roger.

Re: automatic triangle strip generation

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

On Feb 23, 2007, at 4:26 AM, Roger Holmes wrote:

> I think by default it should calculate and cache, just like the
> interactive
> renderer.

You mean the interactive renderer should be changed to use triangle  
strips?

Re: automatic triangle strip generation

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

On 23 Feb, 2007, at 17:01, James W. Walker wrote:

>> I think by default it should calculate and cache, just like the
>> interactive
>> renderer.
>
> You mean the interactive renderer should be changed to use triangle
> strips?

No I mean the Interactive Renderer caches most objects as TriMeshes,
and it does this by default, in fact currently there is no way to  
turn it off.

Re: automatic triangle strip generation

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

Roger Holmes wrote:
> On 23 Feb, 2007, at 17:01, James W. Walker wrote:
> 
>>> I think by default it should calculate and cache, just like the
>>> interactive
>>> renderer.
>> You mean the interactive renderer should be changed to use triangle
>> strips?
> 
> No I mean the Interactive Renderer caches most objects as TriMeshes,
> and it does this by default, in fact currently there is no way to  
> turn it off.

Oh... that's a bit of a different situation.  If the IR gets, say, a 
Torus, the only alternative to turning it into a TriMesh is to skip it, 
since the renderer doesn't know how to render a Torus directly.  Whereas 
the OpenGL renderer can render a TriMesh without creating a triangle strip.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Printing problems on Intel

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

I have been looking into the problems we are having with printing
with the Interactive Renderer on Intel. If I manually push the Hither
clipping plane forward then most, if not all of the problems go away.

Is there a difference between the Z buffer on Intel and PowerPC?
I half remember that the Z Buffer used to default to 16 bit depth,
and that we ask Quesa to use 32 bits instead. Or was the default
changed? Has OpenGL moved on to using a floating point Z buffer
on Intel? If so can we use 64 bit doubles?

Is there a call to set the Z depth? What is it called?

Roger.

Re: Printing problems on Intel

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

On Feb 23, 2007, at 5:39 AM, Roger Holmes wrote:

> I have been looking into the problems we are having with printing
> with the Interactive Renderer on Intel. If I manually push the Hither
> clipping plane forward then most, if not all of the problems go away.
>
> Is there a difference between the Z buffer on Intel and PowerPC?

Not that I know of.  But it may make a difference which Intel Mac  
you're talking about.  The "Pro" models have decent video cards,  
while the cheaper models have the Intel video with no VRAM.

Could you be more explicit about the nature of the problem with  
printing?  Maybe print to PDF and post the PDF somewhere?

> I half remember that the Z Buffer used to default to 16 bit depth,
> and that we ask Quesa to use 32 bits instead. Or was the default
> changed?

Quesa asks for 32.  The default might depend on the video card, I'm  
not sure.

> Has OpenGL moved on to using a floating point Z buffer
> on Intel? If so can we use 64 bit doubles?
>
> Is there a call to set the Z depth? What is it called?

TQ3Uns32	 requestedBitDepth = 32;
Q3Object_AddElement( rendererObject, kQ3ElementTypeDepthBits,
		& requestedBitDepth );

Re: Printing problems on Intel

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

Oh, I forgot to ask, how are you printing?  If you're using offscreen  
rendering, then of course it doesn't matter what video card you have,  
because you're using the Apple software renderer.