quesa-develop — Mailing list for Quesa development

Re: Mipmap filtering

[Frank C <li...@si...>]

NOTE: I tired to send this to the list earlier but ran into some list  
troubles - I've already sent Joe some changes that implement mipmapping  
and filtering as discussed below. I apologize if this is a duplicate  
message!

On 2-Jun-04, at 10:53 PM, Joseph J. Strout wrote:

> OK, let's talk about this issue:
>
>> 1. Proper mipmap filtering  
>> <http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=905678&group_id=45158&atid=442052>. There are several  
>> ideas in this request, but the most important one is to automatically  
>> generate mipmaps from a Pixmap texture, just as QD3D 1.6 does.  (And  
>> then of course if you don't want mipmaps generated for you, you can  
>> use a MipMap texture instead.)
>
> My understanding is that in QD3D 1.6, when you use a PixmapTexture,  
> mipmaps are generated under the hood for you, and the renderer then  
> selects the one most suited to the object's usage in the scene.
> ...
> That suggests that maybe the renderer code is the right place to look  
> -- perhaps IRTexture.c?  Perhaps modify ir_texture_convert_pixmap so  
> that it generates an OpenGL mipmap set, as ir_texture_convert_mipmap  
> does?  If we do it here, is all that scaling and conversion going to  
> happen on every frame, or just once for each time the texture is  
> edited?  And if there are multiple objects sharing the same texture,  
> will it happen just once for the whole lot?

Easiest way is to replace the glTexImage2D call with a call to  
gluBuild2DMipmaps and they'll be created auto-magically. You can  
minimize them manually and call glTexImage2D multiple times as well,  
which is often preferred since the result will be more predictable  
regardless of OS, hardware, or OGL implementation. A custom algorithm  
can also be tweaked to give better results than gluBuild2DMipmaps.

Creating the mipmaps is only the first step however. The  
cachedTexture->qualityFilter settings in the ir_texture_set_state  
function have to be changed to take advantage of mipmaps. This can be  
done in a couple ways, though I'd recommend the following:

Create a new private struct:

typedef struct TQ3QualityFilter {
	GLuint					magFilter;
	GLuint					minFilter;
} TQ3QualityFilter;

Then replace the qualityFilter member of the TQ3CachedTexture struct  
with TQ3QualityFilter and modify the affected routines accordingly;  
ir_texture_convert_rave_filter, ir_texture_set_state,  
IRRenderer_Texture_Rebuild, and ir_texture_cache_add.

The actual values of the mag/min filters would follow the  
recommendations outlined in the bug report.

I've actually gone ahead and did this on a local copy and it seems to  
work just fine (currently using gluBuild2DMipmaps).

Frank.

Re: View port vs. view plane camera (was Re: Quesa - "Most Wanted" list)

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

Edward K. Chew <ek...@lg...> wrote:

>Interesting!  I never thought of using the view port that way, but I
>guess it ought to work.  So let's say I want to get my "hand" tool
>working the way it once did.  Right now, I am moving the point of
>interest laterally, but this makes it look like I'm flying over the
>view below rather than moving around a large, static snapshot of it.
>
>Since you are confined within the 2 x 2 view port dimensions, I
>guess the only way to move away from the point of interest would be
>to shrink down the view port and offset it from (0,0).  The further
>away from the point of interest the user goes, the more you would
>have to shrink it.  At the same time, you would need to move the
>camera further out (and adjust hither and yon accordingly) to make
>up for having an ever-smaller portion of the view being rendered in
>the same-sized window pane.  Am I on the right track?

That isn't how I'd do it.  I'd set up my camera with a wide field of 
view, so that if the view port were at maximum, the camera could see 
everything.  Then I'd set the view port to be something smaller.  To 
pan around, I would then be sliding the view port, but not changing 
its size nor moving the camera.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Mipmap filtering

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

At 10:38 AM -0700 6/3/04, James W. Walker wrote:

>It won't be every frame, but I think there are various things 
>besides editing the texture that can cause textures to be reloaded. 
>For instance resizing the view or moving the window to a different 
>monitor.

I'm OK with that.

>>  And if there are multiple
>>objects sharing the same texture, will it happen just once for the
>>whole lot?
>
>Yes, I think so.  IRRenderer_Texture_Set only calls 
>ir_texture_cache_add for textures that are not already known to 
>OpenGL.

Sounds good.  (And apparently Frank has already tried this and 
observed good results!)

Thanks,
- Joe

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

Re: Mipmap filtering

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

[Please note: the following is actually from Frank Condello, who 
finds himself unable to successfully post to this list at the moment, 
perhaps due to a sourceforge.net issue like #958076 which I ran into 
last week.  So he sent it to me directly and asked me to post it for 
him.  -- JJS]

From: Frank C <li...@si...>
Date: Thu, 3 Jun 2004 13:57:34 -0400

On 2-Jun-04, at 10:53 PM, Joseph J. Strout wrote:

>OK, let's talk about this issue:
>
>>1. Proper mipmap filtering 
>><http://sourceforge.net/tracker/index.php?func=detail&aid=905678&group_id=45158&atid=442052>. 
>>There are several ideas in this request, but the most important one 
>>is to automatically generate mipmaps from a Pixmap texture, just as 
>>QD3D 1.6 does.  (And then of course if you don't want mipmaps 
>>generated for you, you can use a MipMap texture instead.)
>
>My understanding is that in QD3D 1.6, when you use a PixmapTexture, 
>mipmaps are generated under the hood for you, and the renderer then 
>selects the one most suited to the object's usage in the scene.
>...
>That suggests that maybe the renderer code is the right place to 
>look -- perhaps IRTexture.c?  Perhaps modify 
>ir_texture_convert_pixmap so that it generates an OpenGL mipmap set, 
>as ir_texture_convert_mipmap does?  If we do it here, is all that 
>scaling and conversion going to happen on every frame, or just once 
>for each time the texture is edited?  And if there are multiple 
>objects sharing the same texture, will it happen just once for the 
>whole lot?

Easiest way is to replace the glTexImage2D call with a call to 
gluBuild2DMipmaps and they'll be created auto-magically. You can 
minimize them manually and call glTexImage2D multiple times as well, 
which is often preferred since the result will be more predictable 
regardless of OS, hardware, or OGL implementation. A custom algorithm 
can also be tweaked to give better results than gluBuild2DMipmaps.

Creating the mipmaps is only the first step however. The 
cachedTexture->qualityFilter settings in the ir_texture_set_state 
function have to be changed to take advantage of mipmaps. This can be 
done in a couple ways, though I'd recommend the following:

Create a new private struct:

typedef struct TQ3QualityFilter {
	GLuint					magFilter;
	GLuint					minFilter;
} TQ3QualityFilter;

Then replace the qualityFilter member of the TQ3CachedTexture struct 
with TQ3QualityFilter and modify the affected routines accordingly; 
ir_texture_convert_rave_filter, ir_texture_set_state, 
IRRenderer_Texture_Rebuild, and ir_texture_cache_add.

The actual values of the mag/min filters would follow the 
recommendations outlined in the bug report.

I've actually gone ahead and did this on a local copy and it seems to 
work just fine (currently using gluBuild2DMipmaps).

Frank.

View port vs. view plane camera (was Re: Quesa - "Most Wanted" list)

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

On Jun 2, 2004, at 22:44, James W. Walker wrote:

> On Jun 2, 2004, at 7:42 AM, Edward K. Chew wrote:
>
>> 6. View plane camera?
>>
>> Hey, I thought I'd toss that one out FWIW, as it is the last 
>> remaining unimplemented feature which continues to break my app.  
>> Then again, maybe I'm the only one who ever used it.  :-)
>>
>> Mostly, it came in handy for generating high-res and occasionally 
>> multipage printouts, but I have had to disable that feature under 
>> Quesa.  It's also nice at times to be able to pan around a scene 
>> without having the perspective shift.
>
> It's possible to do much the same things (maybe not as easily) using 
> Q3DrawContext_SetPane, Q3DrawContext_SetPaneState, and 
> Q3Camera_SetViewPort.  Quesa's documentation on TQ3CameraViewPort even 
> suggests that it can be used to divide an image into strips for 
> printing.

Interesting!  I never thought of using the view port that way, but I 
guess it ought to work.  So let's say I want to get my "hand" tool 
working the way it once did.  Right now, I am moving the point of 
interest laterally, but this makes it look like I'm flying over the 
view below rather than moving around a large, static snapshot of it.

Since you are confined within the 2 x 2 view port dimensions, I guess 
the only way to move away from the point of interest would be to shrink 
down the view port and offset it from (0,0).  The further away from the 
point of interest the user goes, the more you would have to shrink it.  
At the same time, you would need to move the camera further out (and 
adjust hither and yon accordingly) to make up for having an 
ever-smaller portion of the view being rendered in the same-sized 
window pane.  Am I on the right track?

-Ted

Re: Mipmap filtering

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

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

>That suggests that maybe the renderer code is the right place to
>look -- perhaps IRTexture.c?  Perhaps modify
>ir_texture_convert_pixmap so that it generates an OpenGL mipmap set,
>as ir_texture_convert_mipmap does?  If we do it here, is all that
>scaling and conversion going to happen on every frame, or just once
>for each time the texture is edited?

It won't be every frame, but I think there are various things besides 
editing the texture that can cause textures to be reloaded.  For 
instance resizing the view or moving the window to a different 
monitor.

>  And if there are multiple
>objects sharing the same texture, will it happen just once for the
>whole lot?

Yes, I think so.  IRRenderer_Texture_Set only calls 
ir_texture_cache_add for textures that are not already known to 
OpenGL.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Mipmap filtering

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

OK, let's talk about this issue:

>1. Proper mipmap filtering 
><http://sourceforge.net/tracker/index.php?func=detail&aid=905678&group_id=45158&atid=442052>. 
>There are several ideas in this request, but the most important one 
>is to automatically generate mipmaps from a Pixmap texture, just as 
>QD3D 1.6 does.  (And then of course if you don't want mipmaps 
>generated for you, you can use a MipMap texture instead.)

My understanding is that in QD3D 1.6, when you use a PixmapTexture, 
mipmaps are generated under the hood for you, and the renderer then 
selects the one most suited to the object's usage in the scene.

I'd like to make Quesa do the same thing, but I'm a little over my 
head here.  I can see that E3Texture.c contains the accessors for 
PixmapTextures and MipmapTextures, but there is little to no actual 
computation here -- it's all just thin wrappers for the data 
structures.  I have a feeling this is not the right place to be doing 
such shenanigans.

That suggests that maybe the renderer code is the right place to look 
-- perhaps IRTexture.c?  Perhaps modify ir_texture_convert_pixmap so 
that it generates an OpenGL mipmap set, as ir_texture_convert_mipmap 
does?  If we do it here, is all that scaling and conversion going to 
happen on every frame, or just once for each time the texture is 
edited?  And if there are multiple objects sharing the same texture, 
will it happen just once for the whole lot?

Any input on whether I'm barking up the correct tree will be appreciated.

Thanks,
- Joe

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

Re: Quesa - "Most Wanted" list

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

On Jun 2, 2004, at 7:42 AM, Edward K. Chew wrote:

> 6. View plane camera?
>
> Hey, I thought I'd toss that one out FWIW, as it is the last remaining 
> unimplemented feature which continues to break my app.  Then again, 
> maybe I'm the only one who ever used it.  :-)
>
> Mostly, it came in handy for generating high-res and occasionally 
> multipage printouts, but I have had to disable that feature under 
> Quesa.  It's also nice at times to be able to pan around a scene 
> without having the perspective shift.

It's possible to do much the same things (maybe not as easily) using 
Q3DrawContext_SetPane, Q3DrawContext_SetPaneState, and 
Q3Camera_SetViewPort.  Quesa's documentation on TQ3CameraViewPort even 
suggests that it can be used to divide an image into strips for 
printing.
--
<http://www.jwwalker.com/>

"Most Wanted" list

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

[Resent to the proper list after Lars pointed out that I needed to 
update my address book...]

I've been talking with one of my most expert users about his 
most-wanted Quesa bug fixes and feature requests.  We may even get 
him to chip in a bit (he's an OpenGL whiz as well).  But it got me 
thinking that it might be valuable to kick around our favorite issues 
here a bit, and see whether anyone has any thoughts on them.

1. Proper mipmap filtering 
<http://sourceforge.net/tracker/index.php?func=detail&aid=905678&group_id=45158&atid=442052>. 
There are several ideas in this request, but the most important one 
is to automatically generate mipmaps from a Pixmap texture, just as 
QD3D 1.6 does.  (And then of course if you don't want mipmaps 
generated for you, you can use a MipMap texture instead.)

2. Color/alpha modulation on textured geometry. Even just matching 
QD3D's functionality would be welcome: 
<http://sourceforge.net/tracker/index.php?func=detail&aid=895106&group_id=45158&atid=442052> 
QD3D does this when using the null shader; we should probably do the 
same (and perhaps consider an object property later that extends this 
behavior to phong/lambert-shaded objects).

An example of when this is useful: you could use vertex colors to do 
your own lighting, which can be much faster than using OpenGL lights 
for some kinds of scenes.  Another example: by changing the diffuse 
alpha attribute on a textured model, you could make the object fade 
in or out.

3. The fog/specular blending bugs: 
<http://sourceforge.net/tracker/index.php?func=detail&aid=922742&group_id=45158&atid=442052> 
This is a pretty big one for me; the "Renegades" FPS game that Jeff 
Quan and I are working on (http://www.codenautics.com/renegades) 
suffers from it.  I don't find that specular highlights are very 
often a problem, but fog certainly is.

4. Improved speed -- though this has improved recently, we still find 
that object performance degrades pretty quickly for scenes with lots 
of objects.  (Some of this may actually be in the REALbasic layer on 
top of Quesa, but we'd like to at least look into where the current 
bottlenecks are and see what can be done about them.)

5. Support for writing text 3DMFs.  I looked at the code a little bit 
today, and it doesn't look very conducive to adding text support -- 
about half the code in E3FFW_3DMFBin_Writer.c should actually be 
shared between the bin and text writers.  But it could be 
refactored...

There's also a bug in 1.6d18 that causes psychadelic colors in some 
apps (such as Armageddon -- <http://www.codenautics.com/armageddon/>) 
which work fine with 1.6d17.  But I just tried to reproduce this with 
my current build from CVS, and couldn't do so, so maybe this is 
already fixed.

Anyway, that's our top-five list.  Any thoughts on any of these?

Thanks,
- Joe


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

Quesa book update: loading and saving

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

[Resent to the proper list after Lars pointed out that I needed to 
update my address book...]

I've added a bit of content to the "Loading and Saving" chapter of 
the Quesa book.  Since there is no way to automatically verify the 
correctness of a book, we must rely on each other to spot errors 
before they do too much damage.  So, please have a look at 
<http://quesa.sourceforge.net/developer/book/11_loadsave/index.html> 
and point out any errors or glaring omissions.

(Note that I have so far discussed only loading, not saving -- I'll 
try to add something about saving this evening.)

Thanks,
- Joe

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

Re: Quesa - "Most Wanted" list

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

On Jun 2, 2004, at 6:38 AM, Joseph J. Strout wrote:

>> By the way, reading text 3DMFs is also incomplete; the table of 
>> contents is ignored.  I'm not sure if that's explicitly mentioned in 
>> the bug database, but I know that at least one bug is caused by this 
>> fact.
>
> That's interesting.  What bug is caused by it?  I use text 3DMF almost 
> exclusively, but then, most of the files I'm reading are generated 
> with Meshwork and have a very simple structure.

[ 907879 ] Unable to load some text 3DMFs
--
<http://www.jwwalker.com/>

Re: Quesa - "Most Wanted" list

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

6. View plane camera?

Hey, I thought I'd toss that one out FWIW, as it is the last remaining 
unimplemented feature which continues to break my app.  Then again, 
maybe I'm the only one who ever used it.  :-)

Mostly, it came in handy for generating high-res and occasionally 
multipage printouts, but I have had to disable that feature under 
Quesa.  It's also nice at times to be able to pan around a scene 
without having the perspective shift.

-Ted

Re: Quesa - "Most Wanted" list

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

At 10:02 PM -0700 6/1/04, James W. Walker wrote:

>>4. Improved speed -- though this has improved recently, we still 
>>find that object performance degrades pretty quickly for scenes 
>>with lots of objects.  (Some of this may actually be in the 
>>REALbasic layer on top of Quesa, but we'd like to at least look 
>>into where the current bottlenecks are and see what can be done 
>>about them.)
>
>"degrades pretty quickly" meaning as more than a linear function of 
>the number of triangles?  Have you tried to separate out the effects 
>of lots of triangles, lots of textures, and lots of groups?

Yes; the issue is lots of objects (whether this is because it's lots 
of groups, or because it's lots of TriMeshes, is unclear), not the 
number of triangles.  A scene with 4000 triangles in one TriMesh 
renders very quickly; the same scene composed of 400 objects 
containing 10 triangles each renders poorly.

>>5. Support for writing text 3DMFs.  I looked at the code a little 
>>bit today, and it doesn't look very conducive to adding text 
>>support -- about half the code in E3FFW_3DMFBin_Writer.c should 
>>actually be shared between the bin and text writers.  But it could 
>>be refactored...
>
>By the way, reading text 3DMFs is also incomplete; the table of 
>contents is ignored.  I'm not sure if that's explicitly mentioned in 
>the bug database, but I know that at least one bug is caused by this 
>fact.

That's interesting.  What bug is caused by it?  I use text 3DMF 
almost exclusively, but then, most of the files I'm reading are 
generated with Meshwork and have a very simple structure.

Best,
- Joe

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

Re: Quesa - "Most Wanted" list

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

On Jun 1, 2004, at 7:45 PM, Joseph J. Strout wrote:

> 4. Improved speed -- though this has improved recently, we still find 
> that object performance degrades pretty quickly for scenes with lots 
> of objects.  (Some of this may actually be in the REALbasic layer on 
> top of Quesa, but we'd like to at least look into where the current 
> bottlenecks are and see what can be done about them.)

"degrades pretty quickly" meaning as more than a linear function of the 
number of triangles?  Have you tried to separate out the effects of 
lots of triangles, lots of textures, and lots of groups?

> 5. Support for writing text 3DMFs.  I looked at the code a little bit 
> today, and it doesn't look very conducive to adding text support -- 
> about half the code in E3FFW_3DMFBin_Writer.c should actually be 
> shared between the bin and text writers.  But it could be 
> refactored...

By the way, reading text 3DMFs is also incomplete; the table of 
contents is ignored.  I'm not sure if that's explicitly mentioned in 
the bug database, but I know that at least one bug is caused by this 
fact.
--
<http://www.jwwalker.com/>

Re: Q3Object_GetValue/SetValue API

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

At 7:00 PM -0700 6/1/04, James W. Walker wrote:

>I have written, but not checked in, the following APIs.  They are a 
>bit simpler than, say, Apple's property APIs, in that there is only 
>one property tag rather than a creator and a type.  IMHO, a single 
>type is enough, and it made it possible to implement the feature 
>fairly easily using E3HashTable.  Is this acceptable?

Well, you're mixing "type" (which to mean means something like 
TQ3Uns32, TQ3SInt16, TQ3Boolean, etc.) with "property" (which would 
be something like, "leave the depth buffer uncleared when 
rendering").  That means, if we decide that a particular property 
should be a TQ3Boolean, but later realize we need three values 
instead of two, we're stuck.  If we use both a type and a property 
identifier, then we can change the type under the hood, as long as we 
provide automatic conversion (or at least graceful failure) to/from 
whatever type the client code is specifying.

All that said, I think I'm OK with mixing these two concepts 
together.  We can make it clear by naming our "property type tags" 
with both property identifier and type, e.g., 
kQ3ClearDepthBufferBoolean, or kQ3RenderFlagsUns32.  That way, users 
of the code know what data type to pass and return (important, since 
a four-byte TQ3Uns32 is *not* identical to an arbitrary 4-byte 
buffer, due to endianness issues).  And if we ever need to change the 
type of a particular property, we can do so by just defining a new 
property type tag, but continuing to support the old one.

On the actual APIs: I don't think we need Q3Object_GetPropertySize. 
Instead, why not follow what Apple's doing with most of their newer 
APIs: allow Q3Object_GetProperty to take a null 'buffer' parameter, 
but still stuff the size into the actualSize parameter.  So, when 
unsure of the needed size, you call Q3Object_GetProperty once to get 
the data size, then allocate your buffer, and call it again to get 
the actual data.  (In most cases I don't think you'll need to ask the 
size anyway, since it will be clearly implied by the property type.)

>In case anyone is about to object that it would be nice to 
>distinguish between properties defined by Quesa and user-defined 
>properties, we could use a convention like Apple's, that property 
>tags consisting of all lowercase letters are reserved for official 
>Quesa use.

Yes, that sounds fine to me.

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

Re: Q3Object_GetValue/SetValue API

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

I have written, but not checked in, the following APIs.  They are a 
bit simpler than, say, Apple's property APIs, in that there is only 
one property tag rather than a creator and a type.  IMHO, a single 
type is enough, and it made it possible to implement the feature 
fairly easily using E3HashTable.  Is this acceptable?

In case anyone is about to object that it would be nice to 
distinguish between properties defined by Quesa and user-defined 
properties, we could use a convention like Apple's, that property 
tags consisting of all lowercase letters are reserved for official 
Quesa use.

/*!
  *	@function
  *		Q3Object_GetPropertySize
  *	@discussion
  *		Get the size of a property of an object.
  *		If the object does not have the specified property, 
the operation is
  *		considered to have failed.
  *
  *      <em>This function is not available in QD3D.</em>
  *
  *	@param	object    		The object.
  *	@param	propType		Property type tag.
  *	@param	size			Receives the size of the 
property data in bytes.
  *	@result		Success or failure of the operation.
*/
#if QUESA_ALLOW_QD3D_EXTENSIONS

Q3_EXTERN_API_C ( TQ3Status  )
Q3Object_GetPropertySize (
	TQ3Object				object,
	TQ3ObjectType			propType,
	TQ3Uns32*				size
);

#endif



/*!
  *	@function
  *		Q3Object_GetProperty
  *	@discussion
  *		Get property data from an object.
  *
  *		The operation fails if the property does not exist or 
if the provided
  *		buffer is not large enough to hold the data.
  *
  *      <em>This function is not available in QD3D.</em>
  *
  *	@param	object    		The object.
  *	@param	propType		Property type tag.
  *	@param	bufferSize		Size of provided buffer in bytes.
  *	@param	actualSize		Returns size of returned data in bytes.
  *							You may pass 
NULL if you do not need this information.
  *	@param	buffer			Buffer to receive the property data.
  *	@result		Success or failure of the operation.
*/
#if QUESA_ALLOW_QD3D_EXTENSIONS

Q3_EXTERN_API_C ( TQ3Status  )
Q3Object_GetProperty(
	TQ3Object				object,
	TQ3ObjectType			propType,
	TQ3Uns32				bufferSize,
	TQ3Uns32*				actualSize,
	void*					buffer );

#endif



/*!
  *	@function
  *		Q3Object_RemoveProperty
  *	@discussion
  *		Remove a property from an object.
  *
  *      <em>This function is not available in QD3D.</em>
  *
  *	@param	object    		The object.
  *	@param	propType		Property type tag.
  *	@result		Success or failure of the operation.
*/
#if QUESA_ALLOW_QD3D_EXTENSIONS

Q3_EXTERN_API_C ( TQ3Status  )
Q3Object_RemoveProperty(
	TQ3Object				object,
	TQ3ObjectType			propType );

#endif



/*!
  *	@function
  *		Q3Object_SetProperty
  *	@discussion
  *		Set a property of an object.  If there was already a 
property of the
  *		same type, it is replaced.
  *
  *      <em>This function is not available in QD3D.</em>
  *
  *	@param	object    		The object.
  *	@param	propType		Property type tag.
  *	@param	dataSize		Size in bytes of the data.
  *	@param	data			Data to copy into the property.
  *	@result		Success or failure of the operation.
*/
#if QUESA_ALLOW_QD3D_EXTENSIONS

Q3_EXTERN_API_C ( TQ3Status  )
Q3Object_SetProperty(
	TQ3Object				object,
	TQ3ObjectType			propType,
	TQ3Uns32				dataSize,
	const void*				data );

#endif

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

Re: Q3Object_GetValue/SetValue API

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

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

>yes, but really how it is implemented is not an issue, I see better
>the other way around the custom elements can be implemented in terms
>of Q3Object_GetValue/SetValue ( I prefer
>Q3Object_GetProperty/SetProperty too)

I don't see that we can do it the other way around.  Custom elements 
in general can have special behavior on copying, deleting, etc.  For 
instance a custom element may contain a reference to a Quesa object, 
and must do the right thing with reference counts. 
Q3Object_GetProperty/SetProperty is better suited to "plain old data".
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Nightly CVS Tarball (was Re: CVS error?)

[Dair G. <da...@re...>]

Lane Roathe wrote:

>It's possible you might have to turn this on; I noticed a checkbox on
>the OP cvs admin page for turning on/off CVS.

Yep, that option is turned on. There's actually a link to where our
tarball will be, which is:

  <http://cvs.sourceforge.net/cvstarballs/quesa-cvsroot.tar.bz2>

There's nothing there at the moment, so I suspect this is just part of
that outage.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Q3Object_GetValue/SetValue API

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

On Jun 1, 2004, at 10:36 PM, Dair Grant wrote:

> I guess an ideal-looking API for me would be:
>
> - Version/size-tagged struct to create objects and do batch data 
> get/set
>
> - A common Q3Object_GetValue/SetValue API to assign tagged values to an
> object
>
>

I'm using this method for almost ten years now, everything has changed 
overtime ( DB back-end, platform, GUI framework, ecc but this has 
allowed us to change a bit at a time without breaking much )

we uses something like (C++):

myObject->SetData( UInt32 tag, UInt32 type, void* data, UInt32 options, 
void* param)
myObject->GetData( UInt32 tag, UInt32 type, void* data, UInt32 options, 
void* param)

the type tells us what the data is (typeChar, typeFloat and the like)
the options are used to qualify the meaning of "param", mainly to hint 
the conversion of the data (lang used, format string - decimals ecc and 
the like)

we're talking about to change the tag from a 32 bits value to a string 
( to avoid the conversion with XML tags, DB columns ecc )

the general storage is by using strings, but most common values are 
data members of the proper type, we've not feel the real need for 
VARIANT

On Jun 1, 2004, at 11:24 PM, James W. Walker wrote:

> The Q3Object_GetValue/SetValue APIs could be implemented using a 
> single custom element.  I think that it would be safer and easier to 
> implement it that way, though perhaps a little less efficient at run 
> time.
>

yes, but really how it is implemented is not an issue, I see better the 
other way around the custom elements can be implemented in terms of 
Q3Object_GetValue/SetValue ( I prefer Q3Object_GetProperty/SetProperty 
too)

Pax et Bonum

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

Re: Nightly CVS Tarball (was Re: CVS error?)

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

on Tue, Jun 1, 2004 Joseph J. Strout may have said:

>At 3:19 PM -0500 6/1/04, Lane Roathe wrote:
>
>>  >From the SF cvs intructions:
>>
>>	The Nightly CVS Tarball for your project includes all historical
>>versions of all files in your repository (not just a single version, as
>>is found in a working copy)....
>>
>>For OpenPlay, "Nightly CVS Tarball" is a link to: <http://
>>cvs.sourceforge.net/cvstarballs/openplay-cvsroot.tar.bz2>
>
>Thanks, Lane.  But there is no Quesa tarball there -- in fact there 
>is nothing between "gzochi" and "u-boot".  Perhaps this is suffering 
>from the same malady as anonymous CVS access, as Dair suggested.

It's possible you might have to turn this on; I noticed a checkbox on the
OP cvs admin page for turning on/off CVS.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
We are Micro$oft. Resistance is futile. You will be assimilated.

Nightly CVS Tarball (was Re: CVS error?)

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

At 3:19 PM -0500 6/1/04, Lane Roathe wrote:

>  >From the SF cvs intructions:
>
>	The Nightly CVS Tarball for your project includes all historical
>versions of all files in your repository (not just a single version, as
>is found in a working copy)....
>
>For OpenPlay, "Nightly CVS Tarball" is a link to: <http://
>cvs.sourceforge.net/cvstarballs/openplay-cvsroot.tar.bz2>

Thanks, Lane.  But there is no Quesa tarball there -- in fact there 
is nothing between "gzochi" and "u-boot".  Perhaps this is suffering 
from the same malady as anonymous CVS access, as Dair suggested.

Best,
- Joe

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

Re: Depth buffer option

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

Dair Grant <da...@re...> wrote:

>The alternative is that we build up a big list of custom elements for
>all our additional state, but I can see that getting more and more
>unwieldy over time (some state's held in a struct, some is attached to
>an object, you don't really know which is where).
>
>I guess an ideal-looking API for me would be:
>
>- Version/size-tagged struct to create objects and do batch data get/set
>
>- A common Q3Object_GetValue/SetValue API to assign tagged values to an
>object
>
>
>The two Apple APIs that I've seen work really well have been
>CarbonEvents.h and ControlDefinitions.h. Once you have a system in place
>to get/set arbitary-sized values by name then extending the API becomes
>a lot easier.

If we had Q3Object_GetValue/SetValue (which I might prefer to call 
Q3Object_GetProperty/SetProperty), I'm not sure I see why we would 
need to modify any structs?

The Q3Object_GetValue/SetValue APIs could be implemented using a 
single custom element.  I think that it would be safer and easier to 
implement it that way, though perhaps a little less efficient at run 
time.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Depth buffer option

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

At 9:36 PM +0100 6/1/04, Dair Grant wrote:

>This means you won't be able to take a QD3D app and use it as-is, but is
>that still going to be a problem? After N years of saying we must be
>backwards compatible, I realise this must sound a bit shocking. :-)

It would be a problem for me.  REALbasic still runs happily under 
both Quesa and QD3D, and I see no near-term change in the need to do 
that.

>The question is, how much upgrading of client code is acceptible in
>order to let the API grow? If it was done in such a way that existing
>code continued to work, but new features mean using a new API, would
>that be OK?

Yes, that's OK -- we already have several new APIs of that sort. 
Code that wants to stay QD3D compatible simply ignores them.  But any 
changes that would require us to fork our code would be quite onerous 
-- especially considering that a classic app may be running against 
either QD3D or Quesa, and can't know at compile time which it will be.

>Don't know - just thinking out loud. One of the problems with the
>original API is there's no way to extend these structures in the future
>without breaking older code.
>
>If each structure started with a size or version field then this problem
>would be avoided, so perhaps this would be a good point to think about
>gradually upgrading the API to be future-proof?

Yes, when we're touching things anyway, we certainly should keep that in mind.

Here's one mildly hackish way to do something similar without 
breaking backwards compatibility: add an API for declaring what 
version of the Quesa structures you are compiling with.  (There will 
be some constant in the Quesa headers which you can pass right in for 
this purpose.)  This has global effects on what layout we expect for 
the structures.

In a true shared-library environment, where several clients can be 
sharing the  same Quesa memory, we'll have to take care to store this 
in a data area associated with a particular client.  But I think 
that's doable.

When we present code snippets that require a certain version of 
Quesa, we can indicate that using the same constant, e.g.

   #if kQ3HeadersVersion < 0x0170
	#warning This neat trick requires Quesa headers 1.7 or later
   #else
	...

>I guess an ideal-looking API for me would be:
>
>- Version/size-tagged struct to create objects and do batch data get/set
>
>- A common Q3Object_GetValue/SetValue API to assign tagged values to an
>object

Yes, this would be very cool.

Best,
- Joe

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

Re: Depth buffer option

[Dair G. <da...@re...>]

James W. Walker wrote:

>I'd like to add an option to Quesa to leave the depth buffer=20
>uncleared when rendering.

Good idea.


>I'm wondering what sort of API to use. One option would be to add a
>flag to the TQ3DrawContextClearImageMethod enumeration.  However, the
>option may not make sense for non-OpenGL renderers.  Another option
>would be to do it like the depth buffer depth, with a custom element
>attached to the renderer, view, or draw context.

Hmm, yeah, the depth buffer depth thing is something I've been wondering
about as well - we could keep extending everything through new elements
(depth value to clear to, stencil value to clear through, etc), or
perhaps we should start thinking about extending the API/structures we
use?

One of the things QD3D did try and do was come up with one interface
that would work everywhere, even if the effects were optional (e.g., the
cast/receive shadows styles would have no effect in the interactive
renderer but would in others), so using custom elements for everything
might be pushing it too far.


Proposal 1
----------
Extend the TQ3DrawContextClearImageMethod enum to be a bitfield rather
than an enum:

    typedef enum {
        kQ3ClearMethodNone             =3D 0,
        kQ3ClearMethodMaskColor        =3D (1 << 2),
        kQ3ClearMethodMaskDepth        =3D (1 << 3),
        kQ3ClearMethodMaskStencil      =3D (1 << 4),
        kQ3ClearMethodMaskAccumulation =3D (1 << 5),

        kQ3ClearMethodClearAll         =3D 1,
        kQ3ClearMethodWithColor        =3D kQ3ClearMethodDefault,

        kQ3ClearMethodSize32           =3D 0xFFFFFFFF
    } TQ3DrawContextClearImageMethod;

kQ3ClearMethodNone is at present: nothing is cleared.

The kQ3ClearMethodMaskXXX methods can be or'd together, to indicate the
specific buffers to be cleared. This gives us plenty of room to add more
buffer types later.

The kQ3ClearMethodClearAll method implies that every buffer will be
cleared: it's equvialent to what 0xFFFFFFFF would be for a bitfield.

The kQ3ClearMethodWithColor value needs to be retained for backwards
compatibility, so maps to kQ3ClearMethodClearAll as that's the behaviour
of the old enum (it says WithColor, but it clears the depth buffer too).

The drawbacks here are:

- kQ3ClearMethodClearAll has to have the value 1 rather than 0xFFFFFFFF
so it's not quite as obvious as it should be.

- There's no way to specify the value the depth, stencil, accumulation,
or future (1<<6, etc) buffers should be cleared to



Proposal 2
----------
Replace the draw context API with one that's future-proof, but not 100%
backwards compatible.

This means you won't be able to take a QD3D app and use it as-is, but is
that still going to be a problem? After N years of saying we must be
backwards compatible, I realise this must sound a bit shocking. :-)

Aside from the obvious downside, the plus points would be:

- TQ3DrawContextClearImageMethod could be a bitfield with masks and a
ClearAll that corresponded to 0xFFFFFFFF

- TQ3MacDrawContext2DLibrary would be removed, as QuickDraw GX is a
no-op.

- TQ3DrawContextData would contain additional fields for the various
ways it could be cleared. Not sure what the best approach is: perhaps
something as simple as a 32-element array of unions that could hold
everything? Or a void* to an array of these unions that gets held
externally?

- TQ3MacDrawContextData would lose the viewPort and grafPort fields.

The question is, how much upgrading of client code is acceptible in
order to let the API grow? If it was done in such a way that existing
code continued to work, but new features mean using a new API, would
that be OK?



Don't know - just thinking out loud. One of the problems with the
original API is there's no way to extend these structures in the future
without breaking older code.

If each structure started with a size or version field then this problem
would be avoided, so perhaps this would be a good point to think about
gradually upgrading the API to be future-proof?

The alternative is that we build up a big list of custom elements for
all our additional state, but I can see that getting more and more
unwieldy over time (some state's held in a struct, some is attached to
an object, you don't really know which is where).

I guess an ideal-looking API for me would be:

- Version/size-tagged struct to create objects and do batch data get/set

- A common Q3Object_GetValue/SetValue API to assign tagged values to an
object


The two Apple APIs that I've seen work really well have been
CarbonEvents.h and ControlDefinitions.h. Once you have a system in place
to get/set arbitary-sized values by name then extending the API becomes
a lot easier.

Any thoughts?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: CVS error?

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

on Tue, Jun 1, 2004 Joseph J. Strout may have said:

>That's a good idea.  I know that SourceForge offers web browsing of 
>the CVS tree, but I don't think they provide any way to grab the 
>contents thereof as a tarball or zip file.  That would be very handy 
>for people who want to check out the latest source, but don't want to 
>jump through all the hoops of CVS.

=46rom the SF cvs intructions:

=09The Nightly CVS Tarball for your project includes all historical
versions of all files in your repository (not just a single version, as
is found in a working copy). Access to the full contents of your project
CVS repository is important for Backup purposes (please ensure your
project has established a backup plan). NOTE: As of 2003-07-28, nightly
CVS tarballs are now compressed with bzip2 compression (we formerly used
gzip for compression).

=46or OpenPlay, "Nightly CVS Tarball" is a link to: <http://
cvs.sourceforge.net/cvstarballs/openplay-cvsroot.tar.bz2>

So, it would seem that you could put a link to this file on the website
for others to access, unless it is only open to project committers.

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
=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=5F=5F=5F=5F=5F=5F=5F
When we drive on parkways, park in driveways, and never obey the speed
limit, is it any wonder our children have trouble with right and wrong=3F