quesa-develop — Mailing list for Quesa development

Anyone use edges in TriMeshes?

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

TriMesh edges aren't used in Geom Test or in any of our test files.  I 
was wondering if anyone would care if I didn't implement edges in my new 
renderer.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: view/renderer handling of surface shaders

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

Roger Holmes wrote:
> On 1 Feb, 2007, at 17:27, James W. Walker wrote:

>> It still seems to me that the view could have a single concept of
>> current surface shader (as the IR does), which is the most recently
>> seen surface shader, subject to pushing and popping when you enter/
>> leave a group and when you start/finish a geometry.
> 
> But pushing and popping the graphics state is a slow operation, you  
> would
> not want to do it for every geometry, and certainly not for every  
> part of
> a geometry (you can have an attribute set on every vertex, edge and
> triangle for some geometries, though what a surface shader does for
> a point I wouldn't care to guess, but I think I have seen them on edges
> when we were first developing 3DWorld).

We're already pushing/popping for retained geometries that have 
attribute sets containing surface shaders.  See 
E3Renderer_Method_SubmitGeometry.

Pushing/popping the view state does not update everything, the view does 
make an effort to update only aspects that have changed, using the 
stackState mask.

The test file that I was getting incorrect results with, 
texture-interference.3dmf, contains an attribute set containing a 
surface shader.  I added another test file, texture-interference-2.3dmf, 
that has a free-floating texture shader.  The second file was working 
correctly.  However...

In IRGeometry_Attribute_Handler, the shader contained in an attribute 
set attached to the geometry was being submitted using

	Q3Object_Submit( *theShader, theView );

As a test, I changed that to say

	TQ3AttributeSet	tempAtts = Q3AttributeSet_New();
	Q3AttributeSet_Add( tempAtts, kQ3AttributeTypeSurfaceShader, theShader );
	Q3Object_Submit( tempAtts, theView );
	Q3Object_Dispose( tempAtts );

With that change, texture-interference.3dmf worked correctly, but 
texture-interference-2.3dmf failed.  This makes me more convinced that 
it's just causing confusion having two surface shaders in the view state.

I have removed the second surface shader from E3View.c.  Now both of my 
test files work, and I haven't seen any other problems.  Of course, let 
me know if you see any bugs.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: view/renderer handling of surface shaders

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

Il giorno 01/feb/07, alle ore 22:35, Roger Holmes ha scritto:

> But pushing and popping the graphics state is a slow operation,

not necessarily, I guess,
  a preallocated stack of attribute pointers, that gets realized only  
with needed is as quick as it can be,

you can also keep the intermediate steps to grow from there

the trick could be modifying the OpenGL state to match Quesa's  
without passing it fully every time,

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: view/renderer handling of surface shaders

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

On 1 Feb, 2007, at 17:27, James W. Walker wrote:

>
> On Feb 1, 2007, at 4:30 AM, Roger Holmes wrote:
>
>> I would think that attributeSurfaceShader is for any surface
>> shaders within shapes and shaderSurface is for any loose surface
>> shaders.
>
> If a surface shader belongs to an attribute set, but that attribute
> set is not attached to a shape, do you consider that "loose"?

No.

>
>> The  'inheritance' rules for these are different. A loose surface
>> shader overrides any  previous loose surface shaders up up to the
>> end of the group it is in. A  surface shaders in an attribute set
>> attached to a shape overrides any loose surface  shaders and any
>> previous attribute surface shaders up until the end of the shape it
>> is attached to. Well, I think that's how it works anyway.
>
> It still seems to me that the view could have a single concept of
> current surface shader (as the IR does), which is the most recently
> seen surface shader, subject to pushing and popping when you enter/
> leave a group and when you start/finish a geometry.

But pushing and popping the graphics state is a slow operation, you  
would
not want to do it for every geometry, and certainly not for every  
part of
a geometry (you can have an attribute set on every vertex, edge and
triangle for some geometries, though what a surface shader does for
a point I wouldn't care to guess, but I think I have seen them on edges
when we were first developing 3DWorld).

>
>> I am not sure of the exact rules when a surface shader is in an
>> attribute set attached to (rather than being a member of) a group
>> and there is a loose surface shader in the group or there is a
>> loose attribute set with a surface shader as a member of the group.
>
> I'm not sure that I've ever tried putting an attribute set on a
> group.  My guess would be that it would be treated as if it were a
> member of the group, but before the first normal member.

Seems reasonable.

>
>> I guess attributeSurfaceShader gets changed by ones in any
>> attribute set and shaderSurface gets changed by any loose ones, and
>> that if attributeSurfaceShader is not nil, it uses that, otherwise
>> it uses shaderSurface unless that  is nil, in which case there is
>> no texture and it looks for colours instead.
>>
>> On 1 Feb, 2007, at 07:00, James W. Walker wrote:
>>
>>> I'm trying to figure out why the Interactive Renderer does the wrong
>>> thing with the test file "texture-interference.3dmf" that I recently
>>> committed.  I think it has to do with the fact that TQ3ViewStackItem
>>> has two surface shader members, shaderSurface and
>>> attributeSurfaceShader.  Anyone know why?  It seems crazy.  But  
>>> maybe
>>> I'm just tired.
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> -
>>> ---
>>> Using Tomcat but need to do more? Need to support web services,
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make your
>>> job easier.
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?
>>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Quesa-develop mailing list
>>> Que...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier.
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: view/renderer handling of surface shaders

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

On Feb 1, 2007, at 4:30 AM, Roger Holmes wrote:

> I would think that attributeSurfaceShader is for any surface  
> shaders within shapes and shaderSurface is for any loose surface  
> shaders.

If a surface shader belongs to an attribute set, but that attribute  
set is not attached to a shape, do you consider that "loose"?

> The  'inheritance' rules for these are different. A loose surface  
> shader overrides any  previous loose surface shaders up up to the  
> end of the group it is in. A  surface shaders in an attribute set  
> attached to a shape overrides any loose surface  shaders and any  
> previous attribute surface shaders up until the end of the shape it  
> is attached to. Well, I think that's how it works anyway.

It still seems to me that the view could have a single concept of  
current surface shader (as the IR does), which is the most recently  
seen surface shader, subject to pushing and popping when you enter/ 
leave a group and when you start/finish a geometry.

> I am not sure of the exact rules when a surface shader is in an  
> attribute set attached to (rather than being a member of) a group  
> and there is a loose surface shader in the group or there is a  
> loose attribute set with a surface shader as a member of the group.

I'm not sure that I've ever tried putting an attribute set on a  
group.  My guess would be that it would be treated as if it were a  
member of the group, but before the first normal member.

> I guess attributeSurfaceShader gets changed by ones in any  
> attribute set and shaderSurface gets changed by any loose ones, and  
> that if attributeSurfaceShader is not nil, it uses that, otherwise  
> it uses shaderSurface unless that  is nil, in which case there is  
> no texture and it looks for colours instead.
>
> On 1 Feb, 2007, at 07:00, James W. Walker wrote:
>
>> I'm trying to figure out why the Interactive Renderer does the wrong
>> thing with the test file "texture-interference.3dmf" that I recently
>> committed.  I think it has to do with the fact that TQ3ViewStackItem
>> has two surface shader members, shaderSurface and
>> attributeSurfaceShader.  Anyone know why?  It seems crazy.  But maybe
>> I'm just tired.
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier.
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: view/renderer handling of surface shaders

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

I would think that attributeSurfaceShader is for any surface shaders  
within
shapes and shaderSurface is for any loose surface shaders. The  
'inheritance'
rules for these are different. A loose surface shader overrides any  
previous
loose surface shaders up up to the end of the group it is in. A  
surface shaders
in an attribute set attached to a shape overrides any loose surface  
shaders
and any previous attribute surface shaders up until the end of the  
shape it is
attached to. Well, I think that's how it works anyway.

I am not sure of the exact rules when a surface shader is in an  
attribute set
attached to (rather than being a member of) a group and there is a loose
surface shader in the group or there is a loose attribute set with a  
surface
shader as a member of the group.

I guess attributeSurfaceShader gets changed by ones in any attribute  
set and
shaderSurface gets changed by any loose ones, and that if  
attributeSurfaceShader
is not nil, it uses that, otherwise it uses shaderSurface unless that  
is nil, in
which case there is no texture and it looks for colours instead.

Roger.




On 1 Feb, 2007, at 07:00, James W. Walker wrote:

> I'm trying to figure out why the Interactive Renderer does the wrong
> thing with the test file "texture-interference.3dmf" that I recently
> committed.  I think it has to do with the fact that TQ3ViewStackItem
> has two surface shader members, shaderSurface and
> attributeSurfaceShader.  Anyone know why?  It seems crazy.  But maybe
> I'm just tired.
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

view/renderer handling of surface shaders

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

I'm trying to figure out why the Interactive Renderer does the wrong  
thing with the test file "texture-interference.3dmf" that I recently  
committed.  I think it has to do with the fact that TQ3ViewStackItem  
has two surface shader members, shaderSurface and  
attributeSurfaceShader.  Anyone know why?  It seems crazy.  But maybe  
I'm just tired.

Re: Memory leak in E3AttributeSet_Inherit. + New renderer

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

On Jan 31, 2007, at 6:21 AM, Roger Holmes wrote:

> I presume the new renderer will be faster than the interactive one,
> which will be wonderful.

That's the goal, though I am not far enough along to do benchmarks.   
I'm also finding a few bugs in the course of going through every  
aspect of rendering.

> I also presume there will be some incompatibilities. Whilst doing the
> changes, can you try
> to make a list of what we should look out for, to be published in the
> release note maybe.

OK... the only thing I can think of right now is that there won't be  
a distinction between the "both" and "flip" backfacing styles,  
they'll both just use OpenGL two-sided lighting.  However there will  
probably be some differences in what constitutes the "fast path" for  
trimeshes.

> Will we get any new facilities at all?

Depends on what you consider a new facility.  I'll probably put in a  
feature of caching a fast-path trimesh as a triangle strip.

> I hope this will not affect existing plug-in renderers.

No, I don't see why it would.

Re: Memory leak in E3AttributeSet_Inherit. + New renderer

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

On 31 Jan, 2007, at 07:26, James W. Walker wrote:

> I've committed that change.


Thank you.


I presume the new renderer will be faster than the interactive one,  
which will be wonderful.

I also presume there will be some incompatibilities. Whilst doing the  
changes, can you try
to make a list of what we should look out for, to be published in the  
release note maybe.

Will we get any new facilities at all?

I hope this will not affect existing plug-in renderers.

In about a month I will have the time to go through the changes  
Microspot has made to
Quesa for our new version and describe what they do and offer them to  
the Quesa
group. IIRC there is something to do with the loading of plug-in  
renderers in a
Macho/Cocoa/Intel environment and one or two fixes for crashes, but  
most are the
result of turning on almost all of XCode's warnings and seeing what  
it was complaining
about - most are just keeping the compiler comfortable but a few  
things like unitialised
variables could lead to real faults.


Thanks again,

Roger.

Re: Memory leak in E3AttributeSet_Inherit.

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

On Jan 30, 2007, at 11:03 AM, Roger Holmes wrote:

> Yes, you are right, the whole section can be bypassed under this
> condition.

I've committed that change.

Re: Memory leak in E3AttributeSet_Inherit.

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

On 30 Jan, 2007, at 18:13, James Walker wrote:

>
> I didn't know that Q3AttributeSet_Inherit allowed the result to be the
> same as the parent or child.  It's not documented that way.

The blue book doesn't say they have to be different. I no longer have  
the
old photocopied documentation from before the blue book. I think some  
other
calls allow the result and inputs to be the same, maybe I'm wrong.


>
> It looks to me like that whole section labeled "Process the child" can
> be skipped if result == child.  Am I wrong?


I wondered about that too but in my version I opted for minimum change
as we are a few weeks from issuing the new version of Interiors which we
demoed at MacWorld earlier this month.

It seemed to me that section just copied stuff onto itself when child  
== result.
As we don't have any operator= to worry about I think it would be  
safe to
assume that it does what it says without anything happening in the  
background.

Yes, you are right, the whole section can be bypassed under this  
condition.

Roger.

Re: Memory leak in E3AttributeSet_Inherit.

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

Roger Holmes wrote:

> Could someone see if they agree with what appears to be
> a memory leak in E3AttributeSet_Inherit. I have a provisional
> fix which is:
> 
> In this section of code, change the last but one line
> 
> 
> 	// Process the child
> 	if ( qd3dStatus == kQ3Success )
> 		{
> 		// Copy the mask and attributes directly
> 		resultSet->setData.theMask    = childSet->setData.theMask ;
> 		resultSet->setData.attributes = childSet->setData.attributes ;
> 		if ( resultSet->setData.attributes.surfaceShader != NULL )
> 			resultSet->setData.attributes.surfaceShader =  
> Q3Shared_GetReference ( childSet->setData.attributes.surfaceShader ) ;
> 
> 
> to read:
> 
> 		if ( resultSet->setData.attributes.surfaceShader != NULL && result ! 
> = child )
> 
> 
> When E3AttributeSet_Inherit gets called with child == result, the  
> reference count of surface
> shaders gets incremented incorrectly, which loses huge amounts of  
> memory with even
> modest sized textures if you call this routine a lot, which I do when  
> doing the CSG
> calculations for windows and doors within walls, which is now done  
> for almost every time
> redraw.
> 
> If you agree with the change, could you check it in, or remind me how  
> to do it
> as I have not done a Quesa check in for some time and I've forgotten  
> how.

I didn't know that Q3AttributeSet_Inherit allowed the result to be the 
same as the parent or child.  It's not documented that way.

It looks to me like that whole section labeled "Process the child" can 
be skipped if result == child.  Am I wrong?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Memory leak in E3AttributeSet_Inherit.

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

Hi All,

I like the sound of this new OpenGL optimised renderer.

Could someone see if they agree with what appears to be
a memory leak in E3AttributeSet_Inherit. I have a provisional
fix which is:

In this section of code, change the last but one line


	// Process the child
	if ( qd3dStatus == kQ3Success )
		{
		// Copy the mask and attributes directly
		resultSet->setData.theMask    = childSet->setData.theMask ;
		resultSet->setData.attributes = childSet->setData.attributes ;
		if ( resultSet->setData.attributes.surfaceShader != NULL )
			resultSet->setData.attributes.surfaceShader =  
Q3Shared_GetReference ( childSet->setData.attributes.surfaceShader ) ;


to read:

		if ( resultSet->setData.attributes.surfaceShader != NULL && result ! 
= child )


When E3AttributeSet_Inherit gets called with child == result, the  
reference count of surface
shaders gets incremented incorrectly, which loses huge amounts of  
memory with even
modest sized textures if you call this routine a lot, which I do when  
doing the CSG
calculations for windows and doors within walls, which is now done  
for almost every time
redraw.

If you agree with the change, could you check it in, or remind me how  
to do it
as I have not done a Quesa check in for some time and I've forgotten  
how.
Anyone got some new old stock RAM for a 1953 biological computer?
You can't get the parts you know!

Roger Holmes.

Re: New renderer under construction

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

Jose' Cruanyes wrote:
> Il giorno 29/gen/07, alle ore 19:50, James Walker ha scritto:
> 
>> Jose' Cruanyes wrote:
>>> Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto:
>>>
>>>> I've mentioned before that I was thinking of writing a new renderer
>>>> that
>>>>   would pay more attention to using OpenGL for best performance, and
>>>> less attention to legacy behavior.
>>> In the process will be a good thing to factor better the various
>>> functionality to ease the process to creatre new renderers.
>>>
>>> just separate things in various files that can be included in the
>>> compilation of new renderers,,,
>> I'll see what I can do.  I'd like to figure out a way for something  
>> like
>> the cartoon renderer to be a plug-in, which may require adding a  
>> couple
>> more renderer methods.
> 
> It's not just a matter of compile it using some bits of the Quesa  
> source?
> anyway they are always avalaible... or there are some deep  
> interaction "broking the rules" between view and renderer?

Of course one could copy the entire source of the IR to make a new 
renderer, but in the case of the cartoon render, a very large amount 
would be the same.  In attempting to subclass a renderer, the problem is 
with the way the attribute set of a geometry is handled.  The 
submit-triangle and submit-trimesh methods need to call 
IRGeometry_Attribute_Handler and IRRenderer_Texture_Postamble, which are 
not available to a plugin subclass.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: New renderer under construction

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

Il giorno 29/gen/07, alle ore 19:50, James Walker ha scritto:

> Jose' Cruanyes wrote:
>> Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto:
>>
>>> I've mentioned before that I was thinking of writing a new renderer
>>> that
>>>   would pay more attention to using OpenGL for best performance, and
>>> less attention to legacy behavior.
>>
>> In the process will be a good thing to factor better the various
>> functionality to ease the process to creatre new renderers.
>>
>> just separate things in various files that can be included in the
>> compilation of new renderers,,,
>
> I'll see what I can do.  I'd like to figure out a way for something  
> like
> the cartoon renderer to be a plug-in, which may require adding a  
> couple
> more renderer methods.

It's not just a matter of compile it using some bits of the Quesa  
source?
anyway they are always avalaible... or there are some deep  
interaction "broking the rules" between view and renderer?



>
>> I'm in the process of add wxWidgets as new platform , so it can be
>> also a couple of weeks before we can see anything
>
> I wouldn't have expected wxWidgets to be a platform, not that I know
> anything about it.  Doesn't it use Carbon or Cocoa under the hood?

and Win32, gtk, fbd, OS2, VMS and a couple of others, but since it  
has already factored out the platform differences, makes sense to use  
it as a platform from the Quesa point of view, especially when  
dealing with high level constructs like the viewer, or more mundane  
tools like files, windows ecc (yes, OpenGL surface/context are present)

>
>>> The renderer nickname is tentatively "Quesa OpenGL
>>> Performance", but I'm open to suggestions.
>>
>> just "Quesa OpenGL" ?
>
> Hmm, yes, that might be better.
> -- 
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: New renderer under construction

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

Jose' Cruanyes wrote:
> Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto:
> 
>> I've mentioned before that I was thinking of writing a new renderer  
>> that
>>   would pay more attention to using OpenGL for best performance, and
>> less attention to legacy behavior.
> 
> In the process will be a good thing to factor better the various  
> functionality to ease the process to creatre new renderers.
> 
> just separate things in various files that can be included in the  
> compilation of new renderers,,,

I'll see what I can do.  I'd like to figure out a way for something like 
the cartoon renderer to be a plug-in, which may require adding a couple 
more renderer methods.

> I'm in the process of add wxWidgets as new platform , so it can be  
> also a couple of weeks before we can see anything

I wouldn't have expected wxWidgets to be a platform, not that I know 
anything about it.  Doesn't it use Carbon or Cocoa under the hood?

>> The renderer nickname is tentatively "Quesa OpenGL
>> Performance", but I'm open to suggestions.
> 
> just "Quesa OpenGL" ?

Hmm, yes, that might be better.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

New sample code for Mac Carbon

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

In case anyone is reading this list but not the cvs list, I committed  
a new code example, HIQuesaView, that wraps Quesa in a Carbon control.

Re: New renderer under construction

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

Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto:

> I've mentioned before that I was thinking of writing a new renderer  
> that
>   would pay more attention to using OpenGL for best performance, and
> less attention to legacy behavior.

In the process will be a good thing to factor better the various  
functionality to ease the process to creatre new renderers.

just separate things in various files that can be included in the  
compilation of new renderers,,,



>   I'm actually working on it now.  It
> will probably be another couple of weeks before I'm ready to check
> anything in.

I'm in the process of add wxWidgets as new platform , so it can be  
also a couple of weeks before we can see anything


> The renderer nickname is tentatively "Quesa OpenGL
> Performance", but I'm open to suggestions.

just "Quesa OpenGL" ?


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

New renderer under construction

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

I've mentioned before that I was thinking of writing a new renderer that 
  would pay more attention to using OpenGL for best performance, and 
less attention to legacy behavior.  I'm actually working on it now.  It 
will probably be another couple of weeks before I'm ready to check 
anything in.  The renderer nickname is tentatively "Quesa OpenGL 
Performance", but I'm open to suggestions.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

[ quesa-Bugs-1194603 ] Transparency problem with rasterize camera transforms

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

Bugs item #1194603, was opened at 2005-05-03 10:40
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1194603&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
Private: No
Submitted By: Frank Condello (pox)
>Assigned to: James W. Walker (jwwalker)
Summary: Transparency problem with rasterize camera transforms

Initial Comment:
Transparent triangles with Z coordinates other than zero aren't drawn 
when using rasterize camera transforms. The problem lies in 
ir_geom_transparent_add, where triangles "behind" the camera are 
culled. Rasterize transforms invert Z, which is likely confusing the 
culling check.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-01-19 18:06

Message:
Logged In: YES 
user_id=433183
Originator: NO

I think this was probably fixed by a change to
e3transform_camera_rasterize_submit in July 2006.  Since no test case was
provided, I'll mark this fixed unless I hear differently.

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

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

[ quesa-Bugs-1601345 ] Need option to turn on VBL syncing

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

Bugs item #1601345, was opened at 2006-11-22 11:02
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1601345&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
Private: No
Submitted By: Sean McBride (sean_mcbride)
Assigned to: James W. Walker (jwwalker)
Summary: Need option to turn on VBL syncing

Initial Comment:
With large windows and a complex scene, moving the camera around produces visible tearing.

One solution would be to provide an API to enable VBL syncing, using this snippit: <http://developer.apple.com/technotes/tn/tn2014.html#Section5>

By default it should be off to not disturb existing code.


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

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-12-08 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

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: 2006-11-24 17:51

Message:
Logged In: YES 
user_id=433183
Originator: NO

On the Mac (Carbon), there is now a draw context option to turn on VBL
syncing, kQ3DrawContextPropertySyncToRefresh.  I don't know if there are
equivalent options on Windows and Unix.

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

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

[ quesa-Bugs-1601345 ] Need option to turn on VBL syncing

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

Bugs item #1601345, was opened at 2006-11-22 11:02
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1601345&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
Private: No
Submitted By: Sean McBride (sean_mcbride)
>Assigned to: James W. Walker (jwwalker)
Summary: Need option to turn on VBL syncing

Initial Comment:
With large windows and a complex scene, moving the camera around produces visible tearing.

One solution would be to provide an API to enable VBL syncing, using this snippit: <http://developer.apple.com/technotes/tn/tn2014.html#Section5>

By default it should be off to not disturb existing code.


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

>Comment By: James W. Walker (jwwalker)
Date: 2006-11-24 17:51

Message:
Logged In: YES 
user_id=433183
Originator: NO

On the Mac (Carbon), there is now a draw context option to turn on VBL
syncing, kQ3DrawContextPropertySyncToRefresh.  I don't know if there are
equivalent options on Windows and Unix.

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

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

Re: Tearing with Quesa views

[Sean M. <se...@ro...>]

On 2006-11-21 11:30, James Walker said:

>No, I'm not seeing it.  No doubt there are a number of variables, 
>including video card and screen resolution.

True enough.

>> Thanks, I checked it out.  I see why one would not want it on all the
>> time.  But it seems to me an option would be good, wouldn't you say=3F
>
>Yeah, I don't see any harm in it.  I've certainly added a few obscure 
>options for my own purposes.

I have filed a bug: "1601345 Need option to turn on VBL syncing".

I don't know the Quesa code at all so I can't really submit a patch, but
I am certainly willing to test any patch anyone makes.

Thanks,

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

[ quesa-Bugs-1601345 ] Need option to turn on VBL syncing

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

Bugs item #1601345, was opened at 2006-11-22 14:02
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=1601345&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
Private: No
Submitted By: Sean McBride (sean_mcbride)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need option to turn on VBL syncing

Initial Comment:
With large windows and a complex scene, moving the camera around produces visible tearing.

One solution would be to provide an API to enable VBL syncing, using this snippit: <http://developer.apple.com/technotes/tn/tn2014.html#Section5>

By default it should be off to not disturb existing code.


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

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

Re: Tearing with Quesa views

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

Sean McBride wrote:

>>> Is it just me or do Quesa views tear a lot?
>> I haven't seen any.  Can you see tearing in Geom Test?
> 
> Yes.  With several views in fact.  For example, "Box (textured)" or
> "Quesa logo" when I make the window very big.  Can you repro?

No, I'm not seeing it.  No doubt there are a number of variables, 
including video card and screen resolution.

>> There was an inconclusive discussion of this in 2005.  If you weren't  
>> a subscriber back then, you might want to check the archive.
> 
> Thanks, I checked it out.  I see why one would not want it on all the
> time.  But it seems to me an option would be good, wouldn't you say?

Yeah, I don't see any harm in it.  I've certainly added a few obscure 
options for my own purposes.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>