quesa-develop — Mailing list for Quesa development

using varying res models at varying distance

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

Consider mipmaps for a moment, textures which are downsampled whenever
they are wrapped over objects that are distant from the camera.

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

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

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

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

Or are models never persistantly in VRAM and only textures hang around in
the long term...which would explain why models must be resubmitted for
every single rendering cycle.  I guess I'm not entirely clear on exactly
which things are uploaded persistantly to VRAM until LRU ditches them and
which things are uploaded only for the duration of a single render call
and then are immediately disposed.

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

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: reference counting

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

At 4:21 PM -0700 6/24/04, James W. Walker wrote:

>It has never seemed onerous to me.  I always know which objects are 
>picks or views, I don't have them floating around among other 
>objects.
>
>It would be dangerous to just make Q3Shared_GetReference return the 
>value it was passed for a non-shared object.  Then you might think 
>you'd be free to dispose the "new" reference.

Good point.  It just seems strange, then, that you use 
Q3Object_Dispose on both shared and non-shared objects.  More clear 
(to me) would be a Q3Shared_ReleaseReference that you call on shared 
objects, and reserve Q3Object_Dispose for non-shared objects which 
you want to immediately dispose.

At 1:29 PM +0100 6/25/04, Roger Holmes wrote:

>Its never been a problem for me either. Views and Picks are used in 
>very specific places. I would be happy if they did not inherit from 
>Q3Object at all.

I didn't realize it was just views and picks (though before I 
document that, I'll go crawl the headers to make sure).  I guess two 
exceptions to the rule isn't too hard to remember.

But actually, I'd be happier if they didn't inherit from TQ3Object 
too, and if TQ3Object then had all the semantics of TQ3SharedObject. 
Then we wouldn't have any exceptions, and the compiler would catch it 
if you tried to get or release a reference to something not 
reference-counted.

Oh well, thanks all for your help in clarifying this.

Best,
- Joe

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

Re: reference counting

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

On Friday, June 25, 2004, at 12:21  am, James W. Walker wrote:

> It has never seemed onerous to me.  I always know which objects are 
> picks or views, I don't have them floating around among other objects.

Its never been a problem for me either. Views and Picks are used in 
very specific places. I would be happy if they did not
inherit from Q3Object at all.

> It would be dangerous to just make Q3Shared_GetReference return the 
> value it was passed for a non-shared object.  Then you might think 
> you'd be free to dispose the "new" reference.

I agree.

> It might not be bad to make the view and pick types shared, though 
> it's conceivable that some program out there relies on the fact that 
> they are not.

Yes I think this is possible, though I don't really see the need except 
to make Quesa easier to understand.  I doubt it could possibly cause 
anyone
a problem as code using them already will not call 
Q3Shared_GetReference and hence it doesn't matter which copy of the 
pointer they call Dispose on.

Re: WWDC?

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

On Thursday, June 24, 2004, at 05:09  pm, James W. Walker wrote:

> So, who's going to WWDC this year besides me?
>

Not me.

Roger.

Re: reference counting

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

"Joseph J. Strout" <jo...@st...> wrote:

>So you really have to do this before you know whether to call
>Q3Shared_GetReference on a generic TQ3Object?  Does this seem
>desirable to anyone, or do we only do it that way because it's how
>QD3D worked?
>
>Given the quality of the QD3D API in general, this seems like a
>surprisingly onerous flaw, so I guess I still hope that I'm missing
>something.

It has never seemed onerous to me.  I always know which objects are 
picks or views, I don't have them floating around among other objects.

It would be dangerous to just make Q3Shared_GetReference return the 
value it was passed for a non-shared object.  Then you might think 
you'd be free to dispose the "new" reference.

It might not be bad to make the view and pick types shared, though 
it's conceivable that some program out there relies on the fact that 
they are not.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: reference counting

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

At 9:20 AM -0700 6/24/04, James W. Walker wrote:

>>- If you have some generic routine that takes a TQ3Object and makes 
>>another reference to it, then you can't know at compile time 
>>whether or not it is shared, so you must find out dynamically 
>>somehow whether or not to call Q3Shared_GetReference... but how?
>
>Easy: Q3Object_IsType( x, kQ3ObjectTypeShared )

So you really have to do this before you know whether to call 
Q3Shared_GetReference on a generic TQ3Object?  Does this seem 
desirable to anyone, or do we only do it that way because it's how 
QD3D worked?

Given the quality of the QD3D API in general, this seems like a 
surprisingly onerous flaw, so I guess I still hope that I'm missing 
something.

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

Re: WWDC?

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

At 9:09 AM -0700 6/24/04, James W. Walker wrote:

>So, who's going to WWDC this year besides me?

Not me, alas.

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

Re: WWDC?

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

James W. Walker wrote:

>So, who's going to WWDC this year besides me?

Unfortunately I won't be there this year - too much on at work... :-)


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

Re: WWDC?

[Lane R. <la...@if...>]

on Thu, Jun 24, 2004 James W. Walker may have said:

>So, who's going to WWDC this year besides me?

I will be.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
Q. "If you knew it wasn't true, why did you report it?"
A. "If nobody watches my show, we will all starve."

Actual response from Denver TV news anchor in response to questions in
an A&E Investigative Reports airing. And people believe what they watch!

Re: reference counting

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

On Jun 24, 2004, at 7:47 AM, Joseph J. Strout wrote:

> - If you have some generic routine that takes a TQ3Object and makes 
> another reference to it, then you can't know at compile time whether 
> or not it is shared, so you must find out dynamically somehow whether 
> or not to call Q3Shared_GetReference... but how?

Easy: Q3Object_IsType( x, kQ3ObjectTypeShared )
--
<http://www.jwwalker.com/>

WWDC?

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

So, who's going to WWDC this year besides me?
--
<http://www.jwwalker.com/>

Re: reference counting

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

At 4:09 PM -0700 6/23/04, James W. Walker wrote:

>>When that reference is about to disappear -- for example, because
>>it's in a local variable that is about to go out of scope or be
>>assigned a different value, or in an object that is being destroyed
>>-- then you must call Q3Object_Dispose to let Quesa know that there
>>is one less reference to that object.
>
>The first use of the word "object" here refers, I assume, to 
>something like a C++ object, while the last use refer to a Quesa 
>object.  This may cause confusion.

Your interpretation is right, but I agree, that's confusing.  I'll change it.

>>Assuming this is all correct, the reader will be wondering: Why do
>>Dispose a Q3Object, but I can only GetReference to a Q3SharedObject?
>>It doesn't seem very parallel.
>
>This does not bother me, though maybe I'm just used to it.  For 
>shared objects, "dispose" has a special meaning.

But one would expect GetReference to take a Q3Object, and under the 
hood it would just have a special meaning for shared objects.

>>  And, is it safe to call Q3SharedObject
>
>You mean Q3Shared_GetReference?

Yes, sorry about that...

>>  on something that is not, in fact, a Q3SharedObject
>
>If we look at the source code in Quesa, we see that 
>Q3Shared_GetReference will have an assertion failure and then return 
>NULL.

Well that's not very pleasant.  It makes the whole use of Quesa 
objects much more confusing.  (See below.)

>>(and what's an example of a Q3Object like that)?
>
>Look at the typedefs of TQ3SharedObject etc. in Quesa.h, and you see 
>that views and picks are examples of non-shared Quesa objects.

So would you agree that the proper rule is this:

- When you want to make another reference to a Quesa object, and know 
its type, you must look up that type in Quesa.h and see if it derives 
from TQ3SharedObject.  If it does, call Q3Shared_GetReference; if 
not, just make your other reference and don't worry about it.

- When you're done with a Quesa object that may also be in use 
elsewhere, you must again look it up to see if it's shared; if it is, 
call Q3Object_Dispose; if it's not, then don't do so or you'll be 
pulling the rug out from under some other part of your app.

- If you have some generic routine that takes a TQ3Object and makes 
another reference to it, then you can't know at compile time whether 
or not it is shared, so you must find out dynamically somehow whether 
or not to call Q3Shared_GetReference... but how?

I'm glad we're having this discussion, because even after all these 
years, I still don't seem to have a firm grip on Quesa/QD3D's 
reference-counting system!

Thanks,
- Joe

P.S. This is all for the Using Quesa book, so once I'm clear on it 
I'll try to write it up so that we never have to explain it again!
-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: (no subject)

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

> Assuming this is all correct, the reader will be wondering: Why do 
> Dispose a Q3Object, but I can only GetReference to a Q3SharedObject? 
> It doesn't seem very parallel.  And, is it safe to call Q3SharedObject 
> on something that is not, in fact, a Q3SharedObject (and what's an 
> example of a Q3Object like that)?
>
> I don't have good answers to these questions, so I'm hoping you do!

An object knows how to dispose of itself, just like it knows how to 
submit itself or
how to make a copy of itself. We do not need separate routines to 
dispose of a box,
an ellipsoid, a polygon etc so we do not need a separate routine for 
shared and
unshared objects. Using C++ terminology you just say "delete fred" and 
the system
uses the object's virtual destructor (and any base classes virtual 
destructors in turn).

The only thing that Q3Shared_GetReference does is to increment the 
reference count.
Why It was not called something more appropriate I don't know. As an 
unshared object
does not have a reference count it is both pointless and invalid to 
call GetReference on
one. To get a reference to an unshared object you just assign its 
pointer to another
pointer, but you have to keep track (in the programmer's head) of when 
the object is
no longer needed. Actually you can do the same thing with shared 
objects, and I do,
but only in simple pieces of code where it is easy to track the 
pointers. For more
complex cases this is impossible and the small overhead of calling
Q3Shared_GetReference and Q3Object_Dispose is worth every nanosecond.

Roger.

Re: how is trimesh connected to texture?

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

On Wednesday, June 23, 2004, at 12:58  am, Jose' Cruanyes wrote:

>>
>> Could you clarify this a little. I have an object whose reference 
>> count is say 2, and it is in the attribute
>> sets of two objects. If either of the objects get deleted then the 
>> other must of course still to work correctly.
>> If both get deleted I want the texture deleted too. How can this be 
>> made to work with your method of
>> writing the texture once and then using references? Unless I do a 
>> pre-pass through the data I am going
>> to write. Could Quesa do this for me as it writes out the data?
>>
>
> let's see:
>
> Object 1 ---+
>             |
> Object 2 ---+--- Texture (with ref count of at least 3)
>             |
> Object 3 ---+
>
> when Quesa writes a 3DMF:
> it writes the first object and with the texture, pushing both two in 
> the TOC with ref count 1
> then the second object, but when tries to write the texture it is 
> found in the TOC, and so the texture is not written, just the ref 
> count in the TOC is incremented, and what gets written is an object 
> reference.
>
> same for object three
>
> at the end the TOC is writen (or at least the entries in the TOC with 
> ref count greater than one)
>
> so the texture is written only once
>
> when reading you get the same object tree with only one texture that 
> has a ref count of exactly three.
>
> when you delete two objects, each object releases a ref count of the 
> texture, remaining an object with the texture with a ref count of just 
> one.
>
> deleting the last object the texture is released, its ref count reach 
> zero and then is deleted
>
> is should work like this, if not, it's a bug.


Thanks for the clarification. Quesa is doing it for me already, you 
have fixed the bug which was in the later
versions of QD3D, so it is now safe for me to remove the horrible work 
around I had to write for QD3D.

Many thanks.

Roger.

Re: forwarding www.quesa.org to quesa.sourceforge.net?

[Kevin M. <mat...@ar...>]

In progress.  Thanks!

- K


On Wed, 23 Jun 2004 16:42:55 -0500, Joseph J. Strout wrote:
> 
> Now that the web pages at quesa.sourceforge.net are all updated, 
> spiffy clean, and ready to go, how about making www.quesa.org forward 
> to (or an alias of) the sourceforge site?
> 
> Best,
> - Joe
> 
> -- 
> ,------------------------------------------------------------------.
> |    Joseph J. Strout         Check out the Mac Web Directory:     |
> |    jo...@st...           http://www.macwebdir.com/            |
> `------------------------------------------------------------------'
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
> 

Re: reference counting

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

Joseph J. Strout" <jo...@st...> wrote:

>Please check my text on reference counting (below)... I want to make 
>sure I don't lead anyone astray.
>

>When that reference is about to disappear -- for example, because
>it's in a local variable that is about to go out of scope or be
>assigned a different value, or in an object that is being destroyed
>-- then you must call Q3Object_Dispose to let Quesa know that there
>is one less reference to that object.

The first use of the word "object" here refers, I assume, to 
something like a C++ object, while the last use refer to a Quesa 
object.  This may cause confusion.  If a reference is held by a Quesa 
object, such as a group, then it is Quesa's responsibility to dispose 
the reference when the object is destroyed.

>Assuming this is all correct, the reader will be wondering: Why do
>Dispose a Q3Object, but I can only GetReference to a Q3SharedObject?
>It doesn't seem very parallel.

This does not bother me, though maybe I'm just used to it.  For 
shared objects, "dispose" has a special meaning.

>  And, is it safe to call Q3SharedObject

You mean Q3Shared_GetReference?

>  on something that is not, in fact, a Q3SharedObject

If we look at the source code in Quesa, we see that 
Q3Shared_GetReference will have an assertion failure and then return 
NULL.

>(and what's an example of a Q3Object like that)?

Look at the typedefs of TQ3SharedObject etc. in Quesa.h, and you see 
that views and picks are examples of non-shared Quesa objects.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

(no subject)

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

Hi gang,

Please check my text on reference counting (below)... I want to make 
sure I don't lead anyone astray.

-----
Reference counted objects

  Most objects in Quesa are reference-counted. That means that Quesa 
keeps track of how many references there are to an object, and 
doesn't delete the object until the object is no longer in use (i.e., 
its reference count is zero).

  Not all libraries treat reference-counting the same way. The Quesa 
rules for it are as follows:

	1. The reference count of an object is incremented before 
returning it from a function.

	2. The reference count of an object is not incremented before 
passing it in as a parameter to some other function.

  So, if you call a Quesa function that returns an object (such as 
Q3Box_New or  Q3Group_GetPositionObject), you have gained a reference 
to that object. As long as you keep that reference in your data, 
everything is fine. When that reference is about to disappear -- for 
example, because it's in a local variable that is about to go out of 
scope or be assigned a different value, or in an object that is being 
destroyed -- then you must call Q3Object_Dispose to let Quesa know 
that there is one less reference to that object.

  If your own code causes another reference to an object to be created 
-- for example, because you're returning an object from a function 
but also keeping your own reference to it -- then you should call 
Q3Shared_GetReference to increment its reference count.
-----

Assuming this is all correct, the reader will be wondering: Why do 
Dispose a Q3Object, but I can only GetReference to a Q3SharedObject? 
It doesn't seem very parallel.  And, is it safe to call 
Q3SharedObject on something that is not, in fact, a Q3SharedObject 
(and what's an example of a Q3Object like that)?

I don't have good answers to these questions, so I'm hoping you do!

Thanks,
- Joe

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

Re: 2D 3D projection question

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

Keith Wiley wrote:

>Can I easily take a pixel coordinate and determine which 3D object is
>under that pixel, in other words which 3D object (or actual triangle
>or trimesh I suppose) is shallowest in the z-buffer at the pixel's
>location?

You want to use a pick object - see QuesaPick.h.

If you're just interested in a single point use a window point pick, if
you want to catch everything under a rectangle use a window rect.


>I know Open-GL has routines for this sort of thing.

Actually the routines in QD3D/Quesa are considerably more sophisticated:
in OpenGL you tend to have to restort to tricks like rendering your
scene through a 1x1 viewport with every object rendered in a unique
colour.

Under Quesa you can just submit to a picking loop, then read off your
results at the end (the third type of pick is a world ray pick, which
can be used for simple collision detection: i.e., shoot a ray out of the
front of some object, and see what it hits).


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

forwarding www.quesa.org to quesa.sourceforge.net?

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

Now that the web pages at quesa.sourceforge.net are all updated, 
spiffy clean, and ready to go, how about making www.quesa.org forward 
to (or an alias of) the sourceforge site?

Best,
- Joe

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

Re: 2D 3D projection question

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

On Wed, 23 Jun 2004, James W. Walker wrote:

> Keith Wiley <kw...@cs...> wrote:
>
> >Can I easily take a pixel coordinate and determine which 3D object is
> >under that pixel, in other words which 3D object (or actual triangle or
> >trimesh I suppose) is shallowest in the z-buffer at the pixel's location?
> >
> >I know Open-GL has routines for this sort of thing.  How would this be
> >done in QD3D or Quesa?  Or can it not easily be done?
>
> In QD3D/Quesa that's called picking.  See the "Pick Objects" chapter
> in the QD3D manual.

Thank you very much for the lead.

________________________________________________________________________
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: 2D 3D projection question

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

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

>Can I easily take a pixel coordinate and determine which 3D object is
>under that pixel, in other words which 3D object (or actual triangle or
>trimesh I suppose) is shallowest in the z-buffer at the pixel's location?
>
>I know Open-GL has routines for this sort of thing.  How would this be
>done in QD3D or Quesa?  Or can it not easily be done?

In QD3D/Quesa that's called picking.  See the "Pick Objects" chapter 
in the QD3D manual.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

2D 3D projection question

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

Can I easily take a pixel coordinate and determine which 3D object is
under that pixel, in other words which 3D object (or actual triangle or
trimesh I suppose) is shallowest in the z-buffer at the pixel's location?

I know Open-GL has routines for this sort of thing.  How would this be
done in QD3D or Quesa?  Or can it not easily be done?

It would be useful for a program/game I'm working on because the user
could click on parts of a rendered scene to interact with objects in the
scene, but that will only work if I can figure out what has been clicked
on, right?

I mean, I could force the user to line the camera up perfectly straight
with an object and then interact with it on the assumption that it's the
object directly ahead of the camera's forward-vector in world space, but
that's a tedious requirement to place on the user.

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?

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

On Jun 22, 2004, at 7:36 PM, Roger Holmes wrote:
>
> Could you clarify this a little. I have an object whose reference 
> count is say 2, and it is in the attribute
> sets of two objects. If either of the objects get deleted then the 
> other must of course still to work correctly.
> If both get deleted I want the texture deleted too. How can this be 
> made to work with your method of
> writing the texture once and then using references? Unless I do a 
> pre-pass through the data I am going
> to write. Could Quesa do this for me as it writes out the data?
>

let's see:

Object 1 ---+
             |
Object 2 ---+--- Texture (with ref count of at least 3)
             |
Object 3 ---+

when Quesa writes a 3DMF:
it writes the first object and with the texture, pushing both two in 
the TOC with ref count 1
then the second object, but when tries to write the texture it is found 
in the TOC, and so the texture is not written, just the ref count in 
the TOC is incremented, and what gets written is an object reference.

same for object three

at the end the TOC is writen (or at least the entries in the TOC with 
ref count greater than one)

so the texture is written only once

when reading you get the same object tree with only one texture that 
has a ref count of exactly three.

when you delete two objects, each object releases a ref count of the 
texture, remaining an object with the texture with a ref count of just 
one.

deleting the last object the texture is released, its ref count reach 
zero and then is deleted

is should work like this, if not, it's a bug.



Pax et Bonum

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

Re: how is trimesh connected to texture?

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

>> 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 they are written shared (written only once and then using 
> references) Quesa will read it as shared, I've just tested it (perhaps 
> for some cases there is a bug that prevent this)

Could you clarify this a little. I have an object whose reference count 
is say 2, and it is in the attribute
sets of two objects. If either of the objects get deleted then the 
other must of course still to work correctly.
If both get deleted I want the texture deleted too. How can this be 
made to work with your method of
writing the texture once and then using references? Unless I do a 
pre-pass through the data I am going
to write. Could Quesa do this for me as it writes out the data?

Re: how is trimesh connected to texture?

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

On Jun 22, 2004, at 2:51 PM, Roger Holmes wrote:

> 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 they are written shared (written only once and then using 
references) Quesa will read it as shared, I've just tested it (perhaps 
for some cases there is a bug that prevent this)



Pax et Bonum

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