quesa-develop — Mailing list for Quesa development

Re: NURB patch documentation error

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

Yes this was a problem in QD3D.

I checked my C++ header files from before Quesa and they say

	float*					    	uKnots ; // contains numRows + uOrder values
	float*					    	vKnots ; // contains numColumns + vOrder values

Roger.



On Friday, August 27, 2004, at 10:53  pm, James W. Walker wrote:

> It looks like the documentation of TQ3NURBPatchData is wrong, both in 
> QuesaGeometry.h and in the QD3D manual.  I thought I'd mention it here 
> before changing QuesaGeometry.h, just in case I am misunderstanding 
> something.
>
> The description of the uKnots field says "Array of knots in the u 
> parametric direction.  The number of these knots is the sum of uOrder 
> and numColumns.  The values must be nondecreasing."  That implies that 
> numColumns is the number of control points in the u direction. But the 
> description of numColumns is "Number of control points in the v 
> parametric equation.".  So, at least one of these must be wrong. I've 
> come to the conclusion that the descriptions of numRows and numColumns 
> are swapped.  That seems to be consistent with the NURB patch example 
> in Geom Test.
> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Drag & Drop?

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

James Dessart wrote:

>On Mac OS X, do any Quesa views support drag & drop? Or is this left to=20
>application developers?

=46or a general view, it's left to application developers: the "view" is
just a place to render content, so where that content comes from
(structured as a 3DMF, generated dynamically from some other data
structure, etc) is up to the app.

=46or the TQ3Viewer object, it should be able to support drag and drop
(since it can only draw one thing: a 3DMF model). I'm not sure if we
ever implemented that side of it, but for a simple "display a 3D model
and let the user drag in new content to display that" then that would be
the way to go (subject to any bugs in the viewer).


>In any case, is there a standard flavour for 3DMF drags?

The QD3D viewer library was probably the closest thing to an official
standard: I imagine the flavour code would just be '3DMF', and the data
would be the data from a 3DMF file.


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

Drag & Drop?

[James D. <ja...@ro...>]

On Mac OS X, do any Quesa views support drag & drop? Or is this left to 
application developers? In any case, is there a standard flavour for 
3DMF drags?

Thanks,
James

Re: NURB patch documentation error

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

Bruce Director <ba...@ds...> wrote:

>Last year, in the process of working with Yotam Gingold on a NURB 
>bug, I thought that the row and column definitions were reversed. 
>I had provided an example where there were 3 "rows" and 58 
>"columns", but in order to render the NURB curve correctly I had to 
>set numRows to 58 and numColumns to 3.  Here is his answer:
>
>>I re-read the QD3D documentation regarding rows and columns, and I believe
>>what you think is "reversed" is actually correct.  To QD3D, your model's
>>controlPoints[0-2] are the first row, [3-5] are the second row, and so on.
>>Thus there are 58 rows and 3 columns.  It is good to know then that QD3D
>>is "correct".

That discussion doesn't say anything about what's u and what's v, so 
I don't see how it sheds any light on my argument.

>I think my misunderstanding had to do with thinking the 2-D array of 
>control points was stored as a 1-D array in column major order 
>instead of row major order.

I am aware that the array is stored in row major order, so if I have 
a misunderstanding, that's not it.

Let's consider the code in Geom Test, createGeomNURBPatch.  Since 
uKnots is an array of 8 values, and uOrder is 4, there should be 4 
control points on the u axis.  Similarly, vKnots has 6 values, and 
vOrder is 3, so there should be 3 control points on the v axis. 
However, numRows is 3 and numColumns is 4, which according to the 
documentation means that there are 3 control points in the u 
direction and 4 control points in the v direction.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: NURB patch documentation error

[Bruce D. <ba...@ds...>]

At 2:53 PM -0700 8/27/04, James W. Walker wrote:
>It looks like the documentation of TQ3NURBPatchData is wrong, both 
>in QuesaGeometry.h and in the QD3D manual.  I thought I'd mention it 
>here before changing QuesaGeometry.h, just in case I am 
>misunderstanding something.
>
>The description of the uKnots field says "Array of knots in the u 
>parametric direction.  The number of these knots is the sum of 
>uOrder and numColumns.  The values must be nondecreasing."  That 
>implies that numColumns is the number of control points in the u 
>direction. But the description of numColumns is "Number of control 
>points in the v parametric equation.".  So, at least one of these 
>must be wrong. I've come to the conclusion that the descriptions of 
>numRows and numColumns are swapped.  That seems to be consistent 
>with the NURB patch example in Geom Test.
>--
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>

Last year, in the process of working with Yotam Gingold on a NURB 
bug, I thought that the row and column definitions were reversed.   I 
had provided an example where there were 3 "rows" and 58 "columns", 
but in order to render the NURB curve correctly I had to set numRows 
to 58 and numColumns to 3.  Here is his answer:

>I re-read the QD3D documentation regarding rows and columns, and I believe
>what you think is "reversed" is actually correct.  To QD3D, your model's
>controlPoints[0-2] are the first row, [3-5] are the second row, and so on.
>Thus there are 58 rows and 3 columns.  It is good to know then that QD3D
>is "correct".

I think my misunderstanding had to do with thinking the 2-D array of 
control points was stored as a 1-D array in column major order 
instead of row major order.

Bruce

Re: Transparency issues?

[James D. <ja...@ro...>]

On 30-Aug-04, at 1:24 PM, James W. Walker wrote:

>> 		case k32ARGBPixelFormat:
>> 			mipmap.pixelType = kQ3PixelTypeARGB32;
>
> I suggest that you try kQ3PixelTypeRGB32 in this case.

I wasn't sure whether it would look ignore the first or last byte, as 
alpha, so I didn't take that one. Thanks!

James

Re: Transparency issues?

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

James Dessart <ja...@ro...> wrote:

>		case k32ARGBPixelFormat:
>			mipmap.pixelType = kQ3PixelTypeARGB32;

I suggest that you try kQ3PixelTypeRGB32 in this case.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Transparency issues?

[James D. <ja...@ro...>]

On 27-Aug-04, at 6:32 PM, James W. Walker wrote:

> Sounds like a bug, the question is whether it's Quesa's bug or your 
> bug. :-)  I tried a quick example of a 32-bit non-alpha texture with a 
> transparency color, and it looked reasonable.  Maybe you could show us 
> the code where you set up the texture from the GWorld.

Might be my bug, I don't know.

I'll have to give a bit of explanation on some stuff... the member 
mSourceGWorld is a PowerPlant LGWorld, a wrapper around a GWorld. This 
particular instance I get from some code I wrote to decompress an image 
file from disk, using QuickTime's ImageCompression components. I've 
tried against photoshop format files and tiff files. It seems there's 
no GIF decoder in the QuickTime I've got here, so I couldn't test with 
those. I set the depth of the GWorld elsewhere, and have tried 16, 24 
and 32. The only one that seems to take the transparency colour into 
account is the 16-bit depth GWorld-based texture.

mImageGroup is a TQ3Object, the same for m_Q3_display_object. 
m_Q3_display_object has been initialized in the super class' 
constructor.

Below the following code is the function for creating the rectangle and 
assigning the texture coordinates, etc.

Here's the code that creates the texture object and assorted other 
components:

	Rect theBounds;
	
	mSourceGWorld->GetBounds( theBounds );
	
	// Create the texture
	PixMapHandle thePixMap = GetGWorldPixMap( 
mSourceGWorld->GetMacGWorld() );
	
	TQ3Mipmap mipmap;
	mipmap.pixelType = kQ3PixelTypeUnknown;
	
	switch( (*thePixMap)->pixelFormat )
	{
		case k32RGBAPixelFormat:
			mipmap.pixelType = kQ3PixelTypeRGB32;
			mipmap.bitOrder = kQ3EndianBig;
			mipmap.byteOrder = kQ3EndianBig;
			break;
		
		case k32ARGBPixelFormat:
			mipmap.pixelType = kQ3PixelTypeARGB32;
			mipmap.bitOrder = kQ3EndianBig;
			mipmap.byteOrder = kQ3EndianBig;
			break;

		case k16BE555PixelFormat:
			mipmap.pixelType = kQ3PixelTypeRGB16;
			mipmap.bitOrder = kQ3EndianBig;
			mipmap.byteOrder = kQ3EndianBig;
			break;

		case k16BE565PixelFormat:
			mipmap.pixelType = kQ3PixelTypeRGB16_565;
			mipmap.bitOrder = kQ3EndianBig;
			mipmap.byteOrder = kQ3EndianBig;
			break;
		
		case k24BGRPixelFormat:
			mipmap.pixelType = kQ3PixelTypeRGB24;
			mipmap.bitOrder = kQ3EndianBig;
			mipmap.byteOrder = kQ3EndianLittle;
			break;
	}
	
	if( mipmap.pixelType == kQ3PixelTypeUnknown )
	{
		mValid = false;
		return;
	}
	
	mipmap.reserved = 0;
	mipmap.useMipmapping = kQ3False;
	mipmap.mipmaps[0].width = theBounds.right - theBounds.left;
	mipmap.mipmaps[0].height = theBounds.bottom - theBounds.top;
	mipmap.mipmaps[0].rowBytes = (*thePixMap)->rowBytes & 0x3FFF;
	
	mImageGroup = Q3OrderedDisplayGroup_New();
	
	TQ3TransformObject theTransform = Q3RasterizeCameraTransform_New();
	Q3Group_AddObjectAndDispose( mImageGroup, &theTransform );
	
	LockPixels( thePixMap );
	unsigned char *thePixels = (unsigned char *)GetPixBaseAddr( thePixMap 
);
	mipmap.image
		= Q3MemoryStorage_New( thePixels, mipmap.mipmaps[0].height *
										  mipmap.mipmaps[0].rowBytes );
	UnlockPixels(thePixMap);
	
	TQ3TextureObject textureObject = Q3MipmapTexture_New( &mipmap );
	Q3Object_Dispose( mipmap.image );
	
	TQ3TextureObject textureShader = Q3TextureShader_New( textureObject );
	Q3Group_AddObjectAndDispose( mImageGroup, &textureShader );
	
	Q3Object_Dispose( textureObject );
	
	Q3Group_AddObject( m_Q3_display_object, mImageGroup );
----
In the following, mRectangle is a TQ3GeometryObject.
Other function:
	if( !mValid ) return;

	// Create the 3D rectangle and its attributes
	float width = (inRect.right - inRect.left);
	float height = (inRect.bottom - inRect.top);
	TQ3Point3D		vertexPoints[4] = { { 0, 0, 0 },
										{ width, 0, 0 },
										{ width, height, 0 },
										{ 0, height, 0 } };
	TQ3Param2D		vertexUVs[4] = { { 0, 1.0 },
									 { 1.0, 1.0 },
									 { 1.0, 0 },
									 { 0, 0 } };
	TQ3ColorRGB		transparency = { 0.5, 0.5, 0.5 };
	
	TQ3Vertex3D		theVertices[4];
	TQ3PolygonData	thePolygonData;
	
	int n;
	
	thePolygonData.numVertices			= 4;
	thePolygonData.vertices				= theVertices;
	thePolygonData.polygonAttributeSet	= 0;
	
	for( n=0; n<4; n++ )
	{
		thePolygonData.vertices[n].point = vertexPoints[n];
		thePolygonData.vertices[n].attributeSet = Q3AttributeSet_New();
		
		if( thePolygonData.vertices[n].attributeSet != 0 )
		{
			Q3AttributeSet_Add( thePolygonData.vertices[n].attributeSet,
								kQ3AttributeTypeTransparencyColor, &transparency );
			Q3AttributeSet_Add( thePolygonData.vertices[n].attributeSet,
								kQ3AttributeTypeSurfaceUV, &vertexUVs[n] );
		}
	}
	
	mRectangle = Q3Polygon_New( &thePolygonData );
	
	if( mRectangle != 0 )
	{
		Q3Group_AddObject( mImageGroup, mRectangle );
	}
	
	for( n=0; n<4; n++ )
	{
		if( thePolygonData.vertices[n].attributeSet != 0 )
		{
			Q3Object_Dispose( thePolygonData.vertices[n].attributeSet );
		}
	}

Thanks,
James

Re: Transparency issues?

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

James Dessart <ja...@ro...> wrote:

>Here's my latest set of findings: I've been using 32 bit GWorlds for my
>mipmaps, but when I switched to 16 bit the transparency worked as
>expected. Would this be qualified as a bug? Or simply a quirk?

Sounds like a bug, the question is whether it's Quesa's bug or your 
bug. :-)  I tried a quick example of a 32-bit non-alpha texture with 
a transparency color, and it looked reasonable.  Maybe you could show 
us the code where you set up the texture from the GWorld.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

NURB patch documentation error

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

It looks like the documentation of TQ3NURBPatchData is wrong, both in 
QuesaGeometry.h and in the QD3D manual.  I thought I'd mention it 
here before changing QuesaGeometry.h, just in case I am 
misunderstanding something.

The description of the uKnots field says "Array of knots in the u 
parametric direction.  The number of these knots is the sum of uOrder 
and numColumns.  The values must be nondecreasing."  That implies 
that numColumns is the number of control points in the u direction. 
But the description of numColumns is "Number of control points in the 
v parametric equation.".  So, at least one of these must be wrong. 
I've come to the conclusion that the descriptions of numRows and 
numColumns are swapped.  That seems to be consistent with the NURB 
patch example in Geom Test.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

[ quesa-Bugs-1017906 ] NURBS patch screen space subdivision wrong

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

Bugs item #1017906, was opened at 2004-08-27 14:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1017906&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: NURBS patch screen space subdivision wrong

Initial Comment:
In Geom Test, choose the NURB Patch test and the crudest screen 
space subdivision.  The subdivision seems to be very fine, at a 
subpixel level.  (In contrast, the NURB curve seems to work OK 
with screen space subdivision.)

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

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

Re: Transparency issues?

[James D. <ja...@ro...>]

On 27-Aug-04, at 4:03 PM, James Dessart wrote:

> I seem to be having trouble when I set the attribute 
> kQ3AttributeTypeTransparencyColor on my billboard object. It seems 
> that no matter what I set it to, other than 1.0, I get some strange 
> transparency effect. In one image, the transparent part is simply the 
> darkest part of the image, and with a different transparency setting, 
> the transparent part is the border between a white background and the 
> dark part of the image.
>
> In yet another, the transparency doesn't change, regardless of the 
> transparency colour. Does anyone have any idea what might be going on 
> here? Could it be that these images have an alpha channel, and that 
> that is disrupting Quesa's setting?

Here's my latest set of findings: I've been using 32 bit GWorlds for my 
mipmaps, but when I switched to 16 bit the transparency worked as 
expected. Would this be qualified as a bug? Or simply a quirk?

James

Transparency issues?

[James D. <ja...@ro...>]

I seem to be having trouble when I set the attribute 
kQ3AttributeTypeTransparencyColor on my billboard object. It seems that 
no matter what I set it to, other than 1.0, I get some strange 
transparency effect. In one image, the transparent part is simply the 
darkest part of the image, and with a different transparency setting, 
the transparent part is the border between a white background and the 
dark part of the image.

In yet another, the transparency doesn't change, regardless of the 
transparency colour. Does anyone have any idea what might be going on 
here? Could it be that these images have an alpha channel, and that 
that is disrupting Quesa's setting?

Thanks,
James

Re: Billboarding in Quesa?

[Kevin M. <mat...@ar...>]

Perhaps a billboarding geometry type or transform would be useful so the behavior can go with a 3DMF model from one app to another?  isn't the question more than just what is easy to do within an app?

thx,

K 

On Fri, 27 Aug 2004 10:50:46 -0500, Joseph J. Strout wrote:
> At 4:30 PM +0100 8/27/04, Dair Grant wrote:
> 
>> That's more intended for GUI overlays - it might be useful to have a
>> more 3D-style billboard, that would maintain some orientation to the
>> camera while remaining fixed in other dimensions. E.g., a tree that
>> would rotate around the y axis to face the camera position, while
>> remaining fixed around z and x.
>> 
>> Don't know if that would be best as some kind of transform that would
>> position any type of geometry, or as a new geometry type (the latter
>> would be a textured quad, while the former would let you do both a
>> textured quad and something more complex).
> 
> I don't think anything new in Quesa is needed for that -- I do this 
> all the time, and it's easy enough to simply rotate those objects to 
> face the camera whenever the camera moves.  Note that some things you 
> want to have exactly face the camera (e.g. for sprites), while others 
> you want to only rotate around one axis, as in your tree example. But 
> both are easy to do yourself.
> 
> Best,
> - Joe
> 
> -- 
> ,------------------------------------------------------------------.
> |    Joseph J. Strout         Check out the Mac Web Directory:     |
> |    jo...@st...           http://www.macwebdir.com/            |
> `------------------------------------------------------------------'
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
> 

Re: Billboarding in Quesa?

[James D. <ja...@ro...>]

On 27-Aug-04, at 11:30 AM, Dair Grant wrote:

> See createTestRasterize() in Geom Test.c: if you submit a
> Q3RasterizeCameraTransform object, the x and y coordinates of vertices
> are treated as pixel coordinates (with z allowing an offset).

This is exactly what I'm looking for, thanks! However, the problem is 
that I don't necessarily know the size of the view in the code that 
creates the textured object, and it may change. Is there a way to do 
this without relying on knowing the view bounds?

Thanks,
James

Re: Billboarding in Quesa?

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

Joseph J. Strout wrote:

>I don't think anything new in Quesa is needed for that -- I do this=20
>all the time, and it's easy enough to simply rotate those objects to=20
>face the camera whenever the camera moves.  Note that some things you=20
>want to have exactly face the camera (e.g. for sprites), while others=20
>you want to only rotate around one axis, as in your tree example.=20
>But both are easy to do yourself.

Yes, I was thinking of something like a "billboard transform" object. So
you create one of these saying what axes are to be locked and what's to
track the camera, pop it in a group with your geometry, and you're done.

It is easy enough to do yourself, but I guess if we did group visibility
culling then we could also skip any setup for you as an object that
wasn't visible wouldn't need to bother tracking.


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

Re: Billboarding in Quesa?

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

At 4:30 PM +0100 8/27/04, Dair Grant wrote:

>That's more intended for GUI overlays - it might be useful to have a
>more 3D-style billboard, that would maintain some orientation to the
>camera while remaining fixed in other dimensions. E.g., a tree that
>would rotate around the y axis to face the camera position, while
>remaining fixed around z and x.
>
>Don't know if that would be best as some kind of transform that would
>position any type of geometry, or as a new geometry type (the latter
>would be a textured quad, while the former would let you do both a
>textured quad and something more complex).

I don't think anything new in Quesa is needed for that -- I do this 
all the time, and it's easy enough to simply rotate those objects to 
face the camera whenever the camera moves.  Note that some things you 
want to have exactly face the camera (e.g. for sprites), while others 
you want to only rotate around one axis, as in your tree example. 
But both are easy to do yourself.

Best,
- Joe

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

Re: Billboarding in Quesa?

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

James Dessart wrote:

>Is it possible to do billboarding in Quesa? I noticed it was mentioned=20
>in the transparency thread, but I'm not sure how to go about doing it=20
>with Quesa, and I'd like to.

See createTestRasterize() in Geom Test.c: if you submit a
Q3RasterizeCameraTransform object, the x and y coordinates of vertices
are treated as pixel coordinates (with z allowing an offset).

That's more intended for GUI overlays - it might be useful to have a
more 3D-style billboard, that would maintain some orientation to the
camera while remaining fixed in other dimensions. E.g., a tree that
would rotate around the y axis to face the camera position, while
remaining fixed around z and x.

Don't know if that would be best as some kind of transform that would
position any type of geometry, or as a new geometry type (the latter
would be a textured quad, while the former would let you do both a
textured quad and something more complex).


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

Billboarding in Quesa?

[James D. <ja...@ro...>]

Is it possible to do billboarding in Quesa? I noticed it was mentioned 
in the transparency thread, but I'm not sure how to go about doing it 
with Quesa, and I'd like to.

James

Re: Quesa - QuickDraw3d Compatability

[Lars J. <lar...@rc...>]

> It's now 32...

Thanks! :D

lj

Re: Quesa - QuickDraw3d Compatability

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

James W. Walker wrote:

>It did get done, but it's an option.  Geom Test illustrates switching=20
>the depth buffer between 32 and 16 bits.  It involves attaching a=20
>special element to the renderer.

I figured with VRAM being what it is now, we might as well flip the
default around - so the element can be there to turn it back down to 16
bits, but by default we might as well use the deeper buffer.


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

Re: Quesa - QuickDraw3d Compatability

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

Lars Jensen <lar...@rc...> wrote:

>In January, I lobbied for a default 32-bit depth buffer in Quesa. People
>seemed to think it was an OK idea, but I don't think it ever got done. I'd
>like to re-raise the issue and try to get some closure, and remove an item
>from my long-term issues list... :)

It did get done, but it's an option.  Geom Test illustrates switching 
the depth buffer between 32 and 16 bits.  It involves attaching a 
special element to the renderer.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Quesa - QuickDraw3d Compatability

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

Lars Jensen wrote:

>In January, I lobbied for a default 32-bit depth buffer in Quesa.
>People seemed to think it was an OK idea, but I don't think it ever
>got done. I'd like to re-raise the issue and try to get some closure,
>and remove an item from my long-term issues list... :)

Sorry, I thought this got checked in - there was an element added to
allow you to control the default, but the default without that was still
16.

It's now 32, so the element can be used to reduce it to 16 if you need
to conserve the VRAM.


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

Re: Quesa - QuickDraw3d Compatability

[Lars J. <lar...@rc...>]

In January, I lobbied for a default 32-bit depth buffer in Quesa. People
seemed to think it was an OK idea, but I don't think it ever got done. I'd
like to re-raise the issue and try to get some closure, and remove an item
from my long-term issues list... :)

Here are the screen shots I made at the time:

http://ljensen.com/whiplash/whiplash_qd3d.jpg <-- nice
http://ljensen.com/whiplash/whiplash_quesa.jpg <-- official d18, ugh
http://ljensen.com/whiplash/whiplash_quesa32.jpg <-- 32-bit buffer, sweet!

The third one uses an unofficial build of d18 (made by FrankC in January)
with a 32-bit buffer. As you can see, it's a big improvement on the 16-bit
version.

Other comments can be read in the thread from January (which is not very
long, and has the same title as this message).

Is this a change that can be made for real?

lj

Re: 10.2

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

Roger Holmes wrote:

>Just don't forget about my modifications (at a low priority).

Nope, am also looking at that - we can get some performance benefits
there over and above this stuff, this was just prompted by a new VBO doc
from nVidia.


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