quesa-develop — Mailing list for Quesa development

Re: Distribution files on sourceForge

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

On 5-Jun-04, at 2:17 PM, Jose' Cruanyes wrote:

> I've uploaded the 1.6d18 distribution files on sourceForge
>
> I've then uploaded the unix SDK files, but since those are built from 
> the CVS as today, I've called them 1.6d19
>
> so, I would go ahead to make a full 1.6d19 distribution for the other 
> platforms, if you agree...

The transparent renderer is very broken in the current CVS source - I'd 
highly recommend waiting till it's fixed!

Problems with the transparent renderer that I've seen so far:

1). the new localToFrustum transforms in ir_geom_transparent_add aren't 
working right - I'm consistently seeing jumbled geometry (I'll make an 
example app that shows this if no one else sees it, but all you have to 
do is draw some transparent geometry that approaches or clips the 
frustum).

2). No fog. This is almost better than the additive fog on transparent 
textures in previous releases, but it should be fixed with an 
additional pass.

3). The lighting state is never taken into consideration, so stale 
states from the last solid objects are used - null shaders can come out 
lit and vice-versa (this is an old bug).

4). Facet normals don't appear to be handled properly (i.e. "none" 
interpolation style)

5). Sorting is less than spectacular - it can't handle a rotating cube 
properly.

Points 2, 3, & 4 above all point to a similar problem; the state simply 
isn't managed well for transparent triangles.

I'd also like to see the colour modulation fix I posted yesterday 
checked in for the next release, but I'm still in the processes of 
testing the changes. The only thing I'm concerned about is how and when 
the light state is updated - looking through the code it appears to 
happen once per frame, but in practice it updates for every mesh - so 
I'm missing something here...

Frank.

Web site status, to-do

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

I have updated the web site (in CVS, not actually online yet) so that 
all pages have the SourceForge logo and use CSS to slightly alter the 
look.  I have verified the appearance in Safari 1.2.2, Mozilla 1.7, and 
Internet Explorer (Mac) 5.2.

There are still some things about the web site that could use 
improvement:

* Has the To Do page been updated lately?
* It would be good to get rid of the old bug list, after checking that 
each item is either fixed or in the SourceForge bug list.
* The Building Quesa page needs an update, for instance it does not 
mention XCode.
--
<http://www.jwwalker.com/>

Distribution files on sourceForge

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

I've uploaded the 1.6d18 distribution files on sourceForge

I've then uploaded the unix SDK files, but since those are built from 
the CVS as today, I've called them 1.6d19

so, I would go ahead to make a full 1.6d19 distribution for the other 
platforms, if you agree...

the only thing I'll need, will be a little help with the wording of the 
releases notes. ( as you can see english is not my best trick)

Pax et Bonum

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

[ quesa-Bugs-967190 ] Quesa Fails loading objects

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

Bugs item #967190, was opened at 2004-06-05 12:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967190&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quesa Fails loading objects

Initial Comment:
The version of Quesa that is in CVS fails to load
objects in Bugdom. I am using an older (much older!)
version of Quesa in Bugdom now that loads these files
correctly. I'd really like to update to the latest
Quesa due to the speed improvements, but have not been
able to sort out why the files do not load.

I've attached the items that fail to load before the
project crashes to this report. My working copy of
Quesa is here in case anyone needs it again:

ftp://ftp.ifd.com/pub/Quesa_Bugdom.zip

Here is the function used to load the files:

/***************** READ 3DMF MODEL
************************/
//
// Reads the 3DMF file and saves into new struct
OpaqueTQ3Object*.
//
// INPUT:  file = File Object containing reference to
3DMF file
//
// OUTPUT: model =object containing all the important
data in the 3DMF file
//
//

static TQ3Status MyRead3DMFModel(TQ3FileObject file,
struct OpaqueTQ3Object* *model)
{
struct OpaqueTQ3Object*	myGroup;
struct OpaqueTQ3Object*		myObject;

		/* INIT MODEL TO BE RETURNED */
		
	*model = 0;												// assume return nothing
	myGroup = myObject = 0;
	

		/* OPEN THE FILE OBJECT & EXIT GRACEFULLY IF
UNSUCCESSFUL */

	if (Q3File_OpenRead(file,0) != kQ3Success)							//
open the file
		DoFatalAlert("Reading 3DMF file failed!");
	
				/**************************************/
				/* READ ALL THE OBJECTS FROM THE FILE */
				/**************************************/
	do
	{	
			/* READ A METAFILE OBJECT FROM THE FILE OBJECT */

		myObject = Q3File_ReadObject(file);
		if (myObject == 0)
		{
			if (myGroup)
				Q3Object_Dispose(myGroup);

			DoAlert("MyRead3DMFModel: Q3File_ReadObject Failed!");
			QD3D_ShowRecentError();
			break;
		}

		/* ADD ANY DRAWABLE OBJECTS TO A GROUP */
		
		if (Q3Object_IsDrawable(myObject))								// see if
is a drawable object
		{
			if (myGroup)												// if group exists
				Q3Group_AddObject(myGroup,myObject);					// add
object to group
			else
			if (*model == 0)											// if no model data yet /
this is first
			{
				*model = myObject;										// set model to this object
				myObject = 0;											// clear this object
			}
			else														// this isn't the first & only
object, so add to group
			{
				myGroup = Q3DisplayGroup_New();							// make new group
				if (myGroup == 0)
					DoFatalAlert("MyRead3DMFModel: Q3DisplayGroup_New
failed!");
				
				Q3Group_AddObject(myGroup,*model);						// add
existing model to group
				Q3Group_AddObject(myGroup,myObject);					// add
object to group
				Q3Object_Dispose(*model);								// dispose extra ref
				*model = myGroup;										// set return value to
the new group
			}
		}
		
		if (myObject != 0)											// dispose extra ref
			Q3Object_Dispose(myObject);
			
	} while(!Q3File_IsEndOfFile(file));
	
	
			/* SEE IF ANYTHING WENT WRONG */
			
	if (Q3Error_Get(0) != kQ3ErrorNone)
	{
		if (*model != 0)
		{
			Q3Object_Dispose(*model);
			*model = 0;
		}		
		return(kQ3Failure);
	}
	
	return(kQ3Success);
}


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

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

[ quesa-Bugs-907879 ] Unable to load some text 3DMFs

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

Bugs item #907879, was opened at 2004-03-01 13:41
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907879&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to load some text 3DMFs

Initial Comment:
Frank Cox wrote:

Quesa is having problems loading 3DMFs with multiple trimeshes 
that use shader references. Here's a simplified example model: 
http://webhome.idirect.com/~frankco/ test_3dm.sit It's a simple 
cube, with each face saved as a separate trimesh, but all faces 
reference the first texture shader. QD3D handles these files just 
fine.

A second issue that popped up with 1.6d18 involves specular 
highlighting. I'm getting specular highlights on trimeshes that 
shouldn't be receiving them (i.e. meshes using a null shader). This 
only happens when at least one object in the scene has specular 
highlighting enabled, which leads me to suspect that the GL state 
may be left dangling between vertex flushes.

-----

James Walker wrote:

The bug appears to be in reading text 3DMF files.  After I 
converted the test file to binary form with Anatas, a Quesa app 
was able to read all 6 textured TriMeshes.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-06-05 09:56

Message:
Logged In: YES 
user_id=433183

The underlying problem is that Quesa does not read the table of contents 
in text 3DMF.

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

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

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

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

On Jun 4, 2004, at 11:36 AM, Edward K. Chew wrote:

> Now, I am assuming the only way to adjust the perspective effect is to 
> play with the field of view, so I think I need to stick to whatever 
> value I have calculated for it.

Not following you there.  How much "perspective effect" you see in the 
image of a particular object depends only on the distance between the 
camera and the object.  The field of view only determines how much 
stuff is visible.

>  On the other hand, I think there are several ways you can manipulate 
> the scale of the image.  Reducing the distance of the camera from the 
> view plane

If you mean, moving the view plane closer to the camera, yes, that 
would make a bigger image on the view plane.  But I'm not sure how 
that's relevant.

> or shrinking the size of the view port should both have a linear 
> dilation effect.

Hmm?  Shrinking the size of the view port just makes less of the image 
visible, exactly like reducing the field of view.

>  I suppose you could also do it at the geometry level with a scaling 
> transform.
>
> So if I understand these view ports correctly, I should be able to 
> compensate for changes in view port dimensions by changing something 
> else at the same time like the camera distance, and there should be no 
> distortion of the image in either size or perspective.  Correct?
>
--
<http://www.jwwalker.com/>

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

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

On Jun 3, 2004, at 17:52, James W. Walker wrote:

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

Well, what complicates things for me is that my projection model is 
rather rigidly defined (it's a geophysical modelling app which can 
incorporate survey data).  Whatever I decide to do with view ports, 
there are two properties which must always be satisfied: the scale of 
the rendered image must match real world units as much as possible 
(especially on a printout), and the amount of perspective should be a 
function of the observer's distance from the scale model.

So for example, the default scale factor is 1 cm = 100 m and the 
default viewing distance is 40 cm (in other words, your eye would be 
about 16" from the monitor).  That means a 1 km long survey line lying 
directly on the view plane (which corresponds to the plane of the 
monitor) should look about 10 cm long.  If it was closer to the camera 
by say 5 cm, it should look longer to the extent that an object 
hovering 5 cm in front of the screen would look larger to the human eye 
only 35 cm away.

Now, I am assuming the only way to adjust the perspective effect is to 
play with the field of view, so I think I need to stick to whatever 
value I have calculated for it.  On the other hand, I think there are 
several ways you can manipulate the scale of the image.  Reducing the 
distance of the camera from the view plane or shrinking the size of the 
view port should both have a linear dilation effect.  I suppose you 
could also do it at the geometry level with a scaling transform.

So if I understand these view ports correctly, I should be able to 
compensate for changes in view port dimensions by changing something 
else at the same time like the camera distance, and there should be no 
distortion of the image in either size or perspective.  Correct?

-Ted

Re: Depth buffer option

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

>I presume a renderer can choose to not implement this new
>feature anyway.

Indeed.  In the HeaderDoc comments in QuesaDrawContext.h, I wrote:

"Property types that may be assigned to a draw context, for instance to
request special rendering behavior.  Such requests may be ignored by some
renderers."
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: "Most Wanted" list

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

On 4-Jun-04, at 1:59 PM, Roger Holmes wrote:

> On Friday, June 4, 2004, at 04:55  pm, Frank C wrote:
>
>> Fair enough. Hmmm, I guess no one actually uses Quesa's trigrid or 
>> triangle geometires!
>
> Yes we use TriGrids a lot and triangles occasionally.

I suppose you don't use diffuse colour and textures in the ways Joe and 
Jose described. In the current release trigrids and triangles modulate 
textures and colours when lit.

>> ...or do your own lighting, which is impossible with Quesa at the 
>> moment...
>
> Our users set up their own spot/point lights wherever they want and it 
> works fine, though I'm not
> using the latest CVS version (as I use a more optimised version of 
> Quesa) , so maybe
> a bug has crept in since the two sources diverged.

By "doing your own lighting" I mean bypassing Quesa/OpenGL lights 
altogether and colouring vertices manually. This can be done as a 
preprocessing step to simulate static low-resolution lightmaps with 
occlusion/self-shadowing.

Frank.

Re: Quesa - "Most Wanted" list

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

At 4:58 PM +0100 6/4/04, Dair Grant wrote:

>BTW, Roger's original message went to the old list. Joe did the same
>thing a couple of days ago - can everyone make sure they update their
>address book? Or we end up with threads being split over the two lists,
>like I've just done with this one... :-)

Can't we shut just the old list down?

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

Re: "Most Wanted" list

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

On Friday, June 4, 2004, at 04:55  pm, Frank C wrote:

> Fair enough. Hmmm, I guess no one actually uses Quesa's trigrid or 
> triangle geometires!

Yes we use TriGrids a lot and triangles occasionally.

> ...or do your own lighting, which is impossible with Quesa at the 
> moment...


Our users set up their own spot/point lights wherever they want and it 
works fine, though I'm not
using the latest CVS version (as I use a more optimised version of 
Quesa) , so maybe
a bug has crept in since the two sources diverged.

We submit our widgets before the lights/shaders so they are not 
illuminated like the real
objects in the view.


Roger.

Color modulation fix

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

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

> 2. Color/alpha modulation on textured geometry. Even just matching 
> QD3D's functionality would be welcome:

Here are some changes to get QD3D 1.6 behavior:

---
In IRGeometryTriMesh.c, ir_geom_trimesh_initialise,  get rid of the 
"TEMPORARY FIX" block.

---
In IRGeometry.c, IRGeometry_Generate_Vertex_State, add a "white" const:

	const TQ3ColorRGB		white = {1.0f, 1.0f, 1.0f};

Then in the "Fall back to the defaults" bit change this:

	if (colourDiffuse == NULL || instanceData->stateGeomHilightState == 
kQ3On)
		colourDiffuse = instanceData->stateGeomDiffuseColour;

	if (colourTransparency == NULL &&
		(instanceData->stateGeomTransparencyColour->r != 1.0f ||
		 instanceData->stateGeomTransparencyColour->g != 1.0f ||
		 instanceData->stateGeomTransparencyColour->b != 1.0f))
		colourTransparency = instanceData->stateGeomTransparencyColour;

to:

	if (instanceData->stateTextureActive && 
instanceData->stateViewIllumination != kQ3IlluminationTypeNULL)
		{
		colourDiffuse = &white;
		colourTransparency = &white;	
		}
	else
		{
		if (colourDiffuse == NULL || instanceData->stateGeomHilightState == 
kQ3On)
			colourDiffuse = instanceData->stateGeomDiffuseColour;

		if (colourTransparency == NULL &&
			(instanceData->stateGeomTransparencyColour->r != 1.0f ||
			 instanceData->stateGeomTransparencyColour->g != 1.0f ||
			 instanceData->stateGeomTransparencyColour->b != 1.0f))
			colourTransparency = instanceData->stateGeomTransparencyColour;
		}

---
In IRLights.c, ir_light_reset, change:

	if (numLights != 0)

to:

	if (numLights != 0 && instanceData->stateViewIllumination != 
kQ3IlluminationTypeNULL)

---
In IRTexture.c, ir_texture_set_state, remove the glEnvMode variable and 
the "if" statement that sets it, then change:

	glTexEnvi(      GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,   glEnvMode);

to:

	glTexEnvi(      GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,   GL_MODULATE);


I think that's everything - This can be verified to work with all 
geometries using GeomTest (i.e. it should fix both trimesh and 
tribuffer rendering)

Frank.

Re: Depth buffer option

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

Ok, so you also need the depth buffer to be preserved between renders, 
so you need to tell
it to keep the buffer around on the previous render as well as not 
clear it on the second render.
That makes a bit more sense, though if a pixel's depth is not yon then 
my renderer expects
there to be a pointer to an triangle in a companion buffer (actually 
interleaved), so these would
have to be preserved as well. I presume a renderer can choose to not 
implement this new
feature anyway. Thanks for the clarification.

Roger.

P.S. I sent to the wrong list because I was replying to a message sent 
to the wrong list.

On Friday, June 4, 2004, at 05:21  pm, James W. Walker wrote:

> Of course you don't want it uninitialized.  To achieve a particular 
> special effect, I needed to render some stuff, then make the depth 
> buffer read-only, not clear the depth buffer, and render some more 
> stuff.

Re: Depth buffer option

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

On Jun 4, 2004, at 5:59 AM, Roger Holmes wrote:

> I've had a couple of days off so I'm in catch up mode. Have I missed 
> something? Can an application access the
> depth buffer? I thought it was private to the renderer, I think the 
> one in my renderer is. If it is private, there seems
> very little point in having uninitialised garbage in there before you 
> render. I seem to be missing the point totally.
> Can someone please explain.

Of course you don't want it uninitialized.  To achieve a particular 
special effect, I needed to render some stuff, then make the depth 
buffer read-only, not clear the depth buffer, and render some more 
stuff.
--
<http://www.jwwalker.com/>

Re: Quesa - "Most Wanted" list

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

Roger Holmes wrote:

>But the bulk of the changes have not yet been approved, let alone
>checked in. Its good to see things coming alive on the list, but every
>change makes the task of merging in the changes I made last year just
>that bit more difficult.

Yes, this is my fault - these have been sitting in my inbox for months
now, but I've never got round to looking at them properly.

I'll do so this weekend.


>My "Most Wanted" item would be the removal of the need for every
>texture to be reformatted pixel by pixel into the common format we use
>to drive OpenGL. I understand OpenGL can use native Quesa component
>ordering, so this is a big CPU overhead which is not necessary.

This will be an overhead when a texture is submitted, but once submitted
the texture object should be cached - so the biggest impact is really
memory (we have some extra copies of the image data sitting around
taking pages up in system memory).

BTW, Roger's original message went to the old list. Joe did the same
thing a couple of days ago - can everyone make sure they update their
address book? Or we end up with threads being split over the two lists,
like I've just done with this one... :-)


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

Re: "Most Wanted" list

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

On 4-Jun-04, at 10:08 AM, Joseph J. Strout wrote:

> At 3:25 AM -0400 6/4/04, Frank C wrote:
>>
>> Personally I'd like to see colours modulated _all_ the time - QD3D be  
>> damned! ;)
>
> That's scary...

Fair enough. Hmmm, I guess no one actually uses Quesa's trigrid or  
triangle geometires!

> If we follow QD3D's behavior, and do this only for null-shaded models,  
> then it will cause less screaming.  Typically if you have a textured  
> 3D model, you probably want it to be affected by lighting,

...or do your own lighting, which is impossible with Quesa at the  
moment...

> otherwise you'd just use a sprite.  There are exceptions though --  
> anything that's intended to be internally lit, like a model of flames,  
> or a glowing shield, or a ghost, or whatnot.

This would actually help those cases - you can modulate the  
transparency in real time without touching the texture.

> What I don't understand is, why didn't this problem come up in the  
> QD3D days, when Meshwork was first introduced.  It wasn't as widely  
> used then as it is now, but I certainly never saw a problem.  It's  
> possible that I simply never used a model with a null shader until  
> after I had already switched to Quesa.

This didn't appear until QD3D 1.6, here's the "New API Features and  
Improvements" document:  
<http://developer.apple.com/documentation/QuickTime/QD3D/ 
QD3DDelta.htm#_Toc438524142> (point #6). A related side effect is that  
the default colour is white in 1.6 rather than grey, but I think Quesa  
defaults to white already.

I'm fine with matching QD3D 1.6's behaviour, and if no one else steps  
up I'll attempt to implement this by changing the light state rather  
than the blending state for null shaders. I need this functionality one  
way or another, even if it means maintaining my own personal build.

Frank.

Re: "Most Wanted" list

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

On 4-Jun-04, at 3:50 AM, Jose' Cruanyes wrote:

> On Jun 4, 2004, at 9:25 AM, Frank C wrote:
>
>> Personally I'd like to see colours modulated _all_ the time - QD3D be 
>> damned! ;)
>
> In our application we calculate the mean color for a given texture and 
> submit it as diffuse color of the object. so blending it will broke us 
> (and every 3DMF we saved in the past years)

I'm fine simply matching QD3D 1.6's behaviour - but I am very surprised 
yourself and Joe still used this method after QD3D 1.6 was released!

> so it's just another use for the brand new Get/SetProperty API

I can live with that, but I'm a little unfamiliar with the procedure; 
where would the best place be to declare a new property type? Would 
this make more sense as an extension to geometries or to texture 
shaders? Should there be two flags: 
"kQ3TextureShaderPropertyModulateDiffuseColor" & 
"kQ3TextureShaderPropertyModulateTransparency" since the rest of the 
API makes distinctions between the two?

Sorry for all the questions, I'm just not very familiar with the source 
or the conventions used.

Frank.

Re: "Most Wanted" list

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

At 9:50 AM +0200 6/4/04, Jose' Cruanyes wrote:

>In our application we calculate the mean color for a given texture 
>and submit it as diffuse color of the object. so blending it will 
>broke us (and every 3DMF we saved in the past years)
>
>Why we do that way?
>older versions of Art*lantis will divide objects by color, so in 
>this way we could talk properly with it.
>we have a vector hidden-line renderer that uses it to color the polygons

Yes, those are good reasons.  It also means that if you switch to the 
standard Wireframe renderer, you'll still get a fair approximation of 
your scene, color-wise; and if the texture gets booted out of VRAM 
for some reason, you again get at least a reasonable approximation of 
your object (e.g., a brown tree trunk instead of a flaming orange 
one).

>so it's just another use for the brand new Get/SetProperty API

Yes, I think it might need to be.

Best,
- Joe

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

Re: "Most Wanted" list

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

At 3:25 AM -0400 6/4/04, Frank C wrote:

>So what should be done here? This bug can basically be resolved by 
>removing the "TEMPORARY FIX", but it won't match QD3D's behaviour - 
>or - it can be left as is, and actually disable lights when 
>rendering objects with a null shader while still modulating colours 
>to match QD3D. The tribuffer path would need a similar fix to fully 
>comply in this case.
>
>Personally I'd like to see colours modulated _all_ the time - QD3D 
>be damned! ;)

That's scary -- virtually every app using models made with Meshwork 
would suddenly start looking very very wrong.  In case you haven't 
used it, here's why: Meshwork creates up to eight materials 
(TriMeshes) for an object, but in the editor window, these aren't 
drawn with textures; they're drawn as solid colors.  The materials 
start out with eight easily distinguishable colors by default (blue, 
red, green, white, orange, etc.).  Typical usage is: for an 
untextured material, you set the color the way you want it to appear, 
but for a textured material, you leave it as-is (or set it to 
something easily distinguishable from the other materials in the 
editor), for convenience in the editor, with the understanding that 
it doesn't matter anyway since the color won't appear at runtime 
(unless you run out of texture RAM or some such).

Now, if I understand the proposed change correctly, all such models 
would appear with their textures mixed in with whatever color the 
artist used in the editor.  That's a problem -- there are a lot of 
apps out there using models made with Meshwork.  Our users are going 
to scream.

If we follow QD3D's behavior, and do this only for null-shaded 
models, then it will cause less screaming.  Typically if you have a 
textured 3D model, you probably want it to be affected by lighting, 
otherwise you'd just use a sprite.  There are exceptions though -- 
anything that's intended to be internally lit, like a model of 
flames, or a glowing shield, or a ghost, or whatnot.

What I don't understand is, why didn't this problem come up in the 
QD3D days, when Meshwork was first introduced.  It wasn't as widely 
used then as it is now, but I certainly never saw a problem.  It's 
possible that I simply never used a model with a null shader until 
after I had already switched to Quesa.

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

Re: Depth buffer option

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

I've had a couple of days off so I'm in catch up mode. Have I missed 
something? Can an application access the
depth buffer? I thought it was private to the renderer, I think the one 
in my renderer is. If it is private, there seems
very little point in having uninitialised garbage in there before you 
render. I seem to be missing the point totally.
Can someone please explain.

Roger.




> I'd like to add an option to Quesa to leave the depth buffer uncleared 
> when rendering.  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.

Re: "Most Wanted" list

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

On Jun 4, 2004, at 9:25 AM, Frank C wrote:

> On 2-Jun-04, at 2:15 PM, Joseph J. Strout wrote:
>
>> 2. Color/alpha modulation on textured geometry.
>
> Hmmm... There's a "TEMPORARY FIX" in ir_geom_trimesh_initialise that 
> removes colour and transparency information from all trimeshes - 
> specifically it notes:
>
> 	// If we are using a texture, pretend the vertices are opaque white.
> 	// This is to make it so that a textured TriMesh is affected by 
> lighting,
> 	// but not by the color of the geometry.
>
> Now the question is; what is this supposed to fix? If this code is 
> removed, colour and transparency blends with textures (as they do in 
> the tribuffer path) which is a desirable effect IMHO...
>
>> 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).
>
> Removing the "fix" above results in opposite behaviour to QD3D however 
> - lit objects modulate colours, unlit objects don't - but this is due 
> by the rather lazy way Quesa "disables" lighting on objects affected 
> by null shaders. i.e. it doesn't, but instead uses the GL_REPLACE 
> blend mode.
>
> So what should be done here? This bug can basically be resolved by 
> removing the "TEMPORARY FIX", but it won't match QD3D's behaviour - or 
> - it can be left as is, and actually disable lights when rendering 
> objects with a null shader while still modulating colours to match 
> QD3D. The tribuffer path would need a similar fix to fully comply in 
> this case.
>
> Personally I'd like to see colours modulated _all_ the time - QD3D be 
> damned! ;)
>
> Frank.
>
>

In our application we calculate the mean color for a given texture and 
submit it as diffuse color of the object. so blending it will broke us 
(and every 3DMF we saved in the past years)

Why we do that way?
older versions of Art*lantis will divide objects by color, so in this 
way we could talk properly with it.
we have a vector hidden-line renderer that uses it to color the polygons

so it's just another use for the brand new Get/SetProperty API




Pax et Bonum

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

Re: "Most Wanted" list

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

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

> 2. Color/alpha modulation on textured geometry.

Hmmm... There's a "TEMPORARY FIX" in ir_geom_trimesh_initialise that 
removes colour and transparency information from all trimeshes - 
specifically it notes:

	// If we are using a texture, pretend the vertices are opaque white.
	// This is to make it so that a textured TriMesh is affected by 
lighting,
	// but not by the color of the geometry.

Now the question is; what is this supposed to fix? If this code is 
removed, colour and transparency blends with textures (as they do in 
the tribuffer path) which is a desirable effect IMHO...

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

Removing the "fix" above results in opposite behaviour to QD3D however 
- lit objects modulate colours, unlit objects don't - but this is due 
by the rather lazy way Quesa "disables" lighting on objects affected by 
null shaders. i.e. it doesn't, but instead uses the GL_REPLACE blend 
mode.

So what should be done here? This bug can basically be resolved by 
removing the "TEMPORARY FIX", but it won't match QD3D's behaviour - or 
- it can be left as is, and actually disable lights when rendering 
objects with a null shader while still modulating colours to match 
QD3D. The tribuffer path would need a similar fix to fully comply in 
this case.

Personally I'd like to see colours modulated _all_ the time - QD3D be 
damned! ;)

Frank.

Re: Mipmap filtering

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

On 3-Jun-04, at 10:47 PM, Joseph J. Strout wrote:

> He also mentioned the possibility of anisotropic filtering, but said 
> that would require some discussion, so I'll leave it to him to get 
> that ball rolling if he thinks it important.

Ideally anisotropic filtering would be implemented as a separate 
property of a view, but it could also work as three additional 
Quesa-only filter modes that are converted to hardware specific values:

kQATextureFilter_Anisotropic_Fast
kQATextureFilter_Anisotropic_Mid
kQATextureFilter_Anisotropic_Best

Hardware with a maximum anisotropic range of 8 would use values of 
2,4,8, a maximum of 16 would use 4,8,16 etc. You loose some precision 
on higher-end cards, but it should still work reasonably well without 
adding an additional entry point. I've actually seen many anisotropic 
implementations use a simple toggle (!) so this would certainly offer 
enough control for most uses.

This feature isn't all that critical to me personally, but I'm willing 
to do the grunt work if we can agree on the implementation.

Frank.

Re: Mipmap filtering

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

I've checked in Frank's changes for issue 905678.  The code is nice 
and neat, and Frank has verified that this gives the intended result 
with PixmapTextures, while not affecting MipmapTextures (so, if you 
want to avoid the automatic mipmapping, you can just supply a MipMap 
with only one image, and it'll work use that image at any distance).

The filter constants map to OpenGL quality filters as follows:

kQATextureFilter_Fast = Nearest neighbour (ignores mipmaps)

kQATextureFilter_Mid = Bilinear mipmap (ala QD3D 1.6's default)

kQATextureFilter_Best = Trilinear mipmap (not sure what QD3D does 
here, because we don't think hardware back then supported trilinear 
filtering).

Note that the default quality in both QD3D and Quesa is kQATextureFilter_Mid.

Frank noted that we could consider using a custom halving algorithm 
for generating the mipmap images; currently we just let 
gluBuild2DMipmaps do that for us.  He also mentioned the possibility 
of anisotropic filtering, but said that would require some 
discussion, so I'll leave it to him to get that ball rolling if he 
thinks it important.

I'm not sure quite what the proper Tracker procedure is, but here's 
my stab at it: I set the Resolution pop-up to Fixed, but left the 
Status to Open, thinking that we'll Close it when it's actually 
shipped in an official release and the fix has been verified there. 
Somebody please correct me if that's not right.

Thanks,
- Joe

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

[ quesa-Bugs-905678 ] Texture filtering needs improvements

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

Bugs item #905678, was opened at 2004-02-27 00:16
Message generated for change (Settings changed) made by jstrout
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=905678&group_id=45158

Category: None
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
>Assigned to: Joe Strout (jstrout)
Summary: Texture filtering needs improvements

Initial Comment:
Here are the common filtering options in OpenGL.

// Nearest (Quesa's "kQATextureFilter_Fast" setting)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_NEAREST);

// Linear (Quesa's "kQATextureFilter_Best/Mid" setting)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR);

// Bilinear (Not supported in Quesa)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_NEAREST);

// Trilinear (Not supported in Quesa)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_LINEAR);

Bilinear and Trilinear are commonly the only options most scene 
graphs/games support, yet neither is supported in Quesa.

Fixing this requires a few changes:

1). The "qualityFilter" member in the "TQ3CachedTexture" struct 
can't be defined as a single GLuint. It either needs min/max 
values, or should possibly be a "TQ3TextureFilter" name instead, 
that can be used as a hint when uploading the texture (but that 
means changing how and where the TQ3TextureFilter is translated 
into something OpenGL can use).

2). Mipmaps should be generated when not present in a texture 
shader for filter modes that require them. This will more closely 
match the QD3D behaviour. but also allow mips to be easily 
excluded by using a Fast/Mid filter setting.

3). Quesa needs additional TQ3TextureFilter names, and the 
meaning of existing names should be altered. I'd recommend 
something like this to maintain compatibility:
kQATextureFilter_Fast = Nearest
kQATextureFilter_Mid = Linear
kQATextureFilter_Best = Bilinear
kQATextureFilter_Trilinear = Trilinear


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

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