quesa-develop — Mailing list for Quesa development

Re: 3d rotation question

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

Roger Holmes wrote:

>
> On Monday, June 21, 2004, at 03:40  pm, Keith Wiley wrote:
>
>>
>> I can't figure out how to take the present orientation (a quaternion 
>> of course) and remove the vertical component of this orientation to 
>> flatten it to 0 without affecting the horizontal orientation (so the 
>> body is still looking along the same vertical azimuthal equator of 
>> the world but at 0 degree altitude).  How do I do this?
>>
>>
>
>
> Quesa's camera objects have a placement which has a camera position, a 
> point of interest
> and an up vector. If you set the Y value of the point of interest to 
> the same Y value of the
> camera position this should give you what you want. You might also 
> want to set the up vector
> to (0,1,0).

Thanks.  I might use that.  I was able to get the same effect by getting the presention orientation, zeroing the x and z parameters, and then orienting to the altered orientation, so w and y are left alone and x and z are zapped.  But points of interest are specifically made for these kinds of goals.  Perhaps I'll use that instead.

________________________________________________________________________
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: 3d rotation question

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

On Monday, June 21, 2004, at 03:40  pm, Keith Wiley wrote:

>
> I can't figure out how to take the present orientation (a quaternion 
> of course) and remove the vertical component of this orientation to 
> flatten it to 0 without affecting the horizontal orientation (so the 
> body is still looking along the same vertical azimuthal equator of the 
> world but at 0 degree altitude).  How do I do this?
>
>


Quesa's camera objects have a placement which has a camera position, a 
point of interest
and an up vector. If you set the Y value of the point of interest to 
the same Y value of the
camera position this should give you what you want. You might also want 
to set the up vector
to (0,1,0).

Re: how is trimesh connected to texture?

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

>>  Here's a seemingly simple question.  How do I make two separate 
>> objects,
>>  each with their own trimeshes and UV coordinates point at the same 
>> texture
>>  so the texture doesn't need to be stored in VRAM twice?
> ...
>> The trimeshdata structure doesn't seem to have a pointer in it that 
>> points
>> to a texture object, so how is the connection between a trimesh and 
>> its
>> texture even made in the first place?
>
> The TriMesh data structure has an attribute set, which may contain a 
> texture shader, which in turn contains a texture object.  Depending on 
> your purposes, different objects might have the same attribute set, or 
> different attribute sets but the same texture shader, or different 
> texture shaders but the same texture object.
>

One thing to look out for is that if you have two TriMeshes saving a 
texture then
save it to disk, when you read it back I think you get two TriMeshes 
with identical
textures, but not the same texture. This is what happened in late 
versions of QD3D
at least, and I don't think it has been fixed in Quesa, or indeed if it 
is desirable to
fix it.

If it has been fixed I would like to know as I could remove a whole 
load of
quite slow code from 3D World which scans through looking for identical 
textures
and makes them share the same texture. I never liked this code as there 
are times
when a user wants identical unshared textures so he can change one of 
them later,
but at present we mangle them into one and he ends up editing both 
whether he
likes it or not.

observing vram usage

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

Say I want to known how much VRAM is necessary for a program I've written,
or conversely that I want to write a program and generate models and
textures for use in the program such that I know it will require no more
than some specified amount of VRAM.  Either of these two opposing
scenarios is possible and useful of course.

Are there any function calls that reveal this kind of information to me?
I can get a clear indication of how often the computer is swapping models
and textures in and out of VRAM, or whether VRAM is even full in the first
place at any given point in time?

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
________________________________________________________________________

3d rotation question

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

The camera view in my program will reflect a first-person perspective of 
a person's body and head in a world.  The person can move their "body" 
by going forward and backward or rotating left and right (yaw).  The 
person can also individually move their head around their neck by 
"pitching" up and down.

I want this system to do some specific things, some of which I have 
figured out, others of which I haven't.

Moving forward and backward is easy, since I can get the forward vector 
of the object, discard the Y axis and just translate by a distance or 
speed scalar of X and Z to move over horizontal ground (discarding Y 
because looking up shouldn't make a person fly up into the sky when they 
move forward).

Rotating around Y isn't too hard.  I tried using yaw but of course that 
makes it yaw around the local Y axis which gets funky when the head is 
pitched up or down.  However, this is fairly easy by just orienting 
around the Y Euler angle.  I have found that is works properly even when 
the camera is pitched away from a horizontal viewing axis.

However, I have the following problem.  I would like to make the head 
"snap" back to 0 vertical (no pitch) when I move the body forward or 
backward (so instead of wandering around with one's head pointed an 
arbitrary pitch the head should snap back to horizontal as soon as the 
body and camera are moved forward or backward).

I can't figure out how to take the present orientation (a quaternion of 
course) and remove the vertical component of this orientation to flatten 
it to 0 without affecting the horizontal orientation (so the body is 
still looking along the same vertical azimuthal equator of the world but 
at 0 degree altitude).  How do I do this?

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
________________________________________________________________________

Additional patch for bug #895106

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

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.

Thanks,
Frank.

Re: how is VRAM purged/cleared?

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

Cool.  Thanks for the explanation.

________________________________________________________________________
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: how is VRAM purged/cleared?

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

Keith Wiley wrote:

>How do I remove stuff from VRAM that I don't need anymore because the
>user has wandered far enough away from an object and its texture?  Is
>VRAM automatically on some sort of LRU memory management scheme or do
>I have to intentionally clear space for new stuff?

It's managed automatically - OpenGL/D3D virtualise VRAM for you, so that
the only thing an app developer (or Quesa) needs to do is to activate
the required texture before drawing.

If activating that means bumping other textures out of VRAM, they use
whatever scheme they see fit (typically LRU) to make space.


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

Re: how is trimesh connected to texture?

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

Keith Wiley wrote:

>Hmmm, okay, so you're not referring to the vertex or triangle
>attributes but the attributes of the entire trimesh, called
>triMeshAttributeSet. I'll look at that.  Thanks.

Yes, that's one way to do it - store a reference to the texture object
within the TriMesh's attribute set as a whole.

The other way to do it is to put both the texture and the TriMesh in the
same group.

A group acts as a kind of "scope delimiter" for the state changes within
it, so that if you have:

    Group1
        TriMesh1
        Group2
            TextureA
            TriMesh2
            TriMesh3
        Group3
            TextureB
            TriMesh4

Then TriMesh 1 will be rendered without a exture, TriMesh2 and 3 will
have TextureA, and TriMesh4 will have TextureB.

If a TriMesh has a texture in its own attribute set, that overrides the
"current" (=3D=3Dlast processed texture in the current group or a parent
group) texture - if it doesn't, it's drawn in the current texture if
any.


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

how is VRAM purged/cleared?

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

I understand that by creating and submitting trimesh objects and textures
that Quesa "talks to" VRAM and fills it up with necessary models and
textures and lighting information and whatnot, so that when I tell it to
render a frame it has what it needs to do the job.

Imagine that I have a large terrain based world and as I wander around I
load in part of the map that the user wanders into and purge parts the
user wanders away from.

How do I remove stuff from VRAM that I don't need anymore because the user
has wandered far enough away from an object and its texture?  Is VRAM
automatically on some sort of LRU memory management scheme or do I have to
intentionally clear space for new stuff?

________________________________________________________________________
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: how is trimesh connected to texture?

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

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

> Keith Wiley <kw...@cs...>
>
> >  Here's a seemingly simple question.  How do I make two separate objects,
> >  each with their own trimeshes and UV coordinates point at the same texture
> >  so the texture doesn't need to be stored in VRAM twice?
> ...
> >The trimeshdata structure doesn't seem to have a pointer in it that points
> >to a texture object, so how is the connection between a trimesh and its
> >texture even made in the first place?
>
> The TriMesh data structure has an attribute set, which may contain a
> texture shader, which in turn contains a texture object.  Depending
> on your purposes, different objects might have the same attribute
> set, or different attribute sets but the same texture shader, or
> different texture shaders but the same texture object.

Hmmm, okay, so you're not referring to the vertex or triangle attributes
but the attributes of the entire trimesh, called triMeshAttributeSet.
I'll look at that.  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: how is trimesh connected to texture?

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

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

>  Here's a seemingly simple question.  How do I make two separate objects,
>  each with their own trimeshes and UV coordinates point at the same texture
>  so the texture doesn't need to be stored in VRAM twice?
...
>The trimeshdata structure doesn't seem to have a pointer in it that points
>to a texture object, so how is the connection between a trimesh and its
>texture even made in the first place?

The TriMesh data structure has an attribute set, which may contain a 
texture shader, which in turn contains a texture object.  Depending 
on your purposes, different objects might have the same attribute 
set, or different attribute sets but the same texture shader, or 
different texture shaders but the same texture object.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

how is trimesh connected to texture?

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

Here's a seemingly simple question.  How do I make two separate objects,
each with their own trimeshes and UV coordinates point at the same texture
so the texture doesn't need to be stored in VRAM twice?  As an example
imagine that I have a variety of rocks, for the sake of
adding...variety...to the world, but they can all use the same texture.
The trimeshdata structure doesn't seem to have a pointer in it that points
to a texture object, so how is the connection between a trimesh and its
texture even made in the first place?

These kinds of things are sort of "opaque" in that opening 3DMF files is
done with internal function calls, such as Q3File_ReadObject, so there's
no clear way to know what happens under the hood, how textures are
connected to their associated trimeshes for example.

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: meshwork texture smoothing into trimesh?

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

At 4:17 PM -0600 6/17/04, Keith Wiley wrote:

>Meshwork has an option for smoothing a texture.

No, actually, it's an option for smoothing the shading of the 
geometry.  From section 3.2.5 of the manual,

"Smooth: when Smooth is checked, Meshwork will output vertex normals 
to file formats which support them. These are used for Gouraud 
shading, which gives your model a smoother, less faceted look. If 
unchecked, vertex normals will not be generated for this material."

>I was able to get it to work perfectly, textures are properly mapped to
>each individual subobject, but if I open a 3DMF with a smoothed texture
>and start fanangling the vertices, triangles, and UV values, the model
>renders with the right geometry but a completely messed up texture.

Whet sort of texture mapping are you using?  See the comments just a 
bit further in section 3.2.5 about "Texture Map" where it talks about 
splitting neighbors across a seam when using spherical or cylindrical 
mapping.  Perhaps that's the bit your code isn't taking into account.

HTH,
- Joe

-- 

,------------------------------------------------------------------.
|    Joseph J. Strout         Codenautics: quality Mac software    |
|    jo...@st...           http://codenautics.com/              |
`------------------------------------------------------------------'

Re: texture smoothing

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

Nevermind.  Had to copy to point normal attributes, which I hadn't noticed
before because they didn't exist when I was debugging and studying
trimeshdata structs for objects that didn't have smoothed textures.

Ugh.

Sorry for the wasted post.

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

meshwork texture smoothing into trimesh?

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

Meshwork has an option for smoothing a texture.  It doesn't smooth the
vertices, but has sort of a blurring effect on the texture as it wraps
over edges and around corners.  I assume this is a Quesa/QD3D thing,
otherwise what would it be doing.

What exactly is it doing?  I can't find the string "smooth" in any quesa
header file.  I was hoping it might be some kind of texture attribute.  I
ask because I have been taking 3DMF files and then modifying their
trimeshes in code to change their shape and create multiple subobjects as
part of a single larger trimesh, for the purpose of speeding rendering
over having many small objects.

I was able to get it to work perfectly, textures are properly mapped to
each individual subobject, but if I open a 3DMF with a smoothed texture
and start fanangling the vertices, triangles, and UV values, the model
renders with the right geometry but a completely messed up texture.

Anybody have a clue on this one?

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-967914 ] Highlight style's specular settings do not override

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Highlight style's specular settings do not override

Initial Comment:
An attribute set's specular settings do not get overridden by a 
highlight style.

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

>Comment By: Frank Condello (pox)
Date: 2004-06-17 17:45

Message:
Logged In: YES 
user_id=171509

I've narrowed this down a bit...

This bug only occurs on primitives that use face/cap attribute sets. If 
face or caps inherit the geometry's main attribute set the specular 
properties aren't overridden when applying a highlight style. 
Everything works as it should if face and/or cap attribute sets actually 
exist 
however.

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

Comment By: Dair Grant (grantd)
Date: 2004-06-15 20:09

Message:
Logged In: YES 
user_id=439944

Can you attach a model that demonstrates the problem?

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

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

Re: Bug 895099 proposed fix

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

On 16-Jun-04, at 1:47 PM, Dair Grant wrote:

> Frank C wrote:
>
>> I've gained some speed by removing all NULL binds and wrapping
>> glBindTexture in a GL_Util*** routine that compares the last texture 
>> to
>> the requested one, avoiding redundant uploads.
>
> The texture won't be uploaded when it's bound: unless it got bumped out
> of vram by something else since the last time it was bound, it'll still
> be there.
>
>> This helps the transparent pass quite a bit since it often
>> binds/unbinds the same texture over and over (for every triangle) when
>> drawing a mostly self-sorted mesh.
>
> I guess it removes the need to call GL, but I would expect 
> glBindTexture
> to not do anything if the same object is already bound - although I
> suppose it could be implementation dependent (perhaps some drivers do 
> no
> checking at all: seems unlikely though, checking for a no-change is 
> such
> an obvious thing to do if you were writing glBindTexture).

I would hope drivers would do this as well, but I was under the 
impression you shouldn't rely on this.

I've done some testing with OpenGL Profiler on Mac OS X 10.3.4 with a 
GeForce3 64MB card. The scene consisted of one model with three 
textures (i.e. 3 trimeshes) with approximately 1500 triangles total. 
Below are the average timings for glBindTexture from the "% GL Time" 
column:

CVS source 06/17/04
  All solid textures: 1.3 %
  All transparent textures: 8.6 %

CVS source 06/17/04, with redundant calls to glBindtexture and NULL 
binds removed)
  All solid textures: 0.5 %
  All transparent textures: 1.7 %

This doesn't translate to a huge speed up for the entire application 
but it's measurable.

Frank.

Re: serious texture mapping bug in current code

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

On 16-Jun-04, at 12:50 PM, Dair Grant wrote:

> Frank C wrote:
>
>> Yes - Not sure if you noticed, but hitting command-A in that example
>> app I posted will swap in a solid model for a quick comparison.
>
> Yep. What would be handy actually would be a build with a fixed camera
> (perhaps snap the camera to a failing position on Button()), as that
> would make it easier to see exactly what was being submitted to GL.

I've updated the archive with a new app - clicking on the window will 
now freeze/run the animation 
<http://webhome.idirect.com/~frankco/rb/TransTest.sit>

Frank.

Re: Bug 895099 proposed fix

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

Thanks Dair, that is crystal clear now.




On Thursday, June 17, 2004, at 02:04  pm, Dair Grant wrote:

> Roger Holmes wrote:
>
>>> In this case, it's the currently-running renderer - i.e., some
>>> plug-in, not the renderer-support code in Quesa.
>>
>> OK, so it IS relevant. I don't think we should be doing anything which
>> breaks existing renderers.
>
> This change won't break existing renderers - it fixes a bug in the
> interactive renderer (a bug that may also be present in other 
> renderers,
> but I don't think we can solve it for all renderers automatically).
>
>
>> Yes, but with Quesa, the caching code converts most things to
>> TriMeshes whether I like it or not. Apart from the interactive
>> renderer, are there any which handle boxes directly? If not then I
>> guess I'm just wasting your valuable time. If so, then sorry and I'll
>> shut up about it.
>
> I don't think anything does handle boxes directly, but there's no 
> reason
> why they couldn't.
>
>
> The box thing is a bit of a red herring - the bug is actually:
>
>     Group
>         TextureA
>         Triangle1 { attributes: color=red                     }
>         Triangle2 { attributes: color=green; texture=TextureB }
>         Triangle3 { attributes: color=blue                    }
>
> For this case, the interactive renderer would have rendered Triangle1
> with TextureA, Triangle2 with TextureB, and Triangle3 without any
> texture.
>
> This is because it temporarily makes TextureB active while processing
> Triangle2, but doesn't restore the previously active texture when it's
> finished Triangle2.
>
>
> The proposed fix was to handle this push/pop at the renderer support
> code in Quesa - that would fix it for all renderers, but that wouldn't
> handle immediate mode submits.
>
> Although you can't submit an immediate mode group, you can submit a
> geometry which is equivalent - e.g., submitting a texture followed by 
> an
> immediate mode box that had a face with an attribut set that also had a
> texture would display the same symptoms.
>
>
> That's the case which precludes fixing it in the renderer support code:
> that code can know where to find the attribute set of built-in
> geometries, but wouldn't know where to find the attribute set for
> plug-in geometries (not relevant today, but would like to support 
> them).
>
> If you had a plug-in geometry which a renderer didn't support, it'd be
> fine: the geometry would be broken down into something it did support
> and as part of that the attribute set wold be found.
>
> If you had a plug-in geometry which a renderer supported directly, 
> you'd
> have the same problem as today - the renderer would need to be
> responsible for swapping out the texture if the attribute set also held
> one.
>
>
> So all this means is that renderers that want to support textures in
> attribute sets (as QD3D's IR did, and so our IR does too), the renderer
> needs to restore the previous texture correctly once it's finished the
> attribute-set-textured object.
>
> The bug is that at the moment we don't, so any subsequent objects lose
> their texture.
>
>
> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Bug 895099 proposed fix

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

Roger Holmes wrote:

>> In this case, it's the currently-running renderer - i.e., some
>> plug-in, not the renderer-support code in Quesa.
>
>OK, so it IS relevant. I don't think we should be doing anything which
>breaks existing renderers.

This change won't break existing renderers - it fixes a bug in the
interactive renderer (a bug that may also be present in other renderers,
but I don't think we can solve it for all renderers automatically).


>Yes, but with Quesa, the caching code converts most things to
>TriMeshes whether I like it or not. Apart from the interactive
>renderer, are there any which handle boxes directly? If not then I
>guess I'm just wasting your valuable time. If so, then sorry and I'll
>shut up about it.

I don't think anything does handle boxes directly, but there's no reason
why they couldn't.


The box thing is a bit of a red herring - the bug is actually:

    Group
        TextureA
        Triangle1 { attributes: color=3Dred                     }
        Triangle2 { attributes: color=3Dgreen; texture=3DTextureB }
        Triangle3 { attributes: color=3Dblue                    }

=46or this case, the interactive renderer would have rendered Triangle1
with TextureA, Triangle2 with TextureB, and Triangle3 without any
texture.

This is because it temporarily makes TextureB active while processing
Triangle2, but doesn't restore the previously active texture when it's
finished Triangle2.


The proposed fix was to handle this push/pop at the renderer support
code in Quesa - that would fix it for all renderers, but that wouldn't
handle immediate mode submits.

Although you can't submit an immediate mode group, you can submit a
geometry which is equivalent - e.g., submitting a texture followed by an
immediate mode box that had a face with an attribut set that also had a
texture would display the same symptoms.


That's the case which precludes fixing it in the renderer support code:
that code can know where to find the attribute set of built-in
geometries, but wouldn't know where to find the attribute set for
plug-in geometries (not relevant today, but would like to support them).

If you had a plug-in geometry which a renderer didn't support, it'd be
fine: the geometry would be broken down into something it did support
and as part of that the attribute set wold be found.

If you had a plug-in geometry which a renderer supported directly, you'd
have the same problem as today - the renderer would need to be
responsible for swapping out the texture if the attribute set also held
one.


So all this means is that renderers that want to support textures in
attribute sets (as QD3D's IR did, and so our IR does too), the renderer
needs to restore the previous texture correctly once it's finished the
attribute-set-textured object.

The bug is that at the moment we don't, so any subsequent objects lose
their texture.


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

Re: Bug 895099 proposed fix

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

On Wednesday, June 16, 2004, at 06:43  pm, Dair Grant wrote:

> Roger Holmes wrote:
>
>> I think we need some more specific terminology here.
>>
>> ' The renderer ' is not always the Quesa interactive renderer, the
>> same source code should be able to run under QD3D or Quesa. We need to
>> have some way to differentiate between the plug in renderer layer and
>> the layer which comes between it and Quesa's submit calls.
>
> In this case, it's the currently-running renderer - i.e., some plug-in,
> not the renderer-support code in Quesa.

OK, so it IS relevant. I don't think we should be doing anything which 
breaks
existing renderers.

>
>
>> Which are we discussing here?
>
> When a(ny) renderer is asked to render a geometry with a texture stored
> in the geometry attribute set, it needs to render that geometry using
> the texture in the attribute set rather than the currently active
> geometry.

Yes but most plug in renderers use the 'renderer-support' code to 
convert
from the many different geometries into just TriMesh (not even that with
some renderers), Triangle, Line, Point and Marker. I think that any 
required
change should also be put into this conversion code.

> This is the same behaviour as QD3D and means that if you submit texture
> A followed by a box with a texture B on one of its face attribute sets,
> then the box should be rendered partly with texture A and partly with
> texture B.

Yes, but with Quesa, the caching code converts most things to TriMeshes
whether I like it or not. Apart from the interactive renderer, are 
there any
which handle boxes directly? If not then I guess I'm just wasting your
valuable time. If so, then sorry and I'll shut up about it.

> I.e., the face with the texture attribute overrides the default 
> texture,
> and the other faces inherit the default texture from the parent object
> (which, since the box doesn't have a texture itself, inherits it from
> the current view state, which works back up the enclosing groups until
> it finds a texture).
>
>
> The underlying bug here is that when we activated texture B, we didn't
> restore texture A - instead we did SetTexture(NULL), i.e., turned off
> texturing for any following objects in the current texture scope.
>
> James' initial fix was to handle this attribute-set-overrides-current
> state by pushing/popping the texture in Quesa's renderer support code.
>
> That doesn't work for immediate mode submits, as we don't know what the
> instance data actually looks like at that point. We could add a big
> switch at that level which would try and identify it, but that won't
> work for plug-in geometries (where we would have no way to find the
> attribute set given the void* that would be the geometry data).
>
> Renderers can handle both immediate and retained mode submits, as any
> plug-in geometries would get broken down into something that they know
> what the instance data looks like.
>
>
> So, all this means is:
>
> 1. The IR needs to save/restore the active texture correctly when it
> sees a texture in an attribute set that overrides the last-submitted
> texture object.
>
> 2. Any renderer that wants to support texturing needs to do the same
> thing, or it won't render "group with texture and three geometries the
> middle one of which has a texture in its attribute set" correctly.
>
> This would be another example of where a test suite would be good: once
> you know of a corner case that needs to be supported you just write up 
> a
> test case and that can be used for renderer verification as well as
> catching regressions.
>
>
> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: quesa/Development/Source/Platform/Windows E3WindowsStorage.c,1.8,1.9

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

Jose' Cruanyes wrote:

>the Q3WindowsStorage takes a file HANDLE as parameter, by definition=20
>you can only get HANDLEs on open files...

Ah, that's presumably why the QD3D docs were contradictory. That would
be worth commenting then, just to explain why this storage object is
different - perhaps something for the book?


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

Re: quesa/Development/Source/Platform/Windows E3WindowsStorage.c,1.8,1.9

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

On Jun 17, 2004, at 11:41 AM, Dair Grant wrote:

>
>
> This does make the Win32 storage object inconsistent with the others
> though. Since the QD3D docs were contradictory, should we 
> conditionalise
> this in QUESA_BUILD_AS_BINARY_COMPATIBLE?
>
> I.e., if QUESA_BUILD_AS_BINARY_COMPATIBLE is 0 then we should 
> open/close
> the file as per the other storage objects: if it's 1 then we would take
> this approach of assuming the app is responsible (I assume that's what
> caused the change, i.e., your app passes in an open file on Win32?).
>
>

the Q3WindowsStorage takes a file HANDLE as parameter, by definition 
you can only get HANDLEs on open files...

Pax et Bonum

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

Re: quesa/Development/Source/Platform/Windows E3WindowsStorage.c,1.8,1.9

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

Jose Cruanyes wrote:

>Q3WindowsStorage takes a open file and a open file had to leave, but
>currently it closed the file Now I've made both the open and close
>methods NOPs

Might be worth sticking a comment in just above the switch statement to
say that the open/close methods are deliberately not provided for Win32
storage?

I can see us going back and saying "oops, we're missing open/close here"
at some point without realising why they were removed... :-)


This does make the Win32 storage object inconsistent with the others
though. Since the QD3D docs were contradictory, should we conditionalise
this in QUESA_BUILD_AS_BINARY_COMPATIBLE?

I.e., if QUESA_BUILD_AS_BINARY_COMPATIBLE is 0 then we should open/close
the file as per the other storage objects: if it's 1 then we would take
this approach of assuming the app is responsible (I assume that's what
caused the change, i.e., your app passes in an open file on Win32?).


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