quesa-develop — Mailing list for Quesa development

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

[Lane R. <la...@if...>]

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)

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________ 
If progress means moving forward, what does congress mean?

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

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

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)

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

[Lane R. <la...@if...>]

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)

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
If we aren't supposed to eat animals, why are they made with meat?

Re: High-res printing

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

On Jul 29, 2005, at 6:57 AM, Edward K. Chew wrote:

> So I have been running various tests on this printing algorithm I  
> wrote and noticed that if I push things too far, I begin to see  
> black bands occupy the right or bottom edges of the printout.  For  
> example, an 11 x 17 page in landscape mode at 300 dpi is too far.   
> I am not certain whether I am hitting some sort of limit in the 3D  
> rendering or the printer driver, but I suspect the former.  Of  
> course, there could also be a bug in my code...  :-)
>
> Assuming it's the rendering, would it help if I switched to a  
> divide-and-conquer strategy, rendering it in pieces through careful  
> manipulation of the viewport?  Am I likely to get noticeable  
> artifacts along the borders of each piece?  If this is the way to  
> go, does anyone know how large each pieces can safely be?  8.5 x 11  
> @ 300 dpi seems to print fine.  Assuming a half-inch margin all  
> around, that works out to 2250 x 3000 pixels or thereabouts.  My  
> guess is that the limit lies somewhere in the range of 3000 to 5000  
> pixels.

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.

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

Re: High-res printing

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

Yes, there is a limit in OpenGL ( around 2000 pixels wide ), and  
there is a limit in QuickDraw ( around 32000 pixels wide ).

The limit you are hitting looks like the OpenGL limit, in testing we  
found that using a 23" LCD, then a 17" Monitor you can see the limit  
in the Interactive renderer window but more common in printing.

You can get around this with "banding", breaking up the image into  
different OpenGL windows and then combining them into a QuickDraw  
window or equivalent.

Hope this helps.

Peter Michelsen.

On 29 Jul 2005, at 14:57, Edward K. Chew wrote:

> So I have been running various tests on this printing algorithm I  
> wrote and noticed that if I push things too far, I begin to see  
> black bands occupy the right or bottom edges of the printout.  For  
> example, an 11 x 17 page in landscape mode at 300 dpi is too far.   
> I am not certain whether I am hitting some sort of limit in the 3D  
> rendering or the printer driver, but I suspect the former.  Of  
> course, there could also be a bug in my code...  :-)
>
> Assuming it's the rendering, would it help if I switched to a  
> divide-and-conquer strategy, rendering it in pieces through careful  
> manipulation of the viewport?  Am I likely to get noticeable  
> artifacts along the borders of each piece?  If this is the way to  
> go, does anyone know how large each pieces can safely be?  8.5 x 11  
> @ 300 dpi seems to print fine.  Assuming a half-inch margin all  
> around, that works out to 2250 x 3000 pixels or thereabouts.  My  
> guess is that the limit lies somewhere in the range of 3000 to 5000  
> pixels.
>
> -Ted
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO  
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

High-res printing

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

So I have been running various tests on this printing algorithm I  
wrote and noticed that if I push things too far, I begin to see black  
bands occupy the right or bottom edges of the printout.  For example,  
an 11 x 17 page in landscape mode at 300 dpi is too far.  I am not  
certain whether I am hitting some sort of limit in the 3D rendering  
or the printer driver, but I suspect the former.  Of course, there  
could also be a bug in my code...  :-)

Assuming it's the rendering, would it help if I switched to a divide- 
and-conquer strategy, rendering it in pieces through careful  
manipulation of the viewport?  Am I likely to get noticeable  
artifacts along the borders of each piece?  If this is the way to go,  
does anyone know how large each pieces can safely be?  8.5 x 11 @ 300  
dpi seems to print fine.  Assuming a half-inch margin all around,  
that works out to 2250 x 3000 pixels or thereabouts.  My guess is  
that the limit lies somewhere in the range of 3000 to 5000 pixels.

-Ted

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

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

The reason I added this code in the first place was to correct  
tearing that was occurring while rotating the camera.  However, in  
the event that it does adversely affect someone's use of Quesa,  
perhaps it can be added as a field in the TQ3MacDrawContextData  
structure with its default set to zero.  If someone overrides the  
default, then retrace synchronization could be enabled as I described.

On 29-Jul-2005, at 1:58 AM, James W. Walker wrote:

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

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

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

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?

[ quesa-Bugs-907872 ] Textured geometry without UVs rendered as white

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

Bugs item #907872, was opened at 2004-03-01 13:31
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907872&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: Textured geometry without UVs rendered as white

Initial Comment:
Unlike QD3D, geometry which is submitted without UVs while a 
texture is active will be rendered as white. On QD3D, it will be 
rendered as if no texture was active.

This was broken deliberately in 1.6d18 - we could optionally post a 
notice if we detect this case, as I have assumed it's not terribly 
common (and the QD3D behaviour is probably a side-effect rather 
than deliberate)

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-07-28 22:41

Message:
Logged In: YES 
user_id=433183

I believe this is now fixed in CVS.

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

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

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

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

I just noticed that Quesa on the Mac is doing its double buffer  
swapping without synchronizing with the vertical retrace of the  
monitor.  Adding the following code just before the end of  
gldrawcontext_mac_new() seems to correct the problem:

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

Re: Can Quesa change a TriMesh on its own?

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

Roger Holmes <rog...@mi...> wrote:

>Could we use the existing caching code but extend it a bit to create
>a cleaned up version of any TriMesh which we find is dodgy,  and use
>that instead?

I briefly looked into that, but the cacheNew method is not just used 
for caching.  It also serves to decompose a geometry that is not 
handled directly by a particular renderer.  Hence, TriMesh already 
has a cacheNew method that decomposes a TriMesh into individual 
triangles.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Can Quesa change a TriMesh on its own?

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

On 28 Jul, 2005, at 17:16, James W. Walker wrote:

> Suppose you provide TriMeshes to Quesa either by loading 3DMF files or 
> by calling Q3TriMesh_New.  Would you find it troublesome if Quesa 
> modified the data?  There are open bugs involving TriMeshes without 
> vertex normals or with per-face color which could be fixed by 
> modifying the data, duplicating vertices in some cases.  It also might 
> be reasonable to remove isolated vertices and degenerate triangles.

Could we use the existing caching code but extend it a bit to create a 
cleaned up version of any TriMesh which we find is dodgy,  and use that 
instead?


We could also provide a routine to clean up a TriMesh.

We could also have two extra flags in a TriMesh to say if it has been 
tested and if so whether it was clean or not.

Roger.

Re: Can Quesa change a TriMesh on its own?

[Kevin M. <mat...@ar...>]

On Thu, 28 Jul 2005 09:16:39 -0700, James W. Walker wrote:
> Suppose you provide TriMeshes to Quesa either by loading 3DMF files 
> or by calling Q3TriMesh_New.  Would you find it troublesome if Quesa 
> modified the data?  There are open bugs involving TriMeshes without 
> vertex normals or with per-face color which could be fixed by 
> modifying the data, duplicating vertices in some cases.  It also 
> might be reasonable to remove isolated vertices and degenerate 
> triangles.

This sounds like a tricky area.  As I recall, in DesignWorkshop we exploit the particularities of trimesh data structures in detail.  We were driven to push this area because major performance differences forced the use of trimeshes when meshes would conceptually have been much more appropriate.  

But we should check the details to be sure.

Thanks!

Kevin

Can Quesa change a TriMesh on its own?

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

Suppose you provide TriMeshes to Quesa either by loading 3DMF files  
or by calling Q3TriMesh_New.  Would you find it troublesome if Quesa  
modified the data?  There are open bugs involving TriMeshes without  
vertex normals or with per-face color which could be fixed by  
modifying the data, duplicating vertices in some cases.  It also  
might be reasonable to remove isolated vertices and degenerate  
triangles.

Re: Memory leak within OpenGL with Tiger

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

On Jul 28, 2005, at 7:42 AM, Roger Holmes wrote:

> There appears to be a memory leak in OpenGL (not in Quesa in this  
> instance).
> It does not go wrong with the Microspot Renderer even under Tiger,  
> only the
> interactive renderer. Is anyone else having a similar problem? Any  
> thoughts
> on the cause and how to fix it?

I haven't seen such a problem.  You might try running under OpenGL  
Profiler, which for instance can show you what's in texture memory.

Memory leak within OpenGL with Tiger

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

We are getting crashes when creating a QuickTime movie of an animated 
Quesa
image when rendering with the interactive renderer under Tiger. We do 
not see
the same problem under Panther. The problem is that we are using up all 
the
virtual memory, i.e. it crashes when virtual memory gets to about 1.9GB.
There appears to be a memory leak in OpenGL (not in Quesa in this 
instance).
It does not go wrong with the Microspot Renderer even under Tiger, only 
the
interactive renderer. Is anyone else having a similar problem? Any 
thoughts
on the cause and how to fix it?

Roger Holmes.

[ quesa-Bugs-907855 ] TriMesh shading wrong when no vertex UVs 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: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: TriMesh shading wrong when no vertex UVs 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

[ quesa-Bugs-922742 ] Alpha textures do not work properly with fog or specularity

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

Bugs item #922742, was opened at 2004-03-24 13:32
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922742&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: Frank Condello (pox)
>Assigned to: James W. Walker (jwwalker)
Summary: Alpha textures do not work properly with fog or specularity

Initial Comment:
In order to mimic QD3D's pre-multiplied alpha behaviour, Quesa 
resorts to using an additive blend mode for textures with alpha bits 
(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). This works for the most 
part, but results in vertex effects like fog and specular highlights 
being blended additively over entire polygons rather than clipping 
to the alpha channel, as they would when using a blend mode like 
(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). QD3D does not 
display these artifacts, so binary compatibility is compromised in 
these cases.

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-07-25 23:04

Message:
Logged In: YES 
user_id=433183

The last comment by the submitter seems to indicate that the
fix for bug #973022 may be considered to fix this.  Unless
clarification is forthcoming, such as a good test case, I will
consider this fixed.

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

Comment By: Frank Condello (pox)
Date: 2004-06-15 17:05

Message:
Logged In: YES 
user_id=171509

This problem has changed recently due to changes in the transparent 
surface renderer. In the current source, fog is not rendered at all on 
transparent surfaces.

Contrary to my initial report, it appears that specular highlights are 
blended over entire polygons in QD3D as well (as opposed to clipping to 
alpha channels) so the specular-on-transparency behavior would be fine, 
once bug #973022 is addressed. An option to attenuate highlights based 
on the alpha channel would be a nice addition in the future however.

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

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

Message:
Logged In: YES 
user_id=439944

Can you attach a model demonstrating the problem?

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

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

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

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

Bugs item #967770, was opened at 2004-06-06 14:01
Message generated for change (Comment added) made by jwwalker
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: Pending
>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: James W. Walker (jwwalker)
Date: 2005-07-24 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

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

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

Bugs item #973022, was opened at 2004-06-15 00:03
Message generated for change (Comment added) made by jwwalker
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: Pending
>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: James W. Walker (jwwalker)
Date: 2005-07-24 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

changes to transparent rendering

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

I just committed some changes in an attempt to fix bug 967770 (no fog  
on transparent objects) and 973022 (Specular highlights in  
transparent pass aren't sorted).  Let me know if I broke anything.

Re: any simple examples of rendering to a pixel buffer on Windows?

[Daniele C. <dca...@in...>]

I render a Quesa scena into a Windows bitmap with arbitrary dimension.
I  create a PixmapDrawContext and I use Q3PixmapDrawContext_GetPixmap for 
create the bitmap.

Daniele


At 08.55 21/07/2005 -0600, you wrote:
>We've got a function that renders a Quesa scene into a picture, on both 
>Mac and Windows.  On the Mac this works fine, but on Windows it hangs or 
>crashes for all but the smallest image sizes.  (Yes, that sounds like 
>we're not allocating a big enough pixel buffer, but two of us have gone 
>over the code carefully, and even tried allocating 10 times as much space 
>as we should need, and it still crashes.)
>
>The hang or crash seems to be happening inside Q3View_EndRendering, but we 
>haven't traced it down inside Quesa (my Windows debugging skills are limited).
>
>So, the next step is probably to try to reproduce this in a simpler 
>app.  Do any of the examples in the SDK exercise this functionality? I 
>looked in Geom Test and didn't see it there, and none of the others sound 
>promising, but perhaps I'm missing something.
>
>Barring that, would anyone happen to have a simple example of rendering to 
>a pixel buffer lying around?
>
>Thanks,
>- Joe
>
>--
>,------------------------------------------------------------------.
>|    Joseph J. Strout         Check out the Mac Web Directory:     |
>|    jo...@st...           http://www.macwebdir.com/            |
>`------------------------------------------------------------------'
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

any simple examples of rendering to a pixel buffer on Windows?

[Joseph J. S. <jo...@st...>]

We've got a function that renders a Quesa scene into a picture, on 
both Mac and Windows.  On the Mac this works fine, but on Windows it 
hangs or crashes for all but the smallest image sizes.  (Yes, that 
sounds like we're not allocating a big enough pixel buffer, but two 
of us have gone over the code carefully, and even tried allocating 10 
times as much space as we should need, and it still crashes.)

The hang or crash seems to be happening inside Q3View_EndRendering, 
but we haven't traced it down inside Quesa (my Windows debugging 
skills are limited).

So, the next step is probably to try to reproduce this in a simpler 
app.  Do any of the examples in the SDK exercise this functionality? 
I looked in Geom Test and didn't see it there, and none of the others 
sound promising, but perhaps I'm missing something.

Barring that, would anyone happen to have a simple example of 
rendering to a pixel buffer lying around?

Thanks,
- Joe

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: Switching draw contexts

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

On Jul 19, 2005, at 7:31 PM, Edward K. Chew wrote:

> I just added some printing support taking what I believed to be the  
> path of least resistance.  I use the same view object for printing  
> as I do for window updates.  Maybe that's a bad idea.

Yes, it's safest have have a one-to-one-to-one correspondence between  
views, draw contexts, and renderers.

Switching draw contexts

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

Maybe someone can answer this one for me?

I just added some printing support taking what I believed to be the  
path of least resistance.  I use the same view object for printing as  
I do for window updates.  Maybe that's a bad idea.  I temporarily  
replace the Mac draw context with a pixmap context and fiddle with  
some of the camera settings (to take into account the dimensions of  
the printed page).  Then I run through my rendering loop and shoot  
the off-screen image off to the printer.

Much to my delight, the printing itself actually worked perfectly on  
the first try.  The only strange symptom is that the window blanks  
out the moment I call Q3View_StartRendering.  I would have thought  
that since I am no longer targeting the window, nothing much would  
happen to it, so this sort of caught me by surprise.

I guess I'll just tell it to redraw itself, but I'm curious about  
what is causing this...

-Ted