[whatwg] <model/>: A 3D Equivalent to <img/>

Brian Blakely anewpage.media at gmail.com
Mon Nov 2 19:19:59 PST 2009


CYp,

We are speaking about a native, semantic 3D media type.  It is
inherently compatible with 3D CSS and requires no additional code to
display.  This is very different from a 2D rendering based on 3D
properties (as with VRML and <canvas/>).

-Brian


2009/11/2 CYp <tccyp86 at hotmail.com>:
> * 2D bitmaps are only partially compatible with 3D CSS - they are still
> always flat
>>>3D object  will finally be present as a 2d bitmap. there are always a
>>> process called rendering.
>>>you idea may be similar with the VRML, such as Box(x,y,z,w,l,h) but VRML
>>> still need some ActiveX to render it into bitmap.
> * This includes <canvas/>, which is still a 2D bitmap, not actually a 3D
> object
>>> people now are working on the  CanvasRenderingContext3D,but rendering
>>> efficiency is a big problem I think.
> ________________________________
> From: anewpage.media at gmail.com
> Date: Mon, 2 Nov 2009 14:16:37 -0500
> To: workmad3 at gmail.com
> CC: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] <model/>: A 3D Equivalent to <img/>
>
> David,
>
> 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/>.
>
> I do not agree with two of your points:
>
> * A static 3D rendering is equal to a 2D bitmap
> * JavaScript is necessary to display 3D content
>
> My brief counter-points:
>
> * 2D bitmaps are only partially compatible with 3D CSS - they are still
> always flat
> * This includes <canvas/>, which is still a 2D bitmap, not actually a 3D
> object
>
> A JavaScript-Only Approach is Inferior Because:
>
> * <canvas/> is being purposed as a viewport into 3D content, a function the
> browser itself should serve
> * 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript
> alone
> * 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
>
>
> Explanation and Supporting Examples
> ----------------------------------------------------
>
> 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".
>
> <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.
>
> The foundations of 3D CSS (a la Webkit -
> http://webkit.org/blog/386/3d-transforms/) 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.
>
> 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.
>
> DISPLAYING THE SOLAR SYSTEM IN A 3/4 VIEW
> ----------------------------------------------------------------------
>
> 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/>.
>
> On hover, each planet will rotate about its own axis.
>
>
> 2D HTML & CSS
> -----------------------
>
> <style>
>
> ul {
>     * Background image of space
> }
> li {
>     * Absolutely positioned to correlate perspective
> }
> a {
>     * Block
>     * Negative indentation, hiding text
> }
> a.(planet name) {
>     * Background image of each planet
>     * Height/Width of each background image (alternatively a large
> height/width in the anchor definition above, centering each image on X,Y
> axes)
> }
>
> </style>
>
> <h1>The Solar System in 3/4</h1>
> <ul>
>     <li>
>         <a class="sun" href="sun.html">The Sun</a>
>     </li>
>     <li>
>         <a class="mercury" href="mercury.html">Mercury</a>
>     </li>
>     <li>
>         <a class="venus" href="venus.html">Venus</a>
>     </li>
>     ...
> </ul>
>
> <script>
>     * Slideshow background script attached to each anchor, listening for
> mouseover and mouseout
> </script>
>
>
>
> 3D HTML & CSS (notes in parentheses)
> -----------------------
>
> <style>
>
> div {
>     * Background image of space
> }
> ul {
>     * 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.)
> }
> model {
>     (some of the work will already be done for you by the ul rotation)
>     * Rotate to proper perspective
>     * Translate to desired depth/position
>
>     (in the syntax of -webkit-transition and -webkit-rotate, currently in
> use today)
>     * transition: rotate 3s ease-out;
> }
> model:hover {
>     * rotateY(360deg);
> }
>
> </style>
>
> <h1>The Solar System in 3/4<h1>
> <div>
>     <ul>
>         <li>
>             <a href="sun.html">
>                 <model src="sun.xml" alt="The Sun" />
>             </a>
>         </li>
>         <li>
>             <a href="mercury.html">
>                 <model src="mercury.xml" alt="Mercury" />
>             </a>
>         </li>
>         <li>
>             <a href="venus.html">
>                 <model src="venus.xml" alt="Venus" />
>             </a>
>         </li>
>         ...
>     </ul>
> </div>
>
>
>
> 3D JAVASCRIPT, 2D HTML & CSS
> -----------------------------------------------
>
> <style>
>
> canvas {
>     * Height/Width of viewport
> }
>
> </style>
>
> <h1>The Solar System in 3/4</h1>
> <canvas id="solar-system">
>     <!-- ALT CONTENT FOR BROWSERS NOT SUPPORTING <canvas/> -->
>     (Herein: Code from Example 1)
> </canvas>
>
> <script>
>     (the following is a non-custom snippet from O3D's "simple" example --
> webGL's implementation is slightly cleaner)
>
> function loadFile(context, path) {
>   function callback(pack, parent, exception) {
>     enableInput(true);
>     if (exception) {
>       alert("Could not load: " + path + "\n" + exception);
>       g_loadingElement.innerHTML = "loading failed.";
>     } else {
>       g_loadingElement.innerHTML = "loading finished.";
>       // Generate draw elements and setup material draw lists.
>       o3djs.pack.preparePack(pack, g_viewInfo);
>       var bbox = o3djs.util.getBoundingBoxOfTree(g_client.root);
>       g_camera.target = g_math.lerpVector(bbox.minExtent, bbox.maxExtent,
> 0.5);
>       var diag = g_math.length(g_math.subVector(bbox.maxExtent,
>                                                 bbox.minExtent));
>       g_camera.eye = g_math.addVector(g_camera.target, [0, 0, 1.5 * diag]);
>       g_camera.nearPlane = diag / 1000;
>       g_camera.farPlane = diag * 10;
>       setClientSize();
>       updateCamera();
>       updateProjection();
>
>       // Manually connect all the materials' lightWorldPos params to the
> context
>       var materials = pack.getObjectsByClassName('o3d.Material');
>       for (var m = 0; m < materials.length; ++m) {
>         var material = materials[m];
>         var param = material.getParam('lightWorldPos');
>         if (param) {
>           param.bind(g_lightPosParam);
>         }
>       }
>
>       g_finished = true;  // for selenium
>
>       // Comment out the next line to dump lots of info.
>       if (false) {
>         o3djs.dump.dump('---dumping context---\n');
>         o3djs.dump.dumpParamObject(context);
>
>         o3djs.dump.dump('---dumping root---\n');
>         o3djs.dump.dumpTransformTree(g_client.root);
>
>         o3djs.dump.dump('---dumping render root---\n');
>         o3djs.dump.dumpRenderNodeTree(g_client.renderGraphRoot);
>
>         o3djs.dump.dump('---dump g_pack shapes---\n');
>         var shapes = pack.getObjectsByClassName('o3d.Shape');
>         for (var t = 0; t < shapes.length; t++) {
>           o3djs.dump.dumpShape(shapes[t]);
>         }
>
>         o3djs.dump.dump('---dump g_pack materials---\n');
>         var materials = pack.getObjectsByClassName('o3d.Material');
>         for (var t = 0; t < materials.length; t++) {
>           o3djs.dump.dump (
>               '  ' + t + ' : ' + materials[t].className +
>               ' : "' + materials[t].name + '"\n');
>           o3djs.dump.dumpParams(materials[t], '    ');
>         }
>
>         o3djs.dump.dump('---dump g_pack textures---\n');
>         var textures = pack.getObjectsByClassName('o3d.Texture');
>         for (var t = 0; t < textures.length; t++) {
>           o3djs.dump.dumpTexture(textures[t]);
>         }
>
>         o3djs.dump.dump('---dump g_pack effects---\n');
>         var effects = pack.getObjectsByClassName('o3d.Effect');
>         for (var t = 0; t < effects.length; t++) {
>           o3djs.dump.dump ('  ' + t + ' : ' + effects[t].className +
>                   ' : "' + effects[t].name + '"\n');
>           o3djs.dump.dumpParams(effects[t], '    ');
>         }
>       }
>     }
>   }
>     ...
>
>     (and on, literally, for pages)
> </script>
>
>
> 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.
>
> -Brian MB
>
>
> On Mon, Nov 2, 2009 at 4:46 AM, David Workman <workmad3 at gmail.com> wrote:
>
> 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.
>
> 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.
>
> David W.
>
> ________________________________
> 全新 Windows 7:寻找最适合您的 PC。 了解详情。



More information about the whatwg mailing list