quesa-develop — Mailing list for Quesa development

First stage of Quesa changes now complete

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

I have now completed the change to use a hierarchy of C++ classes so
that the instance data of each Quesa object is allocated as a single 
block
of memory. In CodeWarrior the class hierarchy window now shows the
full tree of Quesa'a built in classes.

I seek your input on what I have done and in particular could the 
versions
for other platforms and even the Macho target for Mac be tested please.

I suspect the problem with the 'Dump' code has sorted itself out, but 
could
this be checked too please.



For my remaining 'slack' time I would like your opinions on the 
possible use of C++ memory
allocation and construction facilities. On Macintosh I think that using 
statements like:

  E3ClassInfo* theInfo = new E3ClassInfo ;

E3ClassInfo* theClass = (E3ClassInfo*) Q3Memory_AllocateClear ( sizeof 
( E3ClassInfo ) ) ;

are (except for the zeroing of the block of memory) equivalent as they 
both end up calling
malloc to actually reserve the memory. Am I correct, and what is the 
situation on the other
platforms?



The other thing I would like to bring forward from the faster Microspot 
version of Quesa is
the elimination of the hash table search for methods each time they are 
used.

I had originally hoped to use proper C++ virtual methods as these are 
exactly what Quesa
is doing, but collective wisdom was that this was a bad move. An 
alternative is to replicate the
class tree of the instance data with one which has ClassInfo at its 
root. Then there could
be pointers to the member functions introduced at each level of the 
hierarchy, and these
could be initialised with a call to E3ClassInfo::Find_Method which 
would find the appropriate
method (by calling the meta handler for the class and if necessary each 
of its parents until
it finds a method) in exactly the same way as is done now when a method 
is not found in
the hash table.

Your opinions please so I can get on with one or both of these if they 
are felt desirable.




Roger.

Re: time for a new release?

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

on Sun, Jan 23, 2005 Joseph J. Strout may have said:

>I may need to ship my product with my own custom builds of Quesa, 
>then.  Any suggestions on how I should identify it?  It's after 
>1.6d19, but prior to what will presumably be 1.6d20...  Should I call 
>it 1.6d19b, perhaps?

How about 1.6d20...

>For that matter, if I find that 1.6d19 will work, are there official 
>builds of that available? 
><http://sourceforge.net/project/showfiles.php?group_id=45158> seems 
>to have built SDKs for 1.6d18, but for 1.6d19, it has only source 
>code tarballs.  Theoretically I can build one that comes out exactly 
>the same as anybody else's build, but in reality, that's not always 
>the case.  So, is there an official build somewhere I'm missing, or 
>should I just build my own and bill it as 1.6d19?

...since such a major change should really move the version # up to 1.7
whatever.


My suggestion: the Jan 1, 2005 is 1.6d20, your version is 1.6d21, and a
merge of the two is the official 1.6 release. Bugs and all. (or maybe
have a beta if you want, but make it short and make sure to have a final
1.6 release.)

Then start the current CVS branch as 1.7 and move forward.

Really, I think the project needs to move past the 1.6 roadblock in
versioning, as well as the "development" status; you need beta releases
and final releases and don't need to keep worrying about keeping the
version set at the last QD3D version # ... from the outside it just makes
it seem as if the project has died or is moving too slowly to bother
with. (And maybe 5 people remember why the version # is 1.6 anyway.)

mho of course :)

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
Data, data everywhere . . . and not a thought to to be had.

Re: problems building 1.6d19

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

Il giorno 23/gen/05, alle 21:51, Joseph J. Strout ha scritto:

> Trying to get caught up here, and assuming that the answer to my last 
> question (is there an official build of 1.6d19) is "No," I'm now 
> trying to build one myself.  This has turned out to be much harder 
> than I expected.  The source tarball available on sourceforge doesn't 
> contain any of the platform code, as far as I can tell -- no "Quesa 
> Prefix Carbon Release.h", no project file, and so on.  I've gotten 
> past that by merging in the missing pieces from my older copy (from a 
> while after 1.6d18).  But now I'm stuck on this bit:
>

the 1.6d19 tarball on source forge is a unix release (the original d18 
was broken)

if you want to buils a release I suggest to get a CVS for date Jan,1 
2005 and call the relase 1.6d20

then we have to up the version to 1.7 or so for the first C++ version


Pax et Bonum

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

Re: problems building 1.6d19

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

On Jan 23, 2005, at 12:51 PM, Joseph J. Strout wrote:

> I need to build a Carbon CFM library, and my understanding is that to 
> do that, I need the OpenGL SDK.  I had that on my old machine, but the 
> new one doesn't seem to have it.  Apple claims to have it available 
> here: <http://developer.apple.com/graphicsimaging/download/>, but 
> they've packed it up as a disk image, which of course won't mount on 
> my 10.3.7 machine.  (I also tried mounting it manually with Disk 
> Utility, but that didn't work either.)
>
> So, am I barking up the wrong tree here somehow?  If not, does anyone 
> happen to have a copy of the OpenGL CFM SDK they can share?

I don't know why you say "of course won't mount on my 10.3.7 machine".  
  Why wouldn't a disk image mount?

I've always used the OS 9-compatible OpenGL SDK, 
<ftp://ftp.apple.com/developer/opengl/SDK/OpenGL_SDK_1.2.img.bin>.
--
<http://www.jwwalker.com/>

problems building 1.6d19

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

Trying to get caught up here, and assuming that the answer to my last 
question (is there an official build of 1.6d19) is "No," I'm now 
trying to build one myself.  This has turned out to be much harder 
than I expected.  The source tarball available on sourceforge doesn't 
contain any of the platform code, as far as I can tell -- no "Quesa 
Prefix Carbon Release.h", no project file, and so on.  I've gotten 
past that by merging in the missing pieces from my older copy (from a 
while after 1.6d18).  But now I'm stuck on this bit:

I need to build a Carbon CFM library, and my understanding is that to 
do that, I need the OpenGL SDK.  I had that on my old machine, but 
the new one doesn't seem to have it.  Apple claims to have it 
available here: 
<http://developer.apple.com/graphicsimaging/download/>, but they've 
packed it up as a disk image, which of course won't mount on my 
10.3.7 machine.  (I also tried mounting it manually with Disk 
Utility, but that didn't work either.)

So, am I barking up the wrong tree here somehow?  If not, does anyone 
happen to have a copy of the OpenGL CFM SDK they can share?

Thanks,
- Joe

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

Re: time for a new release?

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

At 3:03 PM -0800 1/20/05, James W. Walker wrote:

>>Any opinions on whether we're in that state now, and if not, what 
>>is it that's gotten worse?
>
>As you would know if you looked at the CVS mailing list, Roger 
>Holmes is in the midst of a wholesale change in Quesa's 
>infrastructure, taking advantage of our recent move to C++.  We 
>should wait until that work is complete and has been tested before 
>making a release.

In retrospect, we should have done a release before starting such 
major changes, but that's moot now.  (I should have done a better job 
of keeping on top of this list, too -- I'll try to do so in the 
future.)

I may need to ship my product with my own custom builds of Quesa, 
then.  Any suggestions on how I should identify it?  It's after 
1.6d19, but prior to what will presumably be 1.6d20...  Should I call 
it 1.6d19b, perhaps?

For that matter, if I find that 1.6d19 will work, are there official 
builds of that available? 
<http://sourceforge.net/project/showfiles.php?group_id=45158> seems 
to have built SDKs for 1.6d18, but for 1.6d19, it has only source 
code tarballs.  Theoretically I can build one that comes out exactly 
the same as anybody else's build, but in reality, that's not always 
the case.  So, is there an official build somewhere I'm missing, or 
should I just build my own and bill it as 1.6d19?

Thanks,
- Joe

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

Re: MS VC++ 6 issues

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

Jose' Cruanyes <cru...@ce...> wrote:

>really I use VC 6.0 only for Quesa (in production I use CW 8.3
>because the cross compiling abilities) but seems to me that is a
>reasonable minimum target, given the huge installed base

I'm not so sure that is a reasonable minimum target, given that we've 
run into several things that were standard C++ as of 1998 but not 
supported by VC++ 6.  If no one that we know of actually needs to use 
VC++ 6 with Quesa, it seems like masochism to me.  Anyone else have 
an opinion?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Workaround for this bug?

[Keith W. <kw...@cs...>]

On Fri, 21 Jan 2005, Frank Condello wrote:

> That won't work because transparent objects are cached when submitted and 
> drawn last, so you're basically disabling fog, drawing nothing, enabling fog, 
> then Quesa draws the sun after the fact.
>
> Come to think of it, I think there's a bug where Quesa doesn't respect fog 
> states on transparent geometry so my recommendation may not work either - may 
> depend on the Quesa version you're using...

ARGH!  :-)  Okay, that's it.  I'm moving on.  This project is big and I 
have lots of other stuff to work on.  I'll figure out how to make the sun 
pretty at some later time.

Thanks for all they help guys.  I wish I were a Quesa guru, but really I 
just hammer on it a bunch.  Thanks again.

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Workaround for this bug?

[Frank C. <dev...@ch...>]

On 21-Jan-05, at 1:35 PM, Keith Wiley wrote:

> On Fri, 21 Jan 2005, Frank Condello wrote:
>
>> First ensure the alpha in your art is not pre-multiplied (likely the 
>> case already) then put the sun shape in a display group under a fog 
>> object with its visibility set to false. This will ensure no fog is 
>> drawn on the sun, which is typically a desired effect on all 
>> celestial bodies. Also place a Lambert shader before the sun geometry 
>> to turn off any potential specular highlights, since they may display 
>> a similar artifact as fog.
>
> I have a question on this approach.  Is there something inherant about 
> the display group that is supposed to make this alpha-with-fog thing 
> work properly, or is that just the way you suggested to make sure the 
> fog is submitted prior to the sun object?

The latter.

> I ask because before trying to group the fog with the sun, I quickly 
> tried submiting a fog turned off just prior to submitting the sun and 
> then submitting the fog turned on again just after the sun...but the 
> alpha-fog error is still present.  Is that what you would have 
> expected?  Is the display group required?

That won't work because transparent objects are cached when submitted 
and drawn last, so you're basically disabling fog, drawing nothing, 
enabling fog, then Quesa draws the sun after the fact.

Come to think of it, I think there's a bug where Quesa doesn't respect 
fog states on transparent geometry so my recommendation may not work 
either - may depend on the Quesa version you're using...

Frank.
------------
<http://developer.chaoticbox.com>

Re: Workaround for this bug?

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

Keith Wiley <kw...@cs...> wrote:

>Q3TriMesh_Submit( &mTriMeshData, view );
>
>Where mTriMeshData is of type TQ3TriMeshData and view is of type
>TQ3ViewObject.  So, that's how I do it too because I didn't know
>there was any other way.  Any rate, I can't figure out how to group
>these things. Are you saying they're not even the right type for
>grouping?  That I need to convert them into TQ3Objects somehow?

Yes.  The function you need is Q3TriMesh_New.

>Would the conversion make the program run faster btw?

Possibly, assuming that a particular trimesh may be submitted more 
than once.  But it's more a matter of convenience and flexibility 
than speed.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Workaround for this bug?

[Keith W. <kw...@cs...>]

>> I ask because before trying to group the fog with the sun, I quickly
>> tried submiting a fog turned off just prior to submitting the sun
>> and then submitting the fog turned on again just after the sun...but
>> the alpha-fog error is still present.  Is that what you would have
>> expected?  Is the display group required?
>
> I would not have expected that.  I don't know what's going on there.

Rats.  That's annoying.  Ah me.

>> My problem with the display group is that I can't create it because
>> I don't have a TQ3Object to add to it.  My sun (and all the objects
>> in my program) are TQ3TriMeshData, not TQ3Object.  It won't compile
>> passing that to Q3Group_AddObject.  Same is true for passing a
>> TQ3FogStyleData to the group.  When I do this, Q3Group_AddObject
>> returns NULL, which is supposed to mean there was an error with
>> creating the group.
>
> You're doing everything in immediate mode?  Is there some reason you don't 
> create a TriMesh object from your TQ3TriMeshData?

I'm not sure what immediate mode is.  I'll look it up in the QD3D manual 
in a minute.  Basically, I'm using Joe's Queeg framework, as I generally 
learn systems by hacking existing code.  So I'm just duplicating Joe's 
approach.  Maybe Queeg was meant to be small and exemplory and isn't 
really fleshed out in the sense you're describing above.  At any rate, 
during the submition loop, Queeg makes calls like this:

Q3TriMesh_Submit( &mTriMeshData, view );

Where mTriMeshData is of type TQ3TriMeshData and view is of type 
TQ3ViewObject.  So, that's how I do it too because I didn't know there was 
any other way.  Any rate, I can't figure out how to group these things. 
Are you saying they're not even the right type for grouping?  That I need 
to convert them into TQ3Objects somehow?

Would the conversion make the program run faster btw?

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Workaround for this bug?

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

Keith Wiley <kw...@cs...> wrote:

>On Fri, 21 Jan 2005, Frank Condello wrote:
>
>>  First ensure the alpha in your art is not pre-multiplied (likely
>>the case already) then put the sun shape in a display group under a
>>fog object with its visibility set to false. This will ensure no
>>fog is drawn on the sun, which is typically a desired effect on all
>>celestial bodies. Also place a Lambert shader before the sun
>>geometry to turn off any potential specular highlights, since they
>>may display a similar artifact as fog.
>
>I have a question on this approach.  Is there something inherant
>about the display group that is supposed to make this alpha-with-fog
>thing work properly, or is that just the way you suggested to make
>sure the fog is submitted prior to the sun object?

A display group restricts the effect of a style.  The idea was to 
turn off fog for the sun, but not for everything.

>I ask because before trying to group the fog with the sun, I quickly
>tried submiting a fog turned off just prior to submitting the sun
>and then submitting the fog turned on again just after the sun...but
>the alpha-fog error is still present.  Is that what you would have
>expected?  Is the display group required?

I would not have expected that.  I don't know what's going on there.

>My problem with the display group is that I can't create it because
>I don't have a TQ3Object to add to it.  My sun (and all the objects
>in my program) are TQ3TriMeshData, not TQ3Object.  It won't compile
>passing that to Q3Group_AddObject.  Same is true for passing a
>TQ3FogStyleData to the group.  When I do this, Q3Group_AddObject
>returns NULL, which is supposed to mean there was an error with
>creating the group.

You're doing everything in immediate mode?  Is there some reason you 
don't create a TriMesh object from your TQ3TriMeshData?

-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Workaround for this bug?

[Keith W. <kw...@cs...>]

On Fri, 21 Jan 2005, Frank Condello wrote:

> First ensure the alpha in your art is not pre-multiplied (likely the case 
> already) then put the sun shape in a display group under a fog object with 
> its visibility set to false. This will ensure no fog is drawn on the sun, 
> which is typically a desired effect on all celestial bodies. Also place a 
> Lambert shader before the sun geometry to turn off any potential specular 
> highlights, since they may display a similar artifact as fog.

I have a question on this approach.  Is there something inherant about the 
display group that is supposed to make this alpha-with-fog thing work 
properly, or is that just the way you suggested to make sure the fog is 
submitted prior to the sun object?

I ask because before trying to group the fog with the sun, I quickly tried 
submiting a fog turned off just prior to submitting the sun and then 
submitting the fog turned on again just after the sun...but the alpha-fog 
error is still present.  Is that what you would have expected?  Is the 
display group required?

My problem with the display group is that I can't create it because I 
don't have a TQ3Object to add to it.  My sun (and all the objects in my 
program) are TQ3TriMeshData, not TQ3Object.  It won't compile passing that 
to Q3Group_AddObject.  Same is true for passing a TQ3FogStyleData to the 
group.  When I do this, Q3Group_AddObject returns NULL, which is supposed 
to mean there was an error with creating the group.

Don't get too hung up my grouping problem is I am correct in my first 
paragraph.  If the alpha-fog problem should be fixed by submitting a 
turned off fog prior to submitting the alpha object, then why isn't that 
working?

Thanks for any help.

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Workaround for this bug?

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

At 12:28 PM -0500 1/21/05, Frank Condello wrote:

>>  The only reason I used a square was to reduce the number of 
>>triangles.  I considered a circle and thought it was "bad desig" to 
>>make shapes with triangles that could be made with transparent 
>>textures instead.
>
>Indeed...

It's not that clear-cut.  My experience is that if you use the 
software renderer, textures (even opaque ones) tend to be slower than 
colored triangles.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Workaround for this bug?

[Frank C. <dev...@ch...>]

On 21-Jan-05, at 12:11 PM, Keith Wiley wrote:

> On Fri, 21 Jan 2005, James W. Walker wrote:
>
>> On Jan 21, 2005, at 12:10 AM, Keith Wiley wrote:
>>
>>> I am trying to use an alpha channel to make a soft sun that fades 
>>> into the background sky.  It works perfectly except at the horizon, 
>>> where the square shape of the plane the sun texture is put on shows 
>>> up as a translucent square.  This problem vanishes if I turn off 
>>> fog.  I am aware of the discussions pointing out that fog does not 
>>> work properly with alpha channeled textures...and I assume you will 
>>> agree that this bug is the problem I am experiencing.  My question 
>>> is, does anyone havea reccomendation for how to work around it?
>>
>> Why not use a disk instead of a square for the sun?
>
> The only reason I used a square was to reduce the number of triangles. 
>  I considered a circle and thought it was "bad desig" to make shapes 
> with triangles that could be made with transparent textures instead.

Indeed...

> I'll try it with a disk...although I would still like the alpha 
> texture to work properly if I want the sun to have a fuzzy edge.

A similar effect can be achieved by using a subdivided disk with 
per-vertex colour/transparency attributes that fade out towards the 
outer edges, but there is a solution for some additive blended 
textures...

First ensure the alpha in your art is not pre-multiplied (likely the 
case already) then put the sun shape in a display group under a fog 
object with its visibility set to false. This will ensure no fog is 
drawn on the sun, which is typically a desired effect on all celestial 
bodies. Also place a Lambert shader before the sun geometry to turn off 
any potential specular highlights, since they may display a similar 
artifact as fog.

HTH!
Frank.
------------
<http://developer.chaoticbox.com>

Re: Workaround for this bug?

[Keith W. <kw...@cs...>]

On Fri, 21 Jan 2005, James W. Walker wrote:

> In the Geom Test example, choose the cone model.  You'll see transparency 
> that is done with transparency color rather than alpha textures.  If you then 
> select Toggle Texture, you will see how an opaque texture combines with 
> transparency color.

It's not working.  Without textures, the sides of the cone are partially 
transparent and I can see the bottom through the cone, but with textures 
the cone is opaque on the sides.  I have played with the code a little bit 
and I can't figure out how to get the texture to exhibit transparency. 
Should it be doing it with the default code?

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Workaround for this bug?

[Keith W. <kw...@cs...>]

On Fri, 21 Jan 2005, James W. Walker wrote:

> On Jan 21, 2005, at 12:10 AM, Keith Wiley wrote:
>
>> I am trying to use an alpha channel to make a soft sun that fades into the 
>> background sky.  It works perfectly except at the horizon, where the 
>> square shape of the plane the sun texture is put on shows up as a 
>> translucent square.  This problem vanishes if I turn off fog.  I am aware 
>> of the discussions pointing out that fog does not work properly with alpha 
>> channeled textures...and I assume you will agree that this bug is the 
>> problem I am experiencing.  My question is, does anyone havea 
>> reccomendation for how to work around it?
>
> Why not use a disk instead of a square for the sun?

The only reason I used a square was to reduce the number of triangles.  I 
considered a circle and thought it was "bad desig" to make shapes with 
triangles that could be made with transparent textures instead.  I'll try 
it with a disk...although I would still like the alpha texture to work 
properly if I want the sun to have a fuzzy edge.  A round disk doesn't 
really help with that problem.  A sun disk with a hard edge doesn't look 
very realistic...but I understand that's a sacrifice I might have to make. 
Thanks for the tip on the circular disk.

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Workaround for this bug?

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

On Jan 21, 2005, at 12:10 AM, Keith Wiley wrote:

> I am trying to use an alpha channel to make a soft sun that fades into 
> the background sky.  It works perfectly except at the horizon, where 
> the square shape of the plane the sun texture is put on shows up as a 
> translucent square.  This problem vanishes if I turn off fog.  I am 
> aware of the discussions pointing out that fog does not work properly 
> with alpha channeled textures...and I assume you will agree that this 
> bug is the problem I am experiencing.  My question is, does anyone 
> havea reccomendation for how to work around it?

Why not use a disk instead of a square for the sun?

> Incidently, if I make the texture "transparent" instead of alphaed it 
> works just fine, the square background is invisible.  The transparent 
> texture is made by toggling transparency instead of alpha in Meshwork. 
>  This confuses me because I assumed up until now that there is no such 
> thing as "transparency" in Quesa, and that what Meshwork is really 
> doing is simply constructing an alpha channel that is only black and 
> white and applying that to the texture in question...but since 
> Meshwork-made transparent textures work properly with fog and alpha 
> channel textures do not, I am not wondering if transparency is 
> actually something other than 1-bit alpha.

In the Geom Test example, choose the cone model.  You'll see 
transparency that is done with transparency color rather than alpha 
textures.  If you then select Toggle Texture, you will see how an 
opaque texture combines with transparency color.
--
<http://www.jwwalker.com/>

Bug in E3FSSpecStorage_Get

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

For your information, I think I have fixed a bug in E3FSSpecStorage_Get
which had it parameters to Q3Memory_Copy the same way around as
E3FSSpecStorage_Set.  i.e. they both did a 'set' operation.

Roger.

Workaround for this bug?

[Keith W. <kw...@cs...>]

I am trying to use an alpha channel to make a soft sun that fades into 
the background sky.  It works perfectly except at the horizon, where the 
square shape of the plane the sun texture is put on shows up as a 
translucent square.  This problem vanishes if I turn off fog.  I am 
aware of the discussions pointing out that fog does not work properly 
with alpha channeled textures...and I assume you will agree that this 
bug is the problem I am experiencing.  My question is, does anyone havea 
reccomendation for how to work around it?

Incidently, if I make the texture "transparent" instead of alphaed it 
works just fine, the square background is invisible.  The transparent 
texture is made by toggling transparency instead of alpha in Meshwork.  
This confuses me because I assumed up until now that there is no such 
thing as "transparency" in Quesa, and that what Meshwork is really doing 
is simply constructing an alpha channel that is only black and white and 
applying that to the texture in question...but since Meshwork-made 
transparent textures work properly with fog and alpha channel textures 
do not, I am not wondering if transparency is actually something other 
than 1-bit alpha.

Am I wrong in my assumption about how transparency is working?

Thanks.


________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: time for a new release?

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

"Joseph J. Strout" <jo...@st...> wrote:

>Any opinions on whether we're in that state now, and if not, what is 
>it that's gotten worse?

As you would know if you looked at the CVS mailing list, Roger Holmes 
is in the midst of a wholesale change in Quesa's infrastructure, 
taking advantage of our recent move to C++.  We should wait until 
that work is complete and has been tested before making a release.


At 3:07 PM -0700 1/20/05, Keith Wiley wrote:
>Did anyone ever fix the texture animation or the specular highlight
>bugs I mentioned last summer?  I only recently joined sourceforge,
>so I have to confess I didn't officially put these bugs in the
>pipeline, I just mentioned them on this list.

I don't think so.  Please do file bugs, preferably with sample code, 
sample objects, or whatever it takes to reproduce them.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: time for a new release?

[Keith W. <kw...@cs...>]

Hey.  I'm not really a quesa developer so much as a user, but I follow 
this list anyway.  Admittedly, I was wondering if Quesa was going to have 
any new versions or not, specifically because I've found some bugs I wish 
weren't there, so I've always hoped it isn't a completed project as 
a result.

On Thu, 20 Jan 2005, Joseph J. Strout wrote:

> I confess I haven't been keeping up with all the changes lately... but I have

> One thing we might do is update the "Status" page periodically with some 
> notes about what's going on in the project.  But even better would be to put 
> out a new release, as soon as we think it's in a better state than the last 
> one.

Did anyone ever fix the texture animation or the specular highlight bugs I 
mentioned last summer?  I only recently joined sourceforge, so I have to 
confess I didn't officially put these bugs in the pipeline, I just 
mentioned them on this list.

Thanks for making quesa.  I'm working on a pretty big project with it and 
I always like using it.

Cheers!

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Strange tests in Quesa

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

Il giorno 20/gen/05, alle 14:30, Roger Holmes ha scritto:

> Is there any reason why I cannot change the line to test for 
> kQ3GeometryTypeNURBCurve rather
> than kQ3ShapeTypeGeometry?
>
>


seems to me a wild copy/paste

Pax et Bonum

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

time for a new release?

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

I confess I haven't been keeping up with all the changes lately... 
but I have users with the belief that the Quesa project is dying, 
because they see that it's been many months since the last release.

One thing we might do is update the "Status" page periodically with 
some notes about what's going on in the project.  But even better 
would be to put out a new release, as soon as we think it's in a 
better state than the last one.

Any opinions on whether we're in that state now, and if not, what is 
it that's gotten worse?

Thanks,
- Joe

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

Strange tests in Quesa

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

Can anyone tell me why in E3GeometryNURBCurve.c there are a number of 
calls
to Q3_REQUIRE_OR_RESULT which seem to be very lax.

For instance in Q3NURBCurve_SetKnot there is a line:

	Q3_REQUIRE_OR_RESULT(Q3Object_IsType(curve, (kQ3ShapeTypeGeometry)), 
kQ3Failure);

The code then goes on to get the instance data of "curve" and uses as 
if were known to be
a NURBS Curve. Though it is likely the application programmer has 
called it with the a NURB
Curve, there does not seem to be anything to stop him passing any other 
geometry.

Is there any reason why I cannot change the line to test for 
kQ3GeometryTypeNURBCurve rather
than kQ3ShapeTypeGeometry?

Roger.