Perspective Transform (was: Screen shots for Squeak.org)
Bert Freudenberg
bert at isgnw.CS.Uni-Magdeburg.De
Mon Jun 21 10:42:58 UTC 1999
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 ...
> The ability to apply 3D perspective to bitmaps is trivial. WarpBlit does
> this using a quadralateral warp.
It does not do perspective corrected mapping, because the interpolation
always is linear.
> HOWEVER, the abilityt to apply it to vectors, especially text, and then
> edit the same AFTER the perspective has been applied, is not trivial.
> Printing the text as device-independent vectors is also not trivial. You
> need the kind of solution that I described above.
For printing, you are absolutely right.
> >[...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.
> The only graphics engine that does this is GX and that is going away on the
> Mac and was never implemented elsewhere.
>
> 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.
> 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.
> 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 ...
> 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.
It's "Smalltalk", without a capital T :^)
/bert
--
Bert Freudenberg Department of
Simulation and
Computer Graphics
http://isgwww.cs.uni-magdeburg.de/isg/bert.html Univ. of Magdeburg
More information about the Squeak-dev
mailing list
|