quesa-develop — Mailing list for Quesa development

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

On 27 Feb, 2007, at 20:48, James Walker wrote:

>
> OK, I've checked in a version of E3View.c in which attributeSet is  
> gone,
>   and I saw about a 3% increase in frame rate for the Multibox test in
> Geom Test.


That's great. Thank you.

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

On 27 Feb, 2007, at 20:06, James Walker wrote:

> A view does have a default attribute set  
> (Q3View_SetDefaultAttributeSet)
> that gets submitted at the start of a submitting loop.  Maybe that's
> what you were thinking of.

Yes that must be it.

[ quesa-Bugs-902950 ] Improve view state stack performance

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

Bugs item #902950, was opened at 2004-02-23 12:10
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902950&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: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve view state stack performance

Initial Comment:
A  performance bottleneck at present is that pushing/popping the 
view state stack is quite expensive.

This could be improved by doing some kind of lazy-updating of the 
stack, where values would only be pushed if they were changed 
since the view state was 'pushed'.


------- Additional Comments From Dair Grant 2002-04-17 09:58 
-------

Additional comments from Erik Olson:

> Profiling under Quesa did reveal that about one third of cpu 
> time was spent copying and destructing attribute sets on 
> stack pops. An optimization would be to have lazy 
> construction of the stack frame's attribute set. 
> 
> I rely on the stack to unwind hierarchical matrix transforms 
> and infrequent color highlights, so most of the time the 
> attribute set is constant.


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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-27 21:14

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

We're no longer duplicating or destroying attribute sets when the view
state stack is pushed or popped.  The statement of the bug is a bit too
ill-defined to state definitively that it has been "fixed", but I'm not
sure we need the bug around any more.  In the future, performance bugs
should contain specific instructions on how to duplicate a particularly
slow case.

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

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

[ quesa-Bugs-967958 ] Trimesh transparency vertex attributes not applied properly

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

Bugs item #967958, was opened at 2004-06-06 22:40
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967958&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: Rejected
Priority: 5
Private: No
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trimesh transparency vertex attributes not applied properly

Initial Comment:
Transparency color vertex attributes in a trimesh do not appear to 
properly flag all vertices/triangles as transparent.

This screenshot: <http://webhome.idirect.com/~frankco/
transerror.jpg> shows a heightmap that has been flooded with 
transparency color vertex attributes and should draw entirely in 
the transparent color, but it appears that (possibly) every-other 
triangle is solid. The same model works as expected in QD3D.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-27 21:05

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

Since the requested sample file was never provided, I'm going to close
this.  By the way, I think that the new OpenGL renderer would not have such
a problem; vertex transparency would cause a TriMesh to be decomposed into
triangles.

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

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

Message:
Logged In: YES 
user_id=171509

I think I've isolated the issue...

When ir_geom_trimesh_build_transparent checks for transparent vertices 
it flags transparent triangles by running through all the vertices and 
finding their parent triangle. However, ir_geom_trimesh_build_triangles 
only assigns the first triangle that references a given vertex as a
parent, 
potentially leaving some "childless" triangles in the mix. The diagram 
below illustrates a tristrip that would exhibit this bug (hopefully my
ASCII 
art comes out ok):

A-----B
|\    |\
| \ 3 | \
|  \  |  \
| 1 \ | 2 \
|    \|    \
C-----D-----E

vertex A parent = triangle 1
vertex B parent = triangle 2
vertex C parent = triangle 1
vertex D parent = triangle 1
vertex E parent = triangle 2

ir_geom_trimesh_build_transparent won't flag triangle #3 as transparent 
in this case, even if all it's vertices are transparent.

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

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

Message:
Logged In: YES 
user_id=439944

Can you attach the model to this bug, or make it available?

The list of transparent triangles is constructed in 
ir_geom_trimesh_build_transparent: do you see anything odd if you step 
through there? Also, does the TriMesh have a usage array for this vertex 
attribute?

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

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

[ quesa-Bugs-1370363 ] Memory Leak with UVs set too large numbers

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

Bugs item #1370363, was opened at 2005-11-30 12:51
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1370363&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: Invalid
Priority: 5
Private: No
Submitted By: nstensland (nstensland)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leak with UVs set too large numbers

Initial Comment:
There seems to be a memory leaks when assigning textures to shapes 
(general polygon in my example) which have been assigned UV 
coordinates with large values (a range from -500 to 500 in my example). 
When seting the UVs to a range of 0..1, the memory leaks goes away. 
Should the UV always be in range 0..1
?



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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-27 20:57

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

OK, I'll close the bug.

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

Comment By: nstensland (nstensland)
Date: 2007-02-26 17:30

Message:
Logged In: YES 
user_id=1389096
Originator: YES

I believe this may be related to something on my Windows XP machine not
Quesa.


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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-22 11:41

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

We need more information about how a leak is detected, how to replicate
the problem, and whether there is any evidence that the problem is with
Quesa rather than OpenGL.  As far as I know, Quesa always just passes the
UVs on to OpenGL.

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

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

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

James Walker wrote:
> I was looking at the view state stack, and wondered if we really need 
> the attributeSet member of TQ3ViewStackItem.  It causes a 
> Q3Object_Duplicate call every time we push the stack, and it looks like 
> it's only there to support Q3View_GetAttributeState and 
> Q3View_GetAttributeSetState.  Internally, we only call 
> Q3View_GetAttributeSetState when writing view hints, and never call 
> Q3View_GetAttributeState.  So I would think that whenever 
> Q3View_GetAttributeState or Q3View_GetAttributeSetState is called, we 
> could just build an attribute set on the fly from the various attribute 
> members of TQ3ViewStackItem.  Anyone see a problem with that?

OK, I've checked in a version of E3View.c in which attributeSet is gone, 
  and I saw about a 3% increase in frame rate for the Multibox test in 
Geom Test.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

Roger Holmes wrote:
> On 27 Feb, 2007, at 17:34, James W. Walker wrote:
>> I'm not sure how any custom attributes would get in that attribute
>> set.  It looks like the only way an attribute is added to that set is
>> by e3view_stack_update_attribute, which is called by
>> e3view_stack_update only for specific known attribute types.
> 
> Well that's fine then. I thought there was a way of adding attributes
> to the view object itself and that was what we were talking about.
> 
> So carry on.

A view does have a default attribute set (Q3View_SetDefaultAttributeSet) 
that gets submitted at the start of a submitting loop.  Maybe that's 
what you were thinking of.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

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

>
> On Feb 27, 2007, at 3:23 AM, Roger Holmes wrote:
>
>> On 27 Feb, 2007, at 03:08, James Walker wrote:
>>
>>> I was looking at the view state stack, and wondered if we really  
>>> need
>>> the attributeSet member of TQ3ViewStackItem.  It causes a
>>> Q3Object_Duplicate call every time we push the stack, and it looks
>>> like
>>> it's only there to support Q3View_GetAttributeState and
>>> Q3View_GetAttributeSetState.  Internally, we only call
>>> Q3View_GetAttributeSetState when writing view hints, and never call
>>> Q3View_GetAttributeState.  So I would think that whenever
>>> Q3View_GetAttributeState or Q3View_GetAttributeSetState is  
>>> called, we
>>> could just build an attribute set on the fly from the various
>>> attribute
>>> members of TQ3ViewStackItem.  Anyone see a problem with that?
>>
>>
>> I am not sure how much generality we would lose by doing this. I did
>> come across a program which included custom attributes in its data
>> which I
>> picked up on in the Microspot Renderer. I do use lots of custom
>> attributes but our ones do not affect the rendering. I would rather
>> use custom
>> groups or custom geometries to do those sorts of things.
>>
>> I think we can check if there any other attributes which we don't
>> understand.  If there are some then we proceed as now, otherwise we
>> do as you
>> suggest.  Hopefully the former case will be very rare. Maybe we
>> could have a
>> flag to ay if there are currently any custom attributes there, and
>> only do
>> the full check when the attribute set gets changed.
>>
>> I agree we do not want to be calling Q3Object_Duplicate for every
>> group
>> in the data.
>
> I'm not sure how any custom attributes would get in that attribute
> set.  It looks like the only way an attribute is added to that set is
> by e3view_stack_update_attribute, which is called by
> e3view_stack_update only for specific known attribute types.

Well that's fine then. I thought there was a way of adding attributes
to the view object itself and that was what we were talking about.

So carry on.

Roger.

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

On Feb 27, 2007, at 3:23 AM, Roger Holmes wrote:

> On 27 Feb, 2007, at 03:08, James Walker wrote:
>
>> I was looking at the view state stack, and wondered if we really need
>> the attributeSet member of TQ3ViewStackItem.  It causes a
>> Q3Object_Duplicate call every time we push the stack, and it looks
>> like
>> it's only there to support Q3View_GetAttributeState and
>> Q3View_GetAttributeSetState.  Internally, we only call
>> Q3View_GetAttributeSetState when writing view hints, and never call
>> Q3View_GetAttributeState.  So I would think that whenever
>> Q3View_GetAttributeState or Q3View_GetAttributeSetState is called, we
>> could just build an attribute set on the fly from the various
>> attribute
>> members of TQ3ViewStackItem.  Anyone see a problem with that?
>
>
> I am not sure how much generality we would lose by doing this. I did
> come across a program which included custom attributes in its data  
> which I
> picked up on in the Microspot Renderer. I do use lots of custom
> attributes but our ones do not affect the rendering. I would rather  
> use custom
> groups or custom geometries to do those sorts of things.
>
> I think we can check if there any other attributes which we don't
> understand.  If there are some then we proceed as now, otherwise we  
> do as you
> suggest.  Hopefully the former case will be very rare. Maybe we  
> could have a
> flag to ay if there are currently any custom attributes there, and  
> only do
> the full check when the attribute set gets changed.
>
> I agree we do not want to be calling Q3Object_Duplicate for every  
> group
> in the data.

I'm not sure how any custom attributes would get in that attribute  
set.  It looks like the only way an attribute is added to that set is  
by e3view_stack_update_attribute, which is called by  
e3view_stack_update only for specific known attribute types.

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

On 27 Feb, 2007, at 03:08, James Walker wrote:

> I was looking at the view state stack, and wondered if we really need
> the attributeSet member of TQ3ViewStackItem.  It causes a
> Q3Object_Duplicate call every time we push the stack, and it looks  
> like
> it's only there to support Q3View_GetAttributeState and
> Q3View_GetAttributeSetState.  Internally, we only call
> Q3View_GetAttributeSetState when writing view hints, and never call
> Q3View_GetAttributeState.  So I would think that whenever
> Q3View_GetAttributeState or Q3View_GetAttributeSetState is called, we
> could just build an attribute set on the fly from the various  
> attribute
> members of TQ3ViewStackItem.  Anyone see a problem with that?


I am not sure how much generality we would lose by doing this. I did  
come
across a program which included custom attributes in its data which I
picked up on in the Microspot Renderer. I do use lots of custom  
attributes
but our ones do not affect the rendering. I would rather use custom  
groups
or custom geometries to do those sorts of things.

I think we can check if there any other attributes which we don't  
understand.
If there are some then we proceed as now, otherwise we do as you  
suggest.
Hopefully the former case will be very rare. Maybe we could have a  
flag to
say if there are currently any custom attributes there, and only do  
the full
check when the attribute set gets changed.

I agree we do not want to be calling Q3Object_Duplicate for every group
in the data.

Roger.

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

I was looking at the view state stack, and wondered if we really need 
the attributeSet member of TQ3ViewStackItem.  It causes a 
Q3Object_Duplicate call every time we push the stack, and it looks like 
it's only there to support Q3View_GetAttributeState and 
Q3View_GetAttributeSetState.  Internally, we only call 
Q3View_GetAttributeSetState when writing view hints, and never call 
Q3View_GetAttributeState.  So I would think that whenever 
Q3View_GetAttributeState or Q3View_GetAttributeSetState is called, we 
could just build an attribute set on the fly from the various attribute 
members of TQ3ViewStackItem.  Anyone see a problem with that?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

[ quesa-Bugs-1370363 ] Memory Leak with UVs set too large numbers

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

Bugs item #1370363, was opened at 2005-11-30 14:51
Message generated for change (Comment added) made by nstensland
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1370363&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: nstensland (nstensland)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leak with UVs set too large numbers

Initial Comment:
There seems to be a memory leaks when assigning textures to shapes 
(general polygon in my example) which have been assigned UV 
coordinates with large values (a range from -500 to 500 in my example). 
When seting the UVs to a range of 0..1, the memory leaks goes away. 
Should the UV always be in range 0..1
?



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

>Comment By: nstensland (nstensland)
Date: 2007-02-26 19:30

Message:
Logged In: YES 
user_id=1389096
Originator: YES

I believe this may be related to something on my Windows XP machine not
Quesa.


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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-22 13:41

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

We need more information about how a leak is detected, how to replicate
the problem, and whether there is any evidence that the problem is with
Quesa rather than OpenGL.  As far as I know, Quesa always just passes the
UVs on to OpenGL.

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

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

Re: How to Xcode compile latest?

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

Jeff Quan wrote:
> Hello,
> I'm a Quesa user through REALBasic and am interested in compiling the 
> latest version in order to try out the new OpenGL renderer. While I have 
> the Mac OS X developer tools installed (mostly to use the profilers) and 
> the lastest Quesa code via CVS, I'll confess that I don't know how 
> to compile with Xcode and could use some help on how to get a Universal 
> Binary Framework.

1. In the CVS hierarchy, open the Development/Projects/Mac folder.
2. Open the Quesa.xcodeproj project in Xcode.
3. Set the Active Target menu to "Fmwk Univ".
4. Set the Active Build Configuration to Release.
5. Click the Build icon.

P.S. please join the mailing list so that the moderator (me) does not 
have to approve your posts.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

How to Xcode compile latest?

[Jeff Q. <jq...@mi...>]

Hello,
I'm a Quesa user through REALBasic and am interested in compiling the  
latest version in order to try out the new OpenGL renderer. While I  
have the Mac OS X developer tools installed (mostly to use the  
profilers) and the lastest Quesa code via CVS, I'll confess that I  
don't know how to compile with Xcode and could use some help on how  
to get a Universal Binary Framework.

Thanks in advance

==
Jeff Quan
jq...@mi...
http://www.jcquan.com/JQportfolio

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

> How about this:
>
> e3group_display_metahandler returns the same routine for the four
> instances
> 		case kQ3XMethodTypeObjectSubmitBounds:
> 		case kQ3XMethodTypeObjectSubmitPick:
> 		case kQ3XMethodTypeObjectSubmitRender:
> 		case kQ3XMethodTypeObjectSubmitWrite:
>
> These could be four separate routines, call them
> e3group_display_submit_contents_Bounds
> e3group_display_submit_contents_Pick
> e3group_display_submit_contents_Render
> e3group_display_submit_contents_Write
> These would know the view mode and so would
> not have to get it or switch on it.

Sorry about replying to my own e-mails, but in the same way as above,
e3group_metahandler returns the same routine for three instances

		case kQ3XMethodTypeObjectSubmitBounds:
		case kQ3XMethodTypeObjectSubmitPick:
		case kQ3XMethodTypeObjectSubmitRender:

These can also be usefully separated.

I did not say in the original email, but the separated instances
can then be optimised by removing the checks on the mode,
and eliminating the stuff which is not required, which makes the
routines smaller and hence more likely to remain in the cache
as well as not executing so many instructions.

One other thing I noticed, E3Bit_IsSet would probably be very
slightly quicker coded as ((TQ3Boolean) (((_bf) & (_b)) != 0))
rather than ((TQ3Boolean) (((_bf) & (_b)) == (_b)))

Alternatively, just use E3Bit_AnySet instead, and maybe rename
E3Bit_IsSet to be E3Bit_AllSet as there nothing stopping you
passing the first parameter as multiple bits.

Roger.

[ quesa-Bugs-967741 ] Polyline ignores segment attributes

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

Bugs item #967741, was opened at 2004-06-06 12:46
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967741&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: 4
Private: No
Submitted By: James W. Walker (jwwalker)
Assigned to: James W. Walker (jwwalker)
Summary: Polyline ignores segment attributes

Initial Comment:
This was bug 00007 in the ancient pre-Bugzilla bug list: Wireframe/
Interactive renderers don't support segment attributes for 
polylines.

Note that e3geom_polyline_cache_new is never called when using 
these renderers, instead IRGeometry_Submit_PolyLine and 
WFGeometry_PolyLine handle the polyline.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-02-25 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: 2007-02-10 22:53

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

PolyLine segment attributes are now handled in the Interactive, Wireframe,
and OpenGL renderers, by the quick and dirty way of decomposing a PolyLine
into Lines if it has segment attributes.  I added a new test model
Polyline-attributes.3dmf to test this.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-06-06 12:48

Message:
Logged In: YES 
user_id=433183

Bug 00022 in the ancient bug list was also this bug.

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

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

[ quesa-Bugs-1227484 ] Add support for OpenGL display lists

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

Bugs item #1227484, was opened at 2005-06-25 12:50
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1227484&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: Michael Sullivan (imikey)
Assigned to: James W. Walker (jwwalker)
Summary: Add support for OpenGL display lists

Initial Comment:
Was discussed on the list with the following thoughts:

*****

James W. Walker wrote:

 > Yes, but if someone is updating a trimesh every frame (which 
isn"t  
 > an unreasonable expectation) you"ll be compiling a new display 
list  
 > every frame, which will certainly be slower than using the 
current  
 > vertex array path.
 
 I suppose some might do that, but it would not be a concern in 
my use  
 of Quesa.
 
 > To use display lists to their potential you need a geometry type  
 > that"s guaranteed never to change, or some sort of flag for  
 > existing geometries that allows you to declare them as "static"  
 > once their data is set.
 
 It would be easy enough to use an object property as a flag.

*****

Mikey wrote:

 >  To use display lists to their potential you need a
 >  geometry type that"s guaranteed never to change, or some 
sort of flag
 >  for existing geometries that allows you to declare them as 
"static"
 >  once their data is set.
 
 I would think that scenery such as ground terrain, trees, etc. 
would  
 be ideal for using this "static" flag and thus become eligible for  
 storage in display lists.  Furthermore, if all such objects had  
 normals computed for them, then perhaps OpenGL"s built-in 
backface  
 culling could be used when drawing them.


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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-02-25 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: 2007-02-10 21:01

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

The new OpenGL renderer uses VBOs when the OpenGL implementation supports
them, and display lists otherwise.

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

Comment By: James W. Walker (jwwalker)
Date: 2005-07-16 19:13

Message:
Logged In: YES 
user_id=433183

Dair Grant's idea was that we should use VBO's instead of
display lists, as a more modern method. (There has been
some recent disagreement on the comp.graphics.api.opengl
newsgroup as to whether VBOs are necessarily faster than
display lists.)  The trouble with both ideas is that Quesa
currently does its own backface culling. This is to support
the 3 backfacing choices in Quesa, which do not quite
correspond to OpenGL's two choices of two-sided rendering
or not.  But this means that if you moved the camera, you
would have to flush the cached display lists or VBOs.

What we might consider is making a new renderer that
would place less emphasis on compatibility with QD3D
documentation and experience, and more emphasis on
speed.  The new cartoon-style renderer can serve as an
example of how to base a new renderer on the existing
one, rather than writing a whole renderer from scratch.

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

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

[ quesa-Bugs-967914 ] Highlight style's specular settings do not override

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

Bugs item #967914, was opened at 2004-06-06 20:22
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967914&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: Wont Fix
Priority: 5
Private: No
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Highlight style's specular settings do not override

Initial Comment:
An attribute set's specular settings do not get overridden by a 
highlight style.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-02-25 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: 2007-02-10 21:04

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

Without a sample model, it's not reasonable to expect this to be fixed.

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

Comment By: Frank Condello (pox)
Date: 2004-06-17 14:45

Message:
Logged In: YES 
user_id=171509

I've narrowed this down a bit...

This bug only occurs on primitives that use face/cap attribute sets. If 
face or caps inherit the geometry's main attribute set the specular 
properties aren't overridden when applying a highlight style. 
Everything works as it should if face and/or cap attribute sets actually 
exist 
however.

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

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

Message:
Logged In: YES 
user_id=439944

Can you attach a model that demonstrates the problem?

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

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

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

On 24 Feb, 2007, at 03:11, James Walker wrote:

> Roger Holmes wrote:
>
>> More optimisation. Especially I would like to reduce going all
>> around the houses for a group to submit the groups within it.
>> One recursive routine in the stack trace is unavoidable, but at
>> the moment we have three routines repeatedly calling each
>> other. One knows what the submission mode is e.g Picking
>> but the other ones keep checking the mode, which must be
>> slowing us down. There has got to be a better way.
>
>
> I'm not sure which 3 routines you're talking about here.  When you
> submit a group for rendering, the call stack looks something like
>
> Q3Object_Submit
> E3Object_Submit
> E3View_SubmitRetained
> e3view_submit_retained_render
> e3group_display_submit_contents
> e3group_submit_contents
> Q3Object_Submit

Yes, in the debugger that's right. If you compile a version for  
profiling
(names on, optimisations on), then profile it with Shark, only three
of these show up. I guess some get optimised out. As far as optimisation
goes then it is just the three which matter, but of course it would be
nicer when debugging to not have all of these calls showing up.



>
> I say "something like" because if you subclass the view object, as  
> Geom
> Test does, you have the subclass submit-retained-render method in  
> there.
>   It's true that two of these, e3group_display_submit_contents and
> e3group_submit_contents, check the view mode, but  
> E3View_GetViewMode is
> just an accessor and should be quite fast.

But there's the switch statement. There is the call to  
E3DisplayGroup::GetState,
there is the checking of its success/failure, and it only ever  
returns success.
There is loads of code which does nothing constructive towards  
getting the
rendering/picking or whatever done, its just administrative red tape.

>
> One way I see to shorten the cycle is to have e3group_submit_contents
> call E3View_SubmitRetained directly instead of calling  
> Q3Object_Submit.
>   That looks safe, so I'll go ahead and commit it.

Yes that's a step in the right direction.



>
> Also, is anyone using kQ3CallbackElementTypeBeforeRender and
> kQ3CallbackElementTypeAfterRender, which are checked every time  
> through
> e3view_submit_retained_render?

Not me either.

> I put those in a few years back, but I don't use them any more, as I
> decided that I can do more with less trouble by subclassing the  
> view object.

Sounds good, I was thinking about having one set of routines for when  
there
was one and another set for when there wasn't, but if we can get rid  
of them
completely then thats even better.


How about this:

e3group_display_metahandler returns the same routine for the four  
instances
		case kQ3XMethodTypeObjectSubmitBounds:
		case kQ3XMethodTypeObjectSubmitPick:
		case kQ3XMethodTypeObjectSubmitRender:
		case kQ3XMethodTypeObjectSubmitWrite:

These could be four separate routines, call them
e3group_display_submit_contents_Bounds
e3group_display_submit_contents_Pick
e3group_display_submit_contents_Render
e3group_display_submit_contents_Write
These would know the view mode and so would
not have to get it or switch on it.

Roger.

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

Il giorno 24/feb/07, alle ore 04:11, James Walker ha scritto:

>
> Also, is anyone using kQ3CallbackElementTypeBeforeRender and
> kQ3CallbackElementTypeAfterRender, which are checked every time  
> through
> e3view_submit_retained_render?
>

not me

Pax et Bonum

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

Optimization ideas (was Re: 64 bit version of Quesa)

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

Roger Holmes wrote:

> More optimisation. Especially I would like to reduce going all
> around the houses for a group to submit the groups within it.
> One recursive routine in the stack trace is unavoidable, but at
> the moment we have three routines repeatedly calling each
> other. One knows what the submission mode is e.g Picking
> but the other ones keep checking the mode, which must be
> slowing us down. There has got to be a better way.


I'm not sure which 3 routines you're talking about here.  When you 
submit a group for rendering, the call stack looks something like

Q3Object_Submit
E3Object_Submit
E3View_SubmitRetained
e3view_submit_retained_render
e3group_display_submit_contents
e3group_submit_contents
Q3Object_Submit

I say "something like" because if you subclass the view object, as Geom 
Test does, you have the subclass submit-retained-render method in there. 
  It's true that two of these, e3group_display_submit_contents and 
e3group_submit_contents, check the view mode, but E3View_GetViewMode is 
just an accessor and should be quite fast.

One way I see to shorten the cycle is to have e3group_submit_contents 
call E3View_SubmitRetained directly instead of calling Q3Object_Submit. 
  That looks safe, so I'll go ahead and commit it.


Also, is anyone using kQ3CallbackElementTypeBeforeRender and 
kQ3CallbackElementTypeAfterRender, which are checked every time through 
e3view_submit_retained_render?

I put those in a few years back, but I don't use them any more, as I 
decided that I can do more with less trouble by subclassing the view object.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

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

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

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 );