- From: Juergen Roethig <roethig@dhbw-karlsruhe.de>
- Date: Wed, 19 Nov 2014 15:26:24 +0100
- To: Rik Cabanier <cabanier@gmail.com>
- CC: "www-svg@w3.org" <www-svg@w3.org>
Hello, premark: Although I assume that the question was _not_ serious (see later), I will give a serious answer ... Rik Cabanier wrote: > > > On Sun, Nov 16, 2014 at 10:52 PM, Juergen Roethig > <roethig@dhbw-karlsruhe.de <mailto:roethig@dhbw-karlsruhe.de>> wrote: > > Rik Cabanier wrote: > > > > On Sun, Nov 16, 2014 at 12:43 AM, Juergen Roethig > <roethig@dhbw-karlsruhe.de <mailto:roethig@dhbw-karlsruhe.de> > <mailto:roethig@dhbw-__karlsruhe.de > <mailto:roethig@dhbw-karlsruhe.de>>> wrote: > > Steve Schafer wrote: > > On Sat, 15 Nov 2014 19:37:35 +0100, you wrote: > > You really want to tell me that the SVG WG does not even > want to consider non-affine transformations for SVG > because > it might take more computational power than "simple > matrix > math"? > > > Not just more computational power, but more expressive > power. > The space > of "non-affine transformations" is effectively infinite. > Are you > willing > to limit that to some subset (e.g., projective > geometry)? Or do > you want > everything? The more you encompass, the more your means of > expressing a > transformation begins to look like a general-purpose > programming > language. There's no point in reinventing JavaScript within > SVG--it's > already there. > > > I do not want "everything" out of "infinity", for sure! If > transformations other than affine ones had been discussed > before in > the SVG WG, coming to some sort of conclusion, I will see > what to > make out of it. Unfortunately, the specs (the existing 1.1 > as well > as the upcoming 2) as well as my Google search on the topic > (probably using the wrong keywords) don't reflect such a > discussion. > That's why I ask what might have been discussed before! > > > Can you give an example of what such non-affine transformations > look like? Do you know of any tools that offer them? > > Of course, "projective geometry" might be a candidate for such a > class of transformations, especially with regard to the z-index > which hopefully makes it in SVG2! > > > I don't understand why z-index is special. Can you eleborate? > > > An example of such a non-affine transformation might be the > one-point perspective > (http://en.wikipedia.org/wiki/__Perspective_projection#One-__point_perspective > <http://en.wikipedia.org/wiki/Perspective_projection#One-point_perspective>). > This is some sort of projection of a point in a three-dimensional > coordinate system to a point in a two-dimensional coordinate system > (i.e. a plane). Why I would need z-index is obvious ... although I > know that z-index in SVG2 is currently defined as an index just > controlling the rendering order, it might also be regarded as the > third (missing) dimension, although with somewhat restricted > accuracy (since it is an integer value). > > > I didn't hear anyone propose to repurpose z-index as an actual > dimension. You will find a lot of resistance to change this common > HTML/CSS property. I do not propose to change it to be a dimension (with units such as px, mm, in, whatever)! I might just use the z-index not just in a qualitative ("if a>b, then a is in front of b"), but also in a quantitative way! There is no reason (from the spec) not to do so (besides the limited accuracy, since it is integer, but if I can live with that, why not ...). But it was just an example of how to achieve some missing information needed for a perspective view, and not part of any proposal! > Other examples of non-affine transformations are all sorts of map > projections (http://en.wikipedia.org/wiki/__Map_projection > <http://en.wikipedia.org/wiki/Map_projection>) which neither need a > third dimesion (the z-index) nor are probably among the first > candidates for transformations to be implemented in SVG since they > might be somewhat too special. > > > If you could do this with excellent performance using a JS libary, would > that be acceptable? We are not talking about JS libraries (which already exist for that purpose, for sure), but we are talking about native SVG (including JS interfaces to the SVG DOM) on this list! Although you can do all sorts of affine transformations via JavaScript, there is also a way to perform such transformations via pure SVG! And what I would do if a feature is not built in a language which I might use, that's not the question. But nevertheless, my reaction when some language does not offer a feature, but just via some library, might vary from "use the library", or "do not achieve the desired result", up to "do not use the language at all, but look for another one". It depends. > Tools supporting such transformations/projections? The former should > be supported by all sort of tools which allow perspective views of > three-dimensional (virtual) worlds, and the latter might be a case > of special cartographic tools. > > > Can you give an example? I'm not familiar with any of such tools and > would like to see how they work. > It's likely that I'm not the only one. And that's why I doubt the seriousity of the question: When I feed Google with "tools with support for perspective transform", the first two hits are links to help pages from Adobe about their software products "Adobe Illustrator" and "Adobe Photoshop"! I do not assume that someone who is "Senior Computer Scientist on Adobe's Web Standards team" does not know some of the key products of his own company. But if you really do neither know and nor want to use those tools, you might even use GIMP to achieve some sort of "perspective transformation", i.e. some non-affine transformation in a 2D context. BTW: This is obviously performed via a transformation matrix (which can be examined when you try the tool with GIMP) - so the argument from the first answer by Tab Atkins Jr. "Affine transforms are fast and easy to do on modern graphics hardware with simple matrix math. Non-affine transforms don't have this property, unfortunately." does not hold, obviously, for that sort of transformations which are not affine but realized via "simple matrix math". Juergen Roethig
Received on Wednesday, 19 November 2014 14:27:12 UTC