CSS3 Transformation Suggestion: Add additional perspective version to 3D transformations
Axel Dahmen
I'd like to suggest another function prototype to the CSS3 3D Transformation
perspective definition:
The second perspective function declaration would be:
perspective(dx1,dy1,dx2,dy2,dx3,dy3,dx4,dy5)
Where parameters constitute four <length>,<length> tuples, describing an
offset from each of the four originally computed corners, given in this
sequence: top-left, top-right, bottom-left, bottom-right.
I believe this version is easier for designers to tackle with than the
original declaration.
Here's an example projecting an image into street-view (i.e. " | ____ | "
into " /____\ " ):
perspective(30%, 50%, -30%, 50%, 0, 0, 0, 0)
RFC
Axel Dahmen
Axel Dahmen
perspective(dx1,dy1, dx2,dy2, dx3,dy3, dx4,dy4)
--------------------------
"Axel Dahmen" <KeenT...@newsgroup.nospam> schrieb im Newsbeitrag
news:ho30bv$9d0$1...@online.de...
Ben C
> Hi,
>
> I'd like to suggest another function prototype to the CSS3 3D Transformation
> perspective definition:
>
> The second perspective function declaration would be:
>
> perspective(dx1,dy1,dx2,dy2,dx3,dy3,dx4,dy5)
>
> Where parameters constitute four <length>,<length> tuples, describing an
> offset from each of the four originally computed corners, given in this
> sequence: top-left, top-right, bottom-left, bottom-right.
The four originally computed corners of what? The unit square in the xz
plane?
> I believe this version is easier for designers to tackle with than the
> original declaration.
>
>
>
> Here's an example projecting an image into street-view (i.e. " | ____ | "
> into " /____\ " ):
>
> perspective(30%, 50%, -30%, 50%, 0, 0, 0, 0)
Would dx2,dy2 ever be anything different from -dx1,-dy1? And would the
last four numbers ever not be 0?
One weakness with:
http://www.w3.org/TR/css3-3d-transforms/#perspective
is that it appears you can only define a square frustum, not a
rectangular one. It ought to have two parameters really-- depth and
aspect ratio would do.
Axel Dahmen
> The four originally computed corners of what? The unit square in the xz
> plane?
Actually I can't tell. I'm not an expert in 2D graphics. The originally
computed values would be the four corners of the element without this
perspective function being applied.
E.g. on a positioned element with "position: absolute; left: 10px; top:
20px; width: 100px; height: 120px", and having no other transformation
applied yet, the original values would be:
x1 = 10, y1 = 20
x2 = 110, y2 = 20
x3 = 10, y3 = 140
x4 = 110, y4 = 140
Having a perspective applied with arguments:
dx1 = -10%, dy1 = -15%
dx2 = -20%, dy2 = -25%
dx3 = 20%, dy3 = 10%
dx4 = -10%, dy4 = -5%
the resulting corner coordinates would be (something like):
x1 = 9, y1 = 15
x2 = 88, y2 = 15
x3 = 12, y3 = 154
x4 = 99, y4 = 133
and all pixels of the image interpolated within this new plane.
> Would dx2,dy2 ever be anything different from -dx1,-dy1? And would the
> last four numbers ever not be 0?
I crafted above example to reflect your question. Is this what you had been
asking for?
> One weakness with:
>
> http://www.w3.org/TR/css3-3d-transforms/#perspective
>
> is that it appears you can only define a square frustum, not a
> rectangular one. It ought to have two parameters really-- depth and
> aspect ratio would do.
Agreed. But still some in-depth knowledge or great powers of imagination
would be required to find the right values. That's why I'd like to suppose
the above alternative. With this alternative setting appropriate values
won't be not so much of a try & error thing.
Cheers,
Axel Dahmen
www.axeldahmen.de
Ben C
That's not what's normally meant by the term "perspective
transformation", although it is a similar transformation.
A perspective transformation just makes things that are further away
(more negative z, or more positive, depending on convention) smaller in
the x and y dimensions.
You're making things narrower when they're higher on the screen, and
also moving them right or left.
You could probably get that result with a conventional perspective
transform, followed by a rotation and a shear.
But it's rather a strange transformation that I would not expect to be
generally useful, so I wouldn't make a special built-in function for it,
but let authors construct it themselves if they need it. I certainly
wouldn't call it "perspective" because that confuses it with
perspective.
>> Would dx2,dy2 ever be anything different from -dx1,-dy1? And would the
>> last four numbers ever not be 0?
>
> I crafted above example to reflect your question. Is this what you had been
> asking for?
>
>> One weakness with:
>>
>> http://www.w3.org/TR/css3-3d-transforms/#perspective
>>
>> is that it appears you can only define a square frustum, not a
>> rectangular one. It ought to have two parameters really-- depth and
>> aspect ratio would do.
>
> Agreed. But still some in-depth knowledge or great powers of imagination
> would be required to find the right values. That's why I'd like to suppose
> the above alternative. With this alternative setting appropriate values
> won't be not so much of a try & error thing.
Well, the W3C perspective parameter is a bit strange. I would suggest
they make it more like the glu one which everyone is familiar with.
See: http://www.opengl.org/sdk/docs/man/xhtml/gluPerspective.xml
You sit what you consider an average distance from your monitor, put a
ruler on your nose, measure the distance, and using your knowledge of
its height and some trigonometry, compute the field of view.
Then you set a typical aspect ratio and some sensible numbers for zNear
and zFar so as not to clip the objects in your scene, and Bob's your
uncle.
Angle and aspect ratio would do fine for the W3C transform.
Axel Dahmen
than all the others. It's quite the other way around than you say.
With this transform method you can map all basic functions, the translate as
well as the scale, skew and rotate function, all into one single function.
Being so general, OK, let's call it "transform" then.
Cheers,
Axel Dahmen
---------------------------------
"Ben C" <spam...@spam.eggs> schrieb im Newsbeitrag
news:slrnhqccks....@bowser.marioworld...
Axel Dahmen
Would you like to try to create a series of function calls to render the
result of the example I had given? Well, I guess, no...
It's the way like I wrote before: This function prototype makes 2D
transformation less a try & error process. With this function a designer can
take the approach of: "This is what I want it to look like. Now, CSS3, it's
up to you to render it the way I want it to".
There's even another application for this function. Imagine a DHTML page
allowing for editing an image: The user could be enabled to drag each of the
four image corners simply where he wants them to. And the image would
follow. (I wouldn't want to see a JavaScript implementation trying to
construct a pipeline of necessary existing functions in order to reproduce
the user's desire.)
Regards,
Axel Dahmen
www.axeldahmen.de
Axel Dahmen
> they make it more like the glu one which everyone is familiar with.
>
> See: http://www.opengl.org/sdk/docs/man/xhtml/gluPerspective.xml
>
> You sit what you consider an average distance from your monitor, put a
> ruler on your nose, measure the distance, and using your knowledge of
> its height and some trigonometry, compute the field of view.
>
> Then you set a typical aspect ratio and some sensible numbers for zNear
> and zFar so as not to clip the objects in your scene, and Bob's your
> uncle.
>
> Angle and aspect ratio would do fine for the W3C transform.
Considering the existing perspective function I fully agree with you.
Ben C
> One more thought:
>
> Would you like to try to create a series of function calls to render the
> result of the example I had given? Well, I guess, no...
>
> It's the way like I wrote before: This function prototype makes 2D
> transformation less a try & error process. With this function a designer can
> take the approach of: "This is what I want it to look like. Now, CSS3, it's
> up to you to render it the way I want it to".
OK, but where's this going to end? The transformation you describe has
no general use. In fact I can't think of any use for it, except the
curious DHTML application you describe below-- and I can't think of a
use for that!
You can't just add a new CSS property or property value for everything
you can think of, or there would be tens of millions of them in no time.
Axel Dahmen
> you can think of, or there would be tens of millions of them in no time.
Yes Ben, sure, absolutely agreed... But this function is different.
I have counted 11 transformations functions in CSS already. They all could
be easily replaced by this single function - well, except for rotate which
would require additional trigonometry applied then.
So this new function would not just be a "nice-to-have". It's basically the
base function for all other functions. In fact, the other, existing,
functions could easily be omitted and recreated in JavaScript. But not the
other way around.
So this function would not only (a) provide for more flexible usage, it
would also (b) significantly simplify the CSS specification (if replacing
the current function, but which is not my intention).
Here are a few applications that one can't easily achieve with the current
functionality:
http://acko.net/blog/projective-texturing-with-canvas
http://www.canvasdemos.com/2009/03/07/projective-texturing/
http://tulrich.com/geekstuff/canvas/perspective.html
Ben C
>> you can think of, or there would be tens of millions of them in no time.
>
> Yes Ben, sure, absolutely agreed... But this function is different.
>
> I have counted 11 transformations functions in CSS already.
Apart from perspective, they can all be replaced by "matrix" anyway.
> They all could be easily replaced by this single function - well,
> except for rotate which would require additional trigonometry applied
> then.
>
> So this new function would not just be a "nice-to-have". It's
> basically the base function for all other functions. In fact, the
> other, existing, functions could easily be omitted and recreated in
> JavaScript. But not the other way around.
It's true that affine transformations are a subgroup of projective
transformations.
If you wanted to support 2D projective transformations then you could
work in 3D homogenous coordinates, and your proposed "perspective"
function could be one way of defining such a transformation.
Alternatively you could just specify a 3x3 matrix (for 2D) or a 4x4 one
(for 3D).
> So this function would not only (a) provide for more flexible usage,
> it would also (b) significantly simplify the CSS specification (if
> replacing the current function, but which is not my intention).
>
>
> Here are a few applications that one can't easily achieve with the
> current functionality:
>
> http://acko.net/blog/projective-texturing-with-canvas
> http://www.canvasdemos.com/2009/03/07/projective-texturing/
> http://tulrich.com/geekstuff/canvas/perspective.html
Those would be quite nice.
Axel Dahmen
> Apart from perspective, they can all be replaced by "matrix" anyway.
I see...
> It's true that affine transformations are a subgroup of projective
> transformations.
>
> If you wanted to support 2D projective transformations then you could
> work in 3D homogenous coordinates, and your proposed "perspective"
> function could be one way of defining such a transformation.
>
> Alternatively you could just specify a 3x3 matrix (for 2D) or a 4x4 one
> (for 3D).
Well, actually I must admit that I don't know any technical details about
how these transformations are rendered at all.
But that's kind of my point: I don't know about how transformations are
calculated using matrices, so I suppose - with all due respect - that a
common web page designer won't know about how to deal with them as well.
The transformation I suggested would be easily predictable. That's its
advantage and beauty, I believe.
>> http://acko.net/blog/projective-texturing-with-canvas
>> http://www.canvasdemos.com/2009/03/07/projective-texturing/
>> http://tulrich.com/geekstuff/canvas/perspective.html
>
> Those would be quite nice.
Yeah, wouldn't it? I love the third one :)
Cheers,
Axel Dahmen
Ben C
> Sorry for replying so late...
>
>> Apart from perspective, they can all be replaced by "matrix" anyway.
>
> I see...
>
>
>> It's true that affine transformations are a subgroup of projective
>> transformations.
>>
>> If you wanted to support 2D projective transformations then you could
>> work in 3D homogenous coordinates, and your proposed "perspective"
>> function could be one way of defining such a transformation.
>>
>> Alternatively you could just specify a 3x3 matrix (for 2D) or a 4x4 one
>> (for 3D).
>
> Well, actually I must admit that I don't know any technical details about
> how these transformations are rendered at all.
>
> But that's kind of my point: I don't know about how transformations are
> calculated using matrices, so I suppose - with all due respect - that a
> common web page designer won't know about how to deal with them as well.
>
> The transformation I suggested would be easily predictable. That's its
> advantage and beauty, I believe.
What you suggested is a way of representing a transformation, just as in
SVG for example, you can write rotate(20) rather than matrix(0.94, 0.34,
-0.34, 0.94, 0, 0). Both do the same thing (unless I got the numbers
wrong, but you get the idea), but rotate(20) is more intuitive.
So you'd do it the same way-- have 3x3 matrices for arbitrary projective
transformations in 2D, and then have your function as an alternative
intuitive way of constructing them.
As intuitive ways of constructing projective transforms go, I'd say it
looks not too bad.
But there are other reasons why computer graphics often limits itself to
affine transforms.
In particular a useful property of Beziers is that if you transform the
control points with affine transformations and then construct the curve
between the new points, you get the same curve as if you had constructed
it first with the untransformed points, then transformed every pixel,
but much more efficiently.
So this could be used in CSS to transform text (which is all Bezier
curves) and the usual shapes (rectangles mostly, with curved corners in
CSS3) very efficiently.
Of course it wouldn't work on embedded raster images, there you would
have to transform pixels or little tiles like your examples below do.
But this is all a bit more kludgey. It's much better to use pure vector
graphics for everything if you want these kind of effects.