quesa-develop — Mailing list for Quesa development

Re: speed question

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

On Tuesday, July 13, 2004, at 05:57  pm, Keith Wiley wrote:

> The problem is, I can't figure out where in Queeg or in Qut I get 
> access
> to a TQ3RendererObject, which is required by both functions.
>
>

You can get the renderer object from the view object using 
Q3View_GetRenderer.

Re: speed question

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

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

> On Tue, 13 Jul 2004, Frank C wrote:
>
>> The default should be mid (unless Queeg/Qut are changing it behind 
>> your
>> back). Note that auto-mipmapping was introduced after the last 
>> official
>> release so it will currently only work if you compile Quesa from the
>> CVS source.
>
> Ooooooh, so this is all for naught then.  I should be using mipmaps in
> which I manually insert multiple textures at different resolutions,
> because pixmaps simply won't autodownsample at all is what you're 
> saying.
>
> Is that correct?

If you're using Quesa 1.6d18 then _neither_ will downsample (the filter 
modes don't use mipmaps in that version, whether you supply them or 
not). Mipmap rendering is only implemented in the CVS source at this 
point. I'd really recommend compiling yourself a new Quesa lib from 
source rather than using the 1.6d18 release - unless there's a current 
bug that is holding you back.

Frank.

mipmap data structure

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

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.

Am I right?

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

> The default should be mid (unless Queeg/Qut are changing it behind your
> back). Note that auto-mipmapping was introduced after the last official
> release so it will currently only work if you compile Quesa from the
> CVS source.

Ooooooh, so this is all for naught then.  I should be using mipmaps in
which I manually insert multiple textures at different resolutions,
because pixmaps simply won't autodownsample at all is what you're saying.

Is that correct?

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

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

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.

________________________________________________________________________
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 12:57 PM, Keith Wiley wrote:

> I found the constants for texture filtering:
>
> typedef enum TQ3TextureFilter {
>     kQATextureFilter_Fast                       = 0,
>     kQATextureFilter_Mid                        = 1,
>     kQATextureFilter_Best                       = 2,
>     kQATextureFilter_Size32                     = 0xFFFFFFFF
> } TQ3TextureFilter;
>
> but I'm unsure how to use them.  I have only found two functions so far
> that seem related to this:
>
> Q3InteractiveRenderer_GetRAVETextureFilter
> Q3InteractiveRenderer_SetRAVETextureFilter

That's them...

> The problem is, I can't figure out where in Queeg or in Qut I get 
> access
> to a TQ3RendererObject, which is required by both functions.

Hmmm, I've never actually used Queeg/Qut but perhaps they should wrap 
texturefilter control internally so you don't have to dig for 
pointers... sorry I can't be of much help here.

> Are these the functions I'm supposed to use to set texture filtering?
> They're both RAVE.  I thought perhaps I was supposed to be looking for 
> a
> generic solution...whatever generic means.

Yes these are a bit of a sticky point with Quesa and a result of it's 
QD3D roots, but that's how it's done. It may make sense to use a more 
generic API nowadays, and it would also make sense if textureshaders 
could override the global settings, since filtering happens per-texture 
anyway (or perhaps a new TextureFilterStyle object is in order?), but 
for the moment the RAVE filters are all we got.

> I successfully switched my code from mipmaps to pixmaps (new to me 
> since I
> haven't used pixmaps before), but the program doesn't appear to be 
> using
> lower res textures in the distance, so I think the default value is to 
> not
> filter, "fast" I think, which is what the docs say is the default, so
> that makes sense.

The default should be mid (unless Queeg/Qut are changing it behind your 
back). Note that auto-mipmapping was introduced after the last official 
release so it will currently only work if you compile Quesa from the 
CVS source.

Frank.

Re: speed question

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

On 13-Jul-04, at 12:37 PM, Keith Wiley wrote:

> On Tue, 13 Jul 2004, Frank C wrote:
>
>> Actually, only pixmaps auto-generate mipmaps (this has long been a
>> source of confusion with QD3D).
>
>> Use pixmap textures and set the quality filter to mid or best and you
>> get instant mipmaps. Well if you're using the current CVS source at
>> least...
>
> So I can create the texture as a pixmap instead of a mipmap and it
> generates the lower res textures for me...or I can use a mipmap but I 
> have
> to create and supply the downsampled textures manually.  Are both 
> points
> made correct so far?

Yes and yes...

> If so, what is the advantage of mipmaps.  They require more work, so 
> what
> do they buy you?  Do they offer more control over when resolution is
> switched, or more gradations of texture dimension?  Any advantage at 
> all?

You can use your own halving algorithm if the built-in mipmap 
generation isn't to your liking (or too slow), or for debugging 
situations where you want to visualize exactly where the mips are 
switching. More importantly, mipmap texture objects let you create 
textures that don't use mipmapping at all by setting useMipmapping to 
false and only supplying the first mip level. This can save RAM for 
objects that are never minimized (like HUDs) or just in general when 
high quality filtering isn't important or desired.

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.

Frank.

Re: speed question

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

I found the constants for texture filtering:

typedef enum TQ3TextureFilter {
    kQATextureFilter_Fast                       = 0,
    kQATextureFilter_Mid                        = 1,
    kQATextureFilter_Best                       = 2,
    kQATextureFilter_Size32                     = 0xFFFFFFFF
} TQ3TextureFilter;

but I'm unsure how to use them.  I have only found two functions so far
that seem related to this:

Q3InteractiveRenderer_GetRAVETextureFilter
Q3InteractiveRenderer_SetRAVETextureFilter

The problem is, I can't figure out where in Queeg or in Qut I get access
to a TQ3RendererObject, which is required by both functions.

Are these the functions I'm supposed to use to set texture filtering?
They're both RAVE.  I thought perhaps I was supposed to be looking for a
generic solution...whatever generic means.

I successfully switched my code from mipmaps to pixmaps (new to me since I
haven't used pixmaps before), but the program doesn't appear to be using
lower res textures in the distance, so I think the default value is to not
filter, "fast" I think, which is what the docs say is the default, so
that makes sense.

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

> Actually, only pixmaps auto-generate mipmaps (this has long been a
> source of confusion with QD3D).

> Use pixmap textures and set the quality filter to mid or best and you
> get instant mipmaps. Well if you're using the current CVS source at
> least...

So I can create the texture as a pixmap instead of a mipmap and it
generates the lower res textures for me...or I can use a mipmap but I have
to create and supply the downsampled textures manually.  Are both points
made correct so far?

If so, what is the advantage of mipmaps.  They require more work, so what
do they buy you?  Do they offer more control over when resolution is
switched, or more gradations of texture dimension?  Any advantage at all?

________________________________________________________________________
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 12:54 AM, Keith Wiley wrote:

> I have a trimesh with a texture.  Actually, I have lots of these.  In 
> the distance from the camera position I want to use lower res textures 
> on the object, basically lower dimension textures.  For the moment, I 
> am considering not scaling down the mesh geometry by removing less 
> crucial vertices and triangles, just downsampling the texture.  I 
> think there are three ways to do this.  One is to use a mipmap and let 
> Quesa automatically generate the downsampled mipmaps.

Actually, only pixmaps auto-generate mipmaps (this has long been a 
source of confusion with QD3D).

> One is to create my own downsampled images and not let Quesa generate 
> mipmaps (I know how to do this) and transfer them to the trimesh 
> whenever the distance passes a crossover distance designating a switch 
> in resolutions.

You could create your own mipmaps, but there's no need to switch them 
yourself - this happens automatically - depending on the texture 
quality filter setting.

> ...The last way is to create multiple trimeshes during initialization, 
> each one containing identical geometry by varying dimensions of 
> texture.  I then only submit the trimesh that is appropriate for the 
> present distance at any given time and ignore the other trimeshes 
> until I need them for their respective distances.

If you're going to do that you might as well use lower resolution 
meshes as well, but in this case it's still more efficient to use one 
mipmapped texture anyway...

There's a feature of QD3D that could help with dynamic mesh detail (LOD 
groups) but I'm not sure when (or if) that'll make it into Quesa.

> Question 3: is there a fourth way to do this that I haven't thought of?

Use pixmap textures and set the quality filter to mid or best and you 
get instant mipmaps. Well if you're using the current CVS source at 
least...

Frank.

speed question

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

I have a trimesh with a texture.  Actually, I have lots of these.  In 
the distance from the camera position I want to use lower res textures 
on the object, basically lower dimension textures.  For the moment, I am 
considering not scaling down the mesh geometry by removing less crucial 
vertices and triangles, just downsampling the texture.  I think there 
are three ways to do this.  One is to use a mipmap and let Quesa 
automatically generate the downsampled mipmaps.  One is to create my own 
downsampled images and not let Quesa generate mipmaps (I know how to do 
this) and transfer them to the trimesh whenever the distance passes a 
crossover distance designating a switch in resolutions.  I think this 
requires copying the array of the new dimension texture into the texture 
shader pixel array.  I don't think there is any way to simply point the 
texture shader at a different downsampled array.  I think I have to copy 
the whole thing over.  The last way is to create multiple trimeshes 
during initialization, each one containing identical geometry by varying 
dimensions of texture.  I then only submit the trimesh that is 
appropriate for the present distance at any given time and ignore the 
other trimeshes until I need them for their respective distances.

Question 1: how wasteful is it to have extra trimeshes of identical 
geometry floating around in memory.  Is that just stupid, to have 
trimeshes of identical geometry and just different textures?

Question 2: of these three methods, which is best, which is fastest?

Question 3: is there a fourth way to do this that I haven't thought of?

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
________________________________________________________________________

[ quesa-Bugs-967765 ] Bad view transformations for transparent objects

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad view transformations for transparent objects

Initial Comment:
Transparent vertices warp and eventually shoot off into infinity 
when approaching the camera/hither plane. This is likely a problem 
with the  transforms used in ir_geom_transparent_add. See 
attached CFM Mac OS X application for an example.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-07-11 19:13

Message:
Logged In: YES 
user_id=433183

I believe that the TransTest sample application illustrated 3 bugs,
which may have confused some people looking at this bug:
1. flash over the whole screen when the boxes get close to the hither 
plane
2. Distortion of textures with alpha
3. Depth-sorting problems causing flickering of individual triangles.
Changes I made today to IRTransparent.c and IRPrefix.h seem to have
fixed (1) and (2).  I added bug 989156 to record bug (3).

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

Comment By: Dair Grant (grantd)
Date: 2004-06-15 17:00

Message:
Logged In: YES 
user_id=439944

Trying to attach example app.

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

Comment By: Frank Condello (pox)
Date: 2004-06-06 13:57

Message:
Logged In: YES 
user_id=171509

Well that didn't work - grab the test application here: <http://
webhome.idirect.com/~frankco/rb/TransTest.sit>

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

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

[ quesa-Bugs-989156 ] Poor depth sorting of transparent triangles

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

Bugs item #989156, was opened at 2004-07-11 19:08
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=989156&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: Poor depth sorting of transparent triangles

Initial Comment:
When transparent objects overlap, it is well known that you should
render the transparent triangles from back to front to get the
correct appearance, but doing so is easier said than done.
One problem is that it's somewhat tricky to determine which of
two triangles is in front of the other as seen from the camera.
Another problem is that the "in front of" relation is not a linear
ordering or even a partial ordering.  That is, if you know that
triangle A is in front of B, and B is in front of C, then you can't
conclude anything about the relation between B and C.  It may
seem likely that A is in front of C, but it is possible that C is in
front of A, or that there neither is in front of the other.

Currently, when transparent objects pass in front of each other,
there are ugly flashing effects with individual triangles
brightening and darkening.

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

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

Bug #895092 no longer reproducible

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

FYI: It appears that bug #895092 "Edge and point fill styles may render  
textured"  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=895092&group_id=45158&atid=442052> has been fixed  
recently (perhaps inadvertently). All my test cases work with the  
current CVS source, so this bug can probably be closed.

Thanks,
Frank.

Re: Transparent TriMesh bug

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

On 9-Jul-04, at 2:06 PM, James W. Walker wrote:

> Frank C <li...@si...> wrote:
>
>> The checkerboard texture just makes the distortions easier to see -
>> it's definitely the geometry going out of whack though, textured or
>> not.
>
> Well, there clearly is a problem specifically with texture coordinates 
> in alpha textures.  You can see that by downloading the 
> "argb32-test.3dmf" attachment to bug 967765 and loading it in Geom 
> Test.  You will see that the texture distorts and the geometry does 
> not.

Yes, sorry, I see what you're saying... though this would appear to be 
a case of one bug breaking two things, and perhaps not a separate issue 
altogether. The texture projection and geometry projection are both out 
of whack, just not out of the same whack :)

> Therefore, I think that using the checkerboard pattern in your example 
> confuses the issue.  Since you didn't post the source, I can't try it 
> with transparency but not textures.

Here's a new version that allows you to toggle textures: 
<http://webhome.idirect.com/~frankco/rb/TransTest.sit> and the source: 
<http://webhome.idirect.com/~frankco/rb/TransTestSource.zip> (though 
I'm not sure if REALbasic source is of any use to you).

Frank.

Re: Transparent TriMesh bug

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

Frank C <li...@si...> wrote:

>The checkerboard texture just makes the distortions easier to see -
>it's definitely the geometry going out of whack though, textured or
>not.

Well, there clearly is a problem specifically with texture 
coordinates in alpha textures.  You can see that by downloading the 
"argb32-test.3dmf" attachment to bug 967765 and loading it in Geom 
Test.  You will see that the texture distorts and the geometry does 
not.  Therefore, I think that using the checkerboard pattern in your 
example confuses the issue.  Since you didn't post the source, I 
can't try it with transparency but not textures.

-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Transparent TriMesh bug

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

On 8-Jul-04, at 11:51 PM, James W. Walker wrote:

> On Jul 8, 2004, at 8:40 PM, Frank C wrote:
>
>> That sounds like a side effect of this bug:  
>> <http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=967765&group_id=45158&atid=442052>
>
> I looked at that bug report, even downloaded your test app, but it  
> wasn't clear to me that there was anything funny happening with the  
> geometry.  I thought it was a bug having to do with textures with  
> alpha.  It could be that your app shows 2 bugs, but in that case it  
> would be better to have separate test cases.

The checkerboard texture just makes the distortions easier to see -  
it's definitely the geometry going out of whack though, textured or  
not.

Frank.

Re: Transparent TriMesh bug

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

On Jul 8, 2004, at 8:40 PM, Frank C wrote:

> That sounds like a side effect of this bug:  
> <http://sourceforge.net/tracker/index.php? 
> func=detail&aid=967765&group_id=45158&atid=442052>

I looked at that bug report, even downloaded your test app, but it  
wasn't clear to me that there was anything funny happening with the  
geometry.  I thought it was a bug having to do with textures with  
alpha.  It could be that your app shows 2 bugs, but in that case it  
would be better to have separate test cases.
--
<http://www.jwwalker.com/>

Re: Transparent TriMesh bug

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

On 8-Jul-04, at 8:57 PM, James W. Walker wrote:

> I ran into a situation where a transparent TriMesh should be out of  
> view of a camera, yet some distorted part of it is visible.  The  
> object is slightly behind the camera and off to the side.

That sounds like a side effect of this bug:  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=967765&group_id=45158&atid=442052>

> I am not sure that I totally understand the problem, but I found a way  
> to make it go away:  Modify ir_geom_transparent_add to reject a  
> primitive unless all of its z coordinates are in the correct visible  
> range, 0 to -1.  Comments?

That may be a good idea anyway, but it doesn't fix the underlying  
problem. Even entirely in-view transparent primitives get distorted, so  
something's screwy with the projection...

Frank.

Transparent TriMesh bug

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

I ran into a situation where a transparent TriMesh should be out of 
view of a camera, yet some distorted part of it is visible.  The 
object is slightly behind the camera and off to the side.  I am not 
sure that I totally understand the problem, but I found a way to make 
it go away:  Modify ir_geom_transparent_add to reject a primitive 
unless all of its z coordinates are in the correct visible range, 0 
to -1.  Comments?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Additional patch for bug #895106

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

I posted this small patch a couple weeks ago but it hasn't been  
reviewed or committed - I just want to make sure it doesn't get  
forgotten...

Thanks,
Frank.

On 19-Jun-04, at 12:50 PM, Frank C wrote:

> While working on bug #895106 "Colours have no effect on textured  
> geometry"  
> <http://sourceforge.net/tracker/index.php? 
> func=detail&aid=895106&group_id=45158&atid=442052> I failed to realize  
> that QD3D blends transparency colours at all times, on both lit and  
> null shaded geometry. I believe this was true even prior to QD3D  
> 1.6...
>
> This patch: <http://webhome.idirect.com/~frankco/IRGeometry.zip>  
> contains a small change to IRGeometry.c that fixes this oversight.

Re: Marquee selection speed

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

James W. Walker wrote:

>Sounds plausible.  It looks like there are a couple of ways we could=20
>address your problem:
=2E..
>2. Provide kQ3XMethodTypeObjectSubmitPick for TriGrid.

That sounds like the best plan to me - the only reason we don't do date
is that all the internal implicit geometries get decomposed to a TriMesh
rather than a TriGrid.

Another option would be to submit sphere objects directly and let Quesa
handle the decomposition for rendering (and let the spheres process
picking), but I presume there's some subdivision reason why they get
turned into TriGrids? (different controls than the subdivision style?)


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

Re: Marquee selection speed

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

On Jul 2, 2004, at 5:58 AM, Roger Holmes wrote:

> In this test, my spheres are actually  25 x 13 vertex TriGrids which I 
> guess are being split up
> into 650 triangles each. 650 x 60 = 39000 so it sounds like that is 
> what's happening.

Sounds plausible.  It looks like there are a couple of ways we could 
address your problem:

1. Record hits in a slab (growing exponentially) instead of a list.

2. Provide kQ3XMethodTypeObjectSubmitPick for TriGrid.
--
<http://www.jwwalker.com/>

Re: Marquee selection speed

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

On Thursday, July 1, 2004, at 10:50  pm, Dair Grant 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?
>
> Yes, that does seem very high: presumably you use a window rect to
> implement the selection, in which case you'd expect the number of hits
> to be <= the number of objects in the scene?

I set up my PickData thus:

					TQ3WindowRectPickData myWPPickData ;
					
					myWPPickData.data.sort = kQ3PickSortNone ;
					myWPPickData.data.mask = kQ3PickDetailMaskPickID | 
kQ3PickDetailMaskPath ;
					myWPPickData.data.numHitsToReturn = 0x7FFFFFFF ; // I want all the 
objects
					myWPPickData.rect.min.x = newFrame.left ;
					myWPPickData.rect.min.y = newFrame.top ;
					myWPPickData.rect.max.x = newFrame.right ;
					myWPPickData.rect.max.y = newFrame.bottom ;

I ask for the path, but actually only use the rootGroup and element 
zero of the returned array.

I just tried out removing kQ3PickDetailMaskPickID but it made no 
difference.

In this test, my spheres are actually  25 x 13 vertex TriGrids which I 
guess are being split up
into 650 triangles each. 650 x 60 = 39000 so it sounds like that is 
what's happening.

It could be that the problem has already been fixed in the latest CVS 
source but I don't remember
anything being checked in which sounded relevant since my branch 
divided.

Roger.

Re: Marquee selection speed

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

James W. Walker 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?

Yes, that does seem very high: presumably you use a window rect to
implement the selection, in which case you'd expect the number of hits
to be <=3D the number of objects in the scene?


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