quesa-develop — Mailing list for Quesa development

Re: reasonable field of view?

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

Frank C wrote:

> On 26-Jul-04, at 5:57 PM, Keith Wiley wrote:
>
>> What is the generic field of view of all the various first-person 
>> computer
>> games?  My own sloppy experimentation suggests that my binocular field
>> (bounded by the bridge of my nose) is around 70 degrees...
>
>
> Most FPS games default to around 90 degrees of horizontal FOV - but 
> under normal circumstances Quesa's uses vertical FOV, so 65-70 sounds 
> about right.

Hmmm, well that does it make it a little more interesting.  So you're saying the camera fov attribute governs the vertical fov, not the horizontal?  That wasn't my initial expectation.  What do you mean by "normal circumstances"?  Can it be either depending on the details?

________________________________________________________________________
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: reasonable field of view?

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

On 26-Jul-04, at 5:57 PM, Keith Wiley wrote:

> What is the generic field of view of all the various first-person 
> computer
> games?  My own sloppy experimentation suggests that my binocular field
> (bounded by the bridge of my nose) is around 70 degrees...

Most FPS games default to around 90 degrees of horizontal FOV - but 
under normal circumstances Quesa's uses vertical FOV, so 65-70 sounds 
about right.

Frank.

reasonable field of view?

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

What is the generic field of view of all the various first-person computer
games?  My own sloppy experimentation suggests that my binocular field
(bounded by the bridge of my nose) is around 70 degrees, give or take,
(periferal, with one eye only, is much greater of course, around 170), but
I've found references online that say human bincular field is 140 degrees.
I'm not sure what I'm missing here, or what a good value is for a typical
game.

It's also possible this is the wrong forum to ask this question, but most
people don't even think about this kind of stuff.  I thought maybe you
guys would at least understand the question.

________________________________________________________________________
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: camera angle affects lighting

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

Yeah, I've never logged a bug before, but I'll figure it out.  Thanks for
the help.

On Mon, 26 Jul 2004, Dair Grant wrote:

> Keith Wiley wrote:
>
> >Bug then, I'm using Lambert (shiny metallic dirt doesn't make much
> >sense to me).
>
> OK, can you log a bug when SF comes back and attach your screenshot?
>
>
> -dair
> ___________________________________________________
>

________________________________________________________________________
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: camera angle affects lighting

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

Keith Wiley wrote:

>Bug then, I'm using Lambert (shiny metallic dirt doesn't make much
>sense to me).

OK, can you log a bug when SF comes back and attach your screenshot?


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

Re: camera angle affects lighting

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

On Mon, 26 Jul 2004, Frank C wrote:

> That is almost certainly a specular highlight you're seeing. If you're
> not using Phong shading, then it's a bug. If you are using Phong
> shading, it's expected behaviour (highlights clip to polygons not
> alphas).

Bug then, I'm using Lambert (shiny metallic dirt doesn't make much sense
to me).

________________________________________________________________________
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: camera angle affects lighting

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

On 26-Jul-04, at 4:06 PM, Keith Wiley wrote:

> On Mon, 26 Jul 2004, Dair Grant wrote:
>
>> Keith Wiley wrote:
>>
>>> Has anyone ever noticed that the camera angle can affect the apparent
>>> illuimation of surfaces?  As I rotate the camera, the brightness of a
>>> surface changes even though that surface's location in global space,
>>> and with respect to the environmental lights never changes.
>>
>> Not sure if I follow - if you change the camera view, you'll be 
>> looking
>> at a different part of the object, and hence you'd expect the
>> illumination to change surely?
>
> No, look at this example to see what I mean:
>
> http://www.cs.unm.edu/~kwiley/illuminationError.jpg

That is almost certainly a specular highlight you're seeing. If you're 
not using Phong shading, then it's a bug. If you are using Phong 
shading, it's expected behaviour (highlights clip to polygons not 
alphas).

Frank.

Re: camera angle affects lighting

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

On Mon, 26 Jul 2004, Dair Grant wrote:

> Keith Wiley wrote:
>
> >Has anyone ever noticed that the camera angle can affect the apparent
> >illuimation of surfaces?  As I rotate the camera, the brightness of a
> >surface changes even though that surface's location in global space,
> >and with respect to the environmental lights never changes.
>
> Not sure if I follow - if you change the camera view, you'll be looking
> at a different part of the object, and hence you'd expect the
> illumination to change surely?

No, look at this example to see what I mean:

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

The camera is rotating counter clockwise from 1,2,3 and finally 4.  At
various camera positions, the illumination gets dramatically brighter.
This isn't very realistic of course.  The surface being illuminated isn't
moving at all with respect to the lights.  It's also strange that the
image is dark in 1 and 4, which are 180 degrees opposed, so it isn't that
a particular angle is brightest, and its 180 degree opposite is darkest.
Rather, there is a small rotational range, within which the image gets
very bright, and at all other rotations the image is dark.

The alpha layer is mostly transparant (it puts the white pattern on the
brown ground, you can see that I truncate this effect at a certain
distance from the blakc "monolith" object in the center), so the proper
behavior is the dark appearance and the bright appearance is incorrect.

________________________________________________________________________
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: camera angle affects lighting

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

Keith Wiley wrote:

>Has anyone ever noticed that the camera angle can affect the apparent
>illuimation of surfaces?  As I rotate the camera, the brightness of a
>surface changes even though that surface's location in global space,
>and with respect to the environmental lights never changes.

Not sure if I follow - if you change the camera view, you'll be looking
at a different part of the object, and hence you'd expect the
illumination to change surely?

But assuming I just don't understand the description, is this light-type
specific or does it happen with any kind?


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

Re: camera angle affects lighting

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

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

> Has anyone ever noticed that the camera angle can affect the apparent
> illuimation of surfaces?  As I rotate the camera, the brightness of a
> surface changes even though that surface's location in global space, 
> and
> with respect to the environmental lights never changes.  I can observe
> this effect with a null shader, or lambert or phong.  All three do it. 
>  I
> think I am only seeing it with alpha-layer 32 bit textures.

The transparent surface renderer does not respect illumination state so 
you may actually be seeing errant specular highlights and/or lambert 
shading on null shaded objects. It could also be related to sorting 
errors, but it's hard to say without seeing the scene in question.

I'd post some relevant bug ID's but I think sourceforge is having 
problems (there are 0 bugs listed?)

Frank.

camera angle affects lighting

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

Has anyone ever noticed that the camera angle can affect the apparent
illuimation of surfaces?  As I rotate the camera, the brightness of a
surface changes even though that surface's location in global space, and
with respect to the environmental lights never changes.  I can observe
this effect with a null shader, or lambert or phong.  All three do it.  I
think I am only seeing it with alpha-layer 32 bit textures, so it might
have something to do with the way lower layers are combined with higher
layers to produce a projected pixel value.

________________________________________________________________________
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: hiccupping for new objects/textures

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

On Fri, 23 Jul 2004, Roger Holmes wrote:

> In your earlier e-mail you said:
>
> >>> Take a given scene with a number of redundant objects (with varying
> >>> translation, scale, rotation, whatever) and render it as a set of
> >>> individual objects.  Then do the same but first union all the objects
> >>> into
> >>>
>
> It is that varying translation, scale and rotation which you speak of
> which might be slowing you down.

I don't follow.  I mean, nothing varies while the program is running.  All
I'm saying is that the various terrain tiles are located in various
locations, so clearly they are translated so they aren't all on top of
each other.  At any rate, if I put all the tiles in a single trimesh the
program gets a higher framerate than if all the tiles are individual
objects.  That's all I've been saying.  Nothing more complex than that.

________________________________________________________________________
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: hiccupping for new objects/textures

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

In your earlier e-mail you said:

>>> Take a given scene with a number of redundant objects (with varying
>>> translation, scale, rotation, whatever) and render it as a set of
>>> individual objects.  Then do the same but first union all the objects
>>> into
>>>

It is that varying translation, scale and rotation which you speak of 
which
might be slowing you down.

Roger.

Re: hiccupping for new objects/textures

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

I'm not sure what you mean by current transform.  If you are referring to
constant changes to the objects, then bear in mind that the objects are
static after their initial creation.  Tile objects don't move or change
shape of course.  As for the hope of using large numbers of objects with
little speed cost, I'd love to find a way, so I'm not trying to argue with
you, but I honestly didn't quite understand your paragraph below.  I have
directly observed major speed enhancements by reducing the number of
objects, so what is there to dispute then?

If you're saying there is a cleverer way to use many objects and that I
don't know how to do it, then cool, I' love to figure it out, but...

I'm just not that adept at this stuff.  In what sense are my objects in a
common coordinate system, or not in common coordinate system?  The entire
world is a common coordinate system isn't it?  What difference does it
make if they aren't changing in scale, position, or rotation over time?
What are the "global settings" you refer to?  You see my confusion.  :-)

As an example, when this came up in the past, someone pointed me to the
QutGeom program and demonstrated that they had created the world (a 3D
grid of cubes) with various methods of grouping and that the grouped
methods were much faster.

So I'm not following why you think it shouldn't be much faster, since it
clearly is.  Sorry, I just don't understand.

On Fri, 23 Jul 2004, Roger Holmes wrote:

> It could be the calls to the system to change the current transform
> which were slowing you down. Yes that will be slower, but if you make
> them all in a common coordinate system and no other global settings
> change
> then I doubt you would see a factor of between 2 and 8 then. Suppose
> you lose
> 5 percent in speed, wouldn't it be worth it to save a hiccup?
>
> Roger.
>
>
> On Friday, July 23, 2004, at 05:13  pm, Keith Wiley wrote:
>
> > No, we (the group) settled this a few weeks ago.  Someone (or multiple
> > someones) told me that the number of unique trimeshes that are
> > submitted
> > definitely matters.  I subsequently verified that this is definitely
> > true.
> > Take a given scene with a number of redundant objects (with varying
> > translation, scale, rotation, whatever) and render it as a set of
> > individual objects.  Then do the same but first union all the objects
> > into
> > a single huge trimesh.  The second method renders much faster, between
> > 2
> > and 8 times faster in my experience.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

________________________________________________________________________
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: hiccupping for new objects/textures

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

It could be the calls to the system to change the current transform
which were slowing you down. Yes that will be slower, but if you make
them all in a common coordinate system and no other global settings 
change
then I doubt you would see a factor of between 2 and 8 then. Suppose 
you lose
5 percent in speed, wouldn't it be worth it to save a hiccup?

Roger.


On Friday, July 23, 2004, at 05:13  pm, Keith Wiley wrote:

> No, we (the group) settled this a few weeks ago.  Someone (or multiple
> someones) told me that the number of unique trimeshes that are 
> submitted
> definitely matters.  I subsequently verified that this is definitely 
> true.
> Take a given scene with a number of redundant objects (with varying
> translation, scale, rotation, whatever) and render it as a set of
> individual objects.  Then do the same but first union all the objects 
> into
> a single huge trimesh.  The second method renders much faster, between 
> 2
> and 8 times faster in my experience.

Re: hiccupping for new objects/textures

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

No, we (the group) settled this a few weeks ago.  Someone (or multiple
someones) told me that the number of unique trimeshes that are submitted
definitely matters.  I subsequently verified that this is definitely true.
Take a given scene with a number of redundant objects (with varying
translation, scale, rotation, whatever) and render it as a set of
individual objects.  Then do the same but first union all the objects into
a single huge trimesh.  The second method renders much faster, between 2
and 8 times faster in my experience.

On Fri, 23 Jul 2004, Roger Holmes wrote:

> Surely it is the number of triangles which matters, not the number of
> objects
> which they are in. Have you tried halving each dimension of your tiles
> and
> also halving each dimension of your textures and increasing the number
> of tiles to compensate? As there would be the same number of triangles,
> it should not affect the rendering speed much.
>
> Roger.
>
> On Thursday, July 22, 2004, at 10:01  pm, Keith Wiley wrote:
>
> > Anyway, culling aside, increasing the number of
> > objects is clearly undesirable, but I may have to find the necessary
> > balance between texture size and number of tiles.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

________________________________________________________________________
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: quesa/Development/Source/Renderers/Interactive IRGeometry.c,1.46,1.47

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

On Thursday, July 22, 2004, at 09:33  pm, Dair Grant wrote:

> No, just thinking we could add kQ3Epsilon and use that as the preferred
> name then map kQ3RealZero for backwards compatibility.
>
>

Yes, then we can change them when a file needs to be changed for some 
other reason.

Roger.

Re: hiccupping for new objects/textures

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

Surely it is the number of triangles which matters, not the number of 
objects
which they are in. Have you tried halving each dimension of your tiles 
and
also halving each dimension of your textures and increasing the number
of tiles to compensate? As there would be the same number of triangles,
it should not affect the rendering speed much.

Roger.

On Thursday, July 22, 2004, at 10:01  pm, Keith Wiley wrote:

> Anyway, culling aside, increasing the number of
> objects is clearly undesirable, but I may have to find the necessary
> balance between texture size and number of tiles.

Re: hiccupping for new objects/textures

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

On Thu, 22 Jul 2004, Dair Grant wrote:

> Keith Wiley wrote:
>
> >My highest res textures, which of course cover the entire area of a
> >terrain tile, are 1024 pixels across, or just over 1 mil pixels square
> >(2 mil bytes of course).  Granted, that's a pretty big freaking
> >texture, but I do have a very modern computer.  Should I be getting a
> >hiccup for this kind of texture-loading?
>
> Try running the OpenGL Profiler app - that should let you see what's
> happening in terms of communication with the card.

Okay, I'll have to find it first.  :-)  I can probably find it.

> You can't load it in pieces (other than splitting it into separate
> textures), so shrinking it would be my choice.

That would be a great trick wouldn't it.  To piecewise load a texture
before you need it, so it's all there by the time you need it.

> Do you do any visibility culling yourself? At the moment Quesa won't do
> this for you, but if using smaller tiles is to be avoided because it
> increases the number of things in your world, you may be able to reduce
> the impact by reducing the number of things you actually submit on each
> frame.

Yes and no.  I have tried to use Queeg and Nanosaur's camera frustum
culling routines.  Queeg's seem to work better.  :-)  For the most part
they work and I intend to use the culling eventually, but it culls too
"hard" cutting stuff out that is on the edge of the cone of vision.  I'm
probably using it wrong.  Anyway, culling aside, increasing the number of
objects is clearly undesirable, but I may have to find the necessary
balance between texture size and number of tiles.

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: hiccupping for new objects/textures

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

Keith Wiley wrote:

>My highest res textures, which of course cover the entire area of a
>terrain tile, are 1024 pixels across, or just over 1 mil pixels square
>(2 mil bytes of course).  Granted, that's a pretty big freaking
>texture, but I do have a very modern computer.  Should I be getting a
>hiccup for this kind of texture-loading?

Try running the OpenGL Profiler app - that should let you see what's
happening in terms of communication with the card.


>Is there anything that can be done to alleviate this problem?  Can I
>slowly load a texture in pieces in advance of needing it, by
>anticipating its need in the future, so that it is mostly loaded by
>the time it is needed?

You can't load it in pieces (other than splitting it into separate
textures), so shrinking it would be my choice.


>Smaller tiles means many more objects in the world which slows the
>program down.

Do you do any visibility culling yourself? At the moment Quesa won't do
this for you, but if using smaller tiles is to be avoided because it
increases the number of things in your world, you may be able to reduce
the impact by reducing the number of things you actually submit on each
frame.


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

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

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

Roger Holmes wrote:

>Marginally, but I do a lot of testing with the debugging version, and
>I think sqrt is quite a slow function even on a G4 or G5.

Sure, although we should really be using the PPC-specific root
approximations which I suspect would mitigate the cost.


>> Yes, I've always thought kQ3RealZero was an odd name for something
>> that isn't really zero. :-)
>>
>> Perhaps kQ3Epsilon, since that's really what it's used for (and maps
>> to FLT_EPSILON if that's available).
>
>Yes that would be better. Is it public ?

No, just thinking we could add kQ3Epsilon and use that as the preferred
name then map kQ3RealZero for backwards compatibility.


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

hiccupping for new objects/textures

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

I may have asked something similar to this, I'm not sure.  I am using a
1.6Ghz single proc G5 with 64M VRAM, and 768M RAM.  My environment
presently consists of terrain tiles and nothing else.  I only submit tiles
that are within a particular radius of the user.  Likewise, I switch
textures in for each tile at varying resolutions depending on the tile's
distance from the user (I do a similar trick submitting various trimeshes
of varying detail).

As I move around my environment, the program hiccups noticably (1/10th to
1/5th of a second, give or take) just as the boundries of tiles cross the
various distance thresholds.

I have determined that loading the higher res textures causes worse
(longer duration) hiccups.  I figured this out by simply eliminating the
highest res textures from the list of possibilities.  Of course, this
behavior makes perfect sense since these textures would take the longest
to load.

Two questions:

My highest res textures, which of course cover the entire area of a
terrain tile, are 1024 pixels across, or just over 1 mil pixels square (2
mil bytes of course).  Granted, that's a pretty big freaking texture, but
I do have a very modern computer.  Should I be getting a hiccup for this
kind of texture-loading?

Is there anything that can be done to alleviate this problem?  Can I
slowly load a texture in pieces in advance of needing it, by anticipating
its need in the future, so that it is mostly loaded by the time it is
needed?

Clearly, two other solutions are to settle for lower res textures and to
use smaller tiles.  Smaller tiles means many more objects in the world
which slows the program down.  Lower res is simply undesirable.  At the
highest res I have 32 pixels per "meter" on the terrain under the user's
feet.  That's about 1 pixel per 3 centimeters, which will offer pretty
slick, beautiful textures, but maybe I just can't offer that much beauty
in my program.  What do you think?

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: quesa/Development/Source/Renderers/Interactive IRGeometry.c,1.46,1.47

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

>
> That's normally a good trick to use (compare squares rather than actual
> lengths), but this code is only hit in a debug build anyway - so it's
> probably clearer when you're stepping through to just get the actual
> length.

Marginally, but I do a lot of testing with the debugging version, and
I think sqrt is quite a slow function even on a G4 or G5.

>
>
>> 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?
>
> Yes, I've always thought kQ3RealZero was an odd name for something that
> isn't really zero. :-)
>
> Perhaps kQ3Epsilon, since that's really what it's used for (and maps to
> FLT_EPSILON if that's available).
>

Yes that would be better. Is it public ?

Roger.

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

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

Dair Grant <da...@re...> wrote:

>Roger Holmes wrote:
>
>>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?
>
>That's normally a good trick to use (compare squares rather than actual
>lengths), but this code is only hit in a debug build anyway - so it's
>probably clearer when you're stepping through to just get the actual
>length.

While it's true that performance is not top priority in a debug 
build, I'd prefer that the debug build not be unnecessarily slow.  I 
don't think it would be particularly unclear to write

lengthSq = Q3FastVector3D_LengthSquared( &theNormal );
if (fabs( lengthSq - 1.0f ) > 2*kQ3RealZero) ...
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

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

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

Roger Holmes wrote:

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

That's normally a good trick to use (compare squares rather than actual
lengths), but this code is only hit in a debug build anyway - so it's
probably clearer when you're stepping through to just get the actual
length.


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

Yes, I've always thought kQ3RealZero was an odd name for something that
isn't really zero. :-)

Perhaps kQ3Epsilon, since that's really what it's used for (and maps to
=46LT_EPSILON if that's available).


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