quesa-develop — Mailing list for Quesa development

Re: Caching with custom elements

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

Roger Holmes wrote:

> I see. Would a Q3Shared_DecrementEditIndex be very slightly less
> dangerous?

Perhaps... but I can imagine having a situation where you're going to be 
doing several operations that you don't want to affect caches, and it 
would be easier to get the edit index, do the operations, and set the 
edit index, rather then figure out exactly how much you need to 
decrement the edit index.

By the way, Q3Shared_Edited isn't actually documented to increment the 
edit index, though that's what it does.  The docs just say "change the 
edit index".
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Caching with custom elements

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

>>> In the renderers, I'm using a custom element to cache an optimized
>>> version of a TriMesh.  The element contains an edit index along
>>> with the
>>> TriMesh reference, so that a stale cache can be detected.  That  
>>> works
>>> fine in principle, though there's a bug at the moment.
>>>
>>> But now suppose I have another similar custom element, say to  
>>> cache a
>>> triangle strip.  When I update the triangle strip, it bumps the edit
>>> index, so the other cache becomes stale.  Which causes the other
>>> cache
>>> to get updated, bumping the edit index, which makes the triangle
>>> cache
>>> stale...
>>>
>>> How can I get out of this infinite loop?  The simplest way, I
>>> suppose,
>>> would be to add a Q3Shared_SetEditIndex function, and use it when
>>> setting these cache elements. Is there a more elegant way I haven't
>>> thought of?
>>> -- 
>>
>>
>> I don't exactly understand what you are trying to do. You have an
>> object A
>> which has two caches B and C, both of which hold the edit index of A.
>> Why would updating B or C update the edit index of A?
>
> Because B and C are custom elements, and Q3Object_AddElement and
> Q3Shape_AddElement update the edit index.
>
>> Or is C a cache of B? If so, C holds the edit indexes of A and B.
>
> Elements don't even have edit indexes, only shared objects do.

I see. Would a Q3Shared_DecrementEditIndex be very slightly less
dangerous?

Roger

Re: Caching with custom elements

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

On Feb 14, 2007, at 2:57 AM, Roger Holmes wrote:

>
> On 13 Feb, 2007, at 23:49, James Walker wrote:
>
>> In the renderers, I'm using a custom element to cache an optimized
>> version of a TriMesh.  The element contains an edit index along
>> with the
>> TriMesh reference, so that a stale cache can be detected.  That works
>> fine in principle, though there's a bug at the moment.
>>
>> But now suppose I have another similar custom element, say to cache a
>> triangle strip.  When I update the triangle strip, it bumps the edit
>> index, so the other cache becomes stale.  Which causes the other  
>> cache
>> to get updated, bumping the edit index, which makes the triangle  
>> cache
>> stale...
>>
>> How can I get out of this infinite loop?  The simplest way, I  
>> suppose,
>> would be to add a Q3Shared_SetEditIndex function, and use it when
>> setting these cache elements. Is there a more elegant way I haven't
>> thought of?
>> -- 
>
>
> I don't exactly understand what you are trying to do. You have an
> object A
> which has two caches B and C, both of which hold the edit index of A.
> Why would updating B or C update the edit index of A?

Because B and C are custom elements, and Q3Object_AddElement and  
Q3Shape_AddElement update the edit index.

> Or is C a cache of B? If so, C holds the edit indexes of A and B.

Elements don't even have edit indexes, only shared objects do.

Re: Caching with custom elements

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

On 13 Feb, 2007, at 23:49, James Walker wrote:

> In the renderers, I'm using a custom element to cache an optimized
> version of a TriMesh.  The element contains an edit index along  
> with the
> TriMesh reference, so that a stale cache can be detected.  That works
> fine in principle, though there's a bug at the moment.
>
> But now suppose I have another similar custom element, say to cache a
> triangle strip.  When I update the triangle strip, it bumps the edit
> index, so the other cache becomes stale.  Which causes the other cache
> to get updated, bumping the edit index, which makes the triangle cache
> stale...
>
> How can I get out of this infinite loop?  The simplest way, I suppose,
> would be to add a Q3Shared_SetEditIndex function, and use it when
> setting these cache elements. Is there a more elegant way I haven't
> thought of?
> -- 


I don't exactly understand what you are trying to do. You have an  
object A
which has two caches B and C, both of which hold the edit index of A.
Why would updating B or C update the edit index of A?

Or is C a cache of B? If so, C holds the edit indexes of A and B. If  
A gets changed,
its edit index gets modified. When you need C it checks both edit  
indexes,
if A's has changed it forces B to recache then recaches itself. If  
you need B
first then it recaches itself and when you need C it finds both  
indexes are stale,
so gives B a chance to recache (which it decided not to do as its  
edit index
for A is still fresh), and then C recaches itself.

Roger.

Re: Replicated textures

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

On 13 Feb, 2007, at 20:41, James Walker wrote:

> Roger Holmes wrote:
>
>> Can I presume the edit index of the storage object is kept up to  
>> date?
>
> Good question.  Q3Storage_SetData bumps the edit index, but there are
> probably a number of other ways to change a storage object.  For
> instance, I suppose you could use Q3MemoryStorage_GetBuffer to get a
> pointer to the bytes, and then change some bytes, and the storage  
> object
> would have know way of knowing it was edited.

In the documentation and header file comments we would have to note
something like : If you modify a memory storage object, you must call
<The routine which increments the edited count> before calling the
hash routine, otherwise you may get the old value of the hash.
If we write a texture equal function, we would have to have the
same note for it too as it would call the hash routine.


>
>>>> The question is where to store the hashes. I could put them
>>>> in a custom attribute. This would be fine for me, but would
>>>> we be missing an opportunity. If they were stored in the
>>>> texture shaders or even the storage objects, would this
>>>> be of any use to either the renderers or the saving code
>>>> or anywhere else?
>>> It's not immediately obvious to me how it would be of use.
>>
>> Ok, but you have done the same as I'm going to so maybe it
>> would help the next person who wants to reinvent the wheel.
>>
>> Maybe we could have a method on the storage object which gives a
>> hash code. If we stored a cached value and the edit index (which
>> gets set to an invalid value in the NEW method) in the storage
>> object's header, then when we are asked for the hash, we compare
>> the edit indexes. If they match we return the cached value, if not
>> we update the copy of the edit index, hash the data block, store it
>> in the cache and return its value.
>>
>> The extra information in the header would not need to be saved
>> on disc.
>
> Of course, if it's a file storage, you'd have to read the file to
> compute the hash... though I don't know if anyone is likely to use a
> file storage for texture data.


Yes unlikely. Maybe we only support it for RAM storage objects.
Do file storage objects have an edit count? On disc they have a
last modified date we could use instead. But why make work for
ourselves which we don't expect anybody will ever use.

I suppose we could keep the hash routine private and only
expose a texture compare in the API.


Roger.

Caching with custom elements

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

In the renderers, I'm using a custom element to cache an optimized 
version of a TriMesh.  The element contains an edit index along with the 
TriMesh reference, so that a stale cache can be detected.  That works 
fine in principle, though there's a bug at the moment.

But now suppose I have another similar custom element, say to cache a 
triangle strip.  When I update the triangle strip, it bumps the edit 
index, so the other cache becomes stale.  Which causes the other cache 
to get updated, bumping the edit index, which makes the triangle cache 
stale...

How can I get out of this infinite loop?  The simplest way, I suppose, 
would be to add a Q3Shared_SetEditIndex function, and use it when 
setting these cache elements. Is there a more elegant way I haven't 
thought of?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Replicated textures

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

Roger Holmes wrote:

> Can I presume the edit index of the storage object is kept up to date?

Good question.  Q3Storage_SetData bumps the edit index, but there are 
probably a number of other ways to change a storage object.  For 
instance, I suppose you could use Q3MemoryStorage_GetBuffer to get a 
pointer to the bytes, and then change some bytes, and the storage object 
would have know way of knowing it was edited.


>>> The question is where to store the hashes. I could put them
>>> in a custom attribute. This would be fine for me, but would
>>> we be missing an opportunity. If they were stored in the
>>> texture shaders or even the storage objects, would this
>>> be of any use to either the renderers or the saving code
>>> or anywhere else?
>> It's not immediately obvious to me how it would be of use.
> 
> Ok, but you have done the same as I'm going to so maybe it
> would help the next person who wants to reinvent the wheel.
> 
> Maybe we could have a method on the storage object which gives a
> hash code. If we stored a cached value and the edit index (which
> gets set to an invalid value in the NEW method) in the storage
> object's header, then when we are asked for the hash, we compare
> the edit indexes. If they match we return the cached value, if not
> we update the copy of the edit index, hash the data block, store it
> in the cache and return its value.
> 
> The extra information in the header would not need to be saved
> on disc.

Of course, if it's a file storage, you'd have to read the file to 
compute the hash... though I don't know if anyone is likely to use a 
file storage for texture data.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Replicated textures

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

On 13 Feb, 2007, at 16:01, James W. Walker wrote:

>
> On Feb 13, 2007, at 5:12 AM, Roger Holmes wrote:
>
>> I have been thinking about a problem we are having with multiple
>> objects having the same texture on them. They are gobbling up
>> all the logical address space and also causing thrashing on
>> Macs with less than 2GB of RAM.
>
> Been there...
>
>> At one time, when we read in objects, we would compare all
>> their textures with all existing textures and all their own other
>> textures. We would then make identical ones share the same
>> texture shader objects. This worked fine except we had to take
>> it out because users were complaining about the speed of
>> reading files.
>
> When I read an object, I compare (hashes of) its textures to each
> other and share if possible, but I don't compare to other objects.
> That's an interesting thought.
>
>> The comparisons had the obvious speed ups of comparing
>> the size etc first before comparing the actual pixels. What I
>> am now thinking about is storing a hash of the pixels so
>> that most of the time I will only have to compare the hash.
>> When two identical hashes are found, I do not mind doing
>> the comparison because the chances are very good that
>> the textures really are the same and I will be saving memory.
>
> You'd have to be careful to invalidate the cached hash if the texture
> or its storage is edited.

Can I presume the edit index of the storage object is kept up to date?

>
>> The question is where to store the hashes. I could put them
>> in a custom attribute. This would be fine for me, but would
>> we be missing an opportunity. If they were stored in the
>> texture shaders or even the storage objects, would this
>> be of any use to either the renderers or the saving code
>> or anywhere else?
>
> It's not immediately obvious to me how it would be of use.

Ok, but you have done the same as I'm going to so maybe it
would help the next person who wants to reinvent the wheel.

Maybe we could have a method on the storage object which gives a
hash code. If we stored a cached value and the edit index (which
gets set to an invalid value in the NEW method) in the storage
object's header, then when we are asked for the hash, we compare
the edit indexes. If they match we return the cached value, if not
we update the copy of the edit index, hash the data block, store it
in the cache and return its value.

The extra information in the header would not need to be saved
on disc.

Roger

Re: Q3Object_Duplicate and edit index

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

On 13 Feb, 2007, at 16:27, James W. Walker wrote:

> There's no documentation saying what Q3Object_Duplicate does about
> edit index.  Currently, the duplicate's edit index is set to 1.  Is
> there any reason why the duplicate shouldn't have the same edit index
> as the original?

I don't think it would make any difference to me if you changed it so  
it was not reset to 1.

> Here's why I care.  The OpenGL renderer caches a triangle strip for a
> TriMesh in an object property (which I may change to a custom
> element).  There's an edit index stored with the triangle strip, so
> that the strip can be regenerated if the TriMesh changes.  Naturally,
> if a TriMesh gets duplicated, there is no reason to invalidate the
> strip.
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Q3Object_Duplicate and edit index

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

There's no documentation saying what Q3Object_Duplicate does about  
edit index.  Currently, the duplicate's edit index is set to 1.  Is  
there any reason why the duplicate shouldn't have the same edit index  
as the original?

Here's why I care.  The OpenGL renderer caches a triangle strip for a  
TriMesh in an object property (which I may change to a custom  
element).  There's an edit index stored with the triangle strip, so  
that the strip can be regenerated if the TriMesh changes.  Naturally,  
if a TriMesh gets duplicated, there is no reason to invalidate the  
strip.

Re: Replicated textures

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

On Feb 13, 2007, at 5:12 AM, Roger Holmes wrote:

> I have been thinking about a problem we are having with multiple
> objects having the same texture on them. They are gobbling up
> all the logical address space and also causing thrashing on
> Macs with less than 2GB of RAM.

Been there...

> At one time, when we read in objects, we would compare all
> their textures with all existing textures and all their own other
> textures. We would then make identical ones share the same
> texture shader objects. This worked fine except we had to take
> it out because users were complaining about the speed of
> reading files.

When I read an object, I compare (hashes of) its textures to each  
other and share if possible, but I don't compare to other objects.   
That's an interesting thought.

> The comparisons had the obvious speed ups of comparing
> the size etc first before comparing the actual pixels. What I
> am now thinking about is storing a hash of the pixels so
> that most of the time I will only have to compare the hash.
> When two identical hashes are found, I do not mind doing
> the comparison because the chances are very good that
> the textures really are the same and I will be saving memory.

You'd have to be careful to invalidate the cached hash if the texture  
or its storage is edited.

> The question is where to store the hashes. I could put them
> in a custom attribute. This would be fine for me, but would
> we be missing an opportunity. If they were stored in the
> texture shaders or even the storage objects, would this
> be of any use to either the renderers or the saving code
> or anywhere else?

It's not immediately obvious to me how it would be of use.

Replicated textures

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

I have been thinking about a problem we are having with multiple
objects having the same texture on them. They are gobbling up
all the logical address space and also causing thrashing on
Macs with less than 2GB of RAM.

At one time, when we read in objects, we would compare all
their textures with all existing textures and all their own other
textures. We would then make identical ones share the same
texture shader objects. This worked fine except we had to take
it out because users were complaining about the speed of
reading files.

The comparisons had the obvious speed ups of comparing
the size etc first before comparing the actual pixels. What I
am now thinking about is storing a hash of the pixels so
that most of the time I will only have to compare the hash.
When two identical hashes are found, I do not mind doing
the comparison because the chances are very good that
the textures really are the same and I will be saving memory.

The question is where to store the hashes. I could put them
in a custom attribute. This would be fine for me, but would
we be missing an opportunity. If they were stored in the
texture shaders or even the storage objects, would this
be of any use to either the renderers or the saving code
or anywhere else?

Roger Holmes.

Re: How I can try OpenGl render?

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

Ok I will wait the new update.
Jose' Cruanyes ha scritto:
> Il giorno 12/feb/07, alle ore 12:58, Daniele Cavallini ha scritto:
>
>   
>> I would like try the new "OpenGl render".
>>     
>
>   
>> Are Windows Clients Details correct? I try but I obtain:
>>     
>
> Note that currently only Codewarrior and xCode projects are updated,
>
> I'll update the VC++ and Unix projects in a few days (as soon as I  
> find a little time to do it)
>
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

Re: How I can try OpenGl render?

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

Il giorno 12/feb/07, alle ore 12:58, Daniele Cavallini ha scritto:

> I would like try the new "OpenGl render".

> Are Windows Clients Details correct? I try but I obtain:

Note that currently only Codewarrior and xCode projects are updated,

I'll update the VC++ and Unix projects in a few days (as soon as I  
find a little time to do it)


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 I can try OpenGl render?

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

The current root seem it is work fine.
Thank's a lot.

Jose' Cruanyes ha scritto:
> Il giorno 12/feb/07, alle ore 12:58, Daniele Cavallini ha scritto:
>
>   
>> I would like try the new "OpenGl render".
>> I read the site http://www.quesa.org/developer/cvs.html the client
>> Details but  "http://www.wincvs.org/download.html"  seem don't work.
>> I found wincvs with google.
>> Are Windows Clients Details correct? I try but I obtain:
>>
>> cvs [login aborted]: connect to cvs.sourceforge.net:2401 failed:
>> Connection timed out
>>
>> Thank's for help
>>     
>
>
> seems that the current root is:
>
> ano...@qu...:/cvsroot/quesa
>
> I've updated the source docs, should be online shortly
>
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

Re: How I can try OpenGl render?

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

Il giorno 12/feb/07, alle ore 12:58, Daniele Cavallini ha scritto:

> I would like try the new "OpenGl render".
> I read the site http://www.quesa.org/developer/cvs.html the client
> Details but  "http://www.wincvs.org/download.html"  seem don't work.
> I found wincvs with google.
> Are Windows Clients Details correct? I try but I obtain:
>
> cvs [login aborted]: connect to cvs.sourceforge.net:2401 failed:
> Connection timed out
>
> Thank's for help


seems that the current root is:

ano...@qu...:/cvsroot/quesa

I've updated the source docs, should be online shortly


Pax et Bonum

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

How I can try OpenGl render?

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

I would like try the new "OpenGl render".
I read the site http://www.quesa.org/developer/cvs.html the client 
Details but  "http://www.wincvs.org/download.html"  seem don't work.
I found wincvs with google.
Are Windows Clients Details correct? I try but I obtain:

cvs [login aborted]: connect to cvs.sourceforge.net:2401 failed: 
Connection timed out

Thank's for help

[ quesa-Feature Requests-901431 ] Textures should use packed pixel extension

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

Feature Requests item #901431, was opened at 2004-02-20 14:40
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901431&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Textures should use packed pixel extension

Initial Comment:
We currently convert all incoming textures to 32bpp RGBA for 
passing to OpenGL - most OpenGL implementations will now 
support the packed pixel extension, so we should be able to pass 
on 16 or 24 bit pixel data directly rather than copying it.
        
This could also simplify the texture swapping code in IRUpdate.c, 
which  is quite complex and a bit misleading (e.g., 16bpp texture 
data is not really swapped, it's permuted, and yet the variable is 
called 'swap').


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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:19

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:14

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:13

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:12

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

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

[ quesa-Feature Requests-901431 ] Textures should use packed pixel extension

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

Feature Requests item #901431, was opened at 2004-02-20 14:40
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901431&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Textures should use packed pixel extension

Initial Comment:
We currently convert all incoming textures to 32bpp RGBA for 
passing to OpenGL - most OpenGL implementations will now 
support the packed pixel extension, so we should be able to pass 
on 16 or 24 bit pixel data directly rather than copying it.
        
This could also simplify the texture swapping code in IRUpdate.c, 
which  is quite complex and a bit misleading (e.g., 16bpp texture 
data is not really swapped, it's permuted, and yet the variable is 
called 'swap').


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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:14

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:13

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:12

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

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

[ quesa-Feature Requests-901431 ] Textures should use packed pixel extension

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

Feature Requests item #901431, was opened at 2004-02-20 14:40
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901431&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Textures should use packed pixel extension

Initial Comment:
We currently convert all incoming textures to 32bpp RGBA for 
passing to OpenGL - most OpenGL implementations will now 
support the packed pixel extension, so we should be able to pass 
on 16 or 24 bit pixel data directly rather than copying it.
        
This could also simplify the texture swapping code in IRUpdate.c, 
which  is quite complex and a bit misleading (e.g., 16bpp texture 
data is not really swapped, it's permuted, and yet the variable is 
called 'swap').


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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:13

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:12

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

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

[ quesa-Feature Requests-901431 ] Textures should use packed pixel extension

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

Feature Requests item #901431, was opened at 2004-02-20 14:40
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901431&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Textures should use packed pixel extension

Initial Comment:
We currently convert all incoming textures to 32bpp RGBA for 
passing to OpenGL - most OpenGL implementations will now 
support the packed pixel extension, so we should be able to pass 
on 16 or 24 bit pixel data directly rather than copying it.
        
This could also simplify the texture swapping code in IRUpdate.c, 
which  is quite complex and a bit misleading (e.g., 16bpp texture 
data is not really swapped, it's permuted, and yet the variable is 
called 'swap').


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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-11 00:12

Message:
Logged In: YES 
user_id=433183
Originator: NO

Texture loading now uses 24-bit RGB when there is no alpha channel.  Since
Quesa pixmaps are top to bottom and OpenGL textures are bottom to top, we
need to row-order conversion on the texture data anyway.  So I'm not sure
if there's really much point to this.

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

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

[ quesa-Bugs-967741 ] Polyline ignores segment attributes

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 4
Private: No
Submitted By: James W. Walker (jwwalker)
>Assigned to: James W. Walker (jwwalker)
Summary: Polyline ignores segment attributes

Initial Comment:
This was bug 00007 in the ancient pre-Bugzilla bug list: Wireframe/
Interactive renderers don't support segment attributes for 
polylines.

Note that e3geom_polyline_cache_new is never called when using 
these renderers, instead IRGeometry_Submit_PolyLine and 
WFGeometry_PolyLine handle the polyline.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-10 22:53

Message:
Logged In: YES 
user_id=433183
Originator: YES

PolyLine segment attributes are now handled in the Interactive, Wireframe,
and OpenGL renderers, by the quick and dirty way of decomposing a PolyLine
into Lines if it has segment attributes.  I added a new test model
Polyline-attributes.3dmf to test this.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-06-06 12:48

Message:
Logged In: YES 
user_id=433183

Bug 00022 in the ancient bug list was also this bug.

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

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

[ quesa-Bugs-967914 ] Highlight style's specular settings do not override

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Wont Fix
Priority: 5
Private: No
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: James W. Walker (jwwalker)
Date: 2007-02-10 21:04

Message:
Logged In: YES 
user_id=433183
Originator: NO

Without a sample model, it's not reasonable to expect this to be fixed.

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

Comment By: Frank Condello (pox)
Date: 2004-06-17 14: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 17: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

[ quesa-Bugs-1227484 ] Add support for OpenGL display lists

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael Sullivan (imikey)
>Assigned to: James W. Walker (jwwalker)
Summary: Add support for OpenGL display lists

Initial Comment:
Was discussed on the list with the following thoughts:

*****

James W. Walker wrote:

 > Yes, but if someone is updating a trimesh every frame (which 
isn"t  
 > an unreasonable expectation) you"ll be compiling a new display 
list  
 > every frame, which will certainly be slower than using the 
current  
 > vertex array path.
 
 I suppose some might do that, but it would not be a concern in 
my use  
 of Quesa.
 
 > To use display lists to their potential you need a geometry type  
 > that"s guaranteed never to change, or some sort of flag for  
 > existing geometries that allows you to declare them as "static"  
 > once their data is set.
 
 It would be easy enough to use an object property as a flag.

*****

Mikey wrote:

 >  To use display lists to their potential you need a
 >  geometry type that"s guaranteed never to change, or some 
sort of flag
 >  for existing geometries that allows you to declare them as 
"static"
 >  once their data is set.
 
 I would think that scenery such as ground terrain, trees, etc. 
would  
 be ideal for using this "static" flag and thus become eligible for  
 storage in display lists.  Furthermore, if all such objects had  
 normals computed for them, then perhaps OpenGL"s built-in 
backface  
 culling could be used when drawing them.


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

>Comment By: James W. Walker (jwwalker)
Date: 2007-02-10 21:01

Message:
Logged In: YES 
user_id=433183
Originator: NO

The new OpenGL renderer uses VBOs when the OpenGL implementation supports
them, and display lists otherwise.

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

Comment By: James W. Walker (jwwalker)
Date: 2005-07-16 19:13

Message:
Logged In: YES 
user_id=433183

Dair Grant's idea was that we should use VBO's instead of
display lists, as a more modern method. (There has been
some recent disagreement on the comp.graphics.api.opengl
newsgroup as to whether VBOs are necessarily faster than
display lists.)  The trouble with both ideas is that Quesa
currently does its own backface culling. This is to support
the 3 backfacing choices in Quesa, which do not quite
correspond to OpenGL's two choices of two-sided rendering
or not.  But this means that if you moved the camera, you
would have to flush the cached display lists or VBOs.

What we might consider is making a new renderer that
would place less emphasis on compatibility with QD3D
documentation and experience, and more emphasis on
speed.  The new cartoon-style renderer can serve as an
example of how to base a new renderer on the existing
one, rather than writing a whole renderer from scratch.

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

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

Re: Announcing new OpenGL renderer

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

On Feb 9, 2007, at 12:46 PM, Jose' Cruanyes wrote:

> Il giorno 09/feb/07, alle ore 21:27, James Walker ha scritto:
>
>>>
>>> Your renderer is valid only with optimized trimeshes?
>>
>> Well, I've certainly concentrated on the fast path.  But I can do  
>> some
>> automatic optimization the way the IR does.  Stay tuned...
>
> Not every thing can be everything for everyone...
>
> I've no problem with the Quesa renderer speed, so don't worry for me,
> concentrate in your needs...
>

For the record, I have changed it so that it will use  
Q3TriMesh_Optimize if needed.