quesa-develop — Mailing list for Quesa development

Re: Marquee selection speed

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

On Jul 1, 2004, at 1:03 PM, Roger Holmes wrote:

> I have been investigating why my program is so slow when a user does
> a marquee selection. I set up a reasonable test case of 50 to 60 
> spheres
> and pulled out a rectangle around about 80% of the spheres. Quesa
> returned about 28000 hits, and my program works through the list asking
> for the data on each of the hits in turn.

How did 50 to 60 spheres turn into 28000 hits?  What kind of hit data 
are you asking for?
--
<http://www.jwwalker.com/>

Marquee selection speed

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

I have been investigating why my program is so slow when a user does
a marquee selection. I set up a reasonable test case of 50 to 60 spheres
and pulled out a rectangle around about 80% of the spheres. Quesa
returned about 28000 hits, and my program works through the list asking
for the data on each of the hits in turn. I find that when I ask for 
item N
the routine e3pick_hit_find is chasing up a list to a depth of N. So in 
total
that is N squared over 2 - about 392000000 times that it has to do
"currentHit = currentHit->nextHit;"
I think this might be why this section of my program might be so slow.

Would it be feasible to use an array instead of a chain?

If so, any hints on how to do it would be appreciated.

Roger.

Re: missing api functions?

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

Whoops.  Just needed a couple of headers.


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

missing api functions?

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

I'm trying to create trimeshes from scratch, by reading descriptions 
from a home-grown file format (a terrain file format of my own design, 
basically just grayscale extrusion values for a grid of vertices).  
Obviously, I need geometry and texture.  I have had complete success 
with the geometry, it works perfectly.  I can make a trimesh easily 
enough (using Queeg's QGTriMesh class).  However, I want to add a 
texture to the trimesh.  I don't have any particular affinity for 
Nanosaur in this regard but it is the only existing template I have to 
work from, so I'm trying to adapt the relevant code.

First of all, aside from the way I show below, is there some other way 
to create a texture and then attach it to a trimesh?  I'm not sure what 
my options are for either creating textures or for associating them with 
particular trimeshes.

Second, I am getting the following three errors which suggest I can't 
use Nanosaur's method in the first place:

Error   : undefined identifier 'Q3MemoryStorage_New'
QGTriMesh.cpp line 140   emoryStorage_New((unsigned 
char*)blankTextureArray, textureDim * textureDim * 2);

Error   : undefined identifier 'Q3MipmapTexture_New'
QGTriMesh.cpp line 151   TQ3TextureObject texture = 
Q3MipmapTexture_New(&mipMap);

Error   : undefined identifier 'Q3TextureShader_New'
QGTriMesh.cpp line 152   TQ3SurfaceShaderObject shader = 
Q3TextureShader_New(texture);

Here is my code (acting on an existing just-made trimeshdata object.  
this code is just added to the QGTriMesh ctor):

            unsigned short* blankTextureArray = new unsigned 
short[textureDim * textureDim];
           
            TQ3Mipmap mipMap;
            mipMap.image = Q3MemoryStorage_New((unsigned 
char*)blankTextureArray, textureDim * textureDim * 2);
            mipMap.useMipmapping = kQ3False;    //Just one layer of 
mipmaps (basically a pixmap)
            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);
           
            Q3AttributeSet_Add(mTriMeshData.triMeshAttributeSet, 
kQ3AttributeTypeSurfaceShader, &shader);
            Q3Object_Dispose(shader);


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

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

Re: qd3d manual

[Andy S. <as...@bl...>]

>que...@li... writes:
>
>
>Wow, 1762 pages.  I think that's what I was looking for.  Thanks.
>
I find unbookmarked PDFs like this very annoying to navigate, so I added
bookmarks to my copy of the QD3D book manually with Acrobat. It is now
much nicer to use.

So - (unfortunately, I suspect the answer to this question is "no", but
anyway...) Is there any legal way that we could make this bookmarked PDF
version available to Quesa users? I imagine it's not just a matter of
putting it on a website somewhere because I'm sure you would have the
original PDF available on quesa.org if this were the case.

Yours,

The Magic Acrobat Fairy.

Re: LOD groups

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

Jose' Cruanyes wrote:

>first approach, just to introduce the discussion...
>
>groups inside a LOD group
>each group with bounding box/sphere
>each group has some sort of minimal requirements (area of projection in=20
>pixels, distance from POV, minimum angle, moon phase, you name it)
>and the submit loop inside the LOD group choose wich one to submit...
>
>This Switcher group can be also handy to texture and other types of=20
>animation, suffice to change the criterion used to choose which=20
>subelement to submit...

Yes, calling it an "LOD group" is really a misnomer: it's more a
"dynamic group".

So interface is something like:

-----------------------------------
typedef TQ3Object (*TQ3XDynamicGroupSelectorMethod)
                             (TQ3ViewObject  theView,
                              TQ3GroupObject theGroup)

Q3_EXTERN_API_C ( TQ3GroupObject  )
Q3DynamicGroup_New (
    void
);

Q3_EXTERN_API_C ( TQ3XDynamicGroupSelectorMethod )
Q3DynamicGroup_GetSelector (
    TQ3GroupObject                theGroup
);

Q3_EXTERN_API_C ( TQ3Status )
Q3DynamicGroup_SetSelector (
    TQ3GroupObject                 theGroup,
    TQ3XDynamicGroupSelectorMethod theSelector
);
-----------------------------------

A dynamic group is a subclass of a display group, which has the
following behaviour:

1. The group can have a selector function associated with it.

2. When a dynamic group is submitted to a view, it invokes its selector
function (if any).

3. The selector is passed the view, the group, and any other state?

4. The selector returns the object to submit to the view. The object to
submit must be contained within the dynamic group.



Don't know: that gives you the basic building block, but means you have
to implement "get the distance to the camera" and "get the bounds of the
objects" and "pick an appropriate object based on distance".

All of which are doable, but perhaps there's scope to layer some kind of
LOD group on top of this object to make that easier?

Not sure what the best approach for that is - the way I did it was
purely on the distance from the center of some object to the camera, and
with appropriate units for my situation (i.e., I didn't care about
bounding volumes, as I just needed a far/medium/near transition).



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

Re: does quesa play nice with mach-o?

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

Keith Wiley wrote:

>First of all, of course, libraries are handled fairly differently in
>Mach-O projects.  I was unable to simply add the Quesa lib file to the
>project and I don't know how to interpret the Quesa lib file as a
>framework.

It depends how you want to build it - if you want to build Quesa as a
framework I believe the PB/Xcode projects have targets set up to do
that.

I don't know if they're set up to build static libraries: those work as
you'd expect though, i.e., build a .lib file then just add it to your
app project.


>#if ((defined(__MWERKS__) && __dest_os =3D=3D __mac_os && !(__INTEL__)) ||=
=20
>defined(MPW_CPLUS) || defined(MPW_C))
>    #ifndef QUESA_OS_MACINTOSH
>        #define QUESA_OS_MACINTOSH                      1
>    #endif
>#endif
>
>Any thoughts on how to kick-start Mach-O with Quesa?

It sounds like your project isn't defining one of the build constants
ahead of time, and so the auto-detection isn't picking up gcc.

You can probably pull an appropriate test for gcc out of
/usr/include/TargetConditionals.h


>Fundamentally, I don't care too much about Mach-O, except that I
>noticed that Queeg/Qut doesn't use Carbon events for Carbon
>applications.  It uses old fashioned Classic OS 9 events.  The
>preprocs in Queeg/Qut suggest that it only uses Carbon events for
>Mach-O apps, not Carbon apps, as shown here at the top of Qut.c:

This can probably be gutted to be honest, as we might as well use carbon
events for any Carbon builds of Qut - the reason the WNE stuff was in
there at all was to allow some of the apps to build as InterfaceLib apps
(i.e., not Carbon) so they could also link to QD3D.


>....which is why I'm trying to convert Queeg/Qut to Mach-O...although
>I suspect I could approach the problem from the other direction and
>try to get the Carbon version of Queeg/Qut to use Carbon events.

The latter is probably the simplest approach, as there shouldn't
anything stopping a Carbon build of Qut from using CE to get events.


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

QUESA_OBJECTS_ARE_OPAQUE

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

Hi,

I've been discussing some performance improvements with Roger off-list:
we have a couple of different approaches, but the common factor is to
make the definition of TQ3Object be opaque even within Quesa itself.

This then gives us the freedom to change how general object behaviour
happens - if the rest of the code goes through a function to get at
state, we can experiment with changes to how objects are structured
without disturbing existing code.

I've started checking in the first bits of this: you should not notice
any changes in behaviour, but there's a temporary build constant to help
this transition (QUESA_OBJECTS_ARE_OPAQUE).

That is off by default - currently turning it on will produce a lot of
build failures, but I plan to go through checking in fixes for these and
then eventually remove QUESA_OBJECTS_ARE_OPAQUE once the implementation
is hidden from callers.


-dair (in retrospect that's how it should have been from the start: I
knew it should have been, but thought "ah, that'll never change"... :-)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

does quesa play nice with mach-o?

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

Obviously Quesa gets along with Carbon just fine, as I have had no 
trouble carbonizing Queeg (only needed a couple of tweaks to get it 
going) and many of the example programs are clearly OS X native.  I made 
a rather quick attempt to turn Queeg into a Mach-O project and 
immediately faced a couple of serious problems.  First of all, of 
course, libraries are handled fairly differently in Mach-O projects.  I 
was unable to simply add the Quesa lib file to the project and I don't 
know how to interpret the Quesa lib file as a framework.  Any thoughts 
on this?  Second of all, during compiling, the Quesa.h preproc 
directives fail in numerous places, not the least of which is the 
following segment at line 93:

#if (!QUESA_OS_MACINTOSH && \
     !QUESA_OS_WIN32     && \
     !QUESA_OS_UNIX      && \
     !QUESA_OS_BE        && \
     !QUESA_OS_COCOA)
    #error Target OS not selected!

So QUESA_OS_MACINTOSH isn't defined, which means this block at the very 
top of Quesa.h failed to process correctly:

#if ((defined(__MWERKS__) && __dest_os == __mac_os && !(__INTEL__)) || 
defined(MPW_CPLUS) || defined(MPW_C))
    #ifndef QUESA_OS_MACINTOSH
        #define QUESA_OS_MACINTOSH                      1
    #endif
#endif

Any thoughts on how to kick-start Mach-O with Quesa?

Fundamentally, I don't care too much about Mach-O, except that I noticed 
that Queeg/Qut doesn't use Carbon events for Carbon applications.  It 
uses old fashioned Classic OS 9 events.  The preprocs in Queeg/Qut 
suggest that it only uses Carbon events for Mach-O apps, not Carbon 
apps, as shown here at the top of Qut.c:

#ifndef QUT_MAC_CARBON_EVENTS
    #if defined(TARGET_RT_MAC_MACHO) && (TARGET_RT_MAC_MACHO)
        #define QUT_MAC_CARBON_EVENTS                1
    #else
        #define QUT_MAC_CARBON_EVENTS                0
    #endif
#endif

...which is why I'm trying to convert Queeg/Qut to Mach-O...although I 
suspect I could approach the problem from the other direction and try to 
get the Carbon version of Queeg/Qut to use Carbon events.

Thanks for any input on this issue.

Cheers!


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

Fairly off topic

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

Has anyone seen Real Myst yet?  Woooooooooooooooooow.  They have a nice 
reflection "trick".  I'm pretty sure they make reflections by creating a 
translucent cloudy plane instead of a "reflecting" mirrored plane, and 
then extend the reflected object (flipped around of course) into the 
area behind the plane.  It's a stunning illusion.

The game also has very slick atmospheric effects.  Nice clouds and 
stars.  Pretty incredible.


________________________________________________________________________
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: can't get shadows

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

On Fri, 25 Jun 2004, Dair Grant wrote:

> Keith Wiley wrote:
>
> >This is on a G5 with a GeForce FX 5200.  What other knobs do I need to
> >tweak to get shadows going?
>
> The interactive renderer doesn't currently support shadows - I assume
> that's the renderer you're using?

Yeah...I think so.  :-)

> This is more doable now at interactive rates than when QD3D was around:
> I'm not sure if we've logged a bug already, but if not could you add one
> requesting that the IR support the cast/receive shadow styles?

Okay, I'm not sure how the whole bug business works.  I'll look at the
sourceforge site and see if I can figure it out.  I guess I won't worry
about shadows too much for now.  It's kind of eye-candy anyway.

________________________________________________________________________
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: can't get shadows

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

At 3:19 PM -0600 6/25/04, Keith Wiley wrote:

>Hacking on Queeg.  It creates directional lights and sets shadows to true.

That setting will have no effect unless you're using a renderer that 
supports shadows (most interactive renderers do not).

Cheers,
- Joe

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

Re: can't get shadows

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

Keith Wiley wrote:

>This is on a G5 with a GeForce FX 5200.  What other knobs do I need to
>tweak to get shadows going?

The interactive renderer doesn't currently support shadows - I assume
that's the renderer you're using?

This is more doable now at interactive rates than when QD3D was around:
I'm not sure if we've logged a bug already, but if not could you add one
requesting that the IR support the cast/receive shadow styles?


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

can't get shadows

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

Hacking on Queeg.  It creates directional lights and sets shadows to true.
The light is initially horizontal (no Y component of direction vector)
so I tilted it down some, set to -1, -.5, -1.  I have a scene with pillars
on a plane.  I expect to see pillar shadows cast on the ground plane, but
I don't.  I am also making the following call in the render loop:

Q3ReceiveShadowsStyle_Submit(kQ3True, mView);

This is on a G5 with a GeForce FX 5200.  What other knobs do I need to
tweak to get shadows going?

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

qd3d manual

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

On Fri, 25 Jun 2004, Keith Wiley wrote:

> On Fri, 25 Jun 2004, James W. Walker wrote:
>
> > <http://developer.apple.com/documentation/QuickTime/PDF/qd3d154.pdf>

Wow, 1762 pages.  I think that's what I was looking for.  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: using varying res models at varying distance

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

On Fri, 25 Jun 2004, James W. Walker wrote:

> <http://developer.apple.com/documentation/QuickTime/PDF/qd3d154.pdf>

I guess my searches were inadvertantly constrained to v1.6, for which I
guess there isn't a complete manual.  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: using varying res models at varying distance

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

On Jun 25, 2004, at 7:14 PM, Keith Wiley wrote:
>
> I'm not sure what subdivision means in this regard.  I'll look it up.  
> I
> haven't had any success finding QD3D manuals.  developer.apple.com 
> lists a
> couple QD3D PDFs, but none of them are manuals.  They are mostly Carbon
> specs, and Brian Greenstone's articles on general usage of QD3D, but no
> outright manuals, at least not in PDF format.
>

try

<http://www.quesa.org/other/links.html>

among others there's a live link to the official "blue" QD3D book as pdf

Pax et Bonum

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

Re: using varying res models at varying distance

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

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

>I
>haven't had any success finding QD3D manuals.  developer.apple.com lists a
>couple QD3D PDFs, but none of them are manuals.  They are mostly Carbon
>specs, and Brian Greenstone's articles on general usage of QD3D, but no
>outright manuals, at least not in PDF format.

I typed "qd3d manual" in the search field, and the 12th hit was:

<http://developer.apple.com/documentation/QuickTime/PDF/qd3d154.pdf>

That's the manual.

By the way, I have a version of that manual in which I have added PDF 
bookmarks, but I don't suppose it would be legal for me to 
redistribute that.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: using varying res models at varying distance

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

On Fri, 25 Jun 2004, James W. Walker wrote:

> One aspect of this is that Quesa has subdivision styles, one of which
> is by screen space.  However, most of Quesa's geometries do not
> actually implement screen space subdivision, as I noted in bug 967880.

I'm not sure what subdivision means in this regard.  I'll look it up.  I
haven't had any success finding QD3D manuals.  developer.apple.com lists a
couple QD3D PDFs, but none of them are manuals.  They are mostly Carbon
specs, and Brian Greenstone's articles on general usage of QD3D, but no
outright manuals, at least not in PDF format.

It is rather strange, as most of Apple's dev files are available as PDFs
of the original hard-copy Inside Mac volumes.

________________________________________________________________________
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: using varying res models at varying distance

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

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

>I have in mind a similar idea for model geometry.  Any "kind of object"
>would have multiple trimesh models that can represent it, with varying
>degrees of detail: number of vertices, edges, triangles, etc.  Depending
>on the distance an object is from the camera, the program would use the
>proper model for that distance and not use the other models for that
>object, so very low res models in the distance and high res in the
>foreground.

One aspect of this is that Quesa has subdivision styles, one of which 
is by screen space.  However, most of Quesa's geometries do not 
actually implement screen space subdivision, as I noted in bug 967880.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: LOD groups

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

Keith Wiley wrote:

>I'm not deciphering LOD.  What's that supposed to mean?

Level-of-detail.


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

Re: LOD groups

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

I'm not deciphering LOD.  What's that supposed to mean?

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

LOD groups

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

On Jun 25, 2004, at 6:07 PM, Dair Grant wrote:

> This was demo'd once for QD3D as a plug-in group type (a "level of
> detail group"), but never made it into a public release.
>
> I've used a similar scheme in the past which has worked quite well
> (nothing more complicated than the distance from the center of the
> object to the camera, and reevaluate it on each frame), but it would be
> nice to have it as a first-class group type.
>
>

we can open a discussion here...

first approach, just to introduce the discussion...

groups inside a LOD group
each group with bounding box/sphere
each group has some sort of minimal requirements (area of projection in 
pixels, distance from POV, minimum angle, moon phase, you name it)
and the submit loop inside the LOD group choose wich one to submit...

This Switcher group can be also handy to texture and other types of 
animation, suffice to change the criterion used to choose which 
subelement to submit...


Pax et Bonum

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

Re: using varying res models at varying distance

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

On Fri, 25 Jun 2004, Dair Grant wrote:

> The exact usage obviously depends on what you're trying to do, but you

I'm creating a forest setting, so I want to use this trick for two things.

One are the models in the forest, trees mainly.  To have an acceptably
distant horizon there will be a lot of models alive at any given time
(give the tree density of a realistic forest), so I want to use lower res
models as distance increases.

Secondly, I want to have fairly detailed terrain, enough that it looks
believable, but an extruded surface that spans the visible horizon will
have millions of vertices (and be drawn with an intolerably enormous
texture to get good looking patterns in the near foreground) if I don't
drop the resolution of both geometry and texture off as the individual
terrain tiles become distant from the camera.

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: using varying res models at varying distance

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

Keith Wiley wrote:

>A couple questions.  Is this a novel idea or is there existing
>research and work on this idea that I can use as a starting point so
>that I don't have to reinvent the wheel?

This was demo'd once for QD3D as a plug-in group type (a "level of
detail group"), but never made it into a public release.

I've used a similar scheme in the past which has worked quite well
(nothing more complicated than the distance from the center of the
object to the camera, and reevaluate it on each frame), but it would be
nice to have it as a first-class group type.


>How exactly is this handled by Quesa, QD3D, and VRAM?  I am unclear on
>the distinction between the existence of models in the world, and the
>action to submit them to the renderer.  If numerous objects (and their
>textures) have been opened from 3DMF files, then are they inherantly
>taking up VRAM and other resources (aside from RAM of course) just
>because they have been opened?  Or do they not use up rendering
>resources until I intentionally "submit" them?

The only thing that really takes up VRAM are buffers such as texture
data or the back/depth/front buffers.

Geometry data can be loaded into VRAM with some GL/D3D extensions, but
even then it's a hint rather than a requirement (and tends to only be
useful for completely static data, where the model is loaded once from
disk then never touched again by the app).


>Once submitted, is it just the old LRU internal scheme of the VRAM
>that clears them out?  I mean, what happens when the object crosses a
>distance threshold and I start using a different model to represent
>that object?  I assume the only action I can take in this regard is to
>start submitting the other model to the renderer, but what happens
>under the hood?  The old model is still there, right?

No, GL and D3D have no concept of "models" as such - you make an API
call that submits geometry to them, they render the geometry, and then
the "thing" that geometry represents is gone as far as they're
concerned.

Rendering the geometry produces side effects like updating the colour or
depth buffers, but texture data is really the only thing that
corresponds to "an object" (i.e., a thing that hangs around
persistently).

(this isn't quite true any more with things like VARs and VOBs, but as
per above these are recent extensions to GL and in some cases
platform-specific)


>Or are models never persistantly in VRAM and only textures hang around
>in the long term...which would explain why models must be resubmitted
>for every single rendering cycle.

Pretty much, yes.


>Lastly, does my idea sound like a good idea at all, or is it just an
>encyclopedia of complexity that basically won't work?

No, geometric level of detail can be very useful. Say you're rendering a
city, you would have a group that contains:

  - "far" representation, e.g., a  RasterizeCameraTransform and
    a little textured quad to represent a view of the city.
 =20
  - "medium" representation, e.g., a couple of textured boxes to
    represent large city blocks or significant buildings
 =20
  - "near" representation, by which time you expect most of the city
    to be out of view and hence culled (so at this point you start
    having individual textured boxes for buildings)
 =20
  - "close" representation, by which time you expect to be looking
    at a very small part of the city - most of which gets culled, and
    so you can have individual details like benches/windows/doors/etc

The exact usage obviously depends on what you're trying to do, but you
get the idea: essentially it's just mip-mapping for geometry.


-dair (there are also other approaches where you retain the entire data
set but sample parts of it depending on the distance: but the more
general purpose idea, of a group that contains other groups which it
then selects between based on distance, is probably more useful)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/