quesa-develop — Mailing list for Quesa development

Re: serious texture mapping bug in current code

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

=46rank C wrote:

>> But when I load the same floor model used in the screen shots posted=20
>> earlier, the bug is clearly happening in Geom Test.  You can try the=20
>> same model here: <http://www.strout.net/temp/Floor.3DMF>
>
>The texture is ARGB32... I've seen this, and it appears to be the same=20
>(or related) problem I mentioned earlier;

Yep, I think it's the same thing - i.e., bug 967765.

I had a quick look and confirmed that the vertices for your
closer-than-hither test weren't coming out as nans or anything: but the
fact it shows up when texturing a poly that's entirely in view suggests
that our projection is incorrect.

Swapping the texture type to RGB32 will put us back onto the opaque
path, which in theory should be doing exactly the same projection:
obviously isn't, but that was the plan (i.e., what we give GL out of our
pre-transformed transparency buffer should be what it ends up with after
projecting what we give it for opaque triangles).


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

Re: Bug 895099 proposed fix

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

James W. Walker wrote:

>2. In E3Renderer_Method_SubmitGeometry, if the geometry's attribute set=20
>contains a surface shader, then Q3Push_Submit before submitting the=20
>geometry, and Q3Pop_Submit after.
>
>I was just wondering if anyone thinks there should be a more elegant or=20
>efficient solution.

The push/pop are quite expensive for what's just a temporary swapping
out of the active texture - that's really the background to why we use
the current approach.

Although I'm not sure why that's not working then - the idea was that by
swapping out we coud handle things like the box. The box is a group of
faces, so it would be equivalent to:

    group
        texture
        face0
        face1
        face2
        face3 { texture }
        face4
        face5

When the box group is entered its texture becomes active, and when face3
renders it temporarily swaps in the texture from its attribute set then
restores the box texture afterwards.

Presumably the swapping can't affect faces 0/1/2, so is it that faces
4/5 don't get textured? In which case are we restoring the texture
correctly once face3 finishes?


-dair (there's a more general problem we don't handle with the above
though, where an individual triangle within a TriMesh might have a
custom texture on it too: who ever said the TriMesh was the simplest and
most efficient geometry? :-)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: "Most Wanted" list

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

=46rank C wrote:

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

It's perfectly possibly - you just need to write a plug-in renderer. :-)

The current IR tries to push as much work down towards OpenGL as
possible, as doing your own lighting takes you off any HW T&L path.

Which isn't to say that a different lighting model wouldn't be useful,
but the best way to do it nowadays would be to use a vertex shader that
would allow you to plug your own model in/use QD3D's model as desired.


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

Re: Partial "objecting" success

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

Keith Wiley wrote:

>>If so, I would guess that the array is twice as long as
>> the number of vertices in the object, one U and one V coordinate per
>> vertex.  Is that right?
>
>Actually, I'm studying the online PDF "Making Cool QuickDraw 3D
>Applications" and it looks like the attributes array is the same
>length as the number of vertices, which each element being a 2D UV
>coord.

That's correct (i.e., the second statement). There are really two counts
involved:

    TQ3Uns32                       numTriangleAttributeTypes;
    TQ3TriMeshAttributeData       *triangleAttributeTypes;

    TQ3Uns32                       numEdgeAttributeTypes;
    TQ3TriMeshAttributeData       *edgeAttributeTypes;

    TQ3Uns32                       numVertexAttributeTypes;
    TQ3TriMeshAttributeData       *vertexAttributeTypes;

The "numFooAttributeTypes" fields indicate the number of
TQ3TriMeshAttributeData structures pointed to by the corresponding
"fooAttributeTypes" field.

Each TQ3TriMeshAttributeData points to a block of data of some type and
a block of TQ3Uns8-sized flags indicating the validity of the entries in
the data.


The size of those blocks comes from the numTriangles/numEdges/numPoints
fields as appropriate (e.g., the size of the data in one of the items
pointed to by the triangleAttributeTypes field is numTriangles * N).

The size of N, the data stored in each entry withn the data block,
varies depending on the attribute type - TQ3ColorRGB, TQ3Vector3D,
TQ3Param2D, etc.


So for the UV case, if one of the entries in the vertexAttributeTypes
array was to hold the UVs then the data field in that entry would be an
array of TQ3Param2Ds.

If numPoints were 5, there would be 5 TQ3Param2Ds pointed to by that
data field: there may actually be <5 valid entries (as controlled by the
flags array, if present) but there must be enough space for 5 as the
array is just cast to the appropriate type and walked through.


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

Re: strange texture animation behavior

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

Keith Wiley wrote:

>Some of the other objects in the world are displaying texture
>scrolling as well, but yet some other objects aren't.  I didn't want
>anything to scroll that I don't explicitly designate as such of
>course.  I can't figure out why some unintended objects and textures
>are scrolling while others remain normal.

The only place the UV transform is applied is in ir_texture_set_state.

We don't reset it back to the identity when a non-textured objet is
senn, but whenever a texture is activated it should be set to the
current uv transform of the texture shader.

This should either be identity or your animating transform, so whenever
a texture is active a valid transform should be set as well.

I would try hacking in some code to ir_texture_set_state - if you only
have one object which is animated then you can test every other texture
at that point and make sure that they're always applying an identity
matrix.

If they're not then you can work backwards to see where there shader got
its transform from - perhaps the texture is talking to the wrong shader,
so we end up fetching the animating transform for a texture that should
be static?


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

Re: Quesa book update: loading and saving

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

Joseph J. Strout wrote:

>So, please have a look at=20
><http://quesa.sourceforge.net/developer/book/11_loadsave/index.html>=20
>and point out any errors or glaring omissions.

Looks good to me - although the saving code does more error checking, so
it might be worth watching for failures from Q3File_OpenRead or the
xxx_New calls?


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

Re: Quesa - "Most Wanted" list

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

Edward K. Chew wrote:

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

It is logged, but it needs someone to understand what QD3D's behaviour
was in order to create the appropriate transform:

<https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D907878&
group_id=3D45158&atid=3D442052>

However, now that the IR passes the QD3D matrices on to GL rather than
translating cameras manually, once  e3camera_viewplane_frustum_matrix
was implemented then it should "just work".


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

Re: CVS commits overview, a new feature and a bug fix

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

James W. Walker wrote:

>2.  Fixed a bug in picking involving certain decomposable objects.=20
=2E..
>I also made a change to Geom Test to reveal this bug.

Going back through old mail, this caught my eye: I've opened 973627 to
track a test suite, as this is the kind of thing that would be ideal to
add to that if it existed.

I.e., a slightly obscure bug which could easily break again by accident:
if we had a test harness available we could just write a test case to
demonstrate the bug, fix it, and then confirm that the test now passes.

We set one up at work recently, and I've found that just having a place
available to stick test cases makes you much more likely to get round to
writing them.


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

[ quesa-Bugs-973627 ] Test Suite

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

Bugs item #973627, was opened at 2004-06-16 00:26
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=973627&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Test Suite

Initial Comment:
It would be very useful to have an automated test suite for running 
regression tests, to generate a set of current images and compare 
them to set of reference images to identify problems (e.g., a 
change to the renderer which causes an unexpected side effect).

This could also be turned into a performance testing tool, as a test 
harness can easily execute performance tests along with 
regression tests.

We have the beginnings of input data for this in SDK/ModelsTest, 
but really need a cross-platform app that can construct a scene, 
capture an image, and compare that image to a reference copy.

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

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

[ quesa-Bugs-967958 ] Trimesh transparency vertex attributes not applied properly

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

Bugs item #967958, was opened at 2004-06-07 05:40
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967958&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trimesh transparency vertex attributes not applied properly

Initial Comment:
Transparency color vertex attributes in a trimesh do not appear to 
properly flag all vertices/triangles as transparent.

This screenshot: <http://webhome.idirect.com/~frankco/
transerror.jpg> shows a heightmap that has been flooded with 
transparency color vertex attributes and should draw entirely in 
the transparent color, but it appears that (possibly) every-other 
triangle is solid. The same model works as expected in QD3D.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-16 00:15

Message:
Logged In: YES 
user_id=439944

Can you attach the model to this bug, or make it available?

The list of transparent triangles is constructed in 
ir_geom_trimesh_build_transparent: do you see anything odd if you step 
through there? Also, does the TriMesh have a usage array for this vertex 
attribute?

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

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

[ quesa-Bugs-967950 ] Trimesh diffuse color vertex attributes don't override

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

Bugs item #967950, was opened at 2004-06-07 05:31
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967950&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trimesh diffuse color vertex attributes don't override

Initial Comment:
If you have a trimesh containing an attribute set that uses a diffuse 
color, then add diffuse color vertex attributes, the color remains 
that of the main attribute set rather than the vertex colors.

QD3D overrides the attributes in the main set with any like-
attributes in face/edge/vertex attribute arrays.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-16 00:11

Message:
Logged In: YES 
user_id=439944

This actually should be implemented - we have a couple of optimisations 
to avoid calculating it unless we have to (so one of them might be going 
off incorrectly), but IRGeometryTriMesh.c's 
ir_geom_trimesh_vertex_colours_inherit should perform the full 
inheritance.

Can you attach a model that demonstrates the problem? 

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

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

[ quesa-Bugs-967914 ] Highlight style's specular settings do not override

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Highlight style's specular settings do not override

Initial Comment:
An attribute set's specular settings do not get overridden by a 
highlight style.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-16 00:09

Message:
Logged In: YES 
user_id=439944

Can you attach a model that demonstrates the problem?

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

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

SourceForge attachments

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

After trying and failing to attach a couple of examples to some bugs, I
had a look at the docs... :-)

It looks like attachments to the bug tracker can be no larger than
256Kb, and as far as I can see there's no way to increase it. Which is a
bit of a pain, but if you need to submit data and don't have anywhere to
put it let me know and I'll put a copy up on refnum.com that can be
linked to.


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

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

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Alpha textures do not work properly with fog or specularity

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

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

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

Message:
Logged In: YES 
user_id=171509

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

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

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

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

Message:
Logged In: YES 
user_id=439944

Can you attach a model demonstrating the problem?

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

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

[ quesa-Bugs-967765 ] Bad view transformations for transparent objects

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

Bugs item #967765, was opened at 2004-06-06 20:54
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967765&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad view transformations for transparent objects

Initial Comment:
Transparent vertices warp and eventually shoot off into infinity 
when approaching the camera/hither plane. This is likely a problem 
with the  transforms used in ir_geom_transparent_add. See 
attached CFM Mac OS X application for an example.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-16 00:00

Message:
Logged In: YES 
user_id=439944

Trying to attach example app.

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

Comment By: Frank Condello (pox)
Date: 2004-06-06 20:57

Message:
Logged In: YES 
user_id=171509

Well that didn't work - grab the test application here: <http://
webhome.idirect.com/~frankco/rb/TransTest.sit>

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

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

[ quesa-Bugs-967641 ] Flickering objects (shading?)

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

Bugs item #967641, was opened at 2004-06-06 15:21
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967641&group_id=45158

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

Initial Comment:
Using the 6/1/4 cvs version of Quesa, there are
flickering (triangles?) objects in Nanosaur for
Windows; these look like they might be "shadows" or
other shading objects being drawn incorrectly.

The version of Quesa I am using from 2/1/3 does not
have these artifacts.


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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:30

Message:
Logged In: YES 
user_id=439944

This is probably the depth buffer - we ask for a deeper buffer now than 
we used to and although GL should fall back automatically perhaps it's 
not on this machine.

Can you try tweaking the depthBits value used in gldrawcontext_win_new 
in GLDrawContext.c, and see how using 16/24/32 affects it?

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

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

[ quesa-Bugs-967639 ] Nanosaur Overview Map not transparent

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

Bugs item #967639, was opened at 2004-06-06 15:19
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967639&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nanosaur Overview Map not transparent

Initial Comment:
With the latest version of Quesa from cvs (6/1/4) the
overview map in Nanosaur (for Windows) is not
transparent. Using the cvs version from 2/1/3 the map
is correctly transparent.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:29

Message:
Logged In: YES 
user_id=439944

Can you try rolling back IRTransparent to before 1.16? (you may need 
other bits as well, so try a version from CVS at 2004/01/01).

That was the point where transparent prims were submitted in frustum 
coordinates rather than world coordinates, and the QD3D->GL camera 
code changed to using pushing matrices through.

One of those two are probably the culprit.

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

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

[ quesa-Bugs-967633 ] Fog does not work correctly

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

Bugs item #967633, was opened at 2004-06-06 15:11
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967633&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fog does not work correctly

Initial Comment:
The current version of Quesa (cvs as of 6/1/4) does not
render fog correctly in Nanosaur Extreme under Windows.
The verison of Quesa from Bugdom renders fog correctly.
(But I can't use it due to lighting and floor tiling
issues). You can swap in the Bugdom Quesa.dll to see
how for should work, and the source for the Bugdom
Quesa is at:

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

Note that this is not a new issue, all versions of
Quesa from cvs that I have used have had this issue
with Nanosaur.


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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:25

Message:
Logged In: YES 
user_id=439944

Should now be fixed - please reopen and attach a screenshot if not 
(Nanosaur used RAVE fog on the Mac, so it may be that your Windows 
Nanosaur is using its own fog implementation rather than calling Quesa).

We were trying to avoid submitting a fog style if it didn't change the 
current state, but a typo meant that changes to the fogEnd/density/color 
fields would be ignored in the comparison (and so a fog change could be 
incorrectly ignored).

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

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

[ quesa-Bugs-967190 ] Quesa Fails loading objects

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

Bugs item #967190, was opened at 2004-06-05 17:27
Message generated for change (Comment added) made by grantd
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);
}


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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:13

Message:
Logged In: YES 
user_id=439944

Attaching the problem files.

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

Comment By: Lane Roathe (raving)
Date: 2004-06-06 22:17

Message:
Logged In: YES 
user_id=48487

Well...sample code is just that, and I'll stick with doing
things the "right" way since ignoring errors just leads to
hidden problems, as below.

I tested this by replacing the error code after the NULL
with "continue;" and that allows some objects to load;
however they are not correct (for instance, the leave cursor
is upside down and the webbing doesn't even draw). A game
can not be loaded because objects are not read correctly and
cause the game to bomb out.

Again, the version of Quesa from Burger that I compiled for
Bugdom a long time ago loads all of the game objects
correctly, so it would seem that something in it fixes the
toc problem.

QD3D reads all of these objects correctly, and
Q3File_ReadObject never returns null on any of the objects.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-06-06 08:09

Message:
Logged In: YES 
user_id=433183

The difference between your code and that in Qut.c (Qut_ReadModel) is 
that you quit when Q3File_ReadObject returns NULL.  You could argue 
that this is valid, since the documentation says that Q3File_ReadObject 
returning NULL indicates an error.  However, the sample code on p. 1026 
of the QD3D manual also continues if Q3File_ReadObject returns NULL.

The specific reason that Q3File_ReadObject returns NULL is that 
e3fformat_3dmf_bin_readobject does not know what to do about a table 
of contents, which e3fformat_3dmf_bin_read_toc has already dealt with.

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

Comment By: Lane Roathe (raving)
Date: 2004-06-06 06:01

Message:
Logged In: YES 
user_id=48487

For some reason SF will not accept my attachments; probably
requires that I use IE on Windows XP or some ...

Anyway, I put the archive of the files that Quesa fails on
online:

<ftp://ftp.ifd.com/pub/Bugdom_3dmfs.zip>

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

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

[ quesa-Bugs-907879 ] Table of contents not parsed in text 3DMFs

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

Bugs item #907879, was opened at 2004-03-01 21:41
Message generated for change (Comment added) made by grantd
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: Table of contents not parsed in 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: Dair Grant (grantd)
Date: 2004-06-15 23:10

Message:
Logged In: YES 
user_id=439944

Renaming to reflect underlying problem.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-06-05 16: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

[ quesa-Bugs-905678 ] Texture filtering needs improvements

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

Bugs item #905678, was opened at 2004-02-27 08:16
Message generated for change (Comment added) made by grantd
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


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

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

Message:
Logged In: YES 
user_id=439944

Bilinear is currently supported (kQATextureFilter_Mid with mip-maps), 
but the existing texturing filtering options do need rethought - the 
existing options were picked up from RAVE and so use the kQAxxx_yyy 
naming convention.

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

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

[ quesa-Bugs-907880 ] Stale (cached?) data saved in 3DMF file

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Stale (cached?) data saved in 3DMF file

Initial Comment:
I have a TriGrid with a custom attribute attached to it. I draw it, 
that works fine. I change the value of the custom attribute and 
save the file. What gets saved is a TriMesh (fair enough) with the 
original version of the custom attribute rather than the new value.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:02

Message:
Logged In: YES 
user_id=439944

Roger, I believe this one came from you or RobinL - do you remember 
the context, or if it's still an issue?

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

Comment By: James W. Walker (jwwalker)
Date: 2004-05-29 08:41

Message:
Logged In: YES 
user_id=433183

I cannot reproduce this.  If the bug still exists, we need more 
information.

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

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

[ quesa-Bugs-900694 ] Add image import support to Unix/Windows Qut

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: Add image import support to Unix/Windows Qut

Initial Comment:
Add support for image import to Qut will let us test textures on 
these platforms more easily.
        
Need to fill in Qut_SelectPictureFile, and rework QutText.c so that 
it doesn't assume QuickTime.
   
In the short term, possibly just hard-code a fixed texture into the 
source for GeomTest so that textures can be tested more easily.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:01

Message:
Logged In: YES 
user_id=439944

Geom Test.dsp now updated.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-05-04 05:24

Message:
Logged In: YES 
user_id=433183

P.S.  Someone (other than me) needs to update Geom Test.dsp
to include QutTexture.c.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-05-03 18:12

Message:
Logged In: YES 
user_id=433183

I have made changes to Geom Test and Qut so that the Toggle Texture 
and Box (textured) features of Geom Test can work on other platforms 
by loading TGA files.  I chose the TGA format for ease of decoding.

I have not touched Qut_SelectPictureFile, so I cannot claim that the bug 
is completely fixed.

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

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

[ quesa-Bugs-940109 ] Will not render on 2nd monitor of 2 monitor system (WinXP)

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

Bugs item #940109, was opened at 2004-04-22 15:39
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=940109&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Will not render on 2nd monitor of 2 monitor system (WinXP)

Initial Comment:
On a WindowsXP system with desktop spread over 2 
monitors, GeomTest.exe fails to render if dragged over 
onto the second monitor.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 22:58

Message:
Logged In: YES 
user_id=439944

How is your second monitor driven, with a second video card or the 
same video card as the primary display?

If a second video card, does it support OpenGL? I.e., if you switch 
primary and secondary are you able to run on the previously-failing 
display?

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

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

[ quesa-Bugs-922747 ] Orientation style has no effect on trimesh

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Orientation style has no effect on trimesh

Initial Comment:
Orientation styles have no effect on geometry that use the trimesh 
render path. They are handled properly for geometry that use the 
triangle buffer path however.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 22:56

Message:
Logged In: YES 
user_id=439944

The orientation style does affect TriMeshes, but only when triangle 
normals have not been supplied (see 
IRGeometry_Generate_Triangle_Normals).

If you supply triangle normals, you are responsible for ensuring those 
normals are consistent with the current orientation - see  
IRGeometry_Validate_Triangles for the explanation.

Am closing this as invalid for now - reopen with a sample model if you 
have a case which isn't working correctly.

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

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