![](https://csdnimg.cn/release/download_crawler_static/10382713/bg4.jpg)
o Material diffuseColor¼ "0 1 0"
shininess¼ ’0.15625’/ 4
o /Appearance 4
o IndexedFaceSet creaseAngle ¼ ’4’
coordIndex ¼ ’
[indexed vertex coordinates for model]
’/4
o /IndexedFaceSet 4
o /Shape4
o /Transform 4
o /Scene4
o /X3D4
o script type ¼"text/javascript" src ¼ "x3dom.
js"4 o /script4
o /body 4
This code snippet uses hierarchical declaration to create a 3D
o scene 4 . A viewpoint position and orientation is set, as is the
background colour. A o transform 4 tag defines translation,
rotation and scaling transforms which apply to the tag contents
(in this case all the content defined within it should be is
translated by 10 units in the y-axis). The o shape 4 tag defines
an object in the scene, within which the objects properties (such
as the mesh and appearance) are defined in parallel. The mesh in
this scene is defined as a set of indexed faces; no normal vectors
are supplied so X3DOM calculates them to enable lighting effects.
For rendering the scene X3DOM defines a fallback model [11],
trying to initialise preferred renderers first, and using alternativ e
technology if req uired. Currently the fallback model first checks
whether the user application is capable of rendering X3D code
nativ ely, and is so, passes the contents of the o x3d 4 tag to the
X3D rendering engine de
fined by the host application. If native X3D
rendering is not detected, or an X3D browser plugin is not installed,
the application tries to create a W ebGL rendering context, and builds
the X3D scene graph on top of that. With the partial integration of
W ebGL into Microsoft Internet Explorer 11 [12],themajorityofthe
modern browsers now support browser based 3D rendering via
W ebGL (see below). If W ebGL is not supported, X3DOM tries to
render with Stage 3D (see Section 2.1 0 below) before finally
presenting a non-interactiv e image or video if no 3D rendering is
possible.
X3DOM is designed to integrate with the DOM and thus can be
modified in the same manner as any DOM object. For example, if
the programmer wished to modify the position of the shape at
runtime (for example, in response to user input), the translation
attribute of the o transform 4 tag can be modified at runtime
using Javascript, and the scene will update accordingly.
3D models can be loaded into X3D/X3DOM by defining vertex
geometry as in the example above, or by importing an X3D (or
VRML) scene defined in a separate file. This scene file can be coded
manually or, for complex objects and scenes, it can be created
using custom export plugins for 3D digital content creation (DCC)
packages (such as Blender, Autodesk Maya, and Autodesk 3D
Studio Max). Basic shading (such as diffuse or specular shading)
is supported in a declarative manner. Schwenk et al. [13,14] added
a declarative shader to X3D, enabling advanced 3D effects and
lighting (such as multi texturing, reflections and other lighting
effects), this is now partially supported in X3DOM. Custom shaders
are supported via the ComposedShader node; this allows the
programmer to write their own shader code as long as uniform
data is restricted to a supported set and naming conventions.
In 2011, Behr et al. extended their framework with various
functionalities [15]. Several camera navigation methods were
introduced, defining a Viewpoint node (seen in the above example)
and several different navigation patterns (definition of custom
camera navigation is also supported via manipulation of the
equivalent DOM node, for example, via Javascript). Also introduced
was simple object animation, either via CSS transforms and
animations (see below) or by the X3D Interpolators.
2.3. XML3D
XML3D [16] is similar to X3DOM, in that it is an extension to
HTML designed to support interactive 3D graphics in the browser,
requiring the use of XHTML. Its stated goal is to try to find the
minimum set of additions that fully support interactive 3D content
as an integral part of 2D/3D web documents. It takes a similar
high-level approach to 3D programming as X3DOM: both use
declarative language to define a 3D scene, and both expose all
elements of the 3D to the DOM (with the benefits of DOM mani-
pulation that arise thereafter). The central difference between the
two approaches is that X3DOM grew out of an attempt to natively
embed an existing framework (X3D) into a browser context,
whereas XML3D proposes to extend the existing properties of
HTML wherever possible, embedding 3D content into a web page
with the maximum reuse of existing features. The sample XML3D
code below draws a similar scene to the X3D code above (for
brevity, standard html code such as the body and head tags are
excluded, along with lines to load XML3D libraries and the data for
the mesh):
o xml3d id
¼ "BunnyXML3D"
activeView¼ "#defaultView"
class¼ "xml3d" style¼ "width: 400px; height:
400px;" 4
o defs id ¼ "mainDef"4
o transform id ¼"t_Light" rotation ¼ "20 22 92
190"
scale¼ "1.0 1.0 1.0" translation ¼ "400 100
600"4
o /transform 4
o transform id ¼"t_Bunny" rotation ¼ "0.0 0.0
0.0 0"
scale¼ "1.0 1.0 1.0" translation ¼ "0.0 0.0
0.0"4
Fig. 2. Screenshot taken from a Mozilla Firefox browser window executing the
X3DOM code shown above.
A. Evans et al. / Computers & Graphics 41 (2014) 43–6146