On Mon, 21 Jun 1999, Bert Freudenberg wrote:

> On 20 Jun 1999, Lawson English wrote:
> 
> > Bert Freudenberg <bert at isgnw.CS.Uni-Magdeburg.De> said:
> > > And why would we want to have perspective distortion if we do not
> > > go three-dimensional?
> > 
> >       Long, long ago
> > In a galaxy far, far away...
> 
> That doesn't answer my question ...

Lawson refers to the effect used in the introductions to various Star Wars
movies, where text scrolls upwards/away. It is one if his favourite
examples for the kind of effect that QuickDraw GX can achieve (by virtue
of using a full 3x3 matrix for 2d coordinate transforms, rather than the
2x3 matrix used by PostScript and its ilk) that most other 2d graphics
systems cannot.

[ As an aside, my position is that 3d manipulation belongs, if anywhere,
then in a system that is fully 3d aware, rather than a 2d system ]

[ snip ]

> > >[...snip...]
> > >IMHO this would be too specific, the texture mapping approach is more
> > >general.
> > 
> > And doesn't work right for text and vectors. How do you hit-test a
> > selection of text if there's been a texture-mapping warp applied to it?
> 
> Project the mouse coordinates back into de-warped space and do hit
> detection as usual. 

In fact, this has nothing at all to do with texture-mapping as such - just
coordinate space transformations; the same inverse coordinate
transformation would have to be performed even if vectors were passed from
the 2d drawing engine directly to the 3d drawing engine.

> > The only graphics engine that does this is GX and that is going away on the
> > Mac and was never implemented elsewhere.

Quite possibly because there was too little demand for it. But indeed
there are features in QuickDraw GX which were useful, and not offered
elsewhere. But are they useful enough to warrant the extra work?

> > There's several pieces missing from the Squeak graphics libraries in order
> > to make your 3D morph work right:
> > 
> > 3D perspective for vectors & text. 3D perspective for views. Hit-testing
> > methods for 2D graphics & text that work with 3D perspective.
> > Text-selection methods that work with 3D perspective. Etc.
> 
> For the UI, I insist that the texture-mapping approach would work.

The most versatile and general approach for taking something that is
2-dimensional - say, text - and making it do something 3-dimensional, is
to map the text's coordinates (x and y) onto the coordinates of some
surface in 3d space (x, y, z). The 2d drawing system should not need to
know or care about wether it is being called upon by a 2d output system,
or as a subsystem of a 3d graphics system.

Texture mapping is a very simple, well-known way to get the result of
2-dimensional drawing, onto a three-dimensional surface. So, yes, of
course it would work. And it could, nay, _should_ be layered, so that the
2d engine is never aware that it lives in a warped 3d world, and that the
3d layer does all the coordinate transforms, and the texture mapping, 
invisibly to the 2d graphics layer below.

> > In order to print these properly to PS printers, you also need to have a
> > translator that can grab the original vector/text info, apply the 3D warp
> > to it and translate THAT to PS.
> 
> For printing, or vector graphics in general, that is true. Until now,
> there wasn't a big need to do proper printing from Squeak. It's much more
> a vehicle for interaction.

Of course, the texture mapping approach would work to give an arbitrarily
accurate approximation even for printing, if used with a sufficiently high
resolution; but that would largely defeat the point of using a PostScript
printer in the first place, namely device independance.

Perhaps what is really needed for cases like that is an OpenGL printer :)

> > All of the above is very complex and it took Apple 7 years and a LOT of
> > manhours to get right, and I'm not even suggesting that we should work to
> > add these capabilities to Squeak.
> 
> I wouldn't say it's THAT hard, and it may well be worth it - who knows
> what we could do if this is possible ...

Well, if there was a system available for generally taking 2d drawing, and
placing that on an arbitrary 3d surface ... all sorts of fun graphic
experiments would be made easy.

> > However, I *am* pointing out that the "Pure SmallTalk" approach to porting
> > Squeak has certain limitations and that unless some simpler way is created
> > to add and port externals than currently exists, the "pure SmallTalk"
> > limitation is going to become more and more evident.

There is already a mechanism for adding plugins, i.e., primitives defined
by native code, to Squeak. 

Besides that, writing everything in Smalltalk makes Squeak highly
portable, which appears to be one of its design goals :)

> It's "Smalltalk", without a capital T :^)
> 
> /bert

Best regards

// Christian Brunschen