- From: Brian Blakely <anewpage.media@gmail.com>
- Date: Mon, 2 Nov 2009 22:19:59 -0500
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? ?????
Received on Monday, 2 November 2009 19:19:59 UTC