This blog post is an excerpt from the book “Programming 3D Applications with HTML5 and WebGL”, with some translations on the 3D content pipeline. And one of the things I’ve been interested in before: the format of 3D content.
The original
Programming 3D Applications with HTML5 and WebGL – Excerpts from: Programming 3D Applications with HTML5 and WebGL
The 3D Content Pipeline
In the early days of the Web, if you knew how to write markup, you were a content creator. There was no Dreamweaver WYSIWYG editing; no Photoshop tool for slicing images. The task was left, largely, To programmers — and the Web looked like it. Eventually, the makers of professional authoring software developed tools for creating webready content. Once the tools were in place, artists and designers assumed the content responsibilities, and the Internet transformed into a consumer-grade experience.
WebGL development is going through an evolution similar to those early days of the Web. For the first few years of the technology’s existence, content was created by hand by programmers typing into text editors, or cobbled from whatever 3D format they could find a converter for. If a converter didn’t exist, you would write one to get the project done.
Fortunately, the situation is changing rapidly. Three.js and other WebGL libraries are getting better at importing content created by professional tools. The industry is also pulling together to create new 3D file format standards designed specifically for web use. The content creation landscape is still a bit rocky, But at least we have moved beyond the “stone tools” stage of a few years ago into more of a Bronze Age of 3D development.
This chapter covers the 3D content pipeline for web development. First, we will look at the overall content creation process. You may find this useful if you are new to 3D authoring. Then, we survey popular modeling and animation tools being used in today’s WebGL projects, and dig into the details of the 3D file formats that are best suited to web deployment. Finally, we will learn how to load those files into applications using Three.js utilities, in preparation for projects to come in following chapters.
The 3D Creation Process
3D content creation involves a set of highly specialized disciplines. Professional careers in 3D require extensive training and a deep understanding of complex authoring tools and workflows. Often, one 3D artist does everything, including modeling, texture mapping, and animating. But sometimes, especially on bigger projects, people specialize.
In many ways, 3D content creation is similar to making 2D art with Photoshop or Illustrator. But 3D authoring is also different from 2D art creation in a few fundamental respects. Even if you consider yourself a technical person, if you are planning on a developing a 3D project, it’s good to know what it takes to make the content that goes into it. With that in mind, let’s take a look at the basic steps involved in the 3D creation process.
Modeling
3D model creation typically starts with a sketch by the artist. Before long, a modeling package is used to turn that sketch into a digital representation in 3D. Models are usually created as 3D polygonal meshes, drawn first as wireframes and then shaded with materials. This activity is known as 3D modeling, and the person who does it for a living is called a modeler. Figure 8-1 depicts a basic model of a teapot, created with Autodesk 3ds Max. The model is seen from four different views: top, left, front, and perspective.
Figure 8-1. 3D modeling in 3ds Max with top, front, left, and perspective views
(image ©Autodesk, from the main Wikipedia entry on 3ds Max)
Texture Mapping
Texture mapping, also known as UV mapping, is the process of creating 2D art to wrap onto the surface of a 3D object. Modelers often do their own texture mapping, though in larger projects the responsibilities may be divided, and specialized texture artists do the texturing. Texture mapping is usually done with assistance from a visual tool built directly into the modeling package. The tool allows the artist to associate vertices of the mesh with positions on the 2D texture map while providing visual feedback. Figure 8-2 depicts texture mapping, where we see the map on the left; the combined view is on the bottom right and overlays vertex positions with the image data; and the resulting preview is on the top right. Note the somewhat counterintuitive layout of the image data on the left. Only half the face is shown. This is because, in the case of this texture map, the left and right sides of the face are mirror images. This strategy allows the artist to pack more data into less space and/or use other parts of the image for additional detail.
Figure 8-2. Texture mapping: a 2D image is wrapped and reflected onto the surface of a 3D object
(image courtesy Simon Wottge)
The process of creating 3D animations ranges from easy to extremely difficult, depending on the task. Key frame animating tends to be simple, at least in concept. The interfaces can get tricky to use and cluttered visually. A key frame editor, like the one depicted in Figure 8-3 from Autodesk Maya, contains a set of timeline controls (highlighted in the red rectangle near the bottom of the Maya window) that allow the artist, also known as the animator, to move or otherwise changes the object in the view, and then identify and click on positions in the timeline to define the key frames. Key frames can be used to change translation, rotation, scale, and even light and material attributes. When an animator wants to key frame more than one attribute, he or she adds another track tothe animation timeline. The animator lays out tracks in the interface by stacking them, which is what can lead to the visual clutter.
Animating
Animating characters with skinning is much more involved. Before the character can be animated, a set of bones, or rig, must be created. The rig determines various aspects of how the skin moves in response to movements of the bones. Rigging, or the process of creating the rig, is a very specialized skill. Often, different artists do the character animation and rigging.
Figure 8-3. Maya’s Animation Timeline Tool, with Controls for Key Frames Animating Translation, Rotation, Scale and other attributes (image courtesy UCBUGG Open Course Ware)
Technical Art
We may not think of programming as a content creation activity, but in 3D development it often is. Complex special effects, such as certain shaders and post-processing techniques, can require the skills of an experienced programmer. In game and animation shops, this job falls to a technical artist (TA) or technical director (TD). There is no formal definition of these job positions, or strict difference between the two positions; though as the name implies, the TD is usually a more senior and experienced person. TDs write scripts, rig characters, write converter programs to get art from one format into another, implement special effects, Develop shaders – in other words, all the stuff that is too technical for a visual artist to handle. It is a highly valued set of skills, and to many producers, good TDs are worth their weight in gold.
Given that they program for a living, TDs’ tool of choice is usually a text editor. However, there are now some interesting visual development tools for creating shaders and special effects. One example is ShaderFusion, a recently released visual tool for use with the Unity game engine. ShaderFusion allows the developer to develop shaders By defining data flows between one object’s outputs (such as time or position) and another object’s inputs (e.g, color and refraction). The interface is depicted in Figure 8-4.
Figure 8-4. ShaderFusion, a visual shader editor for the Unity3D engine
3D File Formats
There have been many 3D file formats developed over the years — so many that an exhaustive list would not be possible here. Some 3D formats have been designed to store files for a single authoring package; Others have been designed to exchange data between packages. Some formats are proprietary — that is, Completely controlled by a single company or software vendor — whereas others are open standards defined by an industry group. Some 3D file formats are entirely text-based and, therefore, human-readable, while others use a binary representation to save space.
3D file formats fall into three general categories: model formats, used to represent single objects; animation formats for animating key frames and characters; and full-featured formats that support entire scenes, including multiple models, transform hierarchy, cameras, lights, and animations. We will look at each of these kinds of formats, with a special emphasis on the ones that are best suited for web-based applications.
Model Formats
Single-model 3D formats are used extensively for interchange between different packages. Most modeling packages, for example, can import and export the OBJ format (see next section). Because they tend to have a simple syntax and only a few features, it is easy to implement support for them, and their use is prevalent. They do, however, tend to be quite limited in the features they support.
Wavefront OBJ
The OBJ file format, originally developed by Wavefront Technologies, is one of the oldest and best-supported single-model formats in the industry. It is extremely simple, supporting only geometry (with the associated vertices, normals, and texture coordinates).Wavefront introduced the companion MTL (Material Template Library) format for applying materials to geometry.
Example 8-1 illustrates the basics of an OBJ file, An excerpt from the classic “ball chair” model that we will be loading with three. js later in the chapter (and real-life) in Figure 8-12 later in the chapter). The OBJ file is packaged with the code examples in the file Models /ball_chair/ball_chair.obj. Let’s have a look at the syntax. The # character is used as a comment file consists of a series of declarations. The first declaration is a reference to the material library stored in the associated MTL file. After that, several geometry objects are defined. This excerpt shows a partial listing of the definition for the object shell, the outer shell of the ball chair. We define the shell by specifying vertex position, normal, and texture coordinate data, one entry per line, followed by face data, also one per line. Each vertex of the face is specified by a triple in the form v/vt/vn, where v is the index of the previously supplied vertex position, vt the index of the texture coordinate, and vn the index of the vertex normal.
Example 8-1. A model in Wavefront OBJ format
# 3DS Max Wavefront OBJ Exporter V0.97b - (c)2007 Guruware # File Creation: MTL # # Object shell # v −15.693047 49.273174 −15.297686 V −8.895294 50.974277 −18.244076 V −0.243294 51.662109 −19.435429... More Vertex positions here VN −0.537169 0.350554 −0.767177 VN −0.462792 0.358374 −0.810797 VN −0.480322 0.274014 - 0.833191... Normals here vt 0.368635 0.102796 0.000000 vt 0.348531 0.101201 0.000000 vt 0.349342 0.122852 0.000000 more Vertex normals here vt 0.368635 0.102796 0.000000 vt 0.348531 0.101201 0.000000 vt 0.349342 0.122852 0.000000... more texture coordinates here g shell usemtl shell s 1 f 313/1/1 600/2/2 58/3/3 597/4/4 f 598/5/5 313/1/1 597/4/4 109/6/6 f 313/1/1 598/5/5 1/7/7 599/8/8 f 600/2/2 313/1/1 599/8/8 106/9/9 f 314/10/10 603/11/11 58/3/3 600/2/2 ... more face definitions hereCopy the codeThe material definitions that accompany the ball chair are in the MTL file models/ball_chair/ball_chair.mtl. The syntax is very simple; see Example 8-2. A material is declared with the newmtl statement, which contains a handful of parameters used to Phong shade the object: specular colors and coefficients (Ks, Ns, and Ni keywords), diffuse color (Kd), ambient color (Ka), emissive color (Ke), and texture maps (map_Ka and map_Kd). The texture map model for MTL has evolved over the years to include bump maps, displacement maps, environment maps, and other types of textures. In this example, only the diffuse and ambient texture maps are defined for the shell material.
Example 8-2. Material definitions for Wavefront OBJ format
Newmtl shell Ns 77.000000 Ni 1.500000 Tf 1.000000 1.000000 1.000000 illum 2 Ka 0.000000 0.000000 0.000000 Kd 0.588000 0.588000 0.588000 Ks 0.720000 0.720000 0.720000 Ke 0.000000 0.000000 0.000000 map_Ka maps\shell_color.jpg map_Kd maps\shell_color.jpg ...Copy the codeSTL
Another simple, text-based, single model format is STL (for StereoLithography), developed by 3D Systems for rapid prototyping, manufacturing, STL files are even simpler than OBJ. The format supports only vertex geometry — no normals, texture coordinates, or materials. Example 8-3 shows a fragment from one of the Three.js example STL files (examples/models/stl/pr2_head_pan.stl). To see the file in action, open
the Three.js example file examples/webgl_loader_stl.html. STL is an excellent candidate 3D format for building online 3D printing applications in WebGL, because the files can potentially be sent directly to 3D printing hardware. In addition, it loads easily and renders quickly.
Example 8-3. The STL file format
solid MYSOLID created by IVCON, original data in binary/pr2_head_pan.stl
Facet Normal −0.761249 0.041314 −0.647143
outer loop
Vertex – 0.075633-0.095256-0.057711
Vertex – 0.078756-0.079398-0.053025
Vertex – 0.074338-0.088143-0.058780
endloop
endfacet
.
endsolid MYSOLID
STL is such an easy and popular format that GitHub has actually added STL viewing directly into its interface. The viewer is built in WebGL, using our old friend Three.js.
For technical details on the STL format, visit the Wikipedia page.
Animation Formats
The formats described in the previous section represent static model data only. But much of the content in a 3D application is moving around on the screen (i.e., animated). A few specialty formats have evolved to deal with representing animated models. These include the Text-based — and therefore web-friendly — Formats MD2, MD5, and BVH.
id Software animation formats: MD2 and MD5
A couple of 3D formats that you will see crop up in web use from time to time are the animation formats for id Software’s popular Doom and Quake franchises. The MD2 format and its successor, MD5, are formats that define character animation. While the formats are essentially controlled by id, their specifications were released long ago, and many tools have been written to import them.
The MD2 format, created for Quake II, is a binary file format. It supports vertex-based character animation only via morph targets. MD5 (not to be confused with the Message Digest algorithm, a cryptographic hash function used widely on the Web) was developed for Quake III and introduced skinned animation and a text-based, human-readable format.
Excellent documentation on the MD2 and MD5 specifications can be found online.
To use these formats in WebGL applications, we could write a loader that reads them directly, or if using a library like Three.js, we can use a converter. When an MD2 file is converted to JSON, the format looks something like the example from Chapter 5, depicted in Figure 5-11. As a refresher, run the Three.js example located at examples/webgl_morphtargets_md2_control.htm, and have a look at the source code. There is a lot going on to load and interpret MD2 data.
Three.js does not come with an MD5 loader as part of the example set. However, there is a wonderful online converter from MD5 to Three.js JSON that was written by Klas (OutsideOfSociety) of the Swedish web agency North Kingdom (developers of Find Your Way to OZ). To see already-converted models in action, go to Klas’s blog and open this link. You should see a fairly detailed model of a monster, with controls for starting the various gesture animations.
To run the converter on your own MD5 files, you can open this link, which lets you drag and drop MD5 files into the view window, and produces JSON code.
BVH: The motion capture data format
Motion capture, the process of recording the movement of objects, has become a very popular way to create content, especially animations of people. It is used extensively in film, animation, military, and sports applications. Motion capture is widely supported in open formats, including the Biovision Hierarchical Data format, or BVH. BVH was developed by the motion capture company Biovision to represent movements in the animation of human characters. BVH is a very popular, text-based format supported as an import and export format by many tools.
Developer Aki Miyazaki has created an early experiment to import BVH data into WebGL applications. His BVH Motion Creator, a web-based BVH preview tool written using Three.js, is depicted in Figure 8-11. BVH can be uploaded, and its animations previewed on the simple character.
Figure 8-11. BVH Motion Creator, a previewer for motion capture files in BVH format
Full-Featured Scene Formats
Over the years, a few standard formats have been developed by the industry to support representing the entire contents of a 3D scene, including multiple objects, transform hierarchy, lights, cameras, And essentially anything created by an artist in a full-featured tool like 3ds Max, Maya, or Blender. In general, this is a much harder technical problem to solve, and few formats have survived to enjoy widespread use. This situation may change, however, with WebGL driving new requirements for reuse of content and interoperability between applications. In this section, we look at a few potential full-scene formats for use with WebGL.
VRML and X3D
Virtual Reality Markup Language (VRML) is the original text-based standard for 3D on the Web, created in 1994 by a group that includes inventor and theorist Mark Pesce, members of the Silicon Graphics Open Inventor software team, and myself. VRML went through a couple of iterations in the 1990s, enjoying broad industry backing and the support of a nonprofit standards consortium. A successor featuring XML-based text representation was developed in the early 2000s, and renamed as X3D. While these standards are no longer widely deployed in web applications, they are still supported by most modeling tools as import and export formats.
VRML and X3D define full scenes, animation (key frames, morphs, and skinning), materials, lights, and even scripted, interactive objects with behaviors. Example 8-4 shows the X3D syntax for creating a scene with a red cube that will make a full rotation about the y-axis in two seconds when clicked. The geometry, behavior, and animations are all in this single XML file with an intuitive, human-readable syntax. To this day, there is no other open-standard 3D file format that can express all this functionality in such a simple, elegant syntax (if I do say so myself).
Example 8-4. X3D sample: A red cube that rotates when clicked
<? The XML version = "1.0" encoding = "utf-8"? > <! DOCTYPE X3D PUBLIC "ISO / / the Web3D / / DTD X3D / 3.0 / EN" "http://www.web3d.org/specifications/x3d-3.0.dtd" > < X3D Profile = 'Interactive' version = '3.0' XMLNS: XSD = 'http://www.w3.org/2001/XMLSchema-instance' XSD: noNamespaceSchemaLocation = 'http://www.web3d.org/specifications/x3d-3.0.xsd' > < head >... <! -- XML meta information for X3D file goes here --> </head> <! -- Index for DEF nodes: Animation, Clicker, TimeSource, XForm --> <Scene> <! -- XForm ROUTE: [from Animation.value_changed to rotation ] --> <Transform DEF='XForm'> <Shape> <Box/> <Appearance> <Material DiffuseColor ='1.0 0.0 0.0'/> </Appearance> </Shape> <! -- Clicker ROUTE: [from touchTime to TimeSource.startTime ] --> <TouchSensor DEF='Clicker' description='click to animate'/> <! -- TimeSource ROUTEs: [from Clicker.touchTime to startTime ] [from fraction_changed to Animation.set_fraction ] --> <TimeSensor DEF = 'TimeSource cycleInterval =' 2.0 '/ > <! -- Animation ROUTEs: [from TimeSource.fraction_changed to set_fraction ] [from value_changed to XForm.rotation ] --> <OrientationInterpolator DEF='Animation' key='0.0 0.33 0.66 1.0' keyValue='0.0 0.0 0.0 0.0 0.0 2.1 0.0 0.0 0.0 4.2 0.0 0.0 0.0 0.0 0.0'/> </Transform> <ROUTE fromNode='Clicker' fromField='touchTime' toNode='TimeSource' toField='startTime'/> <ROUTE fromNode='TimeSource' fromField='fraction_changed' toNode='Animation' toField='set_fraction'/> <ROUTE fromNode='Animation' fromField='value_changed' toNode='XForm' toField='rotation'/> </Scene> </X3D>Copy the codeThe design of VRML embodies many key concepts of interactive 3D graphics, and for that reason, you might expect that it is well suited for WebGL use. However, the standard was developed in a pre-JavaScript, pre-DOM world, and also before the advent of many key hardware-accelerated graphics features in use today. At this point, in my humble opinion, VRML/X3D is too out of date to consider for practical use. At the same time, there are many ideas in there yet to be tapped for use in WebGL, so it is a great area for study and inspiration.
Over the years, a wealth of VRML and X3D content has been developed. The folks at the German-based Fraunhofer Institute continue to soldier down the X3D path and are now creating X3DOM, a library for viewing X3D content using WebGL, without the
need for a plugin. For more information on X3DDOM, go to www.x3dom.org/. The VRML and X3D specifications may be found online.
COLLADA: The digital asset exchange format
In the mid-2000s, as VRML began showing signs of age, a group of companies, including Sony Computer Entertainment, Alias Systems Corporation, and Avid Technology, Connectivity up to develop a new format for exchanging 3D digital assets among games and interactive 3D applications. Remi Arnaud and Mark C. Barnes of Sony led the design of the format, named COLLADA (for COLLAborative Design Activity). After the initial specification work and support from individual companies, development of the standard was turned over to the Khronos Group, the same nonprofit organization that develops WebGL, OpenGL, and other graphics hardware and software API standards.
COLLADA, like X3D, is a full-featured, XML-based format that can represent entire scenes, with a variety of geometry, material, animation, and lighting types. Unlike X3D, the goal of COLLADA is not to deliver an end-user experience complete with behaviors and runtime semantics. In fact, it is a stated nongoal of the technology. Rather, COLLADA is intended to preserve all of the information that could be exported from a 3D authoring tool so that it can be used downstream in another tool, or imported into a game engine or development environment before being deployed into the final application. The main idea was that, once COLLADA was widely accepted by the industry, the makers of various DCC tools would not have to worry about writing exporters to custom formats ever again; export to COLLADA, and, in theory, any package could import it.
Example 8-5 shows an excerpt from a COLLADA scene that we are going to load with Three.js later in this chapter. As we walk through it, there are several things to note about the structure of COLLADA files. First, Constructs all Constructs are organized into libraries — Collections of types such as images, Shaders, and materials. These libraries usually come first in the XML definition, to be later referenced by constructs that need them (for example, images used in a material definition). Second, note that there are explicit declarations of what would normally be considered a built-in function, such as Blinn shading. COLLADA assumes nothing about shading and rendering models; it simply stores that data so that another tool can get the information and try to do something with it. Then, we see the vertex data for a mesh, expressed as a series of float_array elements. Finally, the mesh is assembled into a scene the user can see by referencing previously defined geometry and materials (using the instance_geometry, bind_material, and instance_material XML elements).
Example 8-5. COLLADA file structure, sample libraries, geometry, and scene
<? The XML version = "1.0"? > < COLLADA XMLNS = "http://www.collada.org/2005/11/COLLADASchema" version = "1.4.1" > < asset > < contributor > <authoring_tool>CINEMA4D 12.043 COLLADA Exporter </authoring_tool> </contributor> </created> <modified> 2012-04-25t16:44:56z </modified> <unit meter="0.01" name=" right "/> <up_axis>Y_UP</up_axis> </asset> <library_images> <image id="ID5"> <init_from>tex/Buss.jpg</init_from> </image> ... <! -- more image definitions here --> </library_images> <library_effects> <effect id="ID2"> <profile_COMMON> <technique Sid ="COMMON"> <blinn> <diffuse> <color>0.8 0.8 0.8 1</color> <specular> <color>0.2 0.2 0.2 1</color> < / specular > < shininess > < float > 0.5 < / float > < / shininess > < / blinn > < / technique > < / profile_COMMON > < / effect >... <! -- more effect definitions here --> <library_geometries> <geometry id="ID56"> <mesh> <source id="ID57"> <float_array Id ="ID58" count="22812">36.2471 9.43441 −6.14603 36.2471 11.6191 −6.14603 36.2471 9.43441 −9.04828 36.2471 11.6191 −9.04828 33.356 9.43441 −9.04828 33.356 11.6191 −9.04828 33.356 9.43441... <! -- remainder of mesh definition here --> ... <! -- define the scene as a hierarchy of nodes --> <library_visual_scenes> <visual_scene id="ID53"> <node id="ID55" Name ="Buss"> <translate sid="translate">5.08833 −0.496439 -0.240191</translate> <rotate SID ="rotateY">0 1 0 0</rotate> <rotate sid="rotateX">1 0 0 0</rotate> <rotate sid="rotateZ">0 0 1 0</rotate> <scale sid="scale">1 1 1</scale> <instance_geometry url="#ID56"> <bind_material> <technique_common> <instance_material symbol="Material1" target="#ID3"> <bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/> </instance_material> </technique_common> </bind_material> </instance_geometry> </node> ... <! -- remainder of scene definition here -->Copy the codeAfter an initial period of high enthusiasm and broad vendor adoption, COLLADA support began to wane. Beginning around 2010, active development on exporter plugins for the popular DCC tools all but stopped. Recently, interest in COLLADA has picked up again, Primarily due to the surge of support for WebGL — and the lack of a built-in file format for WebGL (more in this in a moment). There is a new open source project called OpenCOLLADA, with updated exporters for 3ds Max and Maya, from 2010 versions onward. It exports clean, standard-compliant COLLADA.
While improved COLLADA support is a boon to the 3D content pipeline, there is a problem. As we saw in the previous example, COLLADA is very verbose. The format was designed to preserve data, not to be fast to download and parse. That is why the Khronos Group has undertaken a new initiative that reimagines the Best Aspect of COLLADA — Its Full representation of Rich, Animated 3D scenes — Into a new format designed for Web Delivery: glTF.
glTF: A new format for WebGL, OpenGL ES, and OpenGL applications
The rise in popularity of WebGL created a problem for web developers: the need to deliver full-scene content from 3D DCC tools into a running WebGL application. Singlemesh text formats such as OBJ are adequate for representing one object, but do not contain scene graph structure, lighting, cameras, and animation. COLLADA is fairly full-featured; however, as we saw in the previous section, it is verbose. In addition, it is represented in XML, requiring intensive CPU cycles to process into data structures suitable for rendering in WebGL. What was needed was a Compact, web-ready format that requires minimal extra processing before rendering, something akin to a “JPEG for 3D.”
In the summer of 2012, Fabrice Robinet, an engineer at Motorola and chair of the Khronos COLLADA working group, began working on a 3D file format with the graphics features of COLLADA but with a more compact, WebGL-friendly representation. Originally, the project was dubbed COLLADA2JSON, the idea being that this would be a translation of the heftier XML syntax into lightweight JSON. Since then, the project has taken on a life of its own. Fabrice was joined by other contributors from the working group, including myself, COLLADA creator Remi Arnaud, and Patrick Cozzi, an engineer at defense software vendor AGI. Our mandate was expanded to broaden the scope beyond simple translation/optimization of COLLADA into a ground-up design of a new format for use with OpenGL-based applications for the Web and mobile, and glTF, the Graphics Library Transmission Format, was born.
glTF uses the full-featured nature of COLLADA as a jumping-off point, but it is a completely new format. The COLLADA feature set acts as a reference for the group to determine what sort of graphics features to support, but the details are completely different. glTF uses JSON files to describe scene graph structure and high-level information (such as cameras and lights), and binary files to describe rich data such as vertices, normals, colors, and animation. The binary format for glTF has been designed so that it can be loaded directly into WebGL buffers (typed arrays such as Int32Array and FloatArray). So, the process of loading a glTF file can be as simple as the following:
-
Read a small JSON wrapper file.
-
Load an external binary file via Ajax.
-
Create a handful of typed arrays.
-
Call WebGL drawing context methods to render.
Of course, in practice it is a bit more complicated. But this is far more efficient than downloading and parsing an XML file, and converting arrays of JavaScript Number types to typed arrays. glTF promises significant wins in both file size and Speed of Loading Content – Both critical factors in building high-performance web and mobile applications.
Example 8-6 shows the syntax of the JSON for a typical glTF scene, the famous COLLADA duck model. Note that there are structural similarities to COLLADA: libraries appear first, and we define a scene graph structure at the end by referencing elements in those libraries. But this is where the similarity ends. glTF dispenses with any information not absolutely required for runtime use, opting instead to define structures that will load quickly into WebGL and OpenGL ES. glTF defines in painstaking detail the attributes (vertex positions, normals, colors, texture coordinates, and so on) that are used to render objects with programmable shaders. Using this attribute information, a glTF application can faithfully render any meshes, even if it does not have its own sophisticated materials system.
In addition to the JSON file, glTF references one or more binary files (.bin extension) that store rich data (e.g., vertex data for meshes and animations) in structures called buffers and buffer views. Using this approach, we can stream, download incrementally, or load glTF content in one whack, as appropriate for the application.
Example 8-6. glTF JSON file format example
{"generator": "collada2gltf 0.1.0"}, "asset": {"generator": "collada2gltf 0.1.0"}, "Attributes ": {"attributes _22": {"bufferView": "BufferView_28 ", "byteOffset": 0," stride ": 12, "stride ": 12, "count": 2399," Max ": [96.1799, 163.97, 53.9252], "min": - - 69.2985, 9.92937, 61.3282], "type" : "FLOAT_VEC3"},... more vertex attributes here "bufferViews": { "bufferView_28": { "buffer": "duck.bin", "byteLength": 76768, "byteOffset": 0, "target": "ARRAY_BUFFER" }, "bufferView_29": { "buffer": "duck.bin", "byteLength": 25272, "byteOffset": 76768, "target": "ELEMENT_ARRAY_BUFFER" } }, "buffers": { "duck.bin": { "byteLength": }}, "cameras": {"camera_0": {"aspect_ratio": 1.5, "projection": "perspective", "yfov": 37.8492, "zfar": 10000, "znear": 1}},... other high-level objects here, e.g., materials and lights ... finally, the scene graph "nodes": { "LOD3sp": { "children": [], "matrix": [ ... matrix data here ], "meshes": [ "LOD3spShape-lib" ], "name": "LOD3sp" },Copy the codeWhile the design focus of glTF is on compact and efficient representation of OpenGL data, the team has taken a balanced design approach that preserves other essential 3D data authored in DCC tools, such as animation, cameras, and lighting. The current version of glTF (version 1.0) supports the following features:
Meshes
Polygonal meshes made up of one or more geometry primitives. The mesh definition is in the JSON file, which references one or more binary data files that contain the vertex data.
Materials and shaders
Materials can be expressed as high-level common constructs (Blinn, Phong, Lambert), or implemented in GLSL vertex and fragment shaders that are included as external files referenced by the glTF JSON file.
Lights
Common light types (directional, point, spot, and ambient) are represented as highlevel constructs in the JSON file.
Cameras
glTF defines common camera types such as perspective and orthographic.
Scene graph structure
The scene is represented as a hierarchical graph of nodes (i.e., meshes, cameras, and lights).
Transform hierarchy
Each node in the scene graph has an associated transformation matrix. Each node can contain children; child nodes inherit their parents’ transformation information.
Animations
glTF defines data structures for key frame, skinned, and morph-based animations.
External media
Images and video used as texture maps are referenced via URL.
The glTF project, although executed under the auspices of the Khronos Group, is a completely open effort to which anyone can contribute. There is a source code repository on GitHub that includes working viewers and sample content, and the specification itself. Following a philosophy that we will standardize no features without first proving them in code, the team has already developed four independent glTF viewers, including one for use with Three.js (which we will look at shortly). For more information, see the main Khronos glTF page.
Autodesk FBX
There is one more full-featured scene format worth mentioning, at least in passing. The FBX format from Autodesk is a file format originally developed by Kaydara for use with MotionBuilder. After Autodesk acquired Kaydara, it began to use the FBX format in several of its products. At this point, FBX has become a standard for interchanging data between the various Autodesk products (3ds Max, Maya, and MotionBuilder).
FBX is a rich format that supports many 3D and motion data types. Unlike the other formats covered in this chapter, FBX is proprietary, completely controlled by Autodesk.Autodesk has documented the format, and provided SDKs to read and write FBX in C++ and Python; however, the SDKs require product licenses, which can represent a prohibitive cost for some. There have been successful FBX imports and exports written without the SDKs, such as for Blender, but it is not clear whether these can be used legitimately, given the terms of the FBX license.
Given the proprietary nature of the format, and the ambiguities around licensing, it may be wise to steer clear of FBX. On the other hand, it is a very powerful technology Given the proprietary nature of the format, and the ambiguities around licensing, it may be wise to steer clear of FBX. On the other hand, it is a very powerful technology.
The translation
Excerpt from: HTML5 and WebGL Programming
3D content production process
In the early days of the Web, if you knew how to write tags, you were the creator of Web content. There were no wysiWYG editors like Dreamweaver, no graphics cutting tools like PhotoShop. At the time, most of the work of creating Web content was done by programmers — and the Web at that time reflected that. Later, software developers released professional editing tools to create Web content. As these tools became popular, artists and designers took responsibility for creating content, and the Internet experience was finally elevated to a consumer level.
WebGL development is undergoing a similar evolution to the early days of the Web. In the early years of this technology, content was created manually by programmers using text editors, or converted from other 3D formats to webGL-supported formats using editors they could find. If no conversion tool is available, you may need to write one in order to complete your project.
Fortunately, this is changing fast. Three.js and other WebGL libraries are becoming increasingly powerful at importing 3D content created by professional tools. The industry has also made a concerted effort to create a standard for 3D file formats for the Web. Sui’s overall model is still relatively primitive, but compared to a few years ago, WebGL content has made a leap from the extensive “Stone Age” to the “Bronze Age” of 3D development, where at least the tools are available.
This chapter covers the development process of Web 3D content. First, we’ll go through the content creation process. If you are not familiar with 3D creation, this section is very useful for you. Next, we’ll take a general look at the popular meeting and animation tools used in WebGL projects today, and delve into the details of the 3D file formats best suited for Web development. Finally, we will learn how to load these files using the general utility of three.js, in preparation for the project in the following sections.
3D content creation process
The creation of 3D content involves a range of highly specialized disciplines. The entire career of a 3D worker requires extensive training and a deep understanding of complex authoring tools and processes. A 3D artist usually takes care of everything, including modeling, texture mapping, and animation. But sometimes, especially on larger projects, people divide up.
Creating 3D content is in many ways similar to using Photoshop and Illustrator to create 2D artwork. But there are some fundamental differences between creating A 3D work and creating a 2D work of art. Even if you’re a technical person, when you’re working on a 3D project, it’s a good idea to have some understanding of the production process of what’s being imported into the project. With that in mind, let’s look at the basic steps in the 3D content creation process.
modeling
In the creation of a 3D model, a sketch is usually first drawn by the artist. The sketch is then transformed into a 3D digital representation using a modeling package. The model is usually represented as a 3D polygonal mesh: first drawn by wireframing and then colored with materials. This process is called 3D Modeling, and the person who specializes in it is called a modeler. Figure 8-1 depicts a simple teapot model created by Autodesk 3DS Max. We can view the model from four different views: top, left, front, and perspective.
Figure 8-1:3D modeling in 3 DS Max has four views: top, left, front, and perspective
The images are copyrighted by Autodesk from the Wikipedia entry
Texture mapping
Texture mapping, also known as UV mapping, is the process of expanding and attaching created materials to the surface of a 3D object. Modelers usually do their own mapping, but for larger items, mapping responsibilities may be split between a specialized texture artist and texture mapping assisted by visual tools built into the modeling package. These tools allow maps to visually associate vertices in a 2D texture grid and preview the effect. Figure 8-2 illustrates the texture mapping. On the left is the texture; Combined with the view at the bottom right, you can see the image data overlaying the vertex position: the preview effect is at the top right. Note that the texture map layout on the left is somewhat counterintuitive: only half of the face is shown. This is because for this texture map, the left and right faces are the same. This strategy allows the textiler to put more data into a smaller space and use other parts of the image to add more detail.
Figure 8-2: Texture mapping A 2D image wraps and maps onto the surface of a 3D object
Image courtesy Simon Wottge
animation
The process of creating a 3D animation can be simple or extremely complex, depending on the task. Keyframe animation tends to be simple, at least in theory. The interface can be difficult to use and visually cluttered. A keyframe editor, as shown in Figure 8-3 for Autodesk Maya, includes the Timeline controller (highlighted with a rectangle at the bottom of the Maya window), which allows the animator to move or change objects in the view and then click on the timeline to create keyframes. Keyframes can be used to change transform, rotation, zoom, and even light and material properties. When an animator needs to define multiple attribute transformations in a keyframe, he needs to add additional tracks to the animation timeline. The animator arranges these tracks in a stacked fashion throughout the interface, which can cause visual confusion.
Animating a skinned character involves more work. Before you can animate a character, you need to create a series of bones, also known as a rig, which determines the properties of the skin as it moves along with the skeleton. The process of creating the skeleton is skilled, and the character animation and skeleton are often done by different animators.
Figure 8-3: Maya’s animation Timeline tool, with key frame control for transform, rotation, zoom, and other property transformations; Photo from UCBUGG Open Course Ware
Technology art
We may not think of programming as a part of the content creation activity, but in 3D development, it often is. Complex special effects, such as certain shaders and post-processing techniques, require an experienced programmer. In game and animation companies, these jobs are assigned to technical artists or technical directors. There is no formal definition of these positions, nor is there a strict distinction between the two. But judging by the name, the CTO is usually a more senior and experienced person. Technology involves writing scripts, creating skeletons for characters, writing transformations to convert one format to another, implementing special effects, developing shaders — in other words, all the work that is too technical for a visual designer. This is a highly valued skill, and for many products, a good CTO is priceless.
Because ctos write code for a living, the tools they use are usually text editors. However, there are some interesting visual development tools for developing shaders and special effects. One of them is ShaderFusion, a visualization tool recently released in the Unity game engine. ShaderFusion allows developers to develop shaders by defining the flow of data from one object’s output (such as time or position) to another object’s input (such as color or refraction). Figure 8-4 shows the interface.
Figure 8-4: shaderFusion, a visual shader editor in the Unity3D engine
3D file format
Many 3D file formats have emerged over the years, too many to cover here. Some 3D formats are used by a PARTICULAR 3D software, while others are used to exchange data between multiple software. Some formats are proprietary, that is, completely controlled by a single company or software vendor, while others are open standards developed by an industry group. Some formats are text-based and therefore readable, while others use binary formats to save space.
There are three categories of 3D file formats: model formats, which represent individual models; Animation format, for animation keyframes and character definitions; Full-featured Lo style, containing the entire scene with multiple models, transform levels, cameras, light sources and animations. We’ll look at each type of format, with a focus on those that are suitable for Web applications.
Model format
The 3D format of a single model is often used to exchange data between different 3D software. For example, most 3D software can import and export the OBJ format (see next). It is popular because it is easy to support because of its simple syntax and relatively few features. However, this also leaves it with few features to support.
1. Wavefront OBJ
Developed by Wavefront, the OBJ file format is the industry’s first and most widely supported single model format. It is very simple and only supports geometry (vertices, normals and map coordinates). Wavefront has also introduced an auxiliary MTL(Material Template Library) format to support attaching materials to models.
Example 8-1 shows a basic OBJ file taken from the classic “space chair” model. We will use three.js to load this model in the following sections (see Figure 8-12 for the effect). The OBJ file and associated code are in models/ball_chair/ball_chair.obj. Let’s look at its syntax. The # character is used as a comment delimiter. This file contains a series of declarations. The first declaration is a reference to the associated material library MTL file. A few geometries are then defined, and this excerpt shows some of the data used to define an object called shel1, which is the outer shell of the space chair. We define the shell in a row-by-row fashion, using vertex positions, normals, and map coordinate data, followed by face data, also one row per face. The vertices of each face are defined by three numbers of type V /vt/vn, where V is vertex position data, VT is texture coordinate data, and vn is vertex normal data.
Example 8-1: a Wavefront OBJ format model
# 3DS Max Wavefront OBJ Exporter V0.97b - (c)2007 Guruware # File Creation: 20.08.2013 13:29:52 mtllib ball_chair. MTL # # Object shell # v-15.693047 49.273174-15.297686 v-8.895294 50.974277 -18.244076 V-0.243294 51.662109-19.435429... Other vertex position information vN-0.537169 0.350554-0.767177 VN-0.462792 0.358374-0.810797 vN-0.480322 0.274014-0.833191... Vt 0.368635 0.102796 0.000000 VT 0.348531 0.101201 0.000000 VT 0.349342 0.122852 0.000000... Other vertex texture coordinate information G shell usemtl shell s 1 f 313/1/1 600/2/2 58/3/3 597/4/4 f 598/5/5 313/1/1 597/4/4 109/6/6 f 313/1/1 598/5/5 1/7/7 599/8/8 f 600/2/2 313/1/1 599/8/8 106/9/9 f 314/10/10 603/11/11 58/3/3 600/2/2 ... Other surface definitionsCopy the codeThe materials for the space chair assist are defined in the MTL file Models/BALL_chair /ball_chair.mtl. The syntax is very simple, as shown in Example 8-2. A material is defined by the newMTL statement, which contains a number of parameters to use Phong shading, including specular reflection color and coefficient (Ks, Ns and Ni keywords), diffuse color (Kd), ambient color (Ka), glow color (Ke) and texture map (map_KA and Map_Kd). Texture maps in MTL have been developed over the years to include bump maps, displacement maps, environment maps and other types of textures. In this example, the shell texture only defines the environment map and the diffuse map.
Example 8-2: Material definition for OBJ format
Newmtl shell Ns 77.000000 Ni 1.500000 Tf 1.000000 1.000000 1.000000 illum 2 Ka 0.000000 0.000000 0.000000 Kd 0.588000 0.588000 0.588000 Ks 0.720000 0.720000 0.720000 Ke 0.000000 0.000000 0.000000 map_Ka maps\shell_color.jpg map_Kd maps\shell_color.jpg ...Copy the code2. STL
Another simple text-based single model format is STL(StereoLithography), which has been developed for rapid prototyping of 3D systems, manufacturing and 3D printing. The STL format is simpler than OBJ in that it only supports vertex geometry and does not support normals, texture coordinates and materials. Example 8-3 shows a small piece of STL file code from an example (examples/models/ STL /pr2_head_pan.stl) in three.js. To see what it looks like at run time, open examples/webgl_loader_stl.html in three.js: STL is a great format for developing webGL-based online 3D printing applications: it can be delivered directly to 3D printing devices. Plus, it’s easy to load and fast to render.
Example 8-3: STL file format
solid MYSOLID created by IVCON, Original data in binary/pr2_head_pan. STL Facet Normal-0.761249 0.041314-0.647143 Outer loop Vertex - 0.075633-0.095256 -0.057711 Vertex -0.078756-0.079398-0.053025 Vertex -0.074338-0.088143-0.058780 Endloop Facet... endsolid MYSOLIDCopy the codeSTL is so simple and popular that GitHub has added support for viewing it directly (github.com/blog/1465-s…
The STL format technical details you can refer to wikipedia (en.wikipedia.org/wiki/STL_%2…
Animation format
The format described in the previous section can only be used to represent static model data. But in most 3D applications, the content moves on the screen. There are several formats specifically designed to represent dynamic models, including the text-based (and therefore Web-friendly) MD2, MD5, and BVH formats.
1. Id Software animation format: MD2 and MD5
You’ll see proprietary formats for popular GAMES DOOM and Quake for ID Software on the Web from time to time. MD2, and its subsequent MD5 format, is used to define character animations. The format is controlled by ID SoftWare, who published the format specification early on, and there are many tools that support importing them.
The MD2 format was created for Quake II and is a binary format. It supports vertex-based character animation by morphing goals only. MD5(not to be confused with the cryptographic hash function “Message to” algorithm widely used on the Web) was developed for Quake III, introducing skin animation, and is a text-based readable format.
MD2 (TFC) duke. Free. Fr/coding/MD2 -…
To use these expressions in a WebGL application, we can either write a loader ourselves to read them directly, or if we use a library like Three.js, we can use a conversion tool. If you convert the MD2 file to JSON format, it will look like the example in Chapter 5, as shown in Figure 5-11. Take a look back at the examples/ webgl_Morphtargets_MD2_control.htm file and take a look at its source code. You will see that there is a lot of work involved in loading and interpreting MD2 files.
Three.js does not include an MD5 loader in its example. But there is a nice online conversion tool that can convert MD5 to the three-.js JSON format, developed by Klas(OutsideOfSociety), Klas works for Swedish web company North Kingdom (the team behind Find Your Way to OZ). To see a transformed model, go to Klas’s blog and open the link (oos.moxiecode.com/js_webgl/md…
Md5_converter /), which allows you to drag and drop an MD5 file into the window and output JSON code.
2.BVH: Motion capture data format
Motion capture, which is a way of recording the movement of objects, is very popular for animating people. It is widely used in film, animation, military and sports applications. Motion capture is widely supported in open source formats including Biovision Hierarchical Data(BvH). BVH was developed by Biovision to represent human movement. BVH is very popular, it’s text-based, and there are a lot of devices that support importing and exporting it.
Developer Aki Miyazaki made an early attempt to import BVH data into WEBGL applications. His BVH Motion Creator is a Web-based BVH preview tool, which was originally developed based on three.js, as shown in Figure 8-11. With this tool, users can upload a BVH file and preview its animation on a simple character.
Figure 8-11: BVH Motion Creator (www.akjava.com/demo/bvhpla)…
A BVH format preview tool
Full-featured scene format
Over the years, the industry has developed several standard formats to support the representation of an entire 3D scene, including multiple models, transform hierarchies, cameras, lighting and animation, and all the things that are created in full-featured software like 3DS Max, Maya, Blender. In short, this is still a complex technical problem to be solved, and several formats survive and are widely used. That may change, however, as WebGL creates new requirements, particularly the need to reuse data across applications. In this section, we’ll look at several formats that can be used in WebGL.
1. VRML and X3D
Virtual Reality Markup Language (VRML) is the text format originally used for the 3D Web, Founded in 1994 by Inventor and theorist Mark Pesce, members of the Open Inventor software team at Silicon Graphics, and a group I was part of,VRML went through several iterations in the 1990s, Supported by the industry and the Standards Institute, a non-profit organization. Its successor format, based on XML, was developed in the early 2000s and renamed X3D. Although these formats are no longer widely used in Web applications, most modeling tools still support importing and exporting them.
VRML and X3D define complete scenes, animations (keyframes, deformations, and skins), textures, light sources, and even scripted, interactive objects with behavior. 8-4 shows the X3D syntax, which creates a scene with a red cube that, when clicked, rotates 360° around the Y-axis for 2 seconds. X3D geometry, behavior, and animation are all in an XML script that is intuitive and readable. To this day, not even an open 3D file format can do the same with such simple and elegant syntax (let me brag).
Example 8-4: for the X3D example, the red cube rotates when clicked
<? The XML version = "1.0" encoding = "utf-8"? > <! DOCTYPE X3D PUBLIC "ISO / / the Web3D / / DTD X3D / 3.0 / EN" "http://www.web3d.org/specifications/x3d-3.0.dtd" > < X3D Profile = 'Interactive' version = '3.0' XMLNS: XSD = 'http://www.w3.org/2001/XMLSchema-instance' XSD: noNamespaceSchemaLocation = 'http://www.web3d.org/specifications/x3d-3.0.xsd' > < head >... <! </head> <! <Scene> <! < <Scene> <! <Scene> <! -- XForm ROUTE: [From animation.value_changed ڟrotation] --> <Transform DEF='XForm'> <Shape> <Box/> <Appearance> <Material diffuseColor='1.0 </Appearance> </Shape> <! -- Toucher ROUTE: [from touchTimeڟ timesource.starttime] --> <TouchSensor DEF='Clicker' description='click to animate'/> <! -- TimeSource ROUTEs: [from clicker.touchtime to startTime][from fraction_changed to animation.set_fraction]--> <! -- Animation ROUTEs: [from value_changed to xform.rotation] --> < interpolator DEF='Animation' key='0.0 0.33 0.66 1.0' keyValue='0.0 0.0 0.0 0.0 0.0 2.1 0.0 0.0 0.0 4.2 0.0 0.0 0.0 0.0 0.0'/> </Transform> <ROUTE fromNode='Clicker' fromField='touchTime' toNode='TimeSource' toField='startTime'/> <ROUTE fromNode='TimeSource' fromField='fraction_changed' toNode='Animation' toField='set_fraction'/> <ROUTE fromNode='Animation' fromField='value_changed' toNode='XForm' toField='rotation'/> </Scene> </X3D>Copy the codeThe design of VRML embodies many of the key concepts of interactive 3D graphics, so: you might think it’s suitable for WebGL. However, this format was designed before both JavaScript and DOM existed, and predates many of the key hardware-accelerated features in use today.
At this point, in my humble opinion, VRML/X3D is obsolete and no longer suitable for practical use. However, it contains many ideas that can be borrowed from WebGL.
Over the years, a lot of content has emerged in VRML and X3D formats. The Fraunhofer Institute in Germany is continuing X3D research and has created X3DOM, a viewer that displays X3D content using WebGL. More information about X3DOM can be found at www.x3dom.org/.
VRML (www.web3d.org/standardsvr…
2. COLLADA: Digital resource exchange format
In the mid-2000s, when VRML was starting to look a little stale, a group of companies, including Sony Computer Entertainment, Alias System and Avid Technology, got together to develop a 3D digital resource format, Used to exchange data in games and interactive 3D applications. SONY’s Remi Arnaud and Mark C. Barnes led the development of the format, called COLLADA(COLLAborative Design Activity). After the first version of the specification and support from related companies was completed, the development of the standard was handed over to the Khronos organization. The nonprofit has also developed specifications for WebGL, OpenGL, and other graphics hardware and software apis.
COLLADA, like X3D, is an XML-based full-kinetic format that can represent an entire scene and many different types of geometry, materials, animation, and lighting. Unlike X3D, the goal of COLLADA is not to implement an end-user-oriented format that includes behavior and runtime semantics. In fact, it has no clear technical goal, but rather attempts to preserve all the information that can be exported from 3D software so that it can be used by subsequent software, or imported into the game engine and development environment, and then deployed into the final application. The main idea is that once COLLADA is widely accepted by the industry, there is no need for various DCC tool vendors to write plug-ins to export to other custom formats. As long as export to COLLADA is supported, any other software can theoretically be imported.
Example 8-5 shows part of the code for a COLLADA scenario, which we will load later in this chapter using three.js. Here, briefly, several features of the COLLADA file structure are worth mentioning. First, it is structured in the form of libraries of different types, such as images, shaders, and materials, which are first defined in XML and then referenced by other required parts (such as images used in the material definition). Second, note that it explicitly declares functions that are normally considered built-in functions, such as the Blinn shader. COLLADA makes no assumptions about shaders and rendering models, it simply stores this information and lets another tool get hold of it and act on it accordingly. Next, we find that the grid vertex data is represented as a series of elements of type FLOAT_ARRAY. Finally, by referring to the geometry and materials defined earlier (using the INSTance_Geometry, Bind_material, and Instance_Material elements in XML), these grids are assembled into a user-visible scene.
Example 8-5: The structure of a COLLADA file, including the base, geometry, and scene
<? The XML version = "1.0"? > < COLLADA XMLNS = "http://www.collada.org/2005/11/COLLADASchema" version = "1.4.1" > < asset > < contributor > <authoring_tool>CINEMA4D 12.043 COLLADA Exporter </authoring_tool> </contributor> </created> <modified> 2012-04-25t16:44:56z </modified> <unit meter="0.01" name=" right "/> <up_axis>Y_UP</up_axis> </asset> <library_images> <image id="ID5"> <init_from>tex/Buss.jpg</init_from> </image> ... <! <effect id="ID2"> <profile_COMMON> <technique sid="COMMON"> <blinn> <diffuse> <color>0.8 0.8 0.8 1</color> </specular> <color>0.2 0.2 0.2 1</color> </specular> <shininess> <float>0.5</float> </shininess> </blinn> </profile_COMMON> </effect>... <! <geometry id="ID56"> <mesh> <source id="ID57"> <float_array ID ="ID58" Count ="22812">36.2471 9.43441-6.14603 36.2471 11.6191-6.14603 36.2471 11.63441-6.04828 36.2471 11.63441-9.04828 9.43441-9.04828 33.356 11.6191-9.04828 33.356 9.43441... <! -- The rest of the grid definition -->... <! <library_visual_scenes> <visual_scene id="ID53"> <node ID ="ID55" name="Buss"> <translate </translate> <rotate SID ="rotateY">0 1 0 0</rotate> <rotate SID ="rotateX">1 0 0 0</rotate> <rotate sid="rotateZ">0 0 1 0</rotate> <scale sid="scale">1 1 1</scale> <instance_geometry url="#ID56"> <bind_material> <technique_common> <instance_material symbol="Material1" target="#ID3"> <bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/> </instance_material> </technique_common> </bind_material> </instance_geometry> </node> ... <! -- Other scene definitions -->Copy the codeAfter an initial period of high enthusiasm and wide vendor support, support for COLLADA began to wane. Since about 2010, the development of plug-ins that export this format to popular DCC tools has all but stopped. Recently, COLLADA has been revived, mainly due to the need for WebGL support — the lack of built-in text formats in WebGL (more on this later). Then the emergence of a new open source item OpenCOLLADA (www.khronos.org/collada/wik… Max and Maya after 2010 version of the export tool, can export clean and compatible COLLADA format.
While enhanced support for the COLLADA format is a great benefit to the 3D content production process, it has a problem. As we saw in the previous example, COLLADA is very verbose. This format is designed to hold more data, not for quick download and parsing. As a result, the Khronos organization began to develop a new format that retained the good features in COLLADA — the ability to fully represent rich 3D animation scenes — while taking into account Web delivery issues: glTF.
3. GlTF: a new format for WebGL, OpenGL ES and OpenGL applications
As WebGL grows in popularity, it creates a problem for Web developers to solve, which is how to export complete information from 3D DCC tools to Web applications. A single grid text format like OBJ is used to represent an object, but it does not contain the scene diagram structure, light source, camera, or animation. COLLADA is fully functional, but as we saw in the previous section, it’s verbose, and it’s in XML format, which requires a lot of CPU computation to parse and turn into a data structure that can be rendered by WebGL. We needed a compact, Web-friendly format that required minimal additional processing before rendering, similar to THE JPEG format for 3D.
In the summer of 2012, Fabrice Rohinet(MOTOROLA engineer and Chair of the Khronos COLLADA working Group) began developing a 3D format with COLLADA capabilities that was more compact than COLLADA and better suited to WebGL. Originally called COLLADA2JSON, the idea was to take the clunky XML syntax and turn it into lightweight JSON. Since then, it has started on its own path of development. Other members of the Khronos COLLADA working group joined in, including me, COLLADA creator Remi Arnaud, and Patrick Cozzi, an engineer at defense software vendor AGI. Our work went from simply converting and optimizing the COLLADA format to designing a new format from scratch for OpengL-based Web and mobile applications. So glTF(Graphics Library Transmission Format) was born.
GlTF takes the full functionality of COLLADA as a starting point, but it is a completely new format. The COLLADA feature is used as a reference to support the general graphics feature, with completely different details. GlTF uses JSON to describe scene structure and high-level information (such as cameras and light sources), and binary formats to describe detailed data such as vertices, normals, colors, and animations. GlTF’s binary format is designed to be loaded directly into WebGL’s buffers (arrays of types such as Int32Array and FloatArray). The process of loading a glTF file can be simply described as follows:
(1) Read a simple JSON wrapper file;
(2) Loading external binaries through Ajax;
(3) Create arrays of some types;
(4) Call WebGL to draw the content method to render.
Of course, this actually looks a little more complicated. But it’s much more efficient than downloading and parsing XML files and turning JavaScript Number types into arrays of types. GlTF ensures that files are small and fast to load, which are key elements in creating high-performance Web and mobile applications.
Example 8-6 shows the JSON syntax for a typical glTF scenario, known as the COLLADA duck model. Note that the syntax structure is similar to COLLADA, with the libraries appearing first and the scene diagram structure being defined at the end, where these libraries are referenced. That’s about all they have in common. GlTF eliminates unnecessary information at runtime and instead defines structures that allow WebGL and OpenGL to load quickly. GlTF defines the details of attributes (vertex positions, normal colors, texture coordinates, etc.) that are used to render objects in programmable shaders. Using these properties, the glTF application can render virtually any mesh, even if it doesn’t have a complex material system of its own.
In addition to JSON files, glTF also refers to one or more binary files (.bin) that store rich data such as mesh and animated vertex data. The data structures in these binaries are called buffers and buffer views. This way, we can stream, incremental, or load the glTF content all at once, depending on the application requirements.
Example 8-6: Example of the glTFJSON file format
{"generator": "collada2gltf 0.1.0"}, "asset": {"generator": "collada2gltf 0.1.0"}, "Attributes ": {"attributes _22": {"bufferView": "BufferView_28 ", "byteOffset": 0," stride ": 12, "stride ": 12, "count": 2399," Max ": [96.1799, 163.97, 53.9252], "min": [69.2985, 9.92937, 61.3282], "type" : "FLOAT_VEC3"},... "BufferViews ": {"bufferView_28": {"buffer": "duck.bin", "byteLength": 76768, "byteOffset": 0, "target": "ARRAY_BUFFER" }, "bufferView_29": { "buffer": "duck.bin", "byteLength": 25272, "byteOffset": 76768, "target": "ELEMENT_ARRAY_BUFFER" } }, "buffers": { "duck.bin": { "byteLength": 102040, "path": "duck.bin" } }, "cameras": {" camera_0 ": {" aspect_ratio" : 1.5, "the projection" : "perspective", "yfov" : 37.8492, "zfar:" 10000, "znear" : 1}},... Other advanced objects, like materials and lighting... Finally, the scene graph (scene graph) "nodes" : {" LOD3sp ": {" children" : [], "matrix" : [...] matrix data, "meshes" : [ "LOD3spShape-lib" ], "name": "LOD3sp" },Copy the codeAlthough glTF was designed to provide a compact and efficient data format for OpenGL, the designers made a compromise by retaining some of the essential data created by DCC tools, such as animations, cameras, and light sources. The current version of glTF(1.0) supports the following features.
L grid
A polygonal mesh consists of one or more geometric primitives. The grid is defined in a JSON file and then refers to one or more binary data files that contain vertex data.
L Materials and shaders
Materials can be represented as high-level generic structures (Blinn, Phong, Lambert), or implemented in GLSL vertex shaders and fragment shaders, referenced as external files by glTF files.
L light source
Common light source types (directional, point, spot, and ambient) can be represented as high-level structures in JSON files.
L camera
GlTF defines common camera types such as perspective cameras and orthogonal cameras.
L Scene diagram structure
The scene is represented using a hierarchical diagram with many nodes (i.e. grid, camera, and light source).
L Transformation hierarchy
Each node in the scene diagram has an associated transformation matrix. Each node can contain child nodes, which inherit the transformation information of the parent node.
L animation
GlTF defines data structures used to represent keyframe-based, skin and deformation animations.
L External media
Images and videos can be used as external files to the texture map and are referenced using urls.
The glTF project, although developed under the auspices of the Khronos organization, is fully open, allowing anyone to contribute code. There is a source repository on GitHub that contains usable viewers, examples, and the specification itself. The glTF team believes in the idea that functionality needs to be implemented in code before it is written into the specification. The team has developed four separate glTF viewers, one of which can be used in three.js (as we’ll see later). For more information, visit Khronos glTF’s home page (gltf.gl/).
4. Autodesk FBX
There is also a full-featured scenario format worth mentioning, at least in passing. FBX format is a text format owned by Autodesk. It was originally developed by Kaydara for use in MotionBuilder. After Autodesk acquired Kaydara, it began using the FBX format in several of its products. In this way, FBX became the standard for exchanging data within Autodesk products (3DS Max, Maya, and Motion Builder).
FBX is a rich format that supports many 3D and animation data types. Unlike the other formats covered in this chapter, FBX is private and fully controlled by Autodesk. Autodesk writes the documentation in this format and provides the C++ and Python SDKS to read and write FBX files. But these SDKS require product licenses, and some can be expensive. There are currently some FBX import and export tools developed without the SDK, such as Blender, but it is not clear whether such use is legal under the FBX license.
Because the format is proprietary and the license is ambiguous, it is best not to use FBX. On the other hand, it’s a very powerful technology used in the top tools of the industry, so it’s worth a look. Want to get more information, please visit the fang binxing’s home page (www.autodesk.com/products/fb.