quesa-develop

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: 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: 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...>]

>>> 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. <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...>]

On 15 Feb, 2007, at 21:43, James Walker 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".

Right.

The other thing I was thinking about was a save and restore mechanism
but I initially thought the decrement was better. The save and  
restore is
essentially the same as your get and set but could have an opaque data
structure.

By the way, has anyone thought much about a 64 bit version of Quesa yet?

Roger.

64 bit version of Quesa

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

Il giorno 16/feb/07, alle ore 01:04, Roger Holmes ha scritto:

> By the way, has anyone thought much about a 64 bit version of Quesa  
> yet?

not too far (a year ago or so) I've submitted patches needed to make  
Quesa run on a Linux Gentoo AMD64,
I'm fairly sure Quesa is still 64 bits clean


Pax et Bonum

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

e3pick_hit_find

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

I have been having speed problems with marquee selection.
The application has a FOR loop going through all the hit
triangles. This can easily be 100,000 triangles. It calls a
routine which gets the details of the hit which eventually calls
e3pick_hit_find which has a WHILE loop which indexes
through the list structure looking for the item, hence this
is executed 100,000 * 100,000 / 2 = 10,000,000,000 times
and increases with the square of the complexity, taking
an unacceptable amount of time.

My solution is to cache the last list item found and its index
along with the instance data pointer to make sure we not are
comparing apples and pears. Then if the requested index
is greater than the cached index, we continue looking on
from that point. Typically for my code this is the next item.
My code used to work backwards through the list, and
this would still work, but cannot   not be optimised as the
list is not doubly linked.

I have tested this code and it seems to be OK on Mac with Cocoa.
If you think its OK, could someone check it in please.

Roger.

New version:



static TQ3PickHit *
e3pick_hit_find(TQ3PickUnionData *pickInstanceData, TQ3Uns32 n)
{	TQ3PickHit		*currentHit = pickInstanceData->pickHits;



	// Check we're not out of range
	if (n > pickInstanceData->numHits)
		return(NULL);
	
	if (pickInstanceData->data.common.numHitsToReturn != kQ3ReturnAllHits)
		{
		if (n > pickInstanceData->data.common.numHitsToReturn)
			return(NULL);
		}
	
	// Optimised for programs which read hits by increasing number.
	// As there is no previous pointer, cannot optimise for decrements
	static TQ3PickUnionData* instanceCached = NULL ;
	static TQ3Uns32 indexCached = 0xFFFFFFFF ;
	static TQ3PickHit* hitCached = NULL ;
	
	TQ3Uns32 index = n ;
	if ( instanceCached == pickInstanceData && n > indexCached &&  
hitCached != NULL )
		{
		n -= indexCached ;
		currentHit = hitCached ;
		}

	// Walk through the list to find the right item
	while (currentHit != NULL && n != 0)
		{
		--n ;
		currentHit = currentHit->nextHit;
		}

	indexCached = index ;
	instanceCached = pickInstanceData ;
	hitCached = currentHit ;

	return(currentHit);
}

Re: e3pick_hit_find

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

Roger Holmes wrote:

> I have been having speed problems with marquee selection.
> The application has a FOR loop going through all the hit
> triangles. This can easily be 100,000 triangles. It calls a
> routine which gets the details of the hit which eventually calls
> e3pick_hit_find which has a WHILE loop which indexes
> through the list structure looking for the item, hence this
> is executed 100,000 * 100,000 / 2 = 10,000,000,000 times
> and increases with the square of the complexity, taking
> an unacceptable amount of time.
> 
> My solution is to cache the last list item found and its index
> along with the instance data pointer to make sure we not are
> comparing apples and pears. Then if the requested index
> is greater than the cached index, we continue looking on
> from that point. Typically for my code this is the next item.
> My code used to work backwards through the list, and
> this would still work, but cannot   not be optimised as the
> list is not doubly linked.
> 
> I have tested this code and it seems to be OK on Mac with Cocoa.
> If you think its OK, could someone check it in please.

I'd like to take a broader look at the algorithms and data structures 
used for picking.  The problem you encountered is that e3pick_hit_find 
uses a linear-time search.  But I also notice that E3Pick_RecordHit does 
a linear-time search for the place to insert the next hit, which means 
that in the worst case, inserting H hits could take time on the order of 
H * H.

Here's a proposal:

1. Store the hits, or pointers to them, in a std::vector.  This will 
allow e3pick_hit_find to work in constant time with no caching.

2. Don't keep the hits sorted as they're being collected.  Instead, sort 
them all at once the first time Q3Pick_GetPickDetailData or 
Q3Pick_GetPickDetailValidMask is called after the picking is done.  The 
sorting can be used with std::sort, in time on the order of H log H.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: e3pick_hit_find

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

On 21 Feb, 2007, at 19:18, James Walker wrote:

>
> I'd like to take a broader look at the algorithms and data structures
> used for picking.  The problem you encountered is that e3pick_hit_find
> uses a linear-time search.  But I also notice that E3Pick_RecordHit  
> does
> a linear-time search for the place to insert the next hit, which means
> that in the worst case, inserting H hits could take time on the  
> order of
> H * H.

Presumably if I specify kQ3PickSortNone, it does not do the search. When
the user clicks, I do a pick on that point, sorted and I use just the  
frontmost, the
hits are few anyway. For a marquee selection I don't need to sort the  
picks, I
process all of them within the selection rectangle, but they are  
numerous.
Actually I get lots of references to the same object, and I only need  
one
reference to each object. One day it would be nice to have a pick filter
function which the application supplies, which would have access to the
pick list and a potential new pick, and it would either add the new  
pick or
not, or replace a pick with the new one. For the point pick I could  
just keep
the frontmost pick, and for the  marquee selection I could just keep the
small number I need. This way we would not need to allocate as much
memory. Anyway, lets keep it simple for now.

>
> Here's a proposal:
>
> 1. Store the hits, or pointers to them, in a std::vector.  This will
> allow e3pick_hit_find to work in constant time with no caching.

That would be great.

> 2. Don't keep the hits sorted as they're being collected.  Instead,  
> sort
> them all at once the first time Q3Pick_GetPickDetailData or
> Q3Pick_GetPickDetailValidMask is called after the picking is done.   
> The
> sorting can be used with std::sort, in time on the order of H log H.

Yes, though of course there's no need to do the sort at all for  
kQ3PickSortNone.

Re: e3pick_hit_find

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

Roger Holmes wrote:
> On 21 Feb, 2007, at 19:18, James Walker wrote:

>> Here's a proposal:
>>
>> 1. Store the hits, or pointers to them, in a std::vector.  This will
>> allow e3pick_hit_find to work in constant time with no caching.
> 
> That would be great.
> 
>> 2. Don't keep the hits sorted as they're being collected.  Instead,  
>> sort
>> them all at once the first time Q3Pick_GetPickDetailData or
>> Q3Pick_GetPickDetailValidMask is called after the picking is done.   
>> The
>> sorting can be used with std::sort, in time on the order of H log H.
> 
> Yes, though of course there's no need to do the sort at all for  
> kQ3PickSortNone.

Right.  I've committed this change to E3Pick.c.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: 64 bit version of Quesa

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

On 16 Feb, 2007, at 13:43, Jose' Cruanyes wrote:

>
> Il giorno 16/feb/07, alle ore 01:04, Roger Holmes ha scritto:
>
>> By the way, has anyone thought much about a 64 bit version of Quesa
>> yet?
>
> not too far (a year ago or so) I've submitted patches needed to make
> Quesa run on a Linux Gentoo AMD64,
> I'm fairly sure Quesa is still 64 bits clean
>


Encouraging. I presume that a 3DMF file will be limited to 4GB as
the offset fields are 32 bit, but that will not be a problem for some
time yet. Group counts are 32 bits and there will be various other
problems even further into the future.

Roger.

Re: 64 bit version of Quesa

[Sean M. <se...@ro...>]

On 2007-02-16 14:43, Jose' Cruanyes said:

>> By the way, has anyone thought much about a 64 bit version of Quesa  
>> yet=3F
>
>not too far (a year ago or so) I've submitted patches needed to make  
>Quesa run on a Linux Gentoo AMD64,
>I'm fairly sure Quesa is still 64 bits clean

I think it will be problematic on the Mac though.  Last time I checked,
Quesa uses QuickDraw all over the place, and QuickDraw is not available
to 64 bit apps.

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: 64 bit version of Quesa

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

On 16 Feb, 2007, at 18:25, Sean McBride wrote:

> On 2007-02-16 14:43, Jose' Cruanyes said:
>
>>> By the way, has anyone thought much about a 64 bit version of Quesa
>>> yet?
>>
>> not too far (a year ago or so) I've submitted patches needed to make
>> Quesa run on a Linux Gentoo AMD64,
>> I'm fairly sure Quesa is still 64 bits clean
>
> I think it will be problematic on the Mac though.  Last time I  
> checked,
> Quesa uses QuickDraw all over the place, and QuickDraw is not  
> available
> to 64 bit apps.

The viewer uses QuickDraw but the viewer is a small part of Quesa.
This could be re-coded to use Quartz or Cocoa but Quartz would be
more universal. I doubt Apple will support QuickDraw for too many
more years even on the 32bit Intel platform.

As far as I know, none of the rest of Quesa uses QuickDraw.

Roger.

Re: 64 bit version of Quesa

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

Roger Holmes wrote:

> The viewer uses QuickDraw but the viewer is a small part of Quesa.
> This could be re-coded to use Quartz or Cocoa but Quartz would be
> more universal. I doubt Apple will support QuickDraw for too many
> more years even on the 32bit Intel platform.

There's also QuickDraw in E3MacDrawContext.c and GLDrawContext.c.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: 64 bit version of Quesa

[Sean M. <se...@ro...>]

On 2007-02-16 12:17, James Walker said:

>> The viewer uses QuickDraw but the viewer is a small part of Quesa.
>> This could be re-coded to use Quartz or Cocoa but Quartz would be
>> more universal. I doubt Apple will support QuickDraw for too many
>> more years even on the 32bit Intel platform.
>
>There's also QuickDraw in E3MacDrawContext.c and GLDrawContext.c.

And it's not just QuickDraw.  Quesa uses other long-since-deprecated-and-
now-totally-gone APIs: like FSSpecs.

I think a 64 bit Quesa on Mac will be a non-trivial effort.

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: 64 bit version of Quesa

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

Sean McBride wrote:
> On 2007-02-16 12:17, James Walker said:
> 
>>> The viewer uses QuickDraw but the viewer is a small part of Quesa.
>>> This could be re-coded to use Quartz or Cocoa but Quartz would be
>>> more universal. I doubt Apple will support QuickDraw for too many
>>> more years even on the 32bit Intel platform.
>> There's also QuickDraw in E3MacDrawContext.c and GLDrawContext.c.
> 
> And it's not just QuickDraw.  Quesa uses other long-since-deprecated-and-
> now-totally-gone APIs: like FSSpecs.
> 
> I think a 64 bit Quesa on Mac will be a non-trivial effort.


I suspect that most of the QD stuff in E3MacDrawContext.c is in support 
of the Q3XDrawRegion_* APIs, which are not used by any of our renderers 
(not even RayShade).  We could consider dropping support for those APIs.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: 64 bit version of Quesa

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

> And it's not just QuickDraw.  Quesa uses other long-since- 
> deprecated-and-
> now-totally-gone APIs: like FSSpecs.
>
> I think a 64 bit Quesa on Mac will be a non-trivial effort.


We will need to replace FSSpecs soon I suspect.

When I look up some of the OpenGL APIs we are using in the
interactive renderer (when I am debugging), they are not listed
in the documentation, so I wonder if we need to update Quesa
a bit there too in the not too distant future.


Maybe we should be kicking around some ideas of where we
would like to take Quesa in the next year or so.

Whilst I do not have actual need for any of these right now,
some ideas I have been thinking about:

Multi-processor support (I have already added this to the Microspot
renderer but maybe it could be used in other area too).

More optimisation. Especially I would like to reduce going all
around the houses for a group to submit the groups within it.
One recursive routine in the stack trace is unavoidable, but at
the moment we have three routines repeatedly calling each
other. One knows what the submission mode is e.g Picking
but the other ones keep checking the mode, which must be
slowing us down. There has got to be a better way.

Opening up the opaque data structures in the debugging version so
when debugging we can see inside the structs properly. This might
involve putting the E3 classes into separate files which in the release
version get included in the .cp file to give the same effect as now,
but in the debugging version, have them included in the .h file.

Having an optional C++ interface, not on top of what we currently
have, but calling the E3 routines directly. Maybe somebody
would prefer Objective C though. Maybe two options.

The ability to handle larger models. The problem is mainly textures.
Going 64 bit would cure this of course but maybe there is an
alternative way.

Fixing bugs in the transparent path - textures with alpha channels
cause strange effects where objects overlap - even if the entire
alpha channel is full of 0xFFs. Set the same texture to have no
alpha and the problem goes away.

Using SVN instead of CVS.

Maybe finishing Apple's work with surface UV clipping e.g. a hemisphere.

Finding and implementing the new whizzy features which must have come
along in 3D technology since QuickDraw 3D died.

Weeding out any dead wood in the code which is holding us back. For
instance we have sets and attribute sets, we have these on all objects
and we have an extra one on shape objects, some of which are
geometries which I think have their own whole object attributes. Do
we need all these? Maybe they aren't holding us back but anyone
coming fresh to Quesa would find them confusing I think.

I would like to go back to being able to store lights in display groups,
preferably so that when their group gets submitted, they get added
to the light group so that I would no longer have to do a pre-pass
to read all the lights and add them to the light group myself with
their correct transforms and then afterward remove them from the
light group. Lights are real things in the real world, we do not need
to do anything with them until EndRender time, so why do they
have to be known before StartRender time?

CSGs as implemented in the Apple graphics card.

Roger.

Re: 64 bit version of Quesa

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

On Feb 17, 2007, at 3:53 PM, Roger Holmes wrote:

> When I look up some of the OpenGL APIs we are using in the
> interactive renderer (when I am debugging), they are not listed
> in the documentation, so I wonder if we need to update Quesa
> a bit there too in the not too distant future.

Could you give me an example or two of these APIs?  Do you mean  
OpenGL proper, or AGL?

> Maybe we should be kicking around some ideas of where we
> would like to take Quesa in the next year or so.
>
> Whilst I do not have actual need for any of these right now,
> some ideas I have been thinking about:
>
> Multi-processor support (I have already added this to the Microspot
> renderer but maybe it could be used in other area too).

Is this pretty much the same as multi-threading support?

> The ability to handle larger models. The problem is mainly textures.
> Going 64 bit would cure this of course but maybe there is an
> alternative way.

Do you mean number of textures, or size of textures?  Surely you  
don't have billions of textures, which is where 64 bit would matter.

> Fixing bugs in the transparent path - textures with alpha channels
> cause strange effects where objects overlap - even if the entire
> alpha channel is full of 0xFFs. Set the same texture to have no
> alpha and the problem goes away.

There's a bug about better transparency sorting, I wonder if that's  
what you're talking about.  I keep hoping that one of these years the  
graphics cards will have a way to handle transparency without so much  
hassle.

> Maybe finishing Apple's work with surface UV clipping e.g. a  
> hemisphere.

I don't know what you are talking about here, can you expand on this?

> CSGs as implemented in the Apple graphics card.

I don't know anything about that, either...  Do have a reference?

Re: 64 bit version of Quesa

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

On 18 Feb, 2007, at 00:40, James W. Walker wrote:

>
> On Feb 17, 2007, at 3:53 PM, Roger Holmes wrote:
>
>> When I look up some of the OpenGL APIs we are using in the
>> interactive renderer (when I am debugging), they are not listed
>> in the documentation, so I wonder if we need to update Quesa
>> a bit there too in the not too distant future.
>
> Could you give me an example or two of these APIs?  Do you mean
> OpenGL proper, or AGL?

Will do this when I'm back in the office. What is AGL, please excuse
my ignorance.

>
>> Maybe we should be kicking around some ideas of where we
>> would like to take Quesa in the next year or so.
>>
>> Whilst I do not have actual need for any of these right now,
>> some ideas I have been thinking about:
>>
>> Multi-processor support (I have already added this to the Microspot
>> renderer but maybe it could be used in other area too).
>
> Is this pretty much the same as multi-threading support?

Apple/Next have messed about with terminology here. I am not talking
about cooperative multi-threading on a single processor - no point for
Quesa. All the current Macs have have at least dual core Intel  
processors
and often four cores in two processors, and the last top of the line G5s
have quad processors too. It is nice to see the Activity Monitor showing
400% processor utilisation during rendering and have it finish in about
a third of the time it used to. One of the slowest parts of the  
interactive
renderer is currently the reformatting of textures ready for OpenGL.  
This
could be shared between processors.

>
>> The ability to handle larger models. The problem is mainly textures.
>> Going 64 bit would cure this of course but maybe there is an
>> alternative way.
>
> Do you mean number of textures, or size of textures?  Surely you
> don't have billions of textures, which is where 64 bit would matter.

Due to speed problems we usually limit textures to 512 by 512 pixels,
though a modifier key does allow users to use their full size if needed.
A yea ago we had customers with 600MB 3DMF files, running on
quad processor G5s with maximum RAM and the best graphics
cards. I suspect by now they must be near to hitting the 2GB and
they will be really unhappy when they do. We tell them that there is
little point setting more than about 32 sides to a circle in their
geometries, but they insist they can tell the difference and that
they cannot do with less than 100, which make a single sphere-
like object 10,000 triangles alone. I think with this particular
customer, the geometries and textures must be about half the
disc size each. On disc, the problem is that every object has its
own copy of the textures, even if in memory they are shared
between hundreds of objects.

>
>> Fixing bugs in the transparent path - textures with alpha channels
>> cause strange effects where objects overlap - even if the entire
>> alpha channel is full of 0xFFs. Set the same texture to have no
>> alpha and the problem goes away.
>
> There's a bug about better transparency sorting, I wonder if that's
> what you're talking about.  I keep hoping that one of these years the
> graphics cards will have a way to handle transparency without so much
> hassle.

Sounds like we are sorting the triangles when we should be splitting
them where they intersect.
>
>> Maybe finishing Apple's work with surface UV clipping e.g. a
>> hemisphere.
>
> I don't know what you are talking about here, can you expand on this?

There are two types of UVs, surface UVs and shading UVs. There has been
some confusion with there over the years. The original intention  
apparently
was that shading UVs would be used for texture shaders and surface UVs
would be used to clip the object to minimum and maximum UVs. By  
specifying
a maximum V of 0.5 on a sphere would give a hemisphere, by specifying
a maximum U of 0.25 and V of 0.5 would give an eighth of a sphere with
four flat quarters of a circle extending to the centre of the sphere.

Similarly you could use it in on a cone to cut the point off etc.

>
>> CSGs as implemented in the Apple graphics card.
>
> I don't know anything about that, either...  Do have a reference?

They are in the blue book. The original Apple Nubus card (yes that
far back) supported assigning geometries either A,B,C,D or E
CSG attribute, and you could specify a CSG equation which was
a single 32 bit number ( 2 to the power 5 bits, for A B C D & E) which
specified which combinations would be solid and which thrown away.
The card itself did the hard work of splitting the geometries at their
intersection and chucking away the unwanted bits. I currently do this
in software, but is it possible that OpenGL can handle this by now?

Roger.

Re: 64 bit version of Quesa

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

Il giorno 18/feb/07, alle ore 15:35, Roger Holmes ha scritto:

>  On disc, the problem is that every object has its
> own copy of the textures, even if in memory they are shared
> between hundreds of objects.
>
this is surely a bug in the 3dmf writing routines...
it should not be this way... I'll take a look shortly

Pax et Bonum

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

Disk sharing of textures

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

Il giorno 20/feb/07, alle ore 17:45, Jose' Cruanyes ha scritto:

> Il giorno 18/feb/07, alle ore 15:35, Roger Holmes ha scritto:
>
>>  On disc, the problem is that every object has its
>> own copy of the textures, even if in memory they are shared
>> between hundreds of objects.
>>
> this is surely a bug in the 3dmf writing routines...
> it should not be this way... I'll take a look shortly
>

It seems that the shaders are shared but the textures not... never  
noticed because I create a shared as soon the texture is loaded...



Pax et Bonum

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

Re: Disk sharing of textures

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

Jose' Cruanyes wrote:
> Il giorno 20/feb/07, alle ore 17:45, Jose' Cruanyes ha scritto:
> 
>> Il giorno 18/feb/07, alle ore 15:35, Roger Holmes ha scritto:
>>
>>>  On disc, the problem is that every object has its
>>> own copy of the textures, even if in memory they are shared
>>> between hundreds of objects.
>>>
>> this is surely a bug in the 3dmf writing routines...
>> it should not be this way... I'll take a look shortly
>>
> 
> It seems that the shaders are shared but the textures not... never  
> noticed because I create a shared as soon the texture is loaded...

I don't understand... under what circumstances are textures not shared? 
  I made an example where a texture is used by several TriMeshes, and I 
can save it as 3DMF and see that the textures are still shared.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Optimization ideas (was Re: 64 bit version of Quesa)

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

Roger Holmes wrote:

> More optimisation. Especially I would like to reduce going all
> around the houses for a group to submit the groups within it.
> One recursive routine in the stack trace is unavoidable, but at
> the moment we have three routines repeatedly calling each
> other. One knows what the submission mode is e.g Picking
> but the other ones keep checking the mode, which must be
> slowing us down. There has got to be a better way.


I'm not sure which 3 routines you're talking about here.  When you 
submit a group for rendering, the call stack looks something like

Q3Object_Submit
E3Object_Submit
E3View_SubmitRetained
e3view_submit_retained_render
e3group_display_submit_contents
e3group_submit_contents
Q3Object_Submit

I say "something like" because if you subclass the view object, as Geom 
Test does, you have the subclass submit-retained-render method in there. 
  It's true that two of these, e3group_display_submit_contents and 
e3group_submit_contents, check the view mode, but E3View_GetViewMode is 
just an accessor and should be quite fast.

One way I see to shorten the cycle is to have e3group_submit_contents 
call E3View_SubmitRetained directly instead of calling Q3Object_Submit. 
  That looks safe, so I'll go ahead and commit it.


Also, is anyone using kQ3CallbackElementTypeBeforeRender and 
kQ3CallbackElementTypeAfterRender, which are checked every time through 
e3view_submit_retained_render?

I put those in a few years back, but I don't use them any more, as I 
decided that I can do more with less trouble by subclassing the view object.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

Il giorno 24/feb/07, alle ore 04:11, James Walker ha scritto:

>
> Also, is anyone using kQ3CallbackElementTypeBeforeRender and
> kQ3CallbackElementTypeAfterRender, which are checked every time  
> through
> e3view_submit_retained_render?
>

not me

Pax et Bonum

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