Jeff,

Interfacing a retained mode framework from Squeak is - in my understanding -
a very, very bad idea. The reason for this is that you're basically giving
up all of the control to the framework (e.g., some stuff written in C++).
While this is okay for certain applications that don't want to extend the
framework it requires you to play by the rules not only of the underlying
immediate mode framework (such as OpenGL, or immediate mode Direct3D, or
Apple RAVE) but also by the rules of this retained mode framework [Jeff
mentioned that they (e.g., the Alice team at CMU) had serious problems with
some of the behavior of D3D when it comes to texture loads]. The question
is: Do you gain enough by using the retained mode framework to give up the
freedom you have in a Smalltalk system?! In my understanding the answer is
clearly: No. The reason is that the retained mode framework is basically
just a scene graph with a bunch of actions used for rendering, picking etc.
All of this stuff is mapped to the immediate mode stuff anyways and we can
do this *easily* in Squeak ourselves. In fact, if you look closely at
Squeak-Alice then you'll notice that Squeak-Alice *is* a retained mode
framework - and a pretty good one at this because it allows you to script
arbitrary objects in the 3D world. That it is currently not at the same
speed as other retained mode frameworks has nothing at all to do with
Squeak-Alice. It is the immediate mode stuff which drops us in the framerate
- everything in Squeak is currently run from software only, there is no
hardware accelleration at all.

So, what I think we really need to have is ultra-fast immediate mode
rendering with a highly flexible retained mode framework behind it. The
access to the immediate mode stuff will allow you to do real-time game stuff
(I've never seen a game using any retained mode stuff) while the retained
mode frameworks eases the use of 3D stuff for not so time critical
applications (such as end-user scripting). Using Quesa or Open Inventor or
any other retained mode framework only gives up the flexibility since you
can hardly change anything without going to program C and thus I don't see
any reason to go that way.

  Andreas

PS. Since you're a lead Mac engineer: Is there any way to get HW
accellerated rendering into off-screen bitmaps on a Mac?! If so, how do you
have to setup things to make it work?!
--
+===== Andreas Raab ========= (andreasr at wdi.disney.com) ==+
| Walt Disney Imagineering        Phone: +1 818 544 5016  I
I Glendale, CA                    Fax:   +1 818 544 4544  I
+======< http://isgwww.cs.uni-magdeburg.de/~raab >========+


> ----------
> From: 	Jeff Szuhay
> Reply To: 	jeffs at pstnet.com
> Sent: 	Tuesday, July 27, 1999 10:25 AM
> To: 	squeak at cs.uiuc.edu
> Cc: 	recipient list not shown
> Subject: 	Re: Fwd: Quesa 0.0.2
> 
> At 10:33 AM -0700 7/27/99, Lawson English wrote:
> >Not sure if anyone is really interested, but as I pointed out 
> >earlier, a collaboration between Squeak and Quesa 3D people would be 
> >of benefit to both camps.
> >
> I second this request.
> 
> Remember QD3D/Quesa is not a replacement for OpenGL but would properly
> exist on top if it and provide many things OpenGL does not. I can think
> of several Squeak projects which would benefit from this (Alice for Squeak
> is the first that comes to mind).
> 
> 8-)
> 
> --**************************************************
>     Jeff Szuhay                <mailto:jeffs at pstnet.com>
>     Lead Macintosh Engineer    voice: 412/271-5040 x227
>     Psychology Software Tools  <http://www.pstnet.com/>
>