- From: <bhopgood@brookes.ac.uk>
- Date: Fri, 12 Sep 2008 08:32:41 +0100 (BST)
- To: "Dailey, David P." <david.dailey@sru.edu>
- Cc: public-svg-ig@w3.org
David, I agree with you that some minor additions would be useful. Both when SVG was being developed and also later we made submissions to the WG for a 2.5D extension. Effectively all the SVG elements stayed as flat objects but you gave them a Z position and then had a perspective transformation. It really didn't add anything much to what the implementer had to do, just one more transformation. Noting came of it even though we wrote it up and showed some typical animations with a nice 3D effect where elements in the background moved relative to those in the foreground as you moved across the scene. We also submitted a vector families primitive that has some relevance to the new diffusion curves. Effectively you gave it two paths and asked it to draw N paths in between, say. Thus you can draw graph paper by having two horizontal lines for one vector family and two vertical lines for another. Fot two arbitrary paths, the intermediate paths are the same as you would get if you animated the curve. Again, the current implementations have to support the functionality for animation so the additional work is minimal. If you allowed splines it would be even more effective. I thought it might also be useful for defining the intermediate paths for the proposed diffusion curves. Bob > > Thanks Bob. > > There are some pretty nifty things in that zip archive. I liked the > helicopter! XSLT is quite the tool for one's arsenal. The first URL, > though, crashed my FF and showed up as a big collection of parentheses and > brackets in Opera 9.5 under windows. > > I guess I'm in agreement with you about full-fledged 3D needing its own > harbor (outside SVG). But some straightforward possibilities for extending > SVG in incremental ways [like non-affine transforms, relational SVG (i.e., > map/superpath), contour maps, richer classes of gradients (like diffusion > curves), and so forth] can provide useful things (of a 3D-esque flavor) to > the scientific (and artistic) visualization communities now. > > We can wait for the 3D communities to enumerate how many standards and how > many communities they actually want to have in the long run. That has > taken some years, I gather, and may take a few years more. > > In the meantime, some fractal dimension between 2 and 3 sounds awfully > nice, and given the maturity of SVG, it may be more ready to aim in that > direction from here, that approaching it from the other side. > > David > > ________________________________ > > From: bhopgood@brookes.ac.uk [mailto:bhopgood@brookes.ac.uk] > Sent: Thu 9/11/2008 5:21 AM > To: Dailey, David P. > Cc: public-svg-ig@w3.org > Subject: RE: [SVG-IG] Re: HTML 5 Canvas spec (3D and SVG) > > > > David, > > Producing 3D static images from SVG is relatively easy. An example is the > dance scene used to open WWW16 in Edinburgh: > > http://www.iw3c2.org/conferences/SVG/animw16closing.svg > > You just need to define the 3D scene in XML and perform an XSLT > transformation that does the perspective transformation. > > If you want to do hidden surface elimination and surface rendering with a > genuine 3D model and a proper lighting model it is still possible > but you need a lot of surfaces as you are currently restricted to linear > gradients if you are going to add the lighting model. See Gould's paper at > SVG Open in Enschede: > > http://www.svgopen.org/2005/papers/3d_animation_xslt_svg/3DAnimUsingSVGXSLT.zip > > > Producing good quality 3D animations that are NOT frame-based is pretty > well impossible, faces have to be reordered on the fly, > some added with others being removed and the current > implementations can't handle it. Doing frame based animation is possible. > Again see Gould's walk-through or his 3D Chess Game. Opera performs > this quite well. > > To do it properly, W3C needs a separate standard that browser > manufacturer's are prepared to support. The problem that X3D has is that > it has to rely on plugins and so never gets accepted. That will not > change. W3C currently leaves 3D to the X3D Consortium and that again is a > problem. Somebody should make a submission to W3C to have a W3C 3D > standard and it probably needs to have some browser manufacturer's put > their name to it. > > Bob > > > >> >> Dave and Donald, >> >> Actually from within the SVG WG, (I suspect Doug may talk about this >> some >> tomorrow at the "telecon" -- is that still a word or has it gone the way >> of the dinosaurs?) there has been some talk about 2.5 dimensions. >> >> see for example >> http://svgopen.org/2008/papers/86-Achieving_3D_Effects_with_SVG/ . >> I gather that perspective transformations (allowing a class of >> non-affine >> transforms) are on the plate for the SVGWG's future consideration. (see >> also my talk at SVG Open in which I talk about simulation of non-affine >> transforms) >> >> Closely allied (in some ways) with non-affine transforms are gradients >> which are neither linear nor radial (since the derivative of a gradient >> as >> applied through feDisplacement provides a non-affine transform) (again I >> talked about this some at the conference >> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2008/edges_of_plausibility.htm >> ) and since extensions of the class of gradients can provide results >> equivalent to ray-tracing of actual 3-D objects (using JavaScript plus >> magic* to mediate between the two views), and potentially with a lot >> less >> computation, given proper magic. >> >> A variety of other gentle forays into 2+ dimensions may be seen in the >> recos for extensions to SVG in the form of the <contour> element, the >> <map> element and other speculation at >> http://srufaculty.sru.edu/david.dailey/svg/spec.html (the topic of a >> previous but painfully lengthy email of mine a week ago). >> >> And then, today in svg-developers, there was a thread about zoomability >> of >> text and scaling. Another opportunity to provide gentle extensions to >> SVG >> that would give us slightly more than 2 Dimensions (by for example >> applying a "scale" attribute, which would allow the animation of the >> viewbox to provide differential scaling effects on "layers" of animation >> in "scoobydoo space" as in the mountains at >> http://srufaculty.sru.edu/david.dailey/svg/balloon.svg ). I don't know >> how >> to reference svg-developers threads in yahoo (nor do I know how to >> search >> for things there) but in discussions about >> >> "RE: [svg-developers] Re: Non-scalable text labels in scalable >> graphics?" >> >> some of the reasoning can be followed. >> >> By providing "proper" vectorizations of bitmaps, I think there is one >> more >> opportunity to provide forays into 3-space. While conventional >> vectorization of bitmaps may easily mis-characterize the boundaries >> between meaningful objects, computer-human interactions in the "reading" >> of bitmaps may produce contour maps (or engraving/gradient maps **) that >> provide usable cues to three-dimensionality-- like object recognition. >> >> And to follow yet one more thread of reasoning here, if everyone isn't >> yet >> worn out, just as hypertext is slightly higher than one dimensional -- >> owing to graph theoretic connections across linear text -- so would >> "relational SVG" (as discussed in the <map><superpath/></map> construct >> )-- be higher than two-dimensional by providing extra planar content >> connections between objects (like components) within a diagram. So much >> easier to make machines, for example, by using graph-theoretic and >> spatial/relations between components (usually drawn "close" to the >> components they interact with). >> >> The nice thing about all these "gentle" forays into 2+ dimensions is >> than >> none would require dramatic rethinking of the basic premises or charter >> of >> SVG and all could be accomodated in some future version that could >> actually be undertaken by (in my mind anyhow) the SVGWG once it gets its >> current activity moved to candidate recommendation status. The IG is, by >> charter, "will not produce Rec-track work", but we certainly can respond >> to the spec as it is, and presumably that includes responding to >> directions in which it should perhaps grow. >> >> I don't know the history here, but apparently some previous ventures >> into >> standards for 3D (like http://en.wikipedia.org/wiki/X3D ) have been met >> with less than complete enthusiasm by a highly diverse community (from >> CAD >> to Pixar) community often striated with an excess of momentum and >> inertia. >> >> Holler if any of my rambling is thoroughly incomprehensible, >> David >> (who is delighted to hear voices other than my own piping up!) >> >> >> >> >> * by magic, I mean that not all illustrations of 3D have to be, >> strictly, >> speaking, accurate. Given that we draw, ultimately, on 2D screens, 3D is >> intrinsically an illusion in that 2D space, and the degree to which that >> illusion is convincing is sometimes, paradoxically, greater when less >> realism is applied. >> >> ** I blame this on Albrecht Durer. >> >> ________________________________ >> >> From: Donald Doherty [mailto:donald.doherty@brainstage.com] >> Sent: Wed 9/10/2008 3:40 PM >> To: Porter, David A >> Cc: Dailey, David P.; public-svg-ig@w3.org >> Subject: [SVG-IG] Re: HTML 5 Canvas spec (3D and SVG) >> >> >> The HTML 5 Canvas spec addressed an HTML shortcoming: no high quality 2D >> graphics. >> >> Others have now extended HTML 5 Canvas to address another HTML >> shortcoming: no high quality 3D graphics (although I don't know that >> this >> is standard yet). >> >> What I'd like to see is for the SVG lack of high quality 3D graphics to >> be >> addressed in a similar way. Maybe an official "SVG 3D Canvas" spec? >> >> Don >> >> On Sep 10, 2008, at 3:16 PM, Porter, David A wrote: >> >> >> Indeed, you are prescient about this Donald--there is interesting >> and >> frustrating stuff out there ahead. >> >> When we go beyond 2D to 3D, that brings up a welter of other >> mechanisms >> for getting graphics stuff on somebody's display. Here in Boeing of >> course we are deeply involved in massive capabilities like CGM/WebCGM >> (not me personally). Obviously, way beyond what SVG ever intended to >> address, in scope, size, depth. This computer / web graphics arena such >> a vast field, it's hard to narrow down opportunities to choose paths and >> work on them. >> >> Seems like there is some distinguishing matrix of 2/3D graphics >> characteristics, you almost need a Edward Tufte-like mind mapof them >> floating out there in space, where you could regard their various >> aspects and figure out where the world is going, then flip it around and >> look at it using a different lens. Some of the axes might be things >> like >> simple vs. complex, declarative vs. imperative, past-present-future >> (progressions or versioning), open vs. proprietary, platforms it runs >> on, >> and so forth. One might observe the progression thru VML, to SVG, to >> future versions of it, or the rise of integrated RIA graphics thingies >> like FLEX/Flash, as pieces of this larger picture. As it is, it's kind >> of hard to get oriented to the many things that are on tap. >> >> Apologies if I am rambling, but one might set out to articulate >> some sort >> of positioning of SVG as it is now, or where it's going, in relation to >> those other things, that *could* help someone get engaged. It's a very >> significant and useful standard (IMHO)! >> >> David.A.Porter@Boeing.com >> Distributed Server Integration, GG-GG-5581, homepage >> http://grp-cno-dst-svr.web.boeing.com/ >> Boeing Information Technology, Bellevue Washington USA >> * phone 253-223-4732, other contact options at >> http://card.web.boeing.com/WebCard.cfm?id=113185 >> Server Inventory links: >> http://distributedserver.web.boeing.com/serverinventory/ServerInventoryLinks.htm >> >> >> >> ________________________________ >> >> From: Donald Doherty [mailto:donald.doherty@brainstage.com] >> Sent: Wednesday, September 10, 2008 11:37 AM >> To: Dailey, David P. >> Cc: public-svg-ig@w3.org >> Subject: Re: HTML 5 Canvas spec [3D and SVG] >> >> >> David, >> >> Thank you for jumping in on this topic. I'm only jumping in now >> because >> I'm so behind in my email... >> >> HTML 5 Canvas brings up an SVG frustration for us. That is, 3D >> displays! >> >> SVG in my opinion becomes very interesting in the context of Web >> applications (as apposed to Web pages...I mean applications like Google >> spreadsheets, docs, etc.). However, applications - and especially those >> in life sciences and medicine - often demand 3D graphics. >> >> A standard means for displaying high-quality 3D images would go a >> long >> way towards making SVG irresistible! >> >> Don >> >> >> >> >> >> Donald Doherty, Ph.D. >> Founder and Chief Science Officer >> Brainstage, Inc. >> www.brainstage.com <http://www.brainstage.com/> >> donald.doherty@brainstage.com >> 412-683-1410 >> >> >> On Sep 3, 2008, at 12:16 PM, Dailey, David P. wrote: >> >> >> Hi David: >> >> >> >> David Porter wrote: >> >> >> >> ".[...]Is it a threat or complement >> to one's SVG work? [...] 'A 3D Exploration of the HTML >> Canvas Element >> Greg Travis, DevX.com' " >> >> >> >> I thought someone else might make a stab at this but given >> that they >> didn't I guess I will. Maybe I'll say something wrong just on purpose >> to see if we can persuade lurkers to join some of the conversations. >> >> >> >> When I found out about <canvas> I thought it was someone's >> attempt to >> sabotage SVG. The Apple folks who promoted it tried to convince others >> that it was something entirely different (using lots of fancy jargon to >> make their point). I remained very skeptical. >> >> >> >> Then someone (like maybe Anne from Opera) wrote something >> in the HTML5 >> discussions that basically said - hey mellow out - they both do useful >> stuff. So I have mellowed a bit and concede the point. <canvas> is >> likely to be a really fast way of blittiing pixels onto the screen and >> playing with them. Opera and maybe others have been playing with 3D >> canvas operations - if only we could put an <svg> into a <canvas> so >> that we could read the pixels back from our <svg> or implement the get >> Pixel value and put Pixel value operations from <canvas> then we'd have >> something. >> >> >> >> I think the experience with Photoshop and Illustrator >> indicates that >> it's a lot easier to put pixel stuff into a vector environment than to >> do it the other way around. >> >> >> >> My only concern remaining was that HTML5 would adopt >> <canvas> and ignore >> <svg> in such a way that implementers might be able to continue to >> ignore SVG. Doug seems optimistic that that won't happen, and he knows >> how this stuff works, so I think we can relax a bit more now. >> >> >> >> In the long run, with the fact that Google now supports >> (some) SVG in >> Chrome, it may soon be a moot point. >> >> >> >> I would be delighted if some one could put some really >> simple and some >> really cool demos in the SVG-wiki that show a) how to use canvas and b) >> how to combine the use of canvas with that of svg. The symbiosis could >> be very cool! >> >> >> >> David >> >> >> >> >> > > > > > >
Received on Friday, 12 September 2008 07:33:38 UTC