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.