quesa-develop — Mailing list for Quesa development

Re: automatic triangle strip generation

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

On Feb 23, 2007, at 4:26 AM, Roger Holmes wrote:

> I think by default it should calculate and cache, just like the
> interactive
> renderer.

You mean the interactive renderer should be changed to use triangle  
strips?

Printing problems on Intel

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

I have been looking into the problems we are having with printing
with the Interactive Renderer on Intel. If I manually push the Hither
clipping plane forward then most, if not all of the problems go away.

Is there a difference between the Z buffer on Intel and PowerPC?
I half remember that the Z Buffer used to default to 16 bit depth,
and that we ask Quesa to use 32 bits instead. Or was the default
changed? Has OpenGL moved on to using a floating point Z buffer
on Intel? If so can we use 64 bit doubles?

Is there a call to set the Z depth? What is it called?

Roger.

Re: automatic triangle strip generation

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

On 22 Feb, 2007, at 20:47, James Walker wrote:

> The new OpenGL renderer caches a triangle strip the first time it
> renders a TriMesh.  There can be a drawback, which is that if a lot of
> geometry gets rendered for the first time at the same time, there  
> can be
> a noticeable pause while the triangle strips are being computed.  So,
> I'm thinking of adding an option to turn off the automatic strip
> computation, probably using an object property attached to the  
> renderer
> object.  The renderer would still look for the triangle strip data, it
> just wouldn't compute a strip if one is missing.  Any opinion as to
> which behavior should be the default?

I think by default it should calculate and cache, just like the  
interactive
renderer.

Roger.

automatic triangle strip generation

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

The new OpenGL renderer caches a triangle strip the first time it 
renders a TriMesh.  There can be a drawback, which is that if a lot of 
geometry gets rendered for the first time at the same time, there can be 
a noticeable pause while the triangle strips are being computed.  So, 
I'm thinking of adding an option to turn off the automatic strip 
computation, probably using an object property attached to the renderer 
object.  The renderer would still look for the triangle strip data, it 
just wouldn't compute a strip if one is missing.  Any opinion as to 
which behavior should be the default?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

[ quesa-Bugs-1370363 ] Memory Leak with UVs set too large numbers

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

Bugs item #1370363, was opened at 2005-11-30 12:51
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1370363&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: None
Priority: 5
Private: No
Submitted By: nstensland (nstensland)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leak with UVs set too large numbers

Initial Comment:
There seems to be a memory leaks when assigning textures to shapes 
(general polygon in my example) which have been assigned UV 
coordinates with large values (a range from -500 to 500 in my example). 
When seting the UVs to a range of 0..1, the memory leaks goes away. 
Should the UV always be in range 0..1
?



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

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

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

We need more information about how a leak is detected, how to replicate
the problem, and whether there is any evidence that the problem is with
Quesa rather than OpenGL.  As far as I know, Quesa always just passes the
UVs on to OpenGL.

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

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

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

> 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: 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/>

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

Re: 64 bit version of Quesa

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

On Feb 18, 2007, at 11:33 AM, James W. Walker wrote:

> Oh, you're talking about u/v limits on geometries.  I don't think
> that has anything to do with the surface uv and shading uv
> attributes.  The Ellipsoid might be the only case where that hasn't
> been handled yet.

I'm wrong, it's not implemented for the Torus either.

Re: 64 bit version of Quesa

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

On Feb 18, 2007, at 6:35 AM, Roger Holmes wrote:

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

AGL is the Carbon-specific API for OpenGL, for things like creating a  
rendering context.  These function names all start with "agl".  One  
case you might be thinking of is the FSAA support for ATI cards,  
which calls aglSetInteger.  I never found any documentation for that  
FSAA feature unless you count messages in mailing list archives.


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

... by using (preemptive) threads, presumably.  On the Mac, it might  
be possible to do the texture format conversion using the vImage  
framework, but it would be better to do it in a cross-platform way.   
The Boost threads library might help with that.


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

If by "intersect" you mean the 2D projections onto the window rather  
than the 3D triangles, then yes.  But that sounds like a programming  
nightmare to me.

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

Oh, you're talking about u/v limits on geometries.  I don't think  
that has anything to do with the surface uv and shading uv  
attributes.  The Ellipsoid might be the only case where that hasn't  
been handled yet.

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

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

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

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

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

[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

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

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);
}

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

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.