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.