- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Mon, 26 Oct 2009 15:05:39 +0200
- To: www-svg@w3.org
Jonathan Watt: .... > > "3D" transforms are just an affect that changes an elements appearance as > if it was being transformed in 3D, but they actually have no affect on its > "depth" or rendering order. Only 'render-order'/'z-index' would. Maybe > someone can come up with a fantastic, relatively easy to grasp proposal on > how to change that, but I seriously doubt it. If you want real 3D as > opposed to pseudo 3D, then probably its better to use something like WebGL > (possibly using it to render SVG into planes that can then be manipulated > in true 3D). > Well, often applications are simple enough or can be decomposed in simple enough problems to be presented with SVG. I think, it is not very important which library or number crunchers an author uses (I prefer fortran or PHP), if the SVG output is sufficient to represent the intented result without too many redundancies (for example big file size containing only a lot of data because SVG is not capable to handle it in a problem oriented way). And of course such a z-index functionality as well as the '3D' proposal is a big progress to reduce redundances and complexities, with the result, that an author can solve the same problem with a 10kB SVG 1.2 file instead of an 100MB SVG 1.1 file and a lot of number crunching just to create this 100MB file from the 1kB raw data describing the original problem. Not sure, if it is fantastic, but the proposal I'm currently working on, solves among other more important problems those of simple 3D data as well in a relatively simple way. Combined with a z-index functionality this could be a pretty convenient way to provide simple 3D data representations with low file size and much less author efforts than without: http://purl.oclc.org/net/hoffmann/rdml/ Olaf
Received on Monday, 26 October 2009 13:10:51 UTC