quesa-develop — Mailing list for Quesa development

Re: first draft of release notes for Quesa 1.7.1

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

Il giorno 21/apr/06, alle ore 06:25, James W. Walker ha scritto:

> I skimmed over the CVS commits since the 1.7 release, and here were  
> the highlights I saw... did I miss or misstate anything?
>
> * Updated for Intel Mac support
> * Updated for 64-bit cleanness on Linux
> * Implemented writing of view hint objects and improved reading of  
> view hints
> * Added Cartoon renderer
> * Added VRML file format reader plug-in
> * New functions Q3TriMesh_Optimize, Q3TriMesh_OptimizeData,  
> Q3Int64_Add, Q3Int64_Subtract, Q3Int64_Uns32_Add,  
> Q3Int64_Uns32_Subtract, Q3Memory_GetStatistics.
> * Made plug-in loading more reliable on Windows
> * Improved texture caching in the interactive renderer, so that if  
> multiple texture shaders use the same texture object, only one copy  
> goes into OpenGL texture memory
> * Miscellaneous bugs fixed
>


I propose to call it 1.8 better than 1.7.1


Pax et Bonum

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

first draft of release notes for Quesa 1.7.1

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

I skimmed over the CVS commits since the 1.7 release, and here were  
the highlights I saw... did I miss or misstate anything?

* Updated for Intel Mac support
* Updated for 64-bit cleanness on Linux
* Implemented writing of view hint objects and improved reading of  
view hints
* Added Cartoon renderer
* Added VRML file format reader plug-in
* New functions Q3TriMesh_Optimize, Q3TriMesh_OptimizeData,  
Q3Int64_Add, Q3Int64_Subtract, Q3Int64_Uns32_Add,  
Q3Int64_Uns32_Subtract, Q3Memory_GetStatistics.
* Made plug-in loading more reliable on Windows
* Improved texture caching in the interactive renderer, so that if  
multiple texture shaders use the same texture object, only one copy  
goes into OpenGL texture memory
* Miscellaneous bugs fixed

Re: Quesa on Intel Macs!

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

Il giorno 19/apr/06, alle ore 19:57, James W. Walker ha scritto:

> That's not a bad idea.  We could add universal binary versions of  
> Quesa.framework and the VRML Reader.

and 64 bit cleanness in linux,

Pax et Bonum

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

Re: Quesa on Intel Macs!

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

>What about doing a reference release?

That's not a bad idea.  We could add universal binary versions of 
Quesa.framework and the VRML Reader.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa on Intel Macs!

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

Il giorno 19/apr/06, alle ore 01:18, James W. Walker ha scritto:

> Due to work in progress at SourceForge, these changes will probably  
> not be available by anonymous CVS for another couple of weeks.  
> However, you could get the diffs from the quesa-cvs mailing list.

What about doing a reference release?



Pax et Bonum

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

Re: Quesa on Intel Macs!

[Roch M. C. <ro...@ro...>]

Thanks James!

You are doing better than Apple! We found a similar problem in  
copydeepmask which they have fixed internally, but won't commit to  
releasing until they feel like it!

Sean (they guy who has been looking into this) will be back in 2  
weeks so we can test it then.

Cheers,

Roch
-- 
Roch M. Comeau, Ph.D.
Rogue Research Inc.
4398 St-Laurent, Suite 206
Montreal, QC, Canada, H2W 1Z5
Phone:(514)284-3888
Fax: (514)284-6750
ro...@ro...
www.rogue-research.com


On 18-Apr-06, at 7:18 PM, James W. Walker wrote:

> I now have an Intel Mini on my desk, and I have committed a few  
> changes to address some issues brought up in this thread:
>
> * Quesa.h: Define QUESA_HOST_IS_BIG_ENDIAN correctly on Intel Macs.
>
> * GLDrawContext.c: When creating a Mac offscreen draw context,  
> assert that the byte order is native.
>
> * QutTexture.c: Pass kNativeEndianPixMap flag to NewGWorld.
>
> * Background Test.c: Use native endianness when setting up the  
> pixmap draw context.
>
> Due to work in progress at SourceForge, these changes will probably  
> not be available by anonymous CVS for another couple of weeks.  
> However, you could get the diffs from the quesa-cvs mailing list.
> -- 
>   James W. Walker, Innoventive Software LLC
>   <http://www.frameforge3d.com/>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Quesa on Intel Macs!

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

I now have an Intel Mini on my desk, and I have committed a few 
changes to address some issues brought up in this thread:

* Quesa.h: Define QUESA_HOST_IS_BIG_ENDIAN correctly on Intel Macs.

* GLDrawContext.c: When creating a Mac offscreen draw context, assert 
that the byte order is native.

* QutTexture.c: Pass kNativeEndianPixMap flag to NewGWorld.

* Background Test.c: Use native endianness when setting up the pixmap 
draw context.

Due to work in progress at SourceForge, these changes will probably 
not be available by anonymous CVS for another couple of weeks. 
However, you could get the diffs from the quesa-cvs mailing list.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

change in texture caching

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

I just committed a change to the way Quesa caches textures.   
Previously, if one texture object was used in multiple texture  
shaders, you got multiple copies of the texture in OpenGL texture  
memory.  Now you just get one.  Let me know if any problems arise.

SourceForge has a partial outage concerning anonymous CVS, so you may  
not be able to get these changes by anonymous CVS right now.

Re: Another endian problem - textures

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

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

>I am now working on dropping textures onto 3D objects using Cocoa on 
>an MacBook Pro (Intel).
>
>The easiest way to get the texture from Cocoa is as an NSImage and 
>then get Cocoa to convert it
>to an NSBitmapImageRep. This gives me a 24 bit per pixel image with 
>no pad bytes. I create a
>texture from it and then have some conditional code which sets the 
>texture to little endian byte
>order on Intel and big endian byte order on PowerPC. When I use the 
>interactive renderer to draw
>it (onto a cube), the red and blue components are swapped.

When you say "sets the texture to little endian..." are you referring 
to setting the byte order field in the TQ3StoragePixmap structure? 
Are you sure that the bytes actually are in the order you are 
declaring in the byteOrder field?

>In IRTexture.h there is a routine called 
>IRRenderer_Texture_ConvertDepthAndFlip
>It checks the endian byte order. For little endian it swaps, and for 
>big endian it does not.
>But it never looks at the pixel as a long, always through a 
>TQ3Uns8*. I do not understand
>why it ever needs to swap the bytes.

Because the source data could be in either order.  Even if Intel Macs 
did not exist, you could still be loading a 3DMF file containing 
little-endian textures on a PowerPC Mac.

There's a comment in the code that addresses this: "We will fetch one 
byte at a time from the image, so the native endian-ness doesn't 
matter, only the endian-ness of the image as specified by 
srcByteOrder."
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Another endian problem - textures

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

I am now working on dropping textures onto 3D objects using Cocoa on  
an MacBook Pro (Intel).

The easiest way to get the texture from Cocoa is as an NSImage and  
then get Cocoa to convert it
to an NSBitmapImageRep. This gives me a 24 bit per pixel image with  
no pad bytes. I create a
texture from it and then have some conditional code which sets the  
texture to little endian byte
order on Intel and big endian byte order on PowerPC. When I use the  
interactive renderer to draw
it (onto a cube), the red and blue components are swapped.

In IRTexture.h there is a routine called  
IRRenderer_Texture_ConvertDepthAndFlip
It checks the endian byte order. For little endian it swaps, and for  
big endian it does not.
But it never looks at the pixel as a long, always through a TQ3Uns8*.  
I do not understand
why it ever needs to swap the bytes. There is of course an issue with  
where the Alpha
component is when using 32 bit data, but that just happens to be  
resolved in the same
piece of code.

If I lie and say it is endian big then it works on Intel. Strange.

Roger.

Re: Quesa on Intel Macs!

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

"Sean McBride" <se...@ro...> wrote:

>>I'd say it's a mismatch between the way QD does things and the way
>>OGL does things.  The fact that Quesa ignores the endian information
>>given to it seems like a bug.
>
>OK, is it something you can fix? :)

Possibly, but until I get my hands on an Intel Mac, I won't have much 
motivation.

>I'd like to try adding kNativeEndianPixMap in the 'Background Test' but
>I don't see any NewGWorld calls at all.

It's in QutTexture_CreateGWorldFromFile in QutTexture.c.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa on Intel Macs!

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

On 2006-03-17 09:14, James W. Walker said:

>What I neglected to mention is that I received a clarification off- 
>list from an Apple OpenGL engineer.

Ah. :)

>I'd say it's a mismatch between the way QD does things and the way  
>OGL does things.  The fact that Quesa ignores the endian information  
>given to it seems like a bug.

OK, is it something you can fix=3F :)

>> Should we create all our GWorlds with the kNativeEndianPixMap
>> flag=3F  Would that fix it=3F
>
>I would guess that would work.  I wasn't aware of the  
>kNativeEndianPixMap flag.

It's here:

<http://developer.apple.com/documentation/MacOSX/Conceptual/
universal=5Fbinary/universal=5Fbinary=5Ftips/chapter=5F5=5Fsection=5F15.htm=
l>

I'd like to try adding kNativeEndianPixMap in the 'Background Test' but
I don't see any NewGWorld calls at all.  So searched all of Quesa and
added the flag to every NewGWorld call.  I'm not sure if that's
something you'd want to make permanent, but it did fix the problem in
'Background Test'.  I'll have to try with our real app next... 

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

Re: Quesa on Intel Macs!

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

On Mar 17, 2006, at 7:33 AM, Sean McBride wrote:

> On 2006-03-16 10:30, James W. Walker said:
>
>> I asked about this on the Mac OpenGL mailing list, and it is an
>> endian issue.  As you say, NewGWorld is treating the bytes as xRGB
>> order, whereas OpenGL on Intel uses BGRA order.
>
> I'm on the ogl mailing list, though don't read it generally, and I  
> took
> a look at the thread you started.
>
> But I'm not sure of the conclusion.

What I neglected to mention is that I received a clarification off- 
list from an Apple OpenGL engineer.

>   Is there a Quesa bug?  An OGL bug?
> A QD bug?  Or it is just something Quesa clients need to do  
> differently
> on intel?

I'd say it's a mismatch between the way QD does things and the way  
OGL does things.  The fact that Quesa ignores the endian information  
given to it seems like a bug.

> Should we create all our GWorlds with the kNativeEndianPixMap
> flag?  Would that fix it?

I would guess that would work.  I wasn't aware of the  
kNativeEndianPixMap flag.

Re: Quesa on Intel Macs!

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

On 2006-03-16 10:30, James W. Walker said:

>I asked about this on the Mac OpenGL mailing list, and it is an 
>endian issue.  As you say, NewGWorld is treating the bytes as xRGB 
>order, whereas OpenGL on Intel uses BGRA order.

I'm on the ogl mailing list, though don't read it generally, and I took
a look at the thread you started.

But I'm not sure of the conclusion.  Is there a Quesa bug=3F  An OGL bug=3F 
A QD bug=3F  Or it is just something Quesa clients need to do differently
on intel=3F  Should we create all our GWorlds with the kNativeEndianPixMap
flag=3F  Would that fix it=3F

>Background Test could be fixed without changing Quesa by flipping the 
>bytes of each pixel before and after each render.  Presumably this 
>could be done inside Quesa instead.  The structure that defines a 
>pixmap draw context has a byte order field, which we don't seem to 
>use at present.

I think that's a good idea if kNativeEndianPixMap won't work.  It might
make things a little slower, but offscreen rendering is slow anyway, so
whatever.

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

Re: Quesa on Intel Macs!

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

"Sean McBride" <se...@ro...> wrote:

>In any case, I have reproed the same bug that I see in our app!  On a
>PPC Mac or in Rosetta I see a triangle with R G B corners.  On Intel I
>see a blue triangle.  See attached picture (only 10kb, I hope the list
>allows it).
>
>So this is probably a Quesa bug.
>
>One idea I have is this sentence here:
>
><http://developer.apple.com/documentation/MacOSX/Conceptual/
>universal_binary/universal_binary_tips/chapter_5_section_15.html>
>
>"By default, NewGWorld always creates big-endian pixel formats
>(k16BE555PixelFormat or k32ARGBPixelFormat), regardless of the endian
>format of the system."
>
>Maybe Quesa is incorrectly assuming that its gworlds have the same
>endianess as the host system?
>
>But that's just a guess...

I asked about this on the Mac OpenGL mailing list, and it is an 
endian issue.  As you say, NewGWorld is treating the bytes as xRGB 
order, whereas OpenGL on Intel uses BGRA order.

Background Test could be fixed without changing Quesa by flipping the 
bytes of each pixel before and after each render.  Presumably this 
could be done inside Quesa instead.  The structure that defines a 
pixmap draw context has a byte order field, which we don't seem to 
use at present.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

seeking contract developer for Quesa contributions

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

Dear 'Dillas,

Currently at Artifice, Inc. we're seeking a skilled software developer who knows Quesa well and has some available time.  We'd like to pay for work on some specific refinements to Quesa to complete as-yet unfinished features required for full compatibility with DesignWorkshop.  Our intention is that the output of this work would be a standard open source contribution to the project, unrestricted except as by the Quesa license itself.  Subsequent work might encompass feature additions in line with existing project directions.

If you have interest in this, plus skills, knowledge, and time, and are willing to exercise your talents at a reasonable rate, please let me know at "eng...@ar...".

Best wishes,

Kevin Matthews
Artifice, Inc.




  http://www.ArchitectureWeek.com . design, building, digital media
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
    Artifice, Inc.                    ...the way of architecture
    http://www.greatbuildings.com
    http://www.designcommunity.com
    541.345.7421 vox . 541.345.7438 fax . 800.203.8324 US toll free
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+

  Artifice.  "1534. [a. F., ad. L. artificium]  1. The action of an
  artificer, construction, workmanship.  2. The product of art.  3.
  Mode or style of workmanship.  4. Constructive skill.  5. Human
  skill.  6. Skill in expedients.  7. An ingenious expedient." 
                  -- The Oxford Universal Dictionary, Third Edition 

Re: Quesa on Intel Macs!

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

On 2006-03-10 13:46, James W. Walker said:

>That's what I changed.  Possibly there could be a delay.  Anyway, the 
>fix is just to change
>
>Qut=5FCreateView(appConfigureView);
>
>to
>
>Qut=5FCreateView( NULL, appConfigureView );

OK cool... that's what I ended up doing, hoping a NULL would not burn me. :)

I also created a Xcode 2.2 version of the project by copying the 'Geom
Test' one.  Would you like it=3F

In any case, I have reproed the same bug that I see in our app!  On a
PPC Mac or in Rosetta I see a triangle with R G B corners.  On Intel I
see a blue triangle.  See attached picture (only 10kb, I hope the list
allows it).

So this is probably a Quesa bug.

One idea I have is this sentence here:

<http://developer.apple.com/documentation/MacOSX/Conceptual/
universal=5Fbinary/universal=5Fbinary=5Ftips/chapter=5F5=5Fsection=5F15.htm=
l>

"By default, NewGWorld always creates big-endian pixel formats
(k16BE555PixelFormat or k32ARGBPixelFormat), regardless of the endian
format of the system."

Maybe Quesa is incorrectly assuming that its gworlds have the same
endianess as the host system=3F

But that's just a guess...

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

Re: Quesa on Intel Macs!

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

"Sean McBride" <se...@ro...> wrote:

>Though I have checked out Quesa and compared it to my previous version
>and don't see any changes in the example at least not in any text
>files.  What did you change?
>
>In any case, I got the old project builder project to mostly compile
>after changing the framework search path, but it complains:
>
>../Background Test.c:348: error: too few arguments to function
>'Qut_CreateView'
>
>Is that what you changed?  Maybe sourceforge's cvs servers have a delay?

That's what I changed.  Possibly there could be a delay.  Anyway, the 
fix is just to change

Qut_CreateView(appConfigureView);

to

Qut_CreateView( NULL, appConfigureView );
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa on Intel Macs!

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

On 2006-03-10 19:58, Roger Holmes said:

>Do you mean an Intel Mac under Rosetta or with a native app,
>also with a plug-in renderer, the interactive renderer or the
>cartoon renderer=3F

Everything is fine in Rosetta, it's when the app is native that we have
problems.  We use the regular interactive renderer.  There are also no
problems unless we render offscreen, onscreen all is well.  It could be
our bug, which is why I want to try a sample app.

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

Re: Quesa on Intel Macs!

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

On 2006-03-10 11:44, James W. Walker said:

>It looks like Background Test does.  I just committed a small update 
>to make it compile.

Thanks James!

Though I have checked out Quesa and compared it to my previous version
and don't see any changes in the example at least not in any text
files.  What did you change=3F

In any case, I got the old project builder project to mostly compile
after changing the framework search path, but it complains:

../Background Test.c:348: error: too few arguments to function
'Qut=5FCreateView'

Is that what you changed=3F  Maybe sourceforge's cvs servers have a delay=3F

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

Re: Quesa on Intel Macs!

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

Hi Sean,

Do you mean an Intel Mac under Rosetta or with a native app,
also with a plug-in renderer, the interactive renderer or the
cartoon renderer?

There was a problem with our plugin renderer on Intel Macs, as
it relied on a test for being on Windows to decide which order in
the word the colour components had to be. i.e. our code said
this is a Macintosh, therefore we are big endian, wrong!

I have not had any problems with other renderers as yet.

Roger.


On 10 Mar, 2006, at 19:27, Sean McBride wrote:

> Hi all,
>
> Has anyone tried offscreen rendering (to a gworld) with Quesa on Intel
> Macs?  We seem to be getting incorrect colours.
>
> Is there a Quesa example out there that does offscreen rendering so I
> can rule out our app being buggy?  I've looked at 'Geom Test' but it
> doesn't seem to.
>
> Thanks!
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr=E9al, Qu=E9bec, Canada
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642=

> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Quesa on Intel Macs!

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

"Sean McBride" <se...@ro...> wrote:

>Has anyone tried offscreen rendering (to a gworld) with Quesa on Intel
>Macs?  We seem to be getting incorrect colours.

I don't have an Intel Mac yet.

>Is there a Quesa example out there that does offscreen rendering so I
>can rule out our app being buggy?  I've looked at 'Geom Test' but it
>doesn't seem to.

It looks like Background Test does.  I just committed a small update 
to make it compile.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa on Intel Macs!

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

Hi all,

Has anyone tried offscreen rendering (to a gworld) with Quesa on Intel
Macs=3F  We seem to be getting incorrect colours.

Is there a Quesa example out there that does offscreen rendering so I
can rule out our app being buggy=3F  I've looked at 'Geom Test' but it
doesn't seem to.

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

Re: Background Test

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

Daniele Cavallini <dca...@in...> wrote:

>Is "Background Test" an examples  for display a quesa render with a 
>image in Background?

That appears to be true.

>It is possible compile it under windows?

No, it uses Mac-specific techniques.  Also, it uses offscreen 
rendering, and the software renderer on Windows is pretty bad, so you 
wouldn't want to do it that way.

To render with an image in the background, the key ideas would be:

1. Use Q3DrawContext_SetClearImageMethod with the value kQ3ClearMethodNone.

2. At the beginning of the rendering loop, draw the background.  I've 
never done this, but one approach might be to call Q3Push_Submit, 
Q3RasterizeCameraTransform_Submit, submit a textured polygon, 
Q3Pop_Submit.

The Geom Test sample has an example of using a rasterize transform. 
In that example, the rasterized polygon appears in front of the 
normal 3D content.  However, if you remove the transparency 
attribute, and change the z coordinates of the polygon vertices to 
0.999f, then the polygon will be behind.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Background Test

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

Is "Background Test" an examples  for display a quesa render with a 
image in Background?
It is possible compile it under windows?