David,<br><br>To respond to your points:<br><br>* I'm a bit confused as to what "re-engineering" you are referring. You say "layering on top of HTML" at the end of your response, but none of the example code in this thread amounts to an intrinsic change to HTML whatsoever (it actually riffs heavily on <video/>), so I would appreciate it if you could pull out some snippets to make your statement more clear.<br>
<br>* We aren't going to learn how to use 3D if we don't have the very best tools at our disposal. With new talent and new technology come new opportunities.<br><br>* Picking a format is not a part of this proposal, but yes it is necessary and no it does not sound like a cake walk. One could say this about nearly every point of HTML5.<br>
<br>* Designers will, as always, work off of their audiences, and many technologies in HTML5 will not be useful immediately. Browsers which do not support 3D HTML will likely also not support 3D CSS and 3D JavaScript, but those technologies are no less compelling and necessary for it.<br>
<br>-Brian<br>
<br><br><div class="gmail_quote">On Mon, Nov 2, 2009 at 5:36 PM, David Workman <span dir="ltr"><<a href="mailto:workmad3@gmail.com" target="_blank">workmad3@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brian,<br><br>I agree that a static 3d rendering isn't really equal to a 2d bitmap, but I think that the distinction will be lost on most people. As to javascript not being required? I think that javascript (or some other scripting) will most certainly be required for any form of interactive 3d scene, in exactly the same way as HTML currently requires javascript for interactive elements currently (or some form of plugin driven by a different language).<br>
<br>The rest of your expanded example doesn't fill me with joy though. >From the sounds of things, you are envisaging a complete re-engineering of HTML from it's current format of a document description language with some presentation and media elements put in to make it extremely useful and versatile (and already fraught with legacy problems and some syntactic ambiguities) into a language for describing the placement and content of a full interactive 3d environment and 3d user interface. The problems I see with this are:<br>
* A re-engineering like this would leave the language a complete shambles. There would be legacy elements all over the place, conflicts galore and I doubt the result would be usable at all.<br> * 3d interfaces are barely understood currently, and a lot of the research in the area seems to point to them actually just not being intuitive. Why butcher HTML to add support for this when there isn't even necessarily a use case yet?<br>
* Picking a 3d format to standardise around would be non-trivial and cause even more fragmentation of the web community. Should the programmable API resemble DirectX? OpenGL? Should the scene description be .3ds inspired, maya inspired, VRML inspired or one of the XML based formats also mentioned? Should it be something new?<br>
* Fallback content would become a nightmare from 3d to 2d. It's bad enough currently, just dealing with fallbacks from scripted content to static content. Imagine the problem magnified my having to collapse a dimension as well.<br>
<br>Now I'm not saying that a 3d language for the web isn't a good idea. I think the idea has some huge potential. I just don't think that layering it on top of HTML with all of it's legacy concerns and also it's document centric model is a good idea for the above practical concerns.<br>
<br>David W.<br><br><div class="gmail_quote"><div>2009/11/2 Brian Blakely <span dir="ltr"><<a href="mailto:anewpage.media@gmail.com" target="_blank">anewpage.media@gmail.com</a>></span><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
David,<div><div></div><div><br><br>Excellent perspectives, and there are certainly format decisions that have to be made as a matter of course, just as there have been for <video/>.<br><br>I do not agree with two of your points:<br>
<br>
* A static 3D rendering is equal to a 2D bitmap <br>
* JavaScript is necessary to display 3D content<br><br>My brief counter-points:<br><br>* 2D bitmaps are only partially compatible with 3D CSS - they are still always flat<br>* This includes <canvas/>, which is still a 2D bitmap, not actually a 3D object<br>
<br>A JavaScript-Only Approach is Inferior Because:<br><br>* <canvas/> is being purposed as a viewport into 3D content, a function the browser itself should serve<br>* 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript alone<br>
* Using only 3D JavaScript, the code required in order to serve rich user interfaces is bandwidth intensive, working against one of the key benefits of using web standards<br><br><br>Explanation and Supporting Examples<br>
----------------------------------------------------<br><br>These assumptions are partially the fault of my primordial example, as that example's purpose was to illustrate these concepts clearly, not demonstrate an application of the technology. The goal of <model/> is not merely to serve 3D content, but to allow designers and developers to *lay out web content and applications in 3D*. Let's think of this concept as "3D HTML".<br>
<br><canvas/> is not a solution. It is rendering 3D content inside a
viewport, when the browser itself should be a viewport to 3D content. One alternative, creating a giant <canvas/> and filling it with fallback content, is coding twice - not good.<br><br>The foundations of 3D CSS (a la Webkit - <a href="http://webkit.org/blog/386/3d-transforms/" target="_blank">http://webkit.org/blog/386/3d-transforms/</a>) and 3D JavaScript (WebGL/O3D) are being laid out, but there is no HTML equivalent to cement a truly 3D design platform on the web.<br>
<br>If we draw 3D design to its logical conclusion, rich user interfaces, then the usefulness and necessity of 3D HTML becomes more apparent. I will support this statement with an advanced example, which will demonstrate the inadequacies of 2D design, and the gaps in currently-existing potential standards. <br>
<br>DISPLAYING THE SOLAR SYSTEM IN A 3/4 VIEW<br>----------------------------------------------------------------------<br><br>The below snippets will illustrate how a page would lay out such an interface in three ways: 1) A 2D implementation you will see today; 2) a combination of fictional 3D HTML and 3D CSS; 3) only 3D CSS, 3D JavaScript and <canvas/>.<br>
<br>On hover, each planet will rotate about its own axis.<br><br><br>2D HTML & CSS<br>-----------------------<br><br><style><br><br>ul {<br> * Background image of space<br>}<br>li {<br> * Absolutely positioned to correlate perspective<br>
}<br>a {<br> * Block<br> * Negative indentation, hiding text<br>}<br>a.(planet name) {<br> * Background image of each planet<br> * Height/Width of each background image (alternatively a large height/width in the anchor definition above, centering each image on X,Y axes)<br>
}<br><br></style><br><br><h1>The Solar System in 3/4</h1><br><ul><br> <li><br> <a class="sun" href="sun.html">The Sun</a><br> </li><br> <li><br>
<a class="mercury" href="mercury.html">Mercury</a><br> </li><br> <li><br> <a class="venus" href="venus.html">Venus</a><br> </li><br>
...<br></ul><br><br><script><br> * Slideshow background script attached to each anchor, listening for mouseover and mouseout<br></script><br><br><br><br>3D HTML & CSS (notes in parentheses)<br>
-----------------------<br><br><style><br><br>div {<br> * Background image of space<br>}<br>ul {<br> * Rotate to 3/4 view (We can no longer display a background on this element, because it will become wafer-like when rotated; a <model/> will maintain its desired shape, as it is really 3D.)<br>
}<br>model {<br> (some of the work will already be done for you by the ul rotation)<br> * Rotate to proper perspective<br> * Translate to desired depth/position<br><br> (in the syntax of -webkit-transition and -webkit-rotate, currently in use today)<br>
* transition: rotate 3s ease-out; <br>}<br>model:hover {<br> * rotateY(360deg);<br>}<br><br></style><br><br><h1>The Solar System in 3/4<h1><br><div><br> <ul><br> <li><br>
<a href="sun.html"><br> <model src="sun.xml" alt="The Sun" /><br> </a><br> </li><br> <li><br> <a href="mercury.html"><br>
<model src="mercury.xml" alt="Mercury" /><br> </a><br> </li><br> <li><br> <a href="venus.html"><br> <model src="venus.xml" alt="Venus" /><br>
</a><br> </li><br> ...<br> </ul><br></div><br><br><br><br>3D JAVASCRIPT, 2D HTML & CSS<br>-----------------------------------------------<br><br><style><br><br>
canvas {<br> * Height/Width of viewport<br>}<br><br></style><br><br><h1>The Solar System in 3/4</h1><br><canvas id="solar-system"><br> <!-- ALT CONTENT FOR BROWSERS NOT SUPPORTING <canvas/> --><br>
(Herein: Code from Example 1)<br></canvas><br><br><script><br> (the following is a non-custom snippet from O3D's "simple" example -- webGL's implementation is slightly cleaner)<br><br>
function loadFile(context, path) {<br> function callback(pack, parent, exception) {<br> enableInput(true);<br> if (exception) {<br> alert("Could not load: " + path + "\n" + exception);<br>
g_loadingElement.innerHTML = "loading failed.";<br>
} else {<br> g_loadingElement.innerHTML = "loading finished.";<br> // Generate draw elements and setup material draw lists.<br> o3djs.pack.preparePack(pack, g_viewInfo);<br> var bbox = o3djs.util.getBoundingBoxOfTree(g_client.root);<br>
g_camera.target = g_math.lerpVector(bbox.minExtent, bbox.maxExtent, 0.5);<br> var diag = g_math.length(g_math.subVector(bbox.maxExtent,<br> bbox.minExtent));<br> g_camera.eye = g_math.addVector(g_camera.target, [0, 0, 1.5 * diag]);<br>
g_camera.nearPlane = diag / 1000;<br> g_camera.farPlane = diag * 10;<br> setClientSize();<br> updateCamera();<br> updateProjection();<br><br> // Manually connect all the materials' lightWorldPos params to the context<br>
var materials = pack.getObjectsByClassName('o3d.Material');<br> for (var m = 0; m < materials.length; ++m) {<br> var material = materials[m];<br> var param = material.getParam('lightWorldPos');<br>
if (param) {<br> param.bind(g_lightPosParam);<br> }<br> }<br><br> g_finished = true; // for selenium<br><br> // Comment out the next line to dump lots of info.<br> if (false) {<br>
o3djs.dump.dump('---dumping context---\n');<br> o3djs.dump.dumpParamObject(context);<br><br> o3djs.dump.dump('---dumping root---\n');<br> o3djs.dump.dumpTransformTree(g_client.root);<br>
<br> o3djs.dump.dump('---dumping render root---\n');<br> o3djs.dump.dumpRenderNodeTree(g_client.renderGraphRoot);<br><br> o3djs.dump.dump('---dump g_pack shapes---\n');<br> var shapes = pack.getObjectsByClassName('o3d.Shape');<br>
for (var t = 0; t < shapes.length; t++) {<br> o3djs.dump.dumpShape(shapes[t]);<br> }<br><br> o3djs.dump.dump('---dump g_pack materials---\n');<br> var materials = pack.getObjectsByClassName('o3d.Material');<br>
for (var t = 0; t < materials.length; t++) {<br> o3djs.dump.dump (<br> ' ' + t + ' : ' + materials[t].className +<br> ' : "' + materials[t].name + '"\n');<br>
o3djs.dump.dumpParams(materials[t], ' ');<br> }<br><br> o3djs.dump.dump('---dump g_pack textures---\n');<br> var textures = pack.getObjectsByClassName('o3d.Texture');<br>
for (var t = 0; t < textures.length; t++) {<br> o3djs.dump.dumpTexture(textures[t]);<br> }<br><br> o3djs.dump.dump('---dump g_pack effects---\n');<br> var effects = pack.getObjectsByClassName('o3d.Effect');<br>
for (var t = 0; t < effects.length; t++) {<br> o3djs.dump.dump (' ' + t + ' : ' + effects[t].className +<br> ' : "' + effects[t].name + '"\n');<br>
o3djs.dump.dumpParams(effects[t], ' ');<br> }<br> }<br> }<br> }<br> ...<br><br> (and on, literally, for pages)<br></script><br><br><br>While the paradigms of HTML are inherently dimensionless, media types are not. CSS and JavaScript are embracing 3D in their own ways, HTML is obviously not giving its due diligence. Tons of JS just to open a 3D viewport in HTML is far from what I would consider a complete spec. The wafer-boxes that 3D CSS produce are an ill of HTML, not of CSS.<br>
<br>-Brian MB<div><div></div><div><br><br><br><div class="gmail_quote">On Mon, Nov 2, 2009 at 4:46 AM, David Workman <span dir="ltr"><<a href="mailto:workmad3@gmail.com" target="_blank">workmad3@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm in perfect agreement regarding the rational behind having a model tag as I agree with having more semantic tags in HTML. However, I don't think a model tag would work as described as it would provide no real extra benefits and would just confuse document authors.<br>
<br>The reason I feel this is basically down to the fact that 3d models don't have a visual representation in the same way that images do. A 3d model file is just a list of data that needs rendering into a 2d image for display. There isn't really a standardised way to do this (not in the same way as with images, with standardised png, jpg, bmp, etc. as well known and commonplace formats with commonplace methods of display), and on top of that it isn't a 3d model you a displaying, but a 2d representation (i.e. an <img>). If the representation is static, it isn't really a 3d model as it's just a 2d image, and if it isn't static then you need scripting support, drawing support, rendering and the whole host of items that require javascript hooks and would logically make such a model more suited to a 3d canvas (which I believe is to be supported eventually under a normal <canvas> tag). As such, I don't see a place for a <model> tag in the current environment as a merely semantic element, and adding more than just semantics to the tag would be overlapping it with other efforts.<br>
<br>David W.<br>
</blockquote></div>
</div></div></div></div></blockquote></div><br>
</blockquote></div><br>