From: trevor@cs.man.ac.uk (Trevor Hopkins)
Newsgroups: comp.lang.smalltalk
Subject: Re: 3D graphics in Smalltalk
Date: 7 Sep 92 09:45:27 GMT
Reply-To: trevor@cs.man.ac.uk (Trevor Hopkins)
Organization: Department of Computer Science, University of Manchester

There's been some talk about 3D graphics in Smalltalk in the net.
I've been playing about in this area off and on for a little time now.
I did a very crude early version for ST80 v2.2 (anyone remember that?
;-) More recently, I've been working on a (hopefully) reusable 3D
library for Objectworks/Smalltalk R4.

The basic building blocks are two classes, ThreeDPoint and
ThreeDTransformation.  I've quite a large class hierarchy of primitive
objects (cubes, spheroids, extruded solids and surfaces, etc) -- about
60 or so.  Of course there are composite 3D objects as well, so you
can build complex structures.  There are `wrappers', which contain
exactly one other 3D object (including other wrappers and composites)
which add additional behaviour, such as labels, or `animations' (e.g.
a `path' over which the contained object is moved, or a sequence of
transformations), or even a Process, so that animations can proceed
independently. Finally, there are Associations, which allow you to
`glue' objects together, and behave as a single object under
distortions (imagine sticking a Cuboid and a Parallelepiped
face-to-face, and moving a vertex of the Parallelepiped).

There are a pair of View and Controller classes, which handle the
rendering into windows -- in fact, there are separate rendering
classes to handle different aspects of the displaying process.  This
tool allows existing objects to be moved about and re-shaped, but at
present you have to write code to build the objects themselves.  The
renderers will display in wireframe, or with hidden line removed, or
shaded either matt or shiny (only one light source at present).  You
can use either flat colours or dithering for more shades --
particularly useful if your hardware only supports 16 (or 256)
different colours at a time.

Despite what someone (I think Ralph Johnson - hi Ralph ;-) said, the
performance is not too bad; not wonderful, of course, but certainly
usable.  I've done a fair amount of careful investigation with the
Profiler, and made extensive use of techniques like cacheing and
special-purpose data structures (ThreeDPointCollection).  Admittedly,
some of my inner loops look just like F*RTR*N code :-)  Certainly,
even with a moderately quick X-windows server, more than half of the
time is spent in graphics primitives while rendering.  It's even still
useable (just about -- needs patience :-) on my Toshiba portable
(386SX), which doesn't even have FP hardware!  It's really nice on an
HP Snake, though -- you can animate reasonably complex scenes really
quite well.  I could do with a primitive to make instances of
ThreeDPoint faster, though, and more sophisticated renderers (like
ray-tracing) would need futher primitives for decent performance.

An early (read: buggy) version is in use for some student projects
here this year.  Projects include data visualisation, and VR-style
direct manipulation.  When I've knocked out some more of the bugs, and
written up some decent documentation, I'll make sure this lot appears
in the Manchester goodies lib (and its mirror at UIUC) -- no promises
as to when, though.

I'd appreciate some discussion with others who have tackled this
problem area in Smalltalk, or other OO languages.  In particular, I'm
still unhappy with the class and object structures for the rendering
classes.  Also, the Associations implement a fairly straightforward
constraint satisfaction algorithm, which breaks down under some
circumstances where there is a possible solution. (Of course, there
are cases, where is is *no* solution.)  Other problem areas incluse
the structure of the class hierarchy for the primitive solids and
surfaces, given single inheritance.  I know there's a smallish group
meeting at OOPSLA to discuss this kind of thing, but I have a prior
(and unavoidable) engagement, so I won't be there.  (Very bad timing
on my part, that :-( )

Comments, anyone?
            Trevor.
------------------------------------------------------------------
Trevor P. Hopkins, Room 2.95, Department of Computer Science,
University of Manchester, Oxford Road, Manchester, M13 9PL, U.K.
Tel: (+44) 61-275 6170    FAX: (+44) 61-275 6236    Internal: 6170
NET: trevor@cs.man.ac.uk    UUCP: ..mcsun!uknet!man.cs!trevor
------------------------------------------------------------------
Newsgroups: comp.lang.smalltalk