quesa-develop — Mailing list for Quesa development

Can someone PLEASE fix this?

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

I've sent this patch to the list twice and haven't gotten a shred of 
interest from anyone with CVS access...

The Bug:

QD3D blends transparency colour on textured objects regardless of the 
illumination setting, while Quesa only blends transparency colour when 
the illumination state is null. This behaviour was initially overlooked 
when fixing bug #895106.

The Fix:

In IRGeometry.c, IRGeometry_Generate_Vertex_State, replace:
-----
	if (instanceData->stateTextureActive && 
instanceData->stateViewIllumination != kQ3IlluminationTypeNULL)
		{
		colourDiffuse = &white;
		colourTransparency = &white;	
		}
	else
		{
		if (colourDiffuse == NULL || instanceData->stateGeomHilightState == 
kQ3On)
			colourDiffuse = instanceData->stateGeomDiffuseColour;

		if (colourTransparency == NULL &&
			(instanceData->stateGeomTransparencyColour->r != 1.0f ||
			 instanceData->stateGeomTransparencyColour->g != 1.0f ||
			 instanceData->stateGeomTransparencyColour->b != 1.0f))
			colourTransparency = instanceData->stateGeomTransparencyColour;
		}
-----
with:
-----
	if (instanceData->stateTextureActive && 
instanceData->stateViewIllumination != kQ3IlluminationTypeNULL)
		colourDiffuse = &white;	
	else
		{
		if (colourDiffuse == NULL || instanceData->stateGeomHilightState == 
kQ3On)
			colourDiffuse = instanceData->stateGeomDiffuseColour;
		}
		
	if (colourTransparency == NULL &&
		(instanceData->stateGeomTransparencyColour->r != 1.0f ||
		 instanceData->stateGeomTransparencyColour->g != 1.0f ||
		 instanceData->stateGeomTransparencyColour->b != 1.0f))
		colourTransparency = instanceData->stateGeomTransparencyColour;
-----

If someone with CVS access could review/commit this change it would be 
appreciated!

Thanks,
Frank.

Re: BUG in function "ir_texture_convert_rave_filter" ?

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

Daniele Cavallini <dca...@in...> wrote:

>I think there is a bug in the function :
>
>static TQ3QualityFilter
>ir_texture_convert_rave_filter(TQ3ViewObject theView)
>
>WRONG:
>.....
>
>	switch (raveFilter) {
>		case kQATextureFilter_Fast:
>			oglFilter.magFilter = GL_NEAREST;
>			oglFilter.minFilter = GL_NEAREST;
>			break;
>......
>
>CORRECT:
>....
>switch (raveFilter) {
>		case kQATextureFilter_Fast:
>			oglFilter.magFilter = GL_LINEAR;
>			oglFilter.minFilter = GL_NEAREST;
>			break;
>.....
>What do you think?


What's your reasoning?

In the description of GL_TEXTURE_MAG_FILTER in the OpenGL Reference 
Manual, it says that GL_NEAREST is generally faster than GL_LINEAR. 
That sounds like what we want for kQATextureFilter_Fast.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: BUG in function "ir_texture_convert_rave_filter" ?

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

On 5-Aug-04, at 11:26 AM, Daniele Cavallini wrote:

> I think there is a bug in the function :
>
> static TQ3QualityFilter
> ir_texture_convert_rave_filter(TQ3ViewObject theView)
>
> WRONG:
> .....
>
> 	switch (raveFilter) {
> 		case kQATextureFilter_Fast:
> 			oglFilter.magFilter = GL_NEAREST;
> 			oglFilter.minFilter = GL_NEAREST;
> 			break;
> ......

No, that's correct... kQATextureFilter_Fast uses nearest neighbour 
interpolation when textures are scaled in either direction.

> CORRECT:
> ....
> switch (raveFilter) {
> 		case kQATextureFilter_Fast:
> 			oglFilter.magFilter = GL_LINEAR;
> 			oglFilter.minFilter = GL_NEAREST;
> 			break;
> .....

That isn't a recommended setting, and would produce odd looking results 
at best. If you want bilinear filtering that doesn't use mipmaps (i.e. 
GL_LINEAR/GL_LINEAR) set the filter to kQATextureFilter_Mid or 
kQATextureFilter_Best and use Mipmap textures with their 
"useMipmapping" flag turned off.

Frank.

Re: Bug in E3Triangle_InterpolateHit

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

On Tuesday, August 3, 2004, at 11:22  pm, Dair Grant wrote:

>
>> Our tester has given my changes to E3Triangle_InterpolateHit a few
>> hours testing in Microspot Modeller and it seems to be pretty solid
>> now. We will be making the golden master of Modeller this week.
>>
>> Any objections to me checking in the changes to Quesa?
>
> This solution would be a step forward for the short term anyway, as 
> it'd
> mean we would return the correct result if you're just doing a
> rotation/translation/uniform scale as your transform.
>
> So I'd go with that for now (unless you want to do the general fix 
> too),
> but could you log a bug indicating that this isn't going to be 100%
> correct?


Perhaps you missed one of my e-mails. I think it is the general fix we
were testing, it certainly was much better than simply multiplying by
local to world. I have checked it in as it is definitely much better 
than
before. I used some code I wrote for my renderer for getting the right
normal for the lighting calculations.

I presume the interactive renderer does something similar otherwise
the lighting would look a little weird as a surface in world coordinates
gives different lighting to a parallel surface in local coordinates 
with a
rotation and non uniform scale transform applied.

Roger.

BUG in function "ir_texture_convert_rave_filter" ?

[Daniele C. <dca...@in...>]

I think there is a bug in the function :

static TQ3QualityFilter
ir_texture_convert_rave_filter(TQ3ViewObject theView)

WRONG:
.....

	switch (raveFilter) {
		case kQATextureFilter_Fast:
			oglFilter.magFilter = GL_NEAREST;
			oglFilter.minFilter = GL_NEAREST;
			break;
......

CORRECT:
....
switch (raveFilter) {
		case kQATextureFilter_Fast:
			oglFilter.magFilter = GL_LINEAR;
			oglFilter.minFilter = GL_NEAREST;
			break;
.....
What do you think?
Daniele

Re: Orientation and rasterize transform

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

On Aug 3, 2004, at 3:21 PM, Dair Grant wrote:

> We don't include a fixed orientation style in the test geometry used 
> for
> that case, so I guess either the polygon order isn't really clockwise 
> or
> the normals we're generating for those polygons are pointing the wrong
> way?

I think I get it.  The window coordinate system is left-handed, which 
reverses orientations from what they would normally be.
--
<http://www.jwwalker.com/>

Re: Bug in E3Triangle_InterpolateHit

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

Roger Holmes wrote:

>Am I being simple in thinking that multiplying by localToWorld will do
>the trick? Probably, the rotational component is fine but will non
>uniform scaling in X,Y & Z and shearing mess things up?

Yes, an affine transformation such as a shear will mean the normals are
no longer correct if they're just pushed through the local to world:

<http://www.worldserver.com/turk/computergraphics/NormalTransformations.
pdf>


>So I guess that's it, but it is a heavy bit of calculation. Should we
>be doing it when we get a 'hit' or every time we change localToWorld?
>I guess there are typically not many hits, and it would be easier to
>put the code in the existing routine. Or is this matrix calculated
>somewhere already?

We record the local to world along with the pick, so we could defer this
transform until we actually find the app wants the normal vector.

I.e., record the local normal and the current L->W transform when
collecting the hit information, and defer the expensive work (like
normalisation) until we know the app actually wants that information
back.


>Our tester has given my changes to E3Triangle_InterpolateHit a few
>hours testing in Microspot Modeller and it seems to be pretty solid
>now. We will be making the golden master of Modeller this week.
>
>Any objections to me checking in the changes to Quesa?

This solution would be a step forward for the short term anyway, as it'd
mean we would return the correct result if you're just doing a
rotation/translation/uniform scale as your transform.

So I'd go with that for now (unless you want to do the general fix too),
but could you log a bug indicating that this isn't going to be 100%
correct?


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

Re: Orientation and rasterize transform

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

James W. Walker wrote:

>I notice that the rasterize test in Geom Test is a polygon drawn in=20
>clockwise order, yet it gets dimmer if the orientation style is=20
>clockwise.  What's up with that?

The rasterise transform just affects the camera projection, so the
geometry passing through it will be affected by
orientation/illumination/lighting/etc unless it's submitted in a group
that enforces a particular state.

We don't include a fixed orientation style in the test geometry used for
that case, so I guess either the polygon order isn't really clockwise or
the normals we're generating for those polygons are pointing the wrong
way?


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

Orientation and rasterize transform

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

I notice that the rasterize test in Geom Test is a polygon drawn in 
clockwise order, yet it gets dimmer if the orientation style is 
clockwise.  What's up with that?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: wrappup of my present problem

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

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

>I still wonder if can get increased efficiency by not copying the texture
>in the first place (which can be a large chunk of storage of course and
>might be time consuming to copy pointlessly), but that's a less serious
>problem.

You can duplicate the geometry without duplicating the texture by 
getting the TriMesh data (for efficiency, use Q3TriMesh_LockData 
rather than Q3TriMesh_GetData) and then creating a new one 
(Q3TriMesh_New).
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

wrappup of my present problem

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

Well, presently what I've hacked is that after duplicating a trimesh
(which invariably copies the texture unfortunately) I then get the shaders
and textures from the two trimeshes and insert the old texture into the
new shader immediately, before the trimesh is ever submitted, even for the
first time.  The profiler reflects that I am getting a single copy of the
texture now and the program runs smoother too, I guess because it isn't
constantly paging in and out of VRAM.

So cool.

I still wonder if can get increased efficiency by not copying the texture
in the first place (which can be a large chunk of storage of course and
might be time consuming to copy pointlessly), but that's a less serious
problem.

I assume that when I do what I described above, the act of setting one
texture automatically decrements the ref count of the texture being
replaced and that texture is subsequently erased completely from memory (I
mean RAM, not VRAM), right?

Thanks, you're a patient lot.

________________________________________________________________________
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: duplicating trimesh data con't

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

On Tue, 3 Aug 2004, James W. Walker wrote:

> Keith Wiley <kw...@cs...> wrote:
>
> >What I get in the debugger is unique addresses for the two shaders, but
> >the same address for the two textures.  So copying the trimesh data
> >creates a second new shader, but only copies a pointer or reference to the
> >texture.  I am right so far, right?
>
> That should not be the case.  Duplicating a texture shader also
> duplicates the textures.  The CVS log shows that it has been so since
> Feb. 26 2003.

Dammit, you're right of course.  I accidentally got the shaders from each
trimesh and then got the textures from the shaders, but, oops, got it from
the same shader both times.  So my debugging code had a bug.  :-)

Ah me.  Well, at least that explains some things.  Like I said, I'm
getting multipled copies in the profiler.

So now I need to figure out how to copy a trimesh and copy its REFERENCES
to shaders and textures.  I'll chew on that one for a while.

Ultimately what I'm doing, if you're curious, is creating one prototype
tree object for a forest, and then copying it dozens of times to make
individual trees.  I want them all to link back to the same texture of
course.

Someone mentioned that I could avoid copying the meshes by using transofmr
objects but I am intentionally unioning the meshes of any given terrain
tile into a single large mesh so as to reduce the number of objects in the
world.  As a result of this, each "object" for a tree species is actually
several trees located in various locations on a given terrain tile.  Since
the placements of the trees in a tile are random, each tile has an object
with a unique geometry, so the transform object approach won't work, I
need to make copies of the trees so I can union their trimeshes...but I
still want them to all use just one texture for all the objects on all the
tiles.

________________________________________________________________________
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: open gl profiler question

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

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

>Are you talking about a breakpoint in the profiler program or in
>codewarrior?  The profiler program doesn't seem to have anything call
>IRTexture or ir_texture in its list.

He's talking about a breakpoint in a source-level debugger, be it 
CodeWarrior, XCode, or gdb.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: open gl profiler question

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

On Tue, 3 Aug 2004, Dair Grant wrote:

> Keith Wiley wrote:
>
> >Are you talking about a breakpoint in the profiler program or in
> >codewarrior?  The profiler program doesn't seem to have anything call
> >IRTexture or ir_texture in its list.
>
> Those are functions in Quesa, so you'll need a breakpoint using
> CW/Xcode/gdb not the GL Profiler - the breakpoints in the GL Profiler
> are just for stopping on GL calls.

I'm not sure how to put a breakpoint "in" Quesa.  It's an opaque
precompiled library that's linked into my project.  I guess I need the CVS
source or something instead of the d18 release lib, huh?

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

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

Re: duplicating trimesh data con't

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

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

>What I get in the debugger is unique addresses for the two shaders, but
>the same address for the two textures.  So copying the trimesh data
>creates a second new shader, but only copies a pointer or reference to the
>texture.  I am right so far, right?

That should not be the case.  Duplicating a texture shader also 
duplicates the textures.  The CVS log shows that it has been so since 
Feb. 26 2003.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: open gl profiler question

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

Keith Wiley wrote:

>Are you talking about a breakpoint in the profiler program or in
>codewarrior?  The profiler program doesn't seem to have anything call
>IRTexture or ir_texture in its list.

Those are functions in Quesa, so you'll need a breakpoint using
CW/Xcode/gdb not the GL Profiler - the breakpoints in the GL Profiler
are just for stopping on GL calls.


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

Re: open gl profiler question

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

On Tue, 3 Aug 2004, Dair Grant wrote:

> Keith Wiley wrote:
>
> >Does this mean I have the same texture in VRAM multiple times as
> >separate unique textures?  If so, yuck.  I will have to figure out
> >what I'm doing wrong here, but before going too crazy about it I just
> >want to verify that I am intpretting the profiler correctly in this
> >regard?
>
> If you're seeing distinct OpenGL texture objects then, yes, those will
> be taking up multiple copies of data in memory.
>
> You can break in IRTexture.c's ir_texture_cache_add to watch whenever a
> QD3D texture object creates its OpenGL shadow, which may help you see
> where the extra copies are coming from.

Are you talking about a breakpoint in the profiler program or in
codewarrior?  The profiler program doesn't seem to have anything call
IRTexture or ir_texture in its list.

________________________________________________________________________
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: open gl profiler question

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

Keith Wiley wrote:

>Does this mean I have the same texture in VRAM multiple times as
>separate unique textures?  If so, yuck.  I will have to figure out
>what I'm doing wrong here, but before going too crazy about it I just
>want to verify that I am intpretting the profiler correctly in this
>regard?

If you're seeing distinct OpenGL texture objects then, yes, those will
be taking up multiple copies of data in memory.

You can break in IRTexture.c's ir_texture_cache_add to watch whenever a
QD3D texture object creates its OpenGL shadow, which may help you see
where the extra copies are coming from.


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

open gl profiler question

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

When I run my program and tell profiler to collect resources, it lets me
peruse a list of my textures, which pleasantly enough I recognize as being
the textures I created in the first place.  I am seeing the same texture
multiple times however.

Does this mean I have the same texture in VRAM multiple times as separate
unique textures?  If so, yuck.  I will have to figure out what I'm doing
wrong here, but before going too crazy about it I just want to verify that
I am intpretting the profiler correctly in this regard?

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: Bio-degradable 3DMF

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

Roger Holmes wrote:

>Has anyone else seen this problem? It is possible it may have
>been fixed since my branch of Quesa diverged from the main
>trunk, but I don't remember seeing any e-mails about anything
>similar.

Hmm, no, don't think I've seen anything like this. If you load/save from
within GeomTest, does that preserve the state or does that lose it as
well?


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

Re: duplicating trimesh data con't

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

Keith Wiley wrote:

>Fundamentally, I need to know for certain that I am right in my
>assumption that there is only one copy of the texture in VRAM even if
>I have thousands of these objects, assuming their (unique) shaders all
>use the same texture pointer.

That's correct. You can have:

  TriMesh1 --> Shader1 ----
                           \
                            --> Texture
                           /
  TriMesh2 --> Shader2 ----

So two QD3D shaders, referencing one QD3D texture object, which will
reference one OpenGL texture object, which will correspond to one chunk
of VRAM.


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

duplicating trimesh data con't

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

I'm trying to make certain I totally understand what happens when I dup
trimesh data.  As usual, I'm working with Queeg.  When I pass an existing
QGTriMesh into the copy ctor of another QGTriMesh, it makes the following
call to copy the attribute set:

mTriMeshData.triMeshAttributeSet = Q3Object_Duplicate(
srcData.triMeshAttributeSet );

I have put some debug code in after making the copy where I pull out the
shader and the texture from both TriMeshes:

TQ3TriMeshData* triMeshData = groupTriMeshes[k]->GetTriMeshData();
TQ3SurfaceShaderObject shader;
Q3AttributeSet_Get(triMeshData->triMeshAttributeSet,
kQ3AttributeTypeSurfaceShader, &shader);
TQ3TextureObject texture;
Q3TextureShader_GetTexture(shader, &texture);

TQ3TriMeshData* triMeshData1 =
(ot->prototypeTriMeshes)[k]->GetTriMeshData();
TQ3SurfaceShaderObject shader1;
Q3AttributeSet_Get(triMeshData1->triMeshAttributeSet,
kQ3AttributeTypeSurfaceShader, &shader1);
TQ3TextureObject texture1;
Q3TextureShader_GetTexture(shader, &texture1);

What I get in the debugger is unique addresses for the two shaders, but
the same address for the two textures.  So copying the trimesh data
creates a second new shader, but only copies a pointer or reference to the
texture.  I am right so far, right?

So am I correct in assuming that this means the shader now has two copies
in RAM, but that the texture will only have one copy in VRAM?  Obviously,
VRAM is in short supply, and this is a nice feature, assuming I'm
right...but I'm wondering if I can get any increase in efficiency by using
one shader for both TriMeshes?  Would that decrease the RAM requirements?

More seriously, I would like to minimize the time required to duplicate a
trimesh, so that it stands the least chance of disturbing the framerate.
I assume that copying a reference to the shader would be faster than
copying the entire shader structure, but how would I go about doing this?
Clearly, throwing away the copy and inserting a reference to the original
into the new TriMesh after making the new TriMesh isn't going to do any
good.  In fact, that takes extra time, only to save RAM, but not saving
time.

Can I copying the trimesh attribute data without copying the shader
structure?  Would one expect to see any speed improvements as a result of
this?  Is this worth the trouble?

Fundamentally, I need to know for certain that I am right in my assumption
that there is only one copy of the texture in VRAM even if I have
thousands of these objects, assuming their (unique) shaders all use the
same texture pointer.

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
________________________________________________________________________

Bio-degradable 3DMF

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

> We will be making the golden master of Modeller this week.

Well, maybe not.

We have found that successive saving and opening of 3DMF
files containing deeply nested groups gradually lose their
contents. First a polygon will lose its attribute set, then on the
next save/open cycle the polygon will disappear, then another
polygon will lose its attribute set and turn white, then it will
disappear too.

Has anyone else seen this problem? It is possible it may have
been fixed since my branch of Quesa diverged from the main
trunk, but I don't remember seeing any e-mails about anything
similar.

I see exactly the same problem using drag and drop between
applications, using memory resident file objects.

Any ideas?

Roger.

Re: Bug in E3Triangle_InterpolateHit

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

Our tester has given my changes to E3Triangle_InterpolateHit a few
hours testing in Microspot Modeller and it seems to be pretty solid now.
We will be making the golden master of Modeller this week.

Any objections to me checking in the changes to Quesa?

Roger.


On Friday, July 30, 2004, at 02:23  pm, Roger Holmes wrote:

>
> On Thursday, July 29, 2004, at 09:56  pm, Dair Grant wrote:
>
>> Roger Holmes wrote:
>>
>>> There is a bug in E3Triangle_InterpolateHit when it is asked to 
>>> return
>>> a normal vector.
>>>
>>> It should return a normal in world coordinates, and if there are no
>>> normals in the attribute set of the surface, nor in the attribute 
>>> sets
>>> of the vertices then all is well.
>>
>> A normal is a vector, so it doesn't have a coordinate system as such.
>> But I see what you mean, the normal is from the surface before it was
>> transformed to world coordinates or after the transform.
>
> Yes, its a sort of floating coordinate system, it does not have an 
> origin
> but it does have directions for its axes.
>
>
>
>> The docs for QD3D say the result here is:
>>
>>     The surface normal of the picked object at the point of
>>     intersection with the pick geometry.
>>
>> Are the docs incorrect? I.e., what happened under QD3D was actually:
>>
>>     ...with the pick geometry, transformed by the local->world matrix.
>
> I looked in the blue book and can see no description of the normal.
> As you say, QD3D certainly transformed it by the local->world matrix
> and hence so should we. We can clarify it in our own documentation
> and maybe we should warn our users just in case their programs
> are only happening to see the broken version, and hence will break
> when we fix the broken case to be the same as the unbroken case.
>
> I don't think many people use picking at present so I think it is best
> that we fix it before it becomes more popular. If it worked properly
> that might make it more popular too.
>
>
>
>> At the moment we do have a problem in that we're being inconsistent
>> (we're returning the supplied normal as-is if it exists, but will
>> calculate a normal from a transformed triangle if not), but which is 
>> the
>> correct way to adjust the results?
>
> Am I being simple in thinking that multiplying by localToWorld will do 
> the trick?
> Probably, the rotational component is fine but will non uniform 
> scaling in
> X,Y & Z and shearing mess things up? Come to think of it I think I had 
> to
> write some special code in my renderer for transforming normals.
> I will have a look before I write any more.
>
> OK. In my UpdatePipeline routine I calculate  a localToWorldForNormals
> matrix. I set it to the localToWorld, then set the bottom row to 
> 0,0,0,1 and then
> set it to the inverse of its transpose. A comment refers to 'Computer
> Graphics principals and practice' page 1108.
>
> So I guess that's it, but it is a heavy bit of calculation. Should we 
> be doing it
> when we get a 'hit' or every time we change localToWorld? I guess there
> are typically not many hits, and it would be easier to put the code in 
> the
> existing routine. Or is this matrix calculated somewhere already?
>
>>
>> Should the normal always be of the surface in its own coordinate 
>> system,
>> or taken after the surface has been transformed?
>>
>> The surface point is always returned in world coordinates, so it does
>> sound plausible that the normal should be from the transformed surface
>> too.
>>
>>
>>> I have fixed this in my version of Quesa by passing the view into
>>> E3Triangle_InterpolateHit and then calling Q3Vector3D_Transform where
>>> appropriate. I also have to include E3View.h in E3Utils.c so I can 
>>> get
>>> the transform using E3View_State_GetLocalToWorld.
>>>
>>> Is this OK? Should I pass in the matrix instead? Should it return a
>>> flag to say if the normal is in world or local coordinates and then
>>> fix it in the calling code (2 places)? Should it pick it up in some
>>> other way?
>>
>> Best approach would be to pass in the view I think, as that's also
>> passed in to the next routine in line (E3Pick_RecordHit as it also 
>> needs
>> to record the local->world matrix if the caller wants that info back).
>
> Good.
>
>>
>> I wouldn't try and stash an extra flag somewhere, we should just 
>> mandate
>> that the normal that comes out of here is consistent with the thing 
>> that
>> E3Pick_RecordHit will save for the app (so either before or after the
>> transform, but always the same, depending on what QD3D did).
>
> OK
>
>>
>>
>>> Also, when the normal is calculated from three vertex normals, it can
>>> result in a normal which is not normalised. Is there any good reason
>>> for this or can I normalise it?
>>
>> The normal is normalised by e3pick_hit_initialise - we defer doing the
>> normalisation until we know that the caller really does want that bit 
>> of
>> info back.
>>
>
> Oh good, I can take it out of my version of Quesa then.
>
>> -dair
>> ___________________________________________________
>> mailto:dair+refnum.com       http://www.refnum.com/
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by OSTG. Have you noticed the changes 
>> on
>> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
>> one more big change to announce. We are now OSTG- Open Source 
>> Technology
>> Group. Come see the changes on the new OSTG site. www.ostg.com
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: FYI - quesa.org has old email info

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

James W. Walker wrote:

>There's lots of old stuff there.  Send people to quesa.sourceforge.net=20
>instead.  I believe the plan is to redirect the quesa.org domain there,=20
>but obviously it hasn't happened yet.


Kevin Matthews wrote:

>In progress.  Thanks!

Yes, looks like the dns hasn't switched over yet - Kevin, anything we
can do externally to help this?


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