quesa-develop — Mailing list for Quesa development

Re: Cartoon Renderer

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

Il giorno 10/set/05, alle 12:51, Stefan Huber ha scritto:

> As the cartoon renderer is part of Quesa itself I suggest to use a 
> static object type like kQ3RendererTypeInteractive and 
> kQ3RendererTypeWireFrame (-> Q3XObjectHierarchy_RegisterClass). So it 
> would be very easy to identify this renderer.
>

Yes,  we should do that...

but I think we also should arrange things to be able to build it as 
plug-in too


>
Pax et Bonum

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

Cartoon Renderer

[Stefan H. <st...@to...>]

As the cartoon renderer is part of Quesa itself I suggest to use a 
static object type like kQ3RendererTypeInteractive and 
kQ3RendererTypeWireFrame (-> Q3XObjectHierarchy_RegisterClass). So it 
would be very easy to identify this renderer.

Stefan
__________
www.topoi.ch

3DMF Writer

[Stefan H. <st...@to...>]

Under QD3D it's possible to write multiple viewhints to the same file 
(e.g. the QD3D viewer's camera menu adds cameras from multiple 
viewhints).

In Quesa E3FFW_3DMF_StartFile (E3FFW_3DMFBin_Writer) always writes 
the header (kQ3ObjectType3DMF). In my case (writing the current view, 
then writing several additional viewhints from another views to the 
same file), this behavior is wrong.

In my case changing the first line in E3FFW_3DMF_StartFile to

   TQ3Status status = 
fileFormatPrivate->baseData.currentStoragePosition > 0 ? kQ3Success : 
E3FFW_3DMF_TraverseObject (theView, fileFormatPrivate, NULL, 
kQ3ObjectType3DMF, fileFormatPrivate);

solves the problem.


Stefan
__________
www.topoi.ch

Re: proposed new API: Q3Memory_GetStatistics

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

on Thu, Aug 25, 2005 James W. Walker may have said:

>By the way, how widespread is compiler support for long long (64 bit) 
>integer types?  I don't see long long in the C++ standard, though it 
>is in C99.

I just found out that Visual Studio does not know about long long (it's
a compile error). Still trying to figure out how to handle 64 bit #s in VS...

That's 99% of the total market, but who knows how much of the Quesa market :)

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
I am Pentium of Borg. Precision is futile. You will be approximated.

Re: Custom geometries

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

I am currently defining kQ3XMethodTypeGeomCacheNew etc locally and am
almost happy with defining custom geometries but I have hit a snag.

E3XObjectHierarchy_NewObject calls E3ClassTree::CreateInstance  with the
middle parameter (sharedParams) equal to kQ3True. This means the 
parameter
gets passed all the way down, so when 
OpaqueTQ3Object::InitialiseInstanceData
is called for the geometry class, and it finds the 'newMethod' is null, 
it then calls
to Q3Memory_Copy which copies rubbish data over the cachedObject field 
(etc) of
E3Geometry. This later causes rendering to crash.

I think the safest way to fix this is to write a new method for the 
geometry class. As it
happens it does not need to do anything as the fields have been cleared 
already.

Any objections, or thoughts on a better way forward?

Roger Holmes.



On 23 Aug, 2005, at 14:39, Roger Holmes wrote:

>
> On 23 Aug, 2005, at 04:35, James W. Walker wrote:
>
> Yes I do, though the plan is to save files in the existing format so 
> any other applications
> (or old versions of our own applications) can still read the files. I 
> could use a custom
> group perhaps. Or I could just #include "Globals.h" and patch it up if 
> it changes later.
>
> I am not asking anyone else to do any work, but I would not want to 
> take Quesa in a
> direction which would upset anyone's plans.
>

Re: Exceptions

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

On Aug 26, 2005, at 6:53 AM, Jose' Cruanyes wrote:

> Hi, I'm having problems with the Trimesh optimizer
>
> in a Carbon release build, compiled with CW 8.3, the exception are  
> not catched, inside the lib, jumping out to the program that  
> doesn't expect them and exits
> in the debug version this doesn't happens, nor in windows compiled  
> with VC++ 6.0
>
> in the meantime, I've added a test in the code to avoid the  
> exception to occur in my case (no edges attributes)

I don't know why an exception would not be caught, since  
E3TriMesh_OptimizeData has a catch (...) block.  However I do see why  
there was no exception in the debug build.  E3Memory_AllocateClear is  
asked to allocate a block of size 0, but due to the debugging header  
and trailer, the call to calloc actually allocates a nonzero sized  
block.  Whereas in the release build, E3Memory_AllocateClear will  
return NULL.

I agree with the change you made to  
TriMeshOptimizer::BuildEdgeAttributes.

Exceptions

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

Hi, I'm having problems with the Trimesh optimizer

in a Carbon release build, compiled with CW 8.3, the exception are not 
catched, inside the lib, jumping out to the program that doesn't expect 
them and exits
in the debug version this doesn't happens, nor in windows compiled with 
VC++ 6.0

in the meantime, I've added a test in the code to avoid the exception 
to occur in my case (no edges attributes)

Pax et Bonum

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

Re: proposed new API: Q3Memory_GetStatistics

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

Il giorno 25/ago/05, alle 20:04, James W. Walker ha scritto:
> So I propose an API like the following:
>

> By the way, how widespread is compiler support for long long (64 bit) 
> integer types?  I don't see long long in the C++ standard, though it 
> is in C99.

The following compilers have long long support,
CodeWarrior
gcc and derivatives (MinGW, CigWin ecc)
MS Visual C 8 (2005)
		(perhaps also 7 (.NET) but I'm not sure)
VisualAge (IBM compiler)
ICC (Intel)

a good 98% of the market outside your all-time favorite VC++ 6.0 (that 
has stil more than 50%)


Pax et Bonum

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

Re: proposed new API: Q3Memory_GetStatistics

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

Roger Holmes <rog...@mi...> wrote:

>Sounds good. Can we get anything out of OpenGL? VRAM usage would be useful.

I can see how that information could be useful, but I don't know how 
to get it.  And of course a Quesa renderer does not necessarily use 
OpenGL.

>If we are going to have max bytes, why not max allocations too?

Now that I can easily add.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: proposed new API: Q3Memory_GetStatistics

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

Sounds good. Can we get anything out of OpenGL? VRAM usage would be 
useful.
If we are going to have max bytes, why not max allocations too?

I currently only use CodeWarrior and XCode, so I can't add anything 
about long long,
except to say that the size of short, int, long , long long are not 
defined by the
language. You could find a compiler where they are all the same. If I 
were to write
a C compiler for the old mainframe I have at home, all of them would be 
48 bits,
(actually 12 decimal digits otherwise indexing wouldn't work). Mind you 
there
would be no need for Quesa - it doesn't have a screen, nor even a 
terminal.

Roger.




On 25 Aug, 2005, at 19:04, James W. Walker wrote:

> One might be curious about Quesa memory usage for performance tuning 
> and detecting leaks.  (Some kinds of leaks might not be detected by 
> the current leak detector.)  So I propose an API like the following:
>
> #define	kQ3MemoryStatisticsStructureVersion	1
>
> /*!
> 	@struct		TQ3MemoryStatistics
> 	@abstract	Parameter structure for Q3Memory_GetStatistics.
> 	@field		structureVersion	Version of this structure.
> 						Initialize to kQ3MemoryStatisticsStructureVersion.
> 	@field		currentAllocations	Current number of memory blocks allocated 
> by Quesa.
> 	@field		currentBytes		Current number of memory bytes allocated by 
> Quesa.
> 	@field		maxBytes		Maximum number of memory bytes allocated by Quesa
> 						("high-water mark").
> */
> typedef struct TQ3MemoryStatistics
> {
> 	TQ3Uns32	structureVersion;
> 	TQ3Uns32	currentAllocations;
> 	TQ3Uns64	currentBytes;
> 	TQ3Uns64	maxBytes;
> } TQ3MemoryStatistics;
>
>
> /*!
> 	@function	Q3Memory_GetStatistics
> 	@abstract	Get information about Quesa memory usage.
> 	@discussion	This function will only succeed if Quesa was compiled with
> 			Q3_DEBUG defined to be nonzero.
> 	@param		info		Structure to receive memory statistics.  You must 
> initialize
> 					the structureVersion field.
> 	@result		Success or failure of the operation.
> */
> Q3_EXTERN_API_C( TQ3Status )
> Q3Memory_GetStatistics (
> 	TQ3MemoryStatistics*	info
> );
>
>
> By the way, how widespread is compiler support for long long (64 bit) 
> integer types?  I don't see long long in the C++ standard, though it 
> is in C99.
> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

proposed new API: Q3Memory_GetStatistics

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

One might be curious about Quesa memory usage for performance tuning 
and detecting leaks.  (Some kinds of leaks might not be detected by 
the current leak detector.)  So I propose an API like the following:

#define	kQ3MemoryStatisticsStructureVersion	1

/*!
	@struct		TQ3MemoryStatistics
	@abstract	Parameter structure for Q3Memory_GetStatistics.
	@field		structureVersion	Version of this structure.
						Initialize to 
kQ3MemoryStatisticsStructureVersion.
	@field		currentAllocations	Current number of 
memory blocks allocated by Quesa.
	@field		currentBytes		Current number of 
memory bytes allocated by Quesa.
	@field		maxBytes		Maximum number of 
memory bytes allocated by Quesa
						("high-water mark").
*/
typedef struct TQ3MemoryStatistics
{
	TQ3Uns32	structureVersion;
	TQ3Uns32	currentAllocations;
	TQ3Uns64	currentBytes;
	TQ3Uns64	maxBytes;
} TQ3MemoryStatistics;


/*!
	@function	Q3Memory_GetStatistics
	@abstract	Get information about Quesa memory usage.
	@discussion	This function will only succeed if Quesa was 
compiled with
			Q3_DEBUG defined to be nonzero.
	@param		info		Structure to receive memory 
statistics.  You must initialize
					the structureVersion field.
	@result		Success or failure of the operation.
*/
Q3_EXTERN_API_C( TQ3Status )
Q3Memory_GetStatistics (
	TQ3MemoryStatistics*	info
);


By the way, how widespread is compiler support for long long (64 bit) 
integer types?  I don't see long long in the C++ standard, though it 
is in C99.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: cp extension

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

On Aug 23, 2005, at 8:02 AM, Jose' Cruanyes wrote:

> I'm trying to compile Quesa using Visual Studio, and I've noted  
> that the last file added has a .cp extension
>
> this is not common outside the Mac community, so I suggest to use  
> the .cpp.
> Visual Studio (6.0 and 2005) doesn't recognise the extension and  
> I've to set a custom build (not a big deal but better avoid it)
>
> I'm upgrading the VS projects for VS 2005 Beta 2 that is freely  
> available (and pretty well done IMHO)
>
> (the VRML parser is another part that the extension will complicate  
> the port)

Sorry, that didn't occur to me, I'm just in the habit of using .cp.   
There isn't much CVS history worth preserving on  
E3GeometryTriMeshOptimize.cp, so if you want to rename it, I wouldn't  
be opposed.  The VRML parser is another story.

cp extension

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

I'm trying to compile Quesa using Visual Studio, and I've noted that 
the last file added has a .cp extension

this is not common outside the Mac community, so I suggest to use the 
.cpp.
Visual Studio (6.0 and 2005) doesn't recognise the extension and I've 
to set a custom build (not a big deal but better avoid it)

I'm upgrading the VS projects for VS 2005 Beta 2 that is freely 
available (and pretty well done IMHO)

(the VRML parser is another part that the extension will complicate the 
port)

Pax et Bonum

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

Re: Custom geometries

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

On 23 Aug, 2005, at 04:35, James W. Walker wrote:

Yes I do, though the plan is to save files in the existing format so 
any other applications
(or old versions of our own applications) can still read the files. I 
could use a custom
group perhaps. Or I could just #include "Globals.h" and patch it up if 
it changes later.

I am not asking anyone else to do any work, but I would not want to 
take Quesa in a
direction which would upset anyone's plans.


>
>> The whole concept of custom geometries, are we ready for them, the 
>> pros and cons.
>
> Do you have a specific use in mind for this?  It's not a bad idea, but 
> if nobody is asking for it, I'm not sure it should take precedence 
> over all the other bugs and feature requests.

Re: Custom geometries

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

On Aug 22, 2005, at 11:28 AM, Roger Holmes wrote:

> The whole concept of custom geometries, are we ready for them, the  
> pros and cons.

Do you have a specific use in mind for this?  It's not a bad idea,  
but if nobody is asking for it, I'm not sure it should take  
precedence over all the other bugs and feature requests.

Custom geometries

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

With QuickDraw3D, Apple were gradually opening up the extensibility.
First we had custom attributes, then custom renderers, then custom
groups. Then they dropped the technology and we started work on
Quesa.

I have been thinking about custom geometries. I had a look at the code
of one of the geometries which Apple themselves added, the Torus.
Its meta-handler just overrides six methods, kQ3XMethodTypeObjectNew,
kQ3XMethodTypeObjectDelete,  kQ3XMethodTypeObjectDuplicate,
kQ3XMethodTypeGeomCacheNew, kQ3XMethodTypeGeomGetAttribute
and kQ3XMethodTypeGeomUsesSubdivision.

It is possible to register a custom class which inherits from geometry, 
and
to override the first three of the methods. The next three are private 
to
Quesa, or at least they are in E3Globals.h, which is not supposed to be
a public API.

The 'get geometry attribute' method seems a fairly straightforward thing
to do. In fact I'm surprised it is not built into the geometry class 
itself,
but there may be some gotcha that makes this difficult. Anyway I
don't see too much of a problem if we were to make the constant
public by moving it to Quesa.h.

'uses subdivision' is not even a real method, it merely returns
true or false. Again I personally don't see this as much of an issue.

The kQ3XMethodTypeGeomCacheNew method is actually what
gets called when we call Q3Geometry_GetDecomposed, so in
retrospect the name could maybe have been
kQ3XMethodTypeGeomDecompose. To me this seems a
rather better name to make public. Another alternative I guess
would be to open up the submit methods for render, write,
pick and calculate bounds modes. This would of course be
a bit more complicated.

Your thoughts please on :
The whole concept of custom geometries, are we ready for them, the pros 
and cons.
The way (if found beneficial) of opening up the API to make this 
possible.

Roger Holmes.

Quesa with Cocoa

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

Is there a Queeg-like skeleton around which one can construct 
Cocoa-based Quesa programs?  Can Quesa even be used with Cocoa?  I 
assume it most surely can.  I'm quite new to Cocoa but I'm trying to 
convert my expertise as much as possible.

Thanks.

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

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

[ quesa-Bugs-907855 ] TriMesh shading wrong when no vertex normals are present

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: TriMesh shading wrong when no vertex normals are present

Initial Comment:
(note, this issue could also be solved by bug 907849, as any 
triangles that shared vertex attributes would push us onto the 
break-down-and-push-into-tribuffer path)


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

When rendering a TriMesh with no vertex UVs in Quesa 1.6d16, the 
shading is interpolated across each triangle, as if we had vertex 
normals.  The correct appearance would be for each triangle to 
have a uniform shading, for a faceted appearance.  See attached 
sample 3DMF and picture showing the result in QD3D and Quesa.

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

OK, had a quick look at this. The problem is that the triangles in 
the TriMesh share vertices, and we don't correctly handle the case 
where a shared vertex inherits different values from the triangles 
which reference it.

The model was of a box, so if you consider two of the top/face 
triangles like:

        /|         |
     V_______
     |
  /  |
  ---|
  \  |

I.e., on triangle on the top of the box whose normal points up, and 
one triangle on the side of the face whose normal points out.

What happens at the moment is that when we're looking for the 
normal for V, we check to see if V specifies it. It doesn't, so we 
pick the first triangle which references V and use its normal. This 
then means that when the second triangle is rendered, it also 
references V and so ends up with the wrong normal (which 
produces the smoothed off effect).

The general way to handle this is to introduce new vertices into the 
TriMesh when we see that shared vertices have different parents - 
it looks like this is what QD3D was doing, as the same problem 
occurs with colours (e.g., if the top triangle was red and the side 
one was blue, you would get an all-red and all-blue triangle in 
QD3D: but we'll do a red-to-blue fade over the two triangles).


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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/15/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 08/01/05 09:05

Message:
Logged In: YES 
user_id=433183

I belieive this is now fixed in CVS for the interactive renderer.

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

Comment By: James W. Walker (jwwalker)
Date: 07/27/05 22:51

Message:
Logged In: YES 
user_id=433183

Does this actually refer to vertex normals, not vertex UVs?

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

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

[ quesa-Bugs-902592 ] TriMesh Colours go to the wrong faces

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

Bugs item #902592, was opened at 02/23/04 03:00
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902592&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: James W. Walker (jwwalker)
Summary: TriMesh Colours go to the wrong faces

Initial Comment:
Quesa 1.6d18
OS used: Windows XP (not tested on Mac)

This bug affects cube shaped TriMeshes with 8 vertices 
which specify a colour attribute per face.

I believe that the described behaviour occurs because 
the model has >1 faces referencing the same vertex.


Behaviour:
The following strange behaviour was observed:

Setting Attribute 0 controls faces 0,4,5
Setting Attribute 1 controls face 1
Setting Attribute 2 controls faces 2,6,7,8,9,10
Setting Attribute 3 controls faces 3,11
Setting Attributes 4..11 has no visual effect

The same model renders correctly under QD3D - 
attribute n controls face n for 0<=n<12.


Workaround:
An effective workaround is to build the cube with 
duplicate vertices such that no vertex is shared by two 
faces.

Example trimesh included as a 3DMF.
Best viewed with kQ3InterpolationStyleNone

.triMeshAttributeSet = 0
.numTriangles = 12
.*triangles = 
    (4,6,2) ,
    (4,2,0) ,
    (1,3,7) ,
    (1,7,5) ,
    (5,7,6) ,
    (5,6,4) ,
    (0,2,3) ,
    (0,3,1) ,
    (2,6,3) ,
    (3,6,7) ,
    (4,0,1) ,
    (4,1,5) 
.numTriangleAttributeTypes = 1
.triangleAttributeTypes =
    .attributeType = kQ3AttributeTypeDiffuseColor
    .data =
    (1,0,0),
    (1,1,1),
    (1,1,1),
    remaining 9 faces (1,1,1)
.numEdges = 0
.edges = 0
.numEdgeAttributeTypes = 0
.*edgeAttributeTypes = 0
.numPoints = 8
.*points = 
    (0,0,0),
    (1,0,0),
    (0,1,0),
    (1,1,0),
    (0,0,1),
    (1,0,1),
    (0,1,1),
    (1,1,1)
.numVertexAttributeTypes =  0
.*vertexAttributeTypes = 0
.bBox = (0,0,0) , (10,10,10) , kQ3False

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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/15/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 08/01/05 09:03

Message:
Logged In: YES 
user_id=433183

I believe this is now fixed in CVS for the interactive renderer.

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

Comment By: James W. Walker (jwwalker)
Date: 06/26/05 00:32

Message:
Logged In: YES 
user_id=433183

Quesa does not handle per-face colors correctly, it only uses them to infer 
vertex colors.  Therefore you get smooth color gradations when you 
expected sharp boundaries.

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

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

[ quesa-Bugs-907872 ] Textured geometry without UVs rendered as white

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: Textured geometry without UVs rendered as white

Initial Comment:
Unlike QD3D, geometry which is submitted without UVs while a 
texture is active will be rendered as white. On QD3D, it will be 
rendered as if no texture was active.

This was broken deliberately in 1.6d18 - we could optionally post a 
notice if we detect this case, as I have assumed it's not terribly 
common (and the QD3D behaviour is probably a side-effect rather 
than deliberate)

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

>Comment By: SourceForge Robot (sf-robot)
Date: 08/12/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 07/28/05 22:41

Message:
Logged In: YES 
user_id=433183

I believe this is now fixed in CVS.

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

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

[ quesa-Feature Requests-1256902 ] Custom Renders for Reflections and Shadows

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

Feature Requests item #1256902, was opened at 2005-08-11 17:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=1256902&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: MacFan (granit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom Renders for Reflections and Shadows

Initial Comment:
As I was reading the Quick Draw 3D files at apple.com I Found that 
it supports Custom renders so I could create my own or use another. 
This means I could use raytracing to create Reflection and I knew a 
lot of people want quesa to have reflects.  Even Alias's Maya, which 
uses opengl as well, needs to use raytracing to do reflections.

This is the same with shadows, because these days it's done by the 
hardware, not software.  So we could use the video card to make 
shadows

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

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

Re: High-res printing

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

On Aug 10, 2005, at 17:30, James W. Walker wrote:

> "Edward K. Chew" <ek...@lg...> wrote:
>
>> Well, I managed to compile quesa despite the permissions problem,
>> though my SDK directory is most likely incomplete.  cvs craps out in
>> the middle of quesa/SDK/Examples, so I started out with only that.
>> I quickly inferred the existence of an quesa/SDK/Includes directory,
>> so I checked that out separately.  At present, then, my copy
>> consists of the following:
>>
>> quesa
>>     Development
>>     Documentation
>>     SDK
>>         Examples
>>             Background Test
>>             Camera Test
>>             Dump Group
>>             Geom Test (incomplete)
>>         Includes
>>         Libraries (created during the build, I think)
>>
>> If someone could tell me what I might still be missing in terms of
>> examples, etc., I could probably check out the rest of it in a
>> piecemeal fashion.  I am not a cvs guru, and have yet to find a way
>> to get at a listing of the whole directory hierarchy (cvs log, for
>> example, dies at the same point as checkout).
>>
>
> The Examples folder also has Import Test, Light Test, Shader Test,  
> Qut, Support Files, and Viewer Test.  The SDK folder also includes  
> an Extras folder (including my new VRML reader plug-in) and a  
> Models folder.  The Models folder is just elementary test models,  
> not as fancy as the ones in Support Files/Models.

Thanks!  I think I got everything other than that pesky Geom Test  
using the following script.  (I stuck a -l option in there at the  
last moment to log you in the first time.  Hopefully, I did that right.)

#!/bin/sh
cvs_opts="-d :pserver:ano...@cv...:/cvsroot/quesa"
while getopts l opt; do
     case $opt in
     l)    cvs $cvs_opts login;;
     esac
done
cvs_opts="$cvs_opts -z 9 co"
cvs $cvs_opts "quesa/Development"
cvs $cvs_opts "quesa/Documentation"
cvs $cvs_opts "quesa/SDK/Examples/Background Test"
cvs $cvs_opts "quesa/SDK/Examples/Camera Test"
cvs $cvs_opts "quesa/SDK/Examples/Shader Test"
cvs $cvs_opts "quesa/SDK/Examples/Qut"
cvs $cvs_opts "quesa/SDK/Examples/Support Files"
cvs $cvs_opts "quesa/SDK/Examples/Viewer Test"
cvs $cvs_opts "quesa/SDK/Includes"
cvs $cvs_opts "quesa/SDK/Extras"
cvs $cvs_opts "quesa/SDK/Models"

Re: High-res printing

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

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

>>  I seem to have hit a snag in checking out quesa.  cvs gives me an 
>>error when I reach the Geom Test example:
>>
>>  cvs checkout: failed to create lock directory for 
>>`/cvsroot/quesa/quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj' 
>>(/cvsroot/quesa/quesa/SDK/Examples/Geom Test/Geom 
>>Test.xcodeproj/#cvs.lock): Permission denied
>>  cvs checkout: failed to obtain dir lock in repository 
>>`/cvsroot/quesa/quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj'
>>  cvs [checkout aborted]: read lock failed - giving up
>

This seems to be a problem at SourceForge.  I also get this error 
when I try to check out Geom Test anonymously, though I do not get 
the error when I use my password.  I'll report it to SourceForge 
support.

>Well, I managed to compile quesa despite the permissions problem,
>though my SDK directory is most likely incomplete.  cvs craps out in
>the middle of quesa/SDK/Examples, so I started out with only that.
>I quickly inferred the existence of an quesa/SDK/Includes directory,
>so I checked that out separately.  At present, then, my copy
>consists of the following:
>
>quesa
>     Development
>     Documentation
>     SDK
>         Examples
>             Background Test
>             Camera Test
>             Dump Group
>             Geom Test (incomplete)
>         Includes
>         Libraries (created during the build, I think)
>
>If someone could tell me what I might still be missing in terms of
>examples, etc., I could probably check out the rest of it in a
>piecemeal fashion.  I am not a cvs guru, and have yet to find a way
>to get at a listing of the whole directory hierarchy (cvs log, for
>example, dies at the same point as checkout).

The Examples folder also has Import Test, Light Test, Shader Test, 
Qut, Support Files, and Viewer Test.  The SDK folder also includes an 
Extras folder (including my new VRML reader plug-in) and a Models 
folder.  The Models folder is just elementary test models, not as 
fancy as the ones in Support Files/Models.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: High-res printing

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

On Aug 9, 2005, at 09:15, Edward K. Chew wrote:

> I seem to have hit a snag in checking out quesa.  cvs gives me an  
> error when I reach the Geom Test example:
>
> cvs checkout: failed to create lock directory for `/cvsroot/quesa/ 
> quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj' (/cvsroot/quesa/ 
> quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj/#cvs.lock):  
> Permission denied
> cvs checkout: failed to obtain dir lock in repository `/cvsroot/ 
> quesa/quesa/SDK/Examples/Geom Test/Geom Test.xcodeproj'
> cvs [checkout aborted]: read lock failed - giving up

Well, I managed to compile quesa despite the permissions problem,  
though my SDK directory is most likely incomplete.  cvs craps out in  
the middle of quesa/SDK/Examples, so I started out with only that.  I  
quickly inferred the existence of an quesa/SDK/Includes directory, so  
I checked that out separately.  At present, then, my copy consists of  
the following:

quesa
     Development
     Documentation
     SDK
         Examples
             Background Test
             Camera Test
             Dump Group
             Geom Test (incomplete)
         Includes
         Libraries (created during the build, I think)

If someone could tell me what I might still be missing in terms of  
examples, etc., I could probably check out the rest of it in a  
piecemeal fashion.  I am not a cvs guru, and have yet to find a way  
to get at a listing of the whole directory hierarchy (cvs log, for  
example, dies at the same point as checkout).

On Aug 8, 2005, at 14:07, James W. Walker wrote:

> This sounds like a rowBytes limit, so it prompted me to search for  
> rowBytes usage in Quesa.  I found a bug in E3MacDrawContext.c,  
> where it was directly reading the rowBytes field of a PixMapHandle  
> instead of using GetPixRowBytes.  I checked in a fix.  So you might  
> want to check that out, and try the big-buffer method again.

Alas, this did not fix the problem.  I guess I will stick with the  
workaround for now.  By the way, in case you are curious what the bad  
output looks like, I saved two print jobs as PDF files and posted  
them here:

http://members.kos.net/lgl/printingbug/

-Ted

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
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: SourceForge Robot (sf-robot)
Date: 08/09/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 07/25/05 23:04

Message:
Logged In: YES 
user_id=433183

The last comment by the submitter seems to indicate that the
fix for bug #973022 may be considered to fix this.  Unless
clarification is forthcoming, such as a good test case, I will
consider this fixed.

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

Comment By: Frank Condello (pox)
Date: 06/15/04 17: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: 06/15/04 15: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