quesa-develop — Mailing list for Quesa development

strange texture animation behavior

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

I am doing a simple texture "animation" by scrolling the UV coordinates 
of a texture, exactly as per the Nanosaur public code.  I got it to work 
without a problem, except there's a problem.  I have a couple models in 
the world right now.  It's a test world so it's not very interesting, 
just a place to screw around.  The texture and object in question 
animate perfectly, a really cheap looking waterfall which I will make 
fancier when the time comes.  Here's the thing.  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.

Bear in mind that each of these objects came from a separate 3DMF file 
with its own texture and basically totally separate from all the other 
models in every way I can imagine.

What could possibly cause this?  Here's my code.  It's ridiculously 
simple, because as far as I can tell, scrolling the texture isn't very 
hard.  (This code is written with the Queeg framework, with necessary 
accessors added to the associated classes, and the function below is 
called from the Queeg Update function).

Any help appreciated.  Thanks.

void AnimateWaterfallTexture()
{
    TQ3Matrix3x3 uvTransformMatrix;
    Q3Matrix3x3_SetTranslate(&uvTransformMatrix, gH, gV);
    gH += 0;
    gV -= .003;
   
    QGTriMesh* triMesh = gWaterfall->GetFirstTriMesh();
   
    TQ3TriMeshData triMeshData;
    triMeshData = triMesh->GetTriMeshData();
   
    TQ3SurfaceShaderObject    shader;
   
    if (triMeshData.triMeshAttributeSet)
    {
        if (Q3AttributeSet_Contains(triMeshData.triMeshAttributeSet, 
kQ3AttributeTypeSurfaceShader))
        {
            Q3AttributeSet_Get(triMeshData.triMeshAttributeSet, 
kQ3AttributeTypeSurfaceShader, &shader);
            Q3Shader_SetUVTransform(shader, &uvTransformMatrix);
            Q3Object_Dispose(shader);
        }
    }
}


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

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

repost: Memory storage growth

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

Begin forwarded message:

> From: Jose' Cruanyes <cru...@ce...>
> Date: June 11, 2004 10:11:34 PM CEST
> To: que...@li...
> Subject: Re: Memory storage growth
>
>
> On Jun 11, 2004, at 8:13 PM, James W. Walker wrote:
>
>> While trying to write a large object to a memory storage object, I 
>> noticed that more than half the time was spent in 
>> e3storage_memory_grow.  Memory storage objects grow linearly, but it 
>> is well known that you get better performance if you grow buffers 
>> exponentially (e.g., double the size each time you need to grow.) 
>> Shall I make exponential growth an option, or just change the 
>> standard behavior?  I can't think of any reason that existing 
>> software would be hurt by the change.
>> -- 
>
> Change it... I was sure it were exponential...
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
Pax et Bonum

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

Re: Project web site was gone for a while

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

On Jun 13, 2004, at 2:03 PM, Dair Grant wrote:

> Actually, it does - there isn't any standard support for doing an
> automatic update, so I knocked something together:

OK, I hadn't thought the problem through carefully enough...


> ---------------------------------
> #!/bin/sh
>
> # Check out the current source
> cd ~/tmp
> rm -fR quesa
> cvs -d:pserver:anonymous@cvs1:/cvsroot/quesa -Q export -Dtomorrow
> quesa/Documentation
>
>
> # Replace the web site
> cd /home/groups/q/qu/quesa/htdocs
> rm -fR *
> mv ~/tmp/quesa/Documentation/* .
>
>
> # Clean out the temp directory
> cd ~/tmp
> rm -fR quesa
> ---------------------------------

What if instead of doing rm and mv you did cp -R -f?  Would that be 
safer?  Granted it wouldn't remove obsolete files and directories, but 
we don't remove things very often.
--
<http://www.jwwalker.com/>

Re: Project web site was gone for a while

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

James W. Walker wrote:

>Friday night, I noticed that the web site at
><http://quesa.sourceforge.net/> was gone.  As in, no files there
>whatsoever.

Checking my spam folder shows that I got an error around that time as
well:

---------------------------------
cvs [export aborted]: end of file from server (consult above messages if
any)
rm: cannot remove `developer': Permission denied
rm: cannot remove `images': Permission denied
rm: cannot remove `index.html': Permission denied
rm: cannot remove `info': Permission denied
rm: cannot remove `other': Permission denied
rm: cannot remove `reference': Permission denied
mv: can't stat source /home/users/g/gr/grantd/tmp/quesa/Documentation/*
---------------------------------

It looks like something failed, although I'm not sure why - unless they
were doing something to the system while it was running.


>I would imagine that the cron job that keeps the site up=20
>to date would be doing a CVS update, so there shouldn't be any point
>at which it deletes everything.

Actually, it does - there isn't any standard support for doing an
automatic update, so I knocked something together:

---------------------------------
#!/bin/sh

# Check out the current source
cd ~/tmp
rm -fR quesa
cvs -d:pserver:anonymous@cvs1:/cvsroot/quesa -Q export -Dtomorrow
quesa/Documentation


# Replace the web site
cd /home/groups/q/qu/quesa/htdocs
rm -fR *
mv ~/tmp/quesa/Documentation/* .


# Clean out the temp directory
cd ~/tmp
rm -fR quesa
---------------------------------

The reason for removing the old directory first is that doing a cvs
update will fail if we move/rename any directories on the cvs server.

It'll handle renaming/moving files OK, but for directories rename
support is just non-existent in CVS.

I was expecting the above to always work, as even if Apache had some
files open and was serving them then we should still be able to remove
them.


>I re-uploaded the files and filed a SourceForge support request asking
>what happened.  But they don't work much on weekends, so there hasn't
>been any response yet.

What we could probably do is move the old directory somewhere else
first, check out the current state, and then try and delete the old
directory.

If that fails to delete for some reason then it's not such a big deal,
as the site will have been updated from cvs anyway (I guess we should do
the cvs checkout somewhere else, and check for an error before swapping
them over).

I've marked the sourceforge status stuff as non-spam now, so if it fails
regularly I should see it and can kick it off by hand.


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

Re: Memory storage growth

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

James W. Walker wrote:

>Memory storage objects grow linearly, but it is well known that you
>get better performance if you grow buffers exponentially (e.g., double
>the size each time you need to grow.)

Although that does mean you potentially end up paging more as your
buffers are growing, well, exponentially. :-)


>Shall I make exponential growth an option, or just change the=20
>standard behavior?  I can't think of any reason that existing=20
>software would be hurt by the change.

I've used x1.5in the past quite successfully: buffers grow quickly if
they're being appended to, but you don't have such big jumps like
128->256Mb, 256Mb->512Mb, etc.

I thought we were actually using 1.5 already, but it appears not.

I can't see it breaking anything either though, so go ahead: worst case
is that we find another case where the memory balloons a bit, in which
case we can add something like a usage hint to give some idea of what
the storage object will be used for.


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

Project web site was gone for a while

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

Friday night, I noticed that the web site at 
<http://quesa.sourceforge.net/> was gone.  As in, no files there 
whatsoever.  I would imagine that the cron job that keeps the site up 
to date would be doing a CVS update, so there shouldn't be any point at 
which it deletes everything.  I re-uploaded the files and filed a 
SourceForge support request asking what happened.  But they don't work 
much on weekends, so there hasn't been any response yet.
--
<http://www.jwwalker.com/>

Re: Quesa - "Most Wanted" list

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

On Jun 2, 2004, at 6:38 AM, 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?
>
> 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.

I did an experiment that illustrates this pretty well.  I started with 
the Multibox test in Geom Test, 1000 boxes, each of which is cached as 
a group containing 6 Trimeshes.  On my Powerbook, it runs at about 15.2 
FPS.   Then I decomposed the boxes and flattened the hierarchy, so that 
all 6000 TriMeshes belonged to a single group.  That brought it up to 
20.4 FPS.  Then I merged TriMeshes with like attributes, resulting in 
just 6 TriMeshes, and that ran at 135 FPS.

In case anyone wants to play with these, I saved them as:

<ftp://ftp.jwwalker.com/multibox-orig.3dmf.zip>
<ftp://ftp.jwwalker.com/multibox-decomposed.3dmf.zip>
<ftp://ftp.jwwalker.com/multibox-merged.3dmf.zip>
--
<http://www.jwwalker.com/>

[ quesa-Bugs-895099 ] Local attribute sets break global attributes/shaders.

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
>Assigned to: James W. Walker (jwwalker)
Summary: Local attribute sets break global attributes/shaders.

Initial Comment:
Applying an attribute set with a textureshader to a single face of a 
box for example, will cause any textureshaders further up in the 
hierarchy (in the box's attribute set, etc.) to not render on the 
other 5 faces as it should.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-06-12 00:22

Message:
Logged In: YES 
user_id=433183

I believe I have fixed this, as of today.

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

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

[ quesa-Bugs-900672 ] Scan CFMSupport for plug-ins

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scan CFMSupport for plug-ins

Initial Comment:
E3MacSystem_LoadPlugins should scan these two folders for CFM 
plug-ins when running on Mac OS X:

  /Library/CFMSupport
  ~Library/CFMSupport



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

>Comment By: James W. Walker (jwwalker)
Date: 2004-06-11 22:53

Message:
Logged In: YES 
user_id=433183

I checked in a fix on 6/11/2004.

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

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

Memory storage growth

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

While trying to write a large object to a memory storage object, I 
noticed that more than half the time was spent in 
e3storage_memory_grow.  Memory storage objects grow linearly, but it 
is well known that you get better performance if you grow buffers 
exponentially (e.g., double the size each time you need to grow.) 
Shall I make exponential growth an option, or just change the 
standard behavior?  I can't think of any reason that existing 
software would be hurt by the change.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

[ quesa-Bugs-969657 ] Draw context clipping masks

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

Bugs item #969657, was opened at 2004-06-09 07:49
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=969657&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James W. Walker (jwwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Draw context clipping masks

Initial Comment:
A draw context can specify a mask bitmap, which is currently not 
implemented in Quesa.  In an OpenGL-based renderer, this could 
perhaps be implemented using the stencil buffer.

This relates to bugs 00001 and 00002 of the ancient pre-Bugzilla 
bug list.

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

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

Bug 895099 proposed fix

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

I was looking at this bug:

[ 895099 ] Local attribute sets break global attributes/shaders.

" Applying an attribute set with a textureshader to a single face of a
  box for example, will cause any textureshaders further up in the
  hierarchy (in the box's attribute set, etc.) to not render on the
  other 5 faces as it should."

1. In IRGeometry_Attribute_Handler, submit the shader to the view 
instead of calling IRRenderer_Update_Shader_Surface.

2. In E3Renderer_Method_SubmitGeometry, if the geometry's attribute set 
contains a surface shader, then Q3Push_Submit before submitting the 
geometry, and Q3Pop_Submit after.

I was just wondering if anyone thinks there should be a more elegant or 
efficient solution.
--
<http://www.jwwalker.com/>

Re: Specular highlight pass on transparent triangles is flawed

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

On 7-Jun-04, at 5:28 PM, Joseph J. Strout wrote:

> At 4:29 PM -0400 6/7/04, Frank C wrote:
>
>> The only way to get this to work properly is to draw each primitive 
>> in two passes, rather than drawing the entire set in two passes.
>
> Will this also solve the problems with transparent objects and fog? Or 
> is that a separate issue?

Won't help that directly, but a similar technique could possibly be 
used to fix it (a third pass). In the case of fog however, drawing the 
entire set of primitives at once probably makes more sense - I just 
can't think of a way to do it using standard GL fog.

Frank.

Re: Specular highlight pass on transparent triangles is flawed

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

At 4:29 PM -0400 6/7/04, Frank C wrote:

>The only way to get this to work properly is to draw each primitive 
>in two passes, rather than drawing the entire set in two passes.

Will this also solve the problems with transparent objects and fog? 
Or is that a separate issue?

Thanks,
- Joe

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

Specular highlight pass on transparent triangles is flawed

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

I wanted to bring this up on the list before submitting a bug...

The specular highlight pass for transparent triangles waits till all 
the transparent triangles are drawn, then blends highlights after the 
fact. The problem is, the highlights are drawn on top of everything in 
the colour buffer, so highlights on transparent triangles that are 
occluded by other transparent triangles are drawn full strength when 
they should appear to be filtered through the triangle in front. 
Basically: The sort order is meaningless for the specular pass - it's 
all additive and always on top.

The only way to get this to work properly is to draw each primitive in 
two passes, rather than drawing the entire set in two passes. This will 
undoubtedly be slower, but there are a couple things that can speed 
things up in general:

1). Save all the GL states between primitives and only set them when 
they actually need to be changed. This appears to already be the case 
for the specularity settings.

2). Don't bind texture "0" when turning off texturing. Just disable 
GL_TEXTURE2D and leave the last texture ready to be reused if the next 
primitive needs it (i.e. just enable GL_TEXTURE2D and don't call 
glBindTexture if you don't have to). This should be much faster for 
meshes that are mostly self-sorted and use a single texture.

Doing similar things for the opaque pass to wouldn't hurt either - I 
see client states are cached already, which is a good start.

Frank.

Color modulation fix part 2 (Was: Re: Distribution files on sourceForge)

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

On 5-Jun-04, at 4:37 PM, Frank C wrote:

> On 5-Jun-04, at 3:43 PM, Dair Grant wrote:
>
>> Can you log some bugs demonstrating how?
>
> I'll try to do this tomorrow.

These have been logged...

>>> 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...
>>
>> Where do you see it being updated on each mesh? The lights should be
>> converted once per frame, by IRRenderer_Lights_StartPass.

OK - I think I found why it's working; 
IRRenderer_Update_Shader_Illumination is turning off lighting for null 
shaders, so my changes to IRLights.c were totally unnecessary.

So, to get QD3D colour blending behaviour all ya need to do is make the 
changes posted previously: 
<http://sourceforge.net/mailarchive/message.php?msg_id=8621608> but 
ignore the changes to IRLight.c.

Note To Dair (or any other list moderators): I accidently sent a draft 
of this message from a different account, and got an "awaiting 
moderator approval" message - please disregard that message - sorry!

Thanks,
Frank.

Re: Distribution files on sourceForge

[Frank C. <fr...@lo...>]

On 5-Jun-04, at 4:37 PM, Frank C wrote:

> On 5-Jun-04, at 3:43 PM, Dair Grant wrote:
>
>> Can you log some bugs demonstrating how?
>
> I'll try to do this tomorrow.
>
>>> 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...
>>
>> Where do you see it being updated on each mesh? The lights should be
>> converted once per frame, by IRRenderer_Lights_StartPass.

OK - I think I found why it's working; 
IRRenderer_Update_Shader_Illumination is turning off lighting for null 
shaders, so my changes to IRLights.c were in fact doing nothing and 
totally unnecessary.

So, now to get QD3D blending behaviour all ya need to change is: 
http://sourceforge.net/mailarchive/message.php?msg_id=8621608

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

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

Bugs item #967958, was opened at 2004-06-07 01:40
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=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.

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

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 01:31
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=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.

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

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-06 23:22
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=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.

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

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

[ quesa-Bugs-967880 ] Screen space subdivision not supported by some geometries

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

Bugs item #967880, was opened at 2004-06-06 18:53
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=967880&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James W. Walker (jwwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Screen space subdivision not supported by some geometries

Initial Comment:
kQ3SubdivisionMethodScreenSpace is not supported by Cone, 
Cylinder, Disk, Ellipse, Ellipsoid, or Torus.

This was bug 00020 in the ancient pre-Bugzilla bug list.

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

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

[ 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 (Comment added) made by raving
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: Lane Roathe (raving)
Date: 2004-06-06 17: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 03: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 01: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-967773 ] Lighting state isn't respected on transparent objects

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

Bugs item #967773, was opened at 2004-06-06 17:09
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=967773&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lighting state isn't respected on transparent objects

Initial Comment:
The lighting state isn't restored when rendering transparent 
primitives.

There may already be enough information saved in the 
TQ3TransparentPrim struct to get proper lighting (in the 
"illumination" member)

Fixing this could be as simple as adding the following to 
ir_geom_transparent_render:

	if (thePrim->illumination == kQ3IlluminationTypeNULL)
		{
		glDisable(GL_LIGHTING);
		glDisable(GL_COLOR_MATERIAL);
		}
	else
		{
		glEnable(GL_LIGHTING);
		glEnable(GL_COLOR_MATERIAL);
		}
	}

...but the state should be saved between primitives and only 
changed when needed since they will likely be drawn in large 
groups that are either lit, or unlit.

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

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

[ quesa-Bugs-967770 ] No fog on transparent objects

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

Bugs item #967770, was opened at 2004-06-06 17:01
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=967770&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: No fog on transparent objects

Initial Comment:
The fog state isn't saved when building the transparent primitive 
lists.

Note: Due to Quesa's additive blending, GL fog can't be used on 
textured transparent primitives since it will blend additively across 
the entire primitive rather than just the alpha.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967770&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 16:54
Message generated for change (Comment added) made by pox
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: Frank Condello (pox)
Date: 2004-06-06 16: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