quesa-develop — Mailing list for Quesa development

Re: quesa/Development/Source/Renderers/Interactive IRGeometry.c,1.46,1.47

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

James' change of Q3Vector3D_Length to Q3FastVector3D_Length before
comparing with 1.0 (with a tolerance) made me wonder why we need to do
the square root. Why not call Q3FastVector2D_LengthSquared instead?
The square of something close to one must be close to one.

( 1 + delta ) ^2 = 1 + 2 * delta + delta^2. As we are using the 
floating point
epsilon, delta^2 is insignificant, so we just need to compare with a new
constant of 2 * kQ3RealZero.

By the way, I think the name kQ3RealZero is a bit misleading. Real zero 
is
zero, kQ3RealZero is just a small number. How about kQ3AlmostZero?

Roger.

Opaque TQ3Object

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

Hi,

I've been through and checked in the last set of changes to make
TQ3Object opaque, which will allow us to rearrange its implementation
for some performance gains.

This is now on by default, and fingers crossed everything should still
work. However I haven't built the Windows/Unix builds so if they fail
for anyone let me know.

The QUESA_OBJECTS_ARE_OPAQUE define is still present, although it should
now be a no-op as nothing references the internal TQ3Object structure
(and so will be dropped shortly).

If anyone notices a problem, please let me know.


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

[ quesa-Bugs-901422 ] Improve kQ3ShaderUVBoundaryClamp handling

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

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

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

Initial Comment:
If GL_CLAMP_TO_EDGE is available, the Interactive Renderer 
should implement kQ3ShaderUVBoundaryClamp with this 
extension in preference to GL_EDGE.

This helps avoid seams between otherwise adjacent textures.

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

>Comment By: Dair Grant (grantd)
Date: 2004-07-15 16:48

Message:
Logged In: YES 
user_id=439944

Yes, sorry - GL_CLAMP and GL_REPEAT are the built-ins (that we 
currently use) while GL_CLAMP_TO_EDGE was the final name for the 
extension (which we should use if it's available).

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

Comment By: James W. Walker (jwwalker)
Date: 2004-07-15 16:29

Message:
Logged In: YES 
user_id=433183

You mean GL_CLAMP, there is no such thing as GL_EDGE.

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

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

Re: vertex UV bug perhaps?

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

On Thu, 15 Jul 2004, James W. Walker wrote:

> Have you set the boundary behavior to clamp rather than wrap?
> (Q3Shader_SetUBoundary, Q3Shader_SetVBoundary).  It looks like wrapping
> is the default.

Yeah, I just tried that.  It definitely had an effect.  Things look much
different now.  But for some reason it still creates a strong border
effect.  Here's what it does now:

http://www.cs.unm.edu/~kwiley/textureSliversExe2.jpg

Quite strange, huh?

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

[ quesa-Bugs-901422 ] Improve kQ3ShaderUVBoundaryClamp handling

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Improve kQ3ShaderUVBoundaryClamp handling

Initial Comment:
If GL_CLAMP_TO_EDGE is available, the Interactive Renderer 
should implement kQ3ShaderUVBoundaryClamp with this 
extension in preference to GL_EDGE.

This helps avoid seams between otherwise adjacent textures.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-07-15 09:29

Message:
Logged In: YES 
user_id=433183

You mean GL_CLAMP, there is no such thing as GL_EDGE.

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

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

Re: vertex UV bug perhaps?

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

On Jul 15, 2004, at 8:56 AM, Keith Wiley wrote:

> Upon closer inspection I guess it doesn't look like a "math" error.  It
> looks like the tile is intentionally blended at the edges to wrap 
> around
> on itself so each edge has a blended hint of the opposing edge.
>
> If that's the case, this is a feature, not a bug, and as such is 
> somewhat
> troubling.  Any advice?

Have you set the boundary behavior to clamp rather than wrap?  
(Q3Shader_SetUBoundary, Q3Shader_SetVBoundary).  It looks like wrapping 
is the default.
--
<http://www.jwwalker.com/>

Re: vertex UV bug perhaps?

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

Dair Grant, could you resend your response.  My mail reader (pine) is
claiming some sort of nondecodable error.

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

Re: vertex UV bug perhaps?

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

Keith Wiley wrote:

>Upon closer inspection I guess it doesn't look like a "math" error.=20
>It looks like the tile is intentionally blended at the edges to wrap
>around on itself so each edge has a blended hint of the opposing edge.

I suspect this is bug 901422 - if you try hacking GL_CLAMP_TO_EDGE in
where we currently use GL_EDGE, does it fix it?


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

Re: vertex UV bug perhaps?

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

Followup:
Upon closer inspection I guess it doesn't look like a "math" error.  It
looks like the tile is intentionally blended at the edges to wrap around
on itself so each edge has a blended hint of the opposing edge.

If that's the case, this is a feature, not a bug, and as such is somewhat
troubling.  Any advice?

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

Re: vertex UV bug perhaps?

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

Here's a screenshot that illustrates the problem well:
http://www.cs.unm.edu/~kwiley/textureSliversExe.jpg

Forgive the nonbeauty.  I haven't taken the time to make beautiful
textures yet.  I'm still in the development phase of course.  At any rate,
what's up with the slivers?  The UV coordinates are definitely in the
range 0 to 1...and I don't change them when I switch in a different res
texture for a tile.  The UV coordinates never change as a matter of fact.

And it can't be associated with my res-switching approach, because if I
hardcode the program to use lowest res tiles everywhere and perform now
res switch, I just get the same effect everywhere, including centered on
the user's position.

Thanks.

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

vertex UV bug perhaps?

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

I have noticed a strange behavior in the last week or so.  I have a set of
trimeshes that are perfectly square in the XZ axis (terrain tiles), with Y
extrusion points and subdivision triangulation, etc.  Pretty basic stuff.

I have a series of textures that can be mapped over the tiles.  The series
represents the same texture at varying resolutions.  For example, I might
have a series of 512,256,128,64,32,16,8,4,2,1.

Clearly, since the textures are square and the tiles are square it is
pretty simply to assign UV coordinates to each vertex based on their XZ
location in the mesh.  I make the UV coordinates fill the range 0.0 to 1.0
inclusive.

The textures always wraps (or shifts) around the ends of the tile
slightly.  So for example, if I have a texture that is just two fat bands,
each across the texture but only half the texture in height, of different
colors, like this:

RRRRRRRR
RRRRRRRR
RRRRRRRR
RRRRRRRR
GGGGGGGG
GGGGGGGG
GGGGGGGG
GGGGGGGG

...just as an example, I will get a very thin green sliver on the red edge
and a very thin red sliver on the green edge.  I get this for all the
textures, but it is more pronounced for the lower res textures (the
slivers are wider).  And yes, it does this on both X and Z.

I have hacked my way around this problem by insetting the UV coordinates,
so that they range from, say, .01 to .99, or .1 to .9, if you see what I
mean.

This does alleviate the problem, but since it chops off the edge of the
texture a little bit, the texture doesn't really "tile" perfectly with
adjacent tiles, if you see what I mean.

...and more seriously, since the sliver width varies with the resolution,
a given set of UV coordinates will work "perfectly" at only one texture
resolution (perfect meaning it barely chops off the sliver without cutting
into the "good" part of the texture).

Does anyone have any idea what's going on here?  I can live with it, but
I'd like to know why it's happening, and if it's a bug.

I can put some screen shots on the web if anyone wants to see what I'm
talking about.

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

Re: fog question

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

On 14-Jul-04, at 6:10 PM, Keith Wiley wrote:

> Is there any way to make fog on work as a function of X and Z, and not 
> of
> Y?

Not currently, though you may be able to hack it in by talking to 
OpenGL directly (perhaps using GL_EXT_fog_coord).

> However, I would like a clear blue sky to be visible overhead.  I don't
> want the fog effect to drown out the sky dome object that will hang 
> over
> the entire environment even though that dome must be fairly far away in
> order to surround the entire area of the environment.

You can place the skydome in a display group with a fogstyle object 
that has it's visibility set to false. This will override the view's 
fog settings for your skydome. I find this works best if your 
skydome/box fades to the fog colour (or becomes transparent) as it 
approaches the horizon.

Frank.

fog question

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

Is there any way to make fog on work as a function of X and Z, and not of
Y?  I am building an outdoor natural environment.  I would like to use a
"horizontal fog", one that only works as a function of X and Z.  This
would alleviate having to provide an infinitely distant visible horizon
and would add a nice ambience to the setting...as well as being
authentique to the kind of setting I am working on (rainforest).

However, I would like a clear blue sky to be visible overhead.  I don't
want the fog effect to drown out the sky dome object that will hang over
the entire environment even though that dome must be fairly far away in
order to surround the entire area of the environment.

The dome clearly has to have a radius as least as great as the radius of
the environment, so that it can span the environment without magically
cutting down through the ground.  But if I am forced to set the fog
distance that far, then the fog distance stretches across most of the
world and I lost the point of using fog in the first place, a means to
limit the range of visibility.

Any thoughts?  Thanks.

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

Re: memory leak question

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

Keith Wiley <kw...@cs...> wrote:

>Okay, so that buffer is being using by Quesa though, so I can't delete it
>until I know Quesa won't need it anymore, right?

Right.  You may find it simpler and less confusing to let Quesa 
allocate the storage by passing NULL for the buffer parameter in 
Q3MemoryStorage_New.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: memory leak question

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

On Tue, 13 Jul 2004, Joseph J. Strout wrote:

> Q3MemoryStorage_New makes a Quesa object that wraps a buffer of
> memory you provide, but it doesn't *own* that buffer -- you do.

Okay, so that buffer is being using by Quesa though, so I can't delete it
until I know Quesa won't need it anymore, right?  I mean, that seems
obvious, except that there are a number of situations where you have to
dispose of stuff after temporarily using it, for example when you get a
shader from a trimesh.  You have to dispose it when you're done, but that
doesn't kill the trimesh's shader, just some copy you got...which I find
very strange, since altering the copy you get alters the trimesh's shader
as well, so it kinda isn't a copy also.  For example, in the following
code, you have a trimeshdata.  You get a shader, then a texture, then a
mipmap, then an image.  THEN, you ditch the shader and the texure and
manipulate the image.  So you are altering a shader that belongs to the
trimeshdata (how else would this code actually change the rendered
appearance of an object, which it does do quite nicely), but at the same
time you have to delete the intermediate objects as if they DON'T belong
to the trimeshdata object.  I find it all somewhat confusing.

TQ3SurfaceShaderObject shader;
TQ3TextureObject texture;
TQ3Mipmap mipMap;
TQ3StorageObject image;
unsigned char* pixels;

Q3AttributeSet_Get(triMeshData->triMeshAttributeSet,
kQ3AttributeTypeSurfaceShader, &shader);
Q3TextureShader_GetTexture(shader, &texture);
Q3MipmapTexture_GetMipmap(texture, &mipMap);
image = mipMap.image;

Q3Object_Dispose(shader);
Q3Object_Dispose(texture);

unsigned long validSize, bufferSize;
Q3MemoryStorage_GetBuffer(image, &pixels, &validSize, &bufferSize);

unsigned short* pixelsShortPtr = (unsigned short*)pixels;
for (int i = 0; i < bufferSize / 2; i++)
	*pixelsShortPtr++ = 0;	//Just for demo purposes

//Set the pixel buffer for the trimesh
Q3MemoryStorage_SetBuffer(image, pixels, validSize, bufferSize);
Q3Object_Dispose(image);

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

Re: memory leak question

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

At 2:50 PM -0600 7/13/04, Keith Wiley wrote:

>The question is, do I have to explicitly free my array, ala:
>
>delete [] blankTextureArray;

Yes.

>or does the disposal of the mipmap.image do that because it was somehow
>associated with the array in the Q3MemoryStorage_New call?

No, it couldn't possibly do that -- Quesa doesn't know whether the 
array was allocated with new[], or with malloc, or with NewPtr, or 
with your own custom memory manager, or whatever.

Q3MemoryStorage_New makes a Quesa object that wraps a buffer of 
memory you provide, but it doesn't *own* that buffer -- you do.

Best,
- Joe

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

memory leak question

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

I'm still learning how and when Quesa/QD take care of memory for me.  For
example, to make a mipmap, I do something like this:

int bufferBytes = textureDim * textureDim * 2;
unsigned short* blankTextureArray = new unsigned short[bufferBytes];

//	MIPMAP ===========================

TQ3Mipmap mipMap;
mipMap.image = Q3MemoryStorage_New((unsigned char*)blankTextureArray,
bufferBytes);
mipMap.useMipmapping = kQ3False;
mipMap.pixelType = kQ3PixelTypeRGB16;
mipMap.bitOrder = kQ3EndianBig;
mipMap.byteOrder = kQ3EndianBig;
mipMap.reserved = nil;
mipMap.mipmaps[0].width = textureDim;
mipMap.mipmaps[0].height = textureDim;
mipMap.mipmaps[0].rowBytes = textureDim * 2;
mipMap.mipmaps[0].offset = 0;

TQ3TextureObject texture = Q3MipmapTexture_New(&mipMap);
TQ3SurfaceShaderObject shader = Q3TextureShader_New(texture);

Q3Object_Dispose(texture);
Q3Object_Dispose(mipMap.image);

Afterwhich I would traditionally assign the shader to a trimesh.  No
problem.  The question is, do I have to explicitly free my array, ala:

delete [] blankTextureArray;

or does the disposal of the mipmap.image do that because it was somehow
associated with the array in the Q3MemoryStorage_New call?

My understanding was that every new must have a delete, that I can't hand
off that allocation to another pointer for later deletion.  Am I just
wrong there or do I need to delete that array?

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

Re: speed question

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

On Tue, 13 Jul 2004, Frank C wrote:

> Why not use a combination of the two... Store all your textures in
> textureshader objects, and keep references to all of them. This way the

No good reason, except that I didn't understand the concept fully.  :-)
I'll look into some of the terms you mentioned.  I have had success
editing the pixels of the image associated with a texture, but that
requires me to edit the pixels in some buffer and load them all back into
the texture, as I said.  The idea of keeping copies of the textures around
and simply redirecting the trimesh's reference from one texture to
another seems ideal, I just need to look into how that's done.

Thanks for the tip.

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

Re: speed question

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

On 13-Jul-04, at 2:54 PM, Keith Wiley wrote:

> Two approaches:
>
> One: represent each tile as multiple trimeshes (with identical 
> geometry)
> but with different res textures.  Only submit one trimesh per tile at a
> time, as matches the distance from the camera.
>
> Two: only make one trimesh per tile, but change the texture the 
> trimesh is
> using whenever its distance crosses a threshold.

Why not use a combination of the two... Store all your textures in 
textureshader objects, and keep references to all of them. This way the 
textures will be in RAM when you need them, and you're not duplicating 
geometry. When you want to swap textures just change the trimesh's 
attribute set's texture shader ref to the one you need, or stick all 
trimeshes that use the same texture in a display group with the 
appropriate textureshader and don't thouch the trimesh's attribute set 
at all.

Frank.

Re: speed question

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

On Tue, 13 Jul 2004, Frank C wrote:

> I think I may have misunderstood your situation - if your tiles are
> using mostly different textures then yes, I see how that could help,
> but if you're only using a few textures you can set up your data to
> reuse the same textureshaders and you shouldn't have any problems.

Yeah.  Each tile represents a large chunk of ground, large enough that the
number of tile objects will be managable by the rendering engine, but
small enough that I can gain serious benefits by only activating tiles
that are relatively near the user.  It's an interesting tradeoff.

Of course, each terrain tile has a unique planar image mapped onto it,
which represents dirt, grass, water, whatnot, in a pattern that is clearly
unique to each tile...thus the basis of my original intention, which is to
use lower res textures in the distance.

Sorry, I'm not good at explaining this stuff because my knowledge of 3D
programming is adequate, but not superb.

Thanks for the help.  If I understood correctly, d18 (which I have)
doesn't do any mipmapping for me either with pixmaps or with mipmaps even
if I load a mipmap manually.  As such, I'm back to one of the questions I
asked when I started this thread:

Two approaches:

One: represent each tile as multiple trimeshes (with identical geometry)
but with different res textures.  Only submit one trimesh per tile at a
time, as matches the distance from the camera.

Two: only make one trimesh per tile, but change the texture the trimesh is
using whenever its distance crosses a threshold.

I'm not sure which method is best.  I think the second method would be
more computational because it requires reloading and copying over pixel
buffers while the first one just submits various objects that are sitting
in RAM.  Is that assessment correct?  If so, the only downside to the
first method is that is uses up RAM to store multiple trimeshes, but RAM
is fairly abundant, at least compared to VRAM.  I seriously doubt this
game could tax a modern machine's RAM.

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

Re: speed question

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

On 13-Jul-04, at 2:23 PM, Keith Wiley wrote:

> On Tue, 13 Jul 2004, Frank C wrote:
>
>> Depending on your needs this may indeed be faster than letting
>> Quesa/OpenGL handle it, since you can control exactly how many 
>> textures
>> to use whereas Quesa always uses a full set. I'm actually very
>> surprised you see a speed up when using more textures rather than just
>> using one, but maybe your full-size texture is a little much for your
>> hardware, or it's being uploaded more often than it needs to be.
>
> Another reason it helps is that I have a lot of tiles active, and at 
> their
> highest resolution I doubt they would all fit in VRAM.

I think I may have misunderstood your situation - if your tiles are 
using mostly different textures then yes, I see how that could help, 
but if you're only using a few textures you can set up your data to 
reuse the same textureshaders and you shouldn't have any problems.

Frank.

Re: mipmap data structure

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

On 13-Jul-04, at 2:05 PM, Keith Wiley wrote:

> The QD3D manual doesn't explain clearly *how* a mipmap is organized.  I
> have made mipmaps with a single texture by providing a pixel buffer to 
> the
> image parameter and setting useMipmapping to false.  To use mipmapping 
> I
> set that to true of course.  Presumably, I need to fill in the mipmaps
> array with width, height, and rowBytes that decrease by a factor of two
> from the original texture until a size 1 is reached.
>
> I am not sure what the offset parameter is or where the lower res pixel
> buffers are stored.  There is only the one image parameter.
>
> If I were to guess, I would say that each subsequent lower res texture 
> is
> appended to the image pixel buffer, and the offset for each is from the
> beginning of the image buffer, but I have not documentation on this.

That's correct - I'm not sure Quesa actually uses the offset, but 
rather calculates it on the fly (QD3D may require it however).

Frank.

Re: speed question

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

On Tue, 13 Jul 2004, Frank C wrote:

> Depending on your needs this may indeed be faster than letting
> Quesa/OpenGL handle it, since you can control exactly how many textures
> to use whereas Quesa always uses a full set. I'm actually very
> surprised you see a speed up when using more textures rather than just
> using one, but maybe your full-size texture is a little much for your
> hardware, or it's being uploaded more often than it needs to be.

Another reason it helps is that I have a lot of tiles active, and at their
highest resolution I doubt they would all fit in VRAM.  Using much much
smaller textures for most of the tiles cuts down the VRAM requirements by
a huge factor, since I drop off the texture resolution exponentially with
distance while at the same time there are a larger number of tile far away
than close by (proportional to the circumfrance of the circle at a given
radius).

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

Re: speed question

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

On Tue, 13 Jul 2004, Frank C wrote:

> On 13-Jul-04, at 1:36 PM, Keith Wiley wrote:
>
> > On Tue, 13 Jul 2004, Frank C wrote:
> >
> >> To get back to the original topic of this post, I think your reasoning
> >> for wanting mipmapping may be flawed - it's probably faster to simply
> >> _not_ use mipmapping at all, at the cost of image quality.
> >
> > By which you mean that I should use pixmaps and let the engine do it
> > automatically, or you mean I shouldn't be decreasing resolution when an
> > object is distant from the camera?
>
> To not use mipmaps you create a mipmap texture and set it's
> useMipmapping field to false... (I know it sounds weird to use a mipmap
> texture when you don't want mipmaps but that's how it's done).

No, I understand this fine.  Thanks.  This is how I've done it so far.  I
create multiple trimeshes and attach different res textures.  Then each
frame I only submit the trimesh that corresponds to the proper distance,
with lower res trimeshes appearing in the distance and the highest res
trimesh appear underneath the user's camera position.

I can do it this way, but if there are built in routines for doing this
stuff, it seems wasteful to have spare trimeshes hanging around for no
reason, especially if I am not presently reducing the vertex geometry of
the trimesh itself (which is a later plan, but for now I'm not worrying
about it because of the hassle of cleanly blending edges of terrain
tiles that are presented with differing geometry resolutions).

> Depending on your needs this may indeed be faster than letting
> Quesa/OpenGL handle it, since you can control exactly how many textures
> to use whereas Quesa always uses a full set. I'm actually very
> surprised you see a speed up when using more textures rather than just
> using one, but maybe your full-size texture is a little much for your
> hardware, or it's being uploaded more often than it needs to be.

Sorry, I don't think I'm explaining it properly.  It's not too surprsing
to me.  Each render cycle I calculate the distance from the camera to the
terrain tile in question (there are several tiles active at any given time
of course).  Each tile has multiple trimeshes, each with a texture of
different size attached to it.  I only submit the trimesh that is
appropriate for the distance.  Clearly, the rendering is faster because
many of the distant objects are mapping very very small textures to their
surfaces.  It's a much smaller buffer of pixel values to have to look
through for surface values.  Makes sense to me that it would be faster.
It offers a serious speedup, I don't remember what factor right now.

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

Re: speed question

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

On 13-Jul-04, at 1:36 PM, Keith Wiley wrote:

> On Tue, 13 Jul 2004, Frank C wrote:
>
>> To get back to the original topic of this post, I think your reasoning
>> for wanting mipmapping may be flawed - it's probably faster to simply
>> _not_ use mipmapping at all, at the cost of image quality.
>
> By which you mean that I should use pixmaps and let the engine do it
> automatically, or you mean I shouldn't be decreasing resolution when an
> object is distant from the camera?

To not use mipmaps you create a mipmap texture and set it's 
useMipmapping field to false... (I know it sounds weird to use a mipmap 
texture when you don't want mipmaps but that's how it's done).

> The program I'm writing (a game) is going to push pretty hard on the
> hardware.  Right now I'm only working on the terrain engine, without 
> any
> objects at all in the world.  I'm trying to find a way to get terrain
> tiles in the distance to render with lower res textures.  I have 
> already
> experimented with manually inserting lower res textures for distant
> objects and I get significant speedups.

Depending on your needs this may indeed be faster than letting 
Quesa/OpenGL handle it, since you can control exactly how many textures 
to use whereas Quesa always uses a full set. I'm actually very 
surprised you see a speed up when using more textures rather than just 
using one, but maybe your full-size texture is a little much for your 
hardware, or it's being uploaded more often than it needs to be.

Frank.