PHYSICS SUPPORT IN WEB3D ENVIRONMENTS ANDREAS STAMOULIAS

Transcription

1 PHYSICS SUPPORT IN WEB3D ENVIRONMENTS by ANDREAS STAMOULIAS Master in Informatics and Multimedia, Department of Informatics Engineering, School of Applied Technology, Technological Educational Institute of Crete, 2014 A THESIS Submitted in partial fulfillment of the requirements for the degree MASTER OF SCIENCE DEPARTMENT OF INFORMATICS ENGINEERING SCHOOL OF APPLIED TECHNOLOGY TECHNOLOGICAL EDUCATIONAL INSTITUTE OF CRETE 2014 Approved by: Major Professor Athanasios G. Malamos

2 Copyright ANDREAS STAMOULIAS

3 Abstract Given that physics can be fundamental for realistic and interactive Web3D applications, a number of JavaScript versions of physics engines have been introduced during the past years. Also the technology for representing 3D on the web has been developing for some twenty years now, resulting in the technology named X3D. While interactive 3D content based on the aforementioned technology exists, there has not been proposed yet an implementation of physics support. This thesis presents the implementation of the rigid body physics component, as defined by the X3D specification, into the X3DOM framework, using the JavaScript version of Bullet physics simulation engine. Our work aims in enhancing the interactivity and realism in the production process of dynamic and immersive 3D real-time worlds. We briefly review the state of the art in current technologies for Web3D graphics, including HTML5, WebGL and X3D, and then explore the significance of physics engines in building realistic Web3D worlds. We include a comprehensive review of JavaScript physics engine libraries alongside a frame rate comparison between them as measured in our tests and proceed to summarize the significance of our implementation while presenting in detail the methodology followed. The results obtained so far from our cross-browser experiments demonstrate that real-time interactive scenes with hundreds of rigid bodies can be constructed and operate with acceptable frame rates, while allowing the user to maintain the scene control. Finally we have to mention that our work has been successfully merged with Fraunhofer's X3DOM master branch repository on GitHub 1 and a paper [1] outlining my work has been accepted and presented at the 19th International Conference on 3D Web Technology-Web3D in Vancouver

4 Table of Contents Copyright... 2 Abstract... 3 Table of Contents... 4 List of Figures... 6 List of Tables... 9 Acknowledgements Preface Chapter 1. INTRODUCTION Chapter 2. BACKGROUND D WEB TECHNOLOGIES X3D X3DOM HTML5 and WEBGL Physics Engines Closed Source Physics Engines Open Source Physics Engines JavaScript Physics Engines Related Work Chapter 3. THEORY BEHIND PHYSICS Rigid Body Physics Kinematics Forward Kinematics Inverse Kinematics Inverting the Jacobian Matrix Chapter 4. X3D RIGID BODY PHYSICS ARCHITECTURE Rigid Body Physics Component RigidBody node RigidBodyCollection node CollisionCollection node X3DNBodyCollidableNode abstract node type

5 4.1.5 CollidableShape node X3DRigidJointNode node BallJoint node UniversalJoint node MotorJoint node SliderJoint node SingleAxisHingeJoint node DoubleAxisHingeJoint node Parsing the X3D Scene Building the Physics Simulation World Constraining the Rigid Bodies Realism and Interactivity Chapter 5. EXPERIMENTAL EVALUATION Chapter 6. SHOWCASE Chapter 7. CURRENT RESEARCH AND FUTURE WORK Chapter 8. CONCLUSIONS References

6 List of Figures Figure 1. XML encoded X3D world into an XHTML page with the usage of the X3D namespace prefix Figure 2. The same X3D scene as proposed by X3DOM Figure 3. The USE and id attributes proposed by X3DOM Figure 4. A JavaScript physics engine comparison in respect to their fps rate Figure 5. The cases of normal force (N) Figure 6. Example of joint system and the end effector Figure 7. The Jacobian method algorithm of solving IK problems Figure 8. X3D Rigid Body Physics architecture Figure 9. X3D Rigid Body Physics component diagram Figure 10. The X3D BallJoint constraint type Figure 11. The X3D UniversalJoint constraint type Figure 12. The X3D MotorJoint constraint type Figure 13. The X3D SliderJoint constraint type Figure 14. The X3D SingleAxisHingeJoint constraint type Figure 15. The X3D DoubleAxisHingeJoint constraint type Figure 16. The two classes constructed in order to store, control and bind the X3D elements with Bullet API Figure 17. A component diagram that shows the connection between the X3D Rigid Body Component elements Figure 18. The initialization of the physics simulation world Figure 19. The btboxshape class inheritance diagram Figure 20. The btsphereshape class inheritance diagram Figure 21. The btconeshape class inheritance diagram Figure 22. The btcylindershape class inheritance diagram Figure 23. The btconvexhullshape class inheritance diagram Figure 24. The btcompoundshape class inheritance diagram Figure 25. The inheritance diagram of Bullet s rigid body constraining methods Figure 26. An example of the X3D BallJoint element

7 Figure 27. An example of the X3D UniversalJoint element Figure 28. An example of the X3D SingleAxisHingeJoint element Figure 29. An example of the X3D DoubleAxisHingeJoint element Figure 30. An example of the X3D MotorJoint element Figure 31. An example of the X3D SliderJoint element Figure 32. Dynamically creating moveable objects and attaching them event listeners Figure 33. The Update function responsible for the movement of rigid bodies Figure 34. The first example: a scene of a pendulum system created using BallJoints Figure 35. The second example: a scene of two colliding convex hull rigid bodies constrained using the BallJoint and MotorJoint joint type Figure 36. A cross-browser X3D scene loading time comparison in HTML and XHTML cases. 93 Figure 37. A cross-browser X3DOM frame rate comparison in HTML and XHTML cases.. 94 Figure 38. The third example: a motor joint constrained sphere interacting with free rigid bodies dynamically created in real-time Figure 39. A cross-browser line chart showing the frames per second in respect to the number of rigid bodies Figure 40. A cross-browser column chart showing the frames per second display rate in cases of 10, 50, 100, 200 and 500 rigid bodies Figure 41. The fourth example: dynamic real-time creation of constrained rigid bodies using single axis hinge joint Figure 42. A cross-browser line chart showing X3DOM s frame rate in respect to the number of joints Figure 43. A cross-browser line chart showing Ammo s frame rate in respect to the number of joints. 98 Figure 44. Physics and render frame rate comparison in Chrome browser in cases of 50, 100, 200, 500 and 1000 joints Figure 45. A complex scene with multiple rigid bodies, static colliders, forces and joints Figure 46. A system of a MotorJoint with a torque that acts upon four rigid bodies constrained using BallJoints

8 Figure 47. A complex scene of two rigid bodies constrained together using the UniversalJoint that have their initial velocity forces them to travel over a wall of inactive rigid bodies Figure 48. A chain of rigid bodies created using the SingleAxisHingeJoint constraint Figure 49. An X3D(OM) Particle System based on our current work. Particles are being rendered using the X3D PointSet node rendering component Figure 50. An X3D(OM) Particle System based on our current work. Particles are being rendered using basic X3D shapes. In example (a) we use boxes while in (b) we use spheres

9 List of Tables Table 1. A JavaScript physics engines comparison table in respect to constraint types Table 2. A JavaScript physics engines comparison table in respect to geometry shape types. 26 Table 3. The X3D CollidableShape node class structure Table 4. The X3D RigidBody node class structure Table 5. The X3D RigidBodyCollection node class structure Table 6. The X3D CollisionCollection node class structure Table 7. X3D X3DNBodyCollidableNode abstract node class structure Table 8. X3D CollidableShape node class structure Table 9. The X3D X3DrigidJointNode node class structure Table 10. The X3D BallJoint node class structure Table 11. The X3D UniversalJoint node class structure Table 12. The X3D MotorJoint node class structure Table 13. The X3D SliderJoint node class structure Table 14. The X3D SingleAxisHingeJoint node class structure Table 15. The X3D DoubleAxisHingeJoint node class structure Table 16. The Bullet's btboxshape constructor Table 17. The Bullet's btconvexhullshape constructor Table 18. The btconvexhullshape's addpoint function constructor Table 19. The Bullet's btpoint2pointcontraint constructor Table 20. The Bullet's btuniversalcontraint constructor Table 21. The Bullet's bthingeconstraint first constructor Table 22. The Bullet's bthingeconstraint second constructor Table 23. The Bullet's btgeneric6dofspringconstraint constructor Table 24. The angular limit ranges of Bullet's btgeneric6dofspringconstraint Table 25. The Bullet's btsliderconstraint constructor Table 26. The btdiscretedynamicsworld stepsimulation constructor

10 Acknowledgements I would like to express my gratitude to my supervisor Professor Dr. Athanasios G. Malamos for introducing me to the topic, his comments and the guidance throughout the development process of this master thesis. Furthermore I would like to thank Professor Dr. Don Brutzman 2 for introducing me to Web3D archive 3 and the RigidBodyPhysics examples, which helped me familiarize with the X3D "RigidBodyPhysics" component syntax and hierarchy and for his help and comments on the subject. I would like also to thank my co-workers at Multimedia Content Lab and my friends for their sincere comments and suggestions in my work. Finally a special thanks to my family that supported me all those years of my studies

11 Preface This report is my master thesis for the conclusion of my Master program in Informatics and Multimedia at the Department of Informatics Engineering, School of Technological Applications, Technological Educational Institute of Crete. My work is original and some of the code explained through the chapters has been published by me at GitHub as it has been successfully merged with Fraunhofer's X3DOM master branch repository. Also some of the text of this master thesis is taken directly from a paper [1], which I am author and has been presented at the 19th International Conference on 3D Web Technology. 11

12 Chapter 1. INTRODUCTION The ability to render 3D content in real-time on the web seemed the next step since the first 2D multimedia contents introduced in HTML pages. All started in 1995, when HyperText Markup Language (HTML) [2] inspired and proposed a 3D visualization technology of a text based metalanguage, the so-called Virtual Reality Modeling Language (VRML), for the representation of 3D scenes for the web. Two years later, back in 1997, a newer version of VRML, the so-called VRML97 [3] (also known as VRML 2.0) became the first ISO standard for representing 3D interactive vector graphics for the web. VRML is a text file format that describes 3D geometrical shapes, by defining vertices and edges along with additional information, that of color and texture. VRML technology could also create and define animations, sound and lighting, that can be triggered by external events and timers via Java or ECMA-Script functions defined in a script node of the VRML file. VRML was accepted with much interest by the end users but also accepted by many companies that either implemented the WRL extension into their 3D modeling programs, in order to import/export/save to that specific file format or contributed to the VRML standard by improving its quality level. Since then and for the last 20 years there have been developed various solutions, most of them disappeared over time, that either followed the traditional plugin based method or a method of a direct integration of the rendering system into the browser s architecture. Back then it was required to install a platform specific plug-in for the rendering of the scene, such as, Flash, Silverlight, ShockWave and Quicktime, but then X3D/X3DOM changed the way of implementing interactive3d scenes on the web. X3D [4] is an ISO standard XML-based file format and a technology with multiple functionalities, developed by the Web3D Consortium, for the representation of 3D interactive worlds via a plug-in system. The X3D technology is already been proposed by the HTML5 [5] specification as the technology for declarative 3D scenes on the web. X3D offers the ability to render the scene using the Flash plug-in as the backend renderer. The time X3D developed there was not any plug-in free backend renderer, but some years later some 3D experiments based on HTML canvas element lead to the Web Graphics Library (WebGL) [6], a JavaScript API for rendering interactive 2D/3D graphics on the web page canvas via the GPU accelerated usage of image processing and effects without the need of an plug-in. The mixing of the WebGL and X3D technologies was presented as X3DOM [7], the technology that provides a client side rendering of a 3D virtual world with no external plug-in requirement. The X3DOM framework comprises the X3D API and the WebGL techniques to display a dynamic and interactive 3D environment on a simple web page. Furthermore the X3D Physics component provides the ability to add a subset of the laws of physics, known as rigid body in order to influence the elements of a 3D scene, a procedure that solves many different factors in parallel, typically through the use of different equations. 12

13 Currently X3DOM is using camera movement and animated objects using the ROUTE node element in order to create a dynamic scene that is not seen as static. With our implementation of the rigid body physics laws into the X3DOM s core, we aim in the creation of highly realistic simulations and interactive real-time 3D applications and games based on X3D technology and in enhancing that realism and interactivity by creating and enabling new mechanisms and interactions between objects. In this postgraduate master thesis we present a rigid body physics support implementation in X3DOM. 13

14 Chapter 2. BACKGROUND 2.1 3D WEB TECHNOLOGIES Authoring tools such as Director that supported 3D graphics natively made it possible to embed 3D content on the web via Shockwave and Flash plugins. But as their implementation was based on 2D vector shapes, was not accepted as a proper solution for 3D scenes on the web, as it could not support complex 3D objects. Flash technology of fake 3D, later lead to projects like PaperVision3D [8] which even with their very impressive results did not manage to earn the users interest in long term, as it was not able to support complex 3D shapes and visual effects. Following that same technology, other companies like Microsoft tried to develop a web plugin that would enable the developers to create a rich multimedia environment using vector graphics, animations and even fake 3D objects by a perspective transformation of 2D content. Later another graphics API for interactive 3D web applications was presented by Google, namely O3D [9]. O3D is an open source JavaScript API started in 2009 as a framework for use in the development process of games, advertisements, simulations, engineering applications and massive online virtual worlds. O3D is composed of two layers, the lower level implemented in C/C++ that provides a geometry and shader abstraction using WebGL or DirectX and the higher level API implemented in JavaScript, which provides the scene-graph API. O3D is similar to the current standard X3D, in respect to the scene-graph model, but it does not provide a declarative way of defining its contents and all its scene s content building process should be performed using JavaScript. Finally in 2009 an XML-based Markup Language was introduced namely 3DMLW [10], for the representation of interactive 2D/3D content on the web. 3DMLW is developed by 3D Technologies R&D in order to provide a fast and powerful tool for creating rich, intuitive visual applications. The 3DMLW platform consists of an open source software suite, with its own scripting language, a renderer based on standard OpenGL [11] for cross-platform compatibility, a plugin interface for managing input/output events and a server toolset that provides an automatic conversion process of 3D models and textures of several file formats to the 3DMLW format. 2.2 X3D The X3D is an ISO standard XML-based file format for representing 3D computer graphics, first approved by the ISO in Its initial efforts started by the Web3D Consortium, who designed the language based on the successor to the VRML. X3D was developed as a royalty-free specification for broad 3D graphics, with multiple levels of functionalities, that defines various data-encoding formats, but would still maintain a compatibility with predecessor technology. There are three ISO documents that compose the X3D specification, namely Abstract 14

15 Functionality [12], Encodings [13], [14], [15] and Language Bindings [16], [17]. The first document defines the architecture and abstract definitions of all X3D components alongside the abstract API of X3D. The second defines the three different types of file encoding, namely XML, classic VRML and Binary, while the third document defines the X3D language API bindings, which is separated in ECMA-Script API to Scene Access Interface (SAI) and Java API to SAI. X3D is being used for a variety of purposes by the 3D community, from simple use cases to complex applications, as it supports multi-texture render, real-time reflection and lighting, shaders with texture, normalmap, lightmap, movietexture and a deferred rendering architecture. Also it supports animation, and interchangeable humanoid animation (H-Anim), geospatial position and the IEEE Distributed Interactive Simulation (DIS) network protocol. The functionalities provided by the low level rendering engines of OpenGL and DirectX provides cross-platform interoperability in X3D visual functionalities, such as rendering, texturing and modeling. The geometric modeling functionalities in X3D are composed of geometric primitives like box, sphere, cylinder and cone, but it also supports a triangle-definition node for the representation of an object and even more complex geometric nodes like elevation grid and nonuniform rational basis spline (NURBS) nodes, that represent curves and surfaces. X3D describe nodes that capture the user's events from standard input interface devices like keyboard and mouse and interactivity with objects can be enhanced with simple animations using linear interpolators that control the objects position and rotation, but also with complex animations using SAI functionalities either using ECMAScript or Java. X3D was created in order to deliver a lightweight and balanced web based application. With that in mind and in order to achieve it, Web3D Consortium introduced a profile system that is being used for the specification of the components used in an X3D world. That X3D's component based architecture is composed of several profiles including Core, Interchange, Interactive, Immersive, Full, MPEG-4 Interactive, CDF (CAD Distillation Format) and Medical-Interchange. Each profile declares the required functions that will be needed in the development and rendering process of the X3D world, which in their turn controls the component used, which includes nodes in various levels. That architecture can lead in advancements as the development of one area doesn t affect or slow the other. Furthermore authors can extend the X3D using a prototyping mechanism that allows them to create and describe new prototype nodes or re-use and alter previously defined ones, by introducing new features that support a new technology. X3D has already been proposed in the HTML5 specification as the technology for declarative 3D scenes, meaning that is already defined how these X3D data should be included into the DOM. However HTML5 does not define the structure of the DOM integration or the scene graph accessing methods. Nowadays there are 3D software packages [18], game engines with browser plugins [19] and 3D web rendering APIs [20] just like X3D that can cooperate with the browser and create a rich media environment. But most of the plugin based systems suffer from two major drawbacks. First these systems manage the interaction, communication and rendering internally, which means that developers have to deal with the synchronization between the 15

16 Document Objet Model (DOM) and the plugin, alongside with the familiarization process with the program s API. Secondly because it s a plugin system, an installation process will be needed by the end user, a process that may introduces security and incompatibility issues. 2.3 X3DOM Figure 1. XML encoded X3D world into an XHTML page with the usage of the X3D namespace prefix. Based on the above technologies of X3D and HTML5, a new integration model was proposed, named X3DOM (pronounced X-Freedom). X3DOM can be described as the product of the discussions in both Web3D and W3C communities, for the development of a JavaScript based interface for X3D. That integration model was developed by Fraunhofer research organization, a Web3D Consortium member, as an experimental open source framework and client side rendering API with no external plug-in requirement, based on the HTML5 specification for declarative 3D content using the X3D elements as part of the HTML5 DOM tree. The X3D elements were directly integrated as DOM elements and all the scene manipulations were done using DOM based scripting interfaces. The main goal of X3DOM is to support HTML5 content that includes X3D data inside the browser s DOM tree in a separate namespace. For this purpose X3DOM proposed the removal of the X3D prefix from all the nodes that belongs to the X3D world. The following X3D examples [21] demonstrate an XML encoded X3D world into an XHTML with the usage of the X3D prefix (Figure 1) and how the same X3D scene could look like without it as proposed by the X3DOM (Figure 2). 16

17 Figure 2. The same X3D scene as proposed by X3DOM. Throughout their improvements, Fraunhofer proposed a common event model for the two standards XHTML and X3D, as they had already defined different event models for common events based on their application domains. Based on that common event model one of the changes and improvements, proposed by the X3DOM was the integration of the id attribute that is being used by the XHTML profile for defining elements in the DOM the same way the X3D's DEF attribute defines nodes. The proposed attribute is not aiming in replacing the DEF attribute but rather be an alternative/supplementary solution. Additionally X3DOM proposed the introduction of a new attribute namely USE, that could enable the re-usability of a node and create a multi-parent relationship within the XHTML tree as it was defined in an X3D tree (Figure 3). In Figure 3, we can see the aforementioned id and USE attributes that were introduced by X3DOM into the X3D. The id attribute is being used by X3DOM the same way it handles the DEF attribute. Retrieving the element that is defined by an id, can be performed using the document.getelementbyid( id name ) method, similar to the document.getelementsbytagname( DEF name ) method for retrieving an element using its DEF attribute. At the same example we can observe a second transform element, inside the X3D scene, use the aforementioned USE attribute. That USE attribute right there is what X3DOM proposed in order to create a clone of an element defined by the same DEF name somewhere earlier in the scene. In our example scene the shape defined within the first transform element is being cloned and rerendered for a second time inside the canvas in its new position defined by the translation attribute. The USE attribute can be used in most X3D elements, a procedure that can simplify the scene construction process and improve the performance. 17

18 Figure 3. The USE and id attributes proposed by X3DOM. Also X3DOM s architecture was developed as a connector between the browser frontends and the X3D backend. That connector is responsible for monitoring DOM updates and the synchronization between the two technologies, by creating a DOM/X3D adapter that can support different frontends and backends. Alongside the connector, the X3DOM architecture is composed of the User Agent, which is responsible for composing the final rendering output but also provides the methods for accessing the multimedia content and holds the DOM tree. The final part that completes the X3DOM s architecture is that of the X3D runtime, which is responsible for updating and rendering the scene and handles user interaction like navigation and picking. X3DOM is able to support multiple X3D runtimes, one for every different backend described in the fall-back model. The framework is able to detect what backend is needed by checking the requested profile. The X3DOM implementation supports the X3D/SAI plugins and the WebGL as backend, but may fall-back to Flash in cases of browser incompatibilities. Using WebGL backend renderer the 3D content is instantiated inside the HTML canvas element, via a JavaScript request to the OpenGL context using the gl = canvas.getcontext( webgl ). In X3DOM the backend does not collect the objects to render by traversing the DOM elements directly, but rather construct a scene-graph hierarchy of the X3D nodes, in order to achieve both flexibility and performance. That extra scene-graph is flexible enough as it parse the X3D elements using the X3DOM.fileds math library that comes handy for development purposes, but also is less performance costly as it only updates the initial values and synchronizes only when DOM mutation events occur, a methodology faster than the per-frame element DOM-tree parsing that should had followed in an alternative solution case. That mapping between DOM and X3D nodes is not an one to one connection as one could think, but in many cases an X3D node can link to multiple DOM nodes, using the USE/DEF attribute, a case that is never applied 18

19 for DOM, as every DOM node always links to one X3D node. The X3D scene is first rendered on load and then re-rendered on scene changes either when an interpolator is used or an external script is changing the scene. The rendering process is a resource costly procedure as it enables and instructs the backend renderer to collect all the Shape objects that has geometry and appearance, calculate their position using their Transform grouping nodes and then using the viewport direction sort them back to front. WebGL shaders then calculate each pixel s color based on depth, shadow, transparency, occlusion, lighting and camera angle in order to produce the final image. X3DOM's efforts are being focused in a tight integration of X3D and HTML5 technologies and so far their architecture and implementation have been successfully been accepted by both the Web3D and W3C communities. Their goal is to fulfil the HTML5 promise for 3D everywhere and for everyone by creating an equivalent to the SVG success in 2D graphics for the X3D. 2.4 HTML5 and WEBGL Currently the only backend renderer that does not require a plugin is that of WebGL. WebGL is a 2D rendering API designed as a drawing/rendering context of the HTML Canvas element that provides rendering functionalities similar to OpenGL ES 2.0 [22] by giving access to the hardware accelerated graphics GPU via JavaScript. WebGL started and first demonstrated in 2006 as 3D experiments on Canvas element by Vladimir Vukićević at Mozilla. A year later both Mozilla and Opera had already implemented their own separate WebGL solutions within their browsers, while others like Apple and Google supported this effort from the start. This novel variation of OpenGL modified for browser compatibility and wrapped for the web is designed and maintained by the non-profit technology consortium Khronos Group since 2009.The first specification was released in March 2011 and currently started the development of the specification of WebGL 2 based on the OpenGL ES 3.0 [23]. The current stable release of WebGL is based on OpenGL ES 2.0, which is a Shader-based OpenGL dialect that was designed and developed for portable devices such as Smartphone and tablets that have graphics chips less powerful than the ones used by desktop computers. The ability to render 3D content in a HTML canvas element using WebGL is enabled via the WebGL Rendering Context which provides its own special properties and methods for the interaction and manipulation of the content. WebGL make use of the HTML Canvas, as it provides a destination for programmatic rendering in web pages, which allows the use of different rendering APIs for this task. Canvas specification comes only with the CanvasRenderingContent2D Interface which defines a 2D drawing context for the HTML canvas element that enables the user to draw and manipulate graphics with the provided methods and properties. 19

20 The WebGL in its core is composed of scripts known as shaders, which work together for the visual representation of the 3D content on user s screen. These scripts are being separated in two categories, namely Vertex Shader (VS), and Fragment Shader (FS). The VS is responsible for the vertex coordinate transformations and the final vertex position, an operation that may include per-vertex projection matrix calculations, normal vector and texture coordinate generation and transformation, lighting and color calculations. The VS minimum task is to set the gl position of the object, which passes into GPU and stored internally in order to be passed afterwards at the FS. Actually the two shaders, VS and FS, work together for the final render but if needed the values passed from the VS can be overridden. FS is responsible for the final color of each pixel, but can optionally perform texture lookups and discard fragments, in cases of obscured objects from another object in the scene, an operation that takes into consideration the viewport dimensions and the projection matrix. Since WebGL technology is based on OpenGL ES 2.0, the OpenGL graphics rendering API for 2D/3D hardware accelerated via GPU graphics for embedded systems like Smartphones, tablets and game consoles, mobile browsers started to support WebGL capabilities. Browsers for portable devices like Firefox, Internet Explorer, Google Chrome, and Opera Mobile already support this technology in some devices, as WebGL availability is dependent on their hardware and especially the GPU. Since WebGL became available for mobiles and tablets, more and more interactive, multimedia-heavy, web-based applications start to developed. Such multimedia applications are possible today but still evolve as technology emerges, rendering APIs are being developed, and hardware in portable devices are getting better. Khronos Group continue this technological evolution and since 2013 they are under development of the WebGL 2 specification [24] that is based on the OpenGL ES 3.0 API that allows additional rendering functionalities. The WebGL 2 is an extension of the WebGL 1 and compatible with it, which mean that all the existing content will run in WebGL 2 without any modifications, but in order to access the new functionalities provided the new WebGL2RenderingContexthas to be explicitly requested by the content. 2.5 Physics Engines As a physics engine we describe any software system for simulating physical phenomena used in the domains of graphics, video games, in film industry and for scientific purposes. This computer software provides an approximate simulation of certain physical systems, like the rigid body dynamics which manages bodies as solid, soft body dynamics which manages deformable physical bodies, and fluid dynamics. There are generally two classes of physics engines: realtime and high-precision. Real-time physics engines use simplified calculations, which decrease in accuracy in order to respond in the appropriate frame rate of the video game and in other forms of interactive computing. High-precision physics engines are usually used by scientists 20

21 and computer animation studios for difficult or critical physics calculations, but require more processing power and completion time than the real-time physics engines. The main task of all physics engines is to solve the forward dynamics problem. There are a number of factors that influence the characteristics of a physics engine, that range from the simulation paradigm, collision detection algorithms, collision dispatcher, memory pool size, multiple simulation sub-steps and error correction. As a result each physics engine will provide quite different results despite stimulating the exact same system. An evaluation of real-time physics engines can be found in [25], [26]. Real-time physics engines come in various license formats. Some 3D physics engine like Bullet [27], Open Dynamics Engine [28], Newton Dynamics [29] and Tokamak [30] are open source, while others like Havok [31] and PhysX [32] are closed source with limited free distribution. For web purposes, JavaScript physics simulation engines have begun to develop. We compared all the available JavaScript physics engines and the JavaScript ported version of the above C/C++ open source physics libraries in order to end up in the most suitable for our implementation purposes Closed Source Physics Engines One of the most renowned physics engine named PhysX, is currently owned by Nvidia. PhysX is a closed source real-time physics engine middleware SDK, which was developed by Ageia in The PhysX SDK provides to developers all the appropriate tools of handling the complex physics interactions. PhysX physics engine is used by big game engine companies like Unreal Engine, Unity, Gamebryo, Torque, Panda3D and Vision. PhysX take gaming to new level delivering rich, immersive physical environments via realistic explosions with dust and collateral debris, soft body simulations for clothing, dense smoke and complex jointed geometries simulations. To do all the above Ageia has developed a dedicated hardware accelerator that enables enhanced physics in PC games. The PhysX SDK is provided to developers for free for both commercial and non-commercial use on Windows and for free for educational and noncommercial use for Linux, OSX and Android platforms. Also PhysX engine and SDK are available for gaming console likes PlayStation 3, Xbox 360 and Wii. Another well-known 3D physics engine is that of Havok middleware software suite, that in their product line includes not only a physics engine, but dedicated tools for AI, animation and behaviour, such as the Havok Animation Studio, the Havok Cloth tool, the Havok Destruction tool, the Havok AI tool, the Havok Script tool and the Havok Vision Engine. Havok Physics is a cross-platform, closed source physics engine developed by the Irish company Havok. Havok engine supports real-time collision and dynamics between rigid bodies and provides multiple 21

22 ways of constraining them. Havok has an optimized physics library and tools that allows the creation of realistic virtual via dynamic character creation, efficient path finding of dynamic game environments, an optimized cloth simulation and a high quality and performance rendering system. In 2008 was honoured for pioneering physics engines which make games more realistic by the Academy of Television, Arts & Science. Havok tools are being used by the best known publishers and development studios, like Microsoft Games Studios, Sony Computer Entertainment, EA Games, Activision Blizzard, Warner Bros, Nintendo and Ubisoft, while is being used in big game franchises and movies Open Source Physics Engines Bullet is a 3D open source physics engine, developed by Erwin Coumans while he was at Sony Computer Entertainment (currently joined Google to work on the robotic projects), that supports collision and detection of rigid body dynamics and soft-body dynamics. Bullet engine is supported on numerous platforms, such as Sony PlayStation 3, Xbox 360, iphone, and Wii. It includes operating system support for Windows, Linux, and Mac OS, as well as a number of optimizations targeted for the Cell Synergistic Processing Unit in PlayStation 3 and the OpenCL framework on the PC. Bullet is a production physics engine that has wide support both in games and in movies. Bullet physics engine support rigid body simulation with discrete or continuous collision detection, and soft body simulations such as cloth and other deformable objects. Bullet Physics 3 [33] is under development right now and it includes a rich API and SDK. Essentially the Bullet engine is used in this thesis work since it is the basis for the Ammo.js codebase. Open Dynamics Engine (ODE) is a C/C++, platform independent, open source physics engine, developed by Russell Smith since 2001 and is separated into two main components, namely rigid body dynamics simulation engine and collision detection engine. Both engines are licensed under the BSD license and the LGPL license. The ODE handles simulation of rigid bodies and their dynamic interactions in 3D space and supports several geometries like, box, sphere, capsule (cylinder capped with hemispheres), triangle mesh, cylinder and heightmap. Also, it includes a graphical API called drawstuff, for the representation of the physics objects, but it is not tied to any particular graphical 3D library. Furthermore ODE is well documented and is already been used in a number of known games and in robotics applications. Newton Dynamics is an open source and cross-platform 3D physics simulation library developed by Julio Jerez. This physics engine provides scene management, collision detection, dynamic object behaviour and comes with official ports for most operating systems like Windows, Mac and Linux. Newton Dynamics solver has the stability and speed of the traditional LCP or iterative methods, but it is actually deterministic, a feature that makes it a good choice equally for game development and real-time applications. Its SDK license allows developers to freely incorporate the engine into personal projects or commercial products as long as credit is given 22

23 and the engine is distributed solely as part of a compiled software program that is itself not a physics engine. Newton Dynamics 3.x is available for download via GitHub and comes with a small, fast, stable and easy to use API. Currently there is an on-going development that support and take advantage of multi-core CPUs and GPUs. The Tokamak Game Physics SDK is an open source physics engine since May 2007 under a BSD License. Tokamak has implemented a unique iterative method for solving constraints that allows developers to make trade-offs between accuracy and speed and supports a variety of constraining methods and a realistic friction model. Tokamak provides collision detection for primitive shapes like box, sphere and capsule, for combinations of those primitives, and for arbitrary static triangle meshes. Also Tokamak is optimized for handling large numbers of physics objects and provides a lightweight particle system, both equally needed in game development. Finally it supports a "Breakage Constructing models", a feature that handles collision between objects in order to break them and spawn their fragments realistically JavaScript Physics Engines The most popular JavaScript physics library for the web is Ammo.js [34]. Ammo.js is a direct port of Bullet, a real-time physics simulation engine that supports rigid body and soft-body dynamics and collision detection in 3D space. As a production physics engine, Bullet has wide support both in games and in movies and includes a rich and explanatory API and an SDK. Bullet port to JavaScript named Ammo.js is performed using Emscripten [35], a LLVM bitcode generated from C/C++ to JavaScript compiler that can produce a compiled JavaScript version ready to run on the web. Due to the automatic compiling process, Ammo.js is considered to be not optimized enough for the web, but other than that is a very feature rich physics engine supporting rigid body and soft body dynamics, various types of solvers, continuous collision detection, basic primitive and complex shapes and multiple constraining methods. The build-in shapes that are being supported within Ammo.js, are capable of describing any primitive mesh like sphere and box, but also provide convex shape type constructors for complex geometries. Constraints are responsible for the binding of the objects to a world position or relative to each other in duplets. Each type of constraint has its own configurable settings for the constrained rigid bodies, their degree of freedom and the type of movement the objects would be able to perform. As for collision detection, Ammo.js unlike any other library does not support collision events, but it contains a contact manifold list with these events that can be accessed via the physics simulation world in order to search for collidable objects and retrieve their point of contact. Also Ammo.js comes with methods to find all the rigid bodies and constraints in the world, from where we can keep track of the position, rotation, velocity and many more. Ammo.js as a direct port of Bullet engine does not come with a different API and because some 23

24 knowledge of Bullet s library class structure is needed using Ammo, Bullet s API even if it is not well-documented in all areas can cover most of the capabilities Ammo.js can offer. One more JavaScript physics library is JiglibJS2.js [36], a port of yet another C++ library named JiglibFlash. JiglibJS2.js code is automatically generated from the AS3, but with many handmade tweaks and optimizations for the web. Also unlike Ammo.js where there is only one file to import in a page, here there are separate file for each class. This customizations gives JiglibJS2.js better performance and memory usage compared to Ammo.js, although lack in missing functionalities like constraints. Another JavaScript physics library is Cannon.js [37], which is inspired by Ammo.js and Three.js. Cannon.js is written by Stefan Hedman and is described as a lightweight 3D physics engine for the web. Cannon.js supports rigid body simulation with primitive shapes and custom convex polygons, constraints like point-to-point, motor and hinge joints but is still under development. Lastly there is one more JavaScript physics library, named Physijs.js [38], which is based on Ammo.js and Three.js (it was introduced as a plugin for the Three.js library). This JavaScript is built on top of Ammo.js and runs the physics simulation separately via a web worker, in order to avoid impacting in the rendering time and also uses the Three.js methods for math-related operations, object description and scene construction. So Physijs.js cannot be used as a separate physics library (as it is not one) but only in conjunction with Ammo.js and Three.js. In order to compare and have a deeper, better understanding of the complexity introduced, the similarities and dissimilarities of the aforementioned JavaScript physics engines namely, Ammo.js, Cannon.js, JigLib.js and Physi.js, we implemented a subset of their methods within X3DOM and then created a scene of a pendulum system and measured the frame rate of the scene. The results obtained are illustrated in the following figure (Figure 4). As we can observe Ammo.js has the best overall performance, an expected result as it is the base for the most of the rest physics engines. Cannon.js seems to have a performance close to Ammo.js, as it is designed and written based on Ammo.js but for the web. Physi.js seems to be slowing down the simulation of the scene as it is based in three.js for the description of the scene s object and add unnecessary complexity and furthermore the web worker implementation seems to add a sufficient delay in simulation. Finally jiglib.js was ranked third in our simulations, but the simulation step was lower than the rest of the physics engines and the simulation of the rigid bodies seemed to be slow, as faster steps introduced problems with the constraints and the overall simulation. 24

25 Figure 4. A JavaScript physics engine comparison in respect to their fps rate. Constraint Types JavaScript Physics Engines Ammo.js Cannon.js Physi.js JigLib.js Cone Twist Constraint YES NO YES NO Gear Constraint YES YES NO NO Generic 6Dof Constraint YES NO YES NO Hinge Constraint YES YES YES YES Point to Point Constraint YES YES YES YES Slider Constraint YES YES YES YES Universal Constraint YES NO NO NO Table 1. A JavaScript physics engines comparison table in respect to constraint types 25

26 Geometry Shape Types JavaScript Physics Engines Ammo.js Cannon.js Physi.js JigLib.js Box Geometry YES YES YES YES Sphere Geometry YES YES YES YES Cylinder Geometry YES YES YES NO Plane Geometry YES YES YES YES Capsule Geometry YES NO YES YES Cone Geometry YES NO YES NO Convex Geometry YES NO YES NO Concave Geometry YES NO YES NO Table 2. A JavaScript physics engines comparison table in respect to geometry shape types Based on the above, we can conclude that Ammo.js is the best choice so far for our implementation, as Cannon.js and Physijs.js are based on either the actual Ammo.js or its features and class structure for their development, while JigLibJS2.js is based on JiglibFlash but lack in functionalities like constraints compared to Ammo.js. Furthermore the evaluation of open source real-time physics engines, as presented in [25], shows that in its original C++ implementation, Bullet simulation engine is found to be one of the best performing engine overall. Also in [26], was presented a more recent evaluation and comparison of JavaScriptbased physics engines that is limited between Cannon.js and Bullet.js (an older attempt to port Bullet to JavaScript) and shows that Cannon.js may be faster than Bullet.js but less accurate. Ammo.js even if is a non-trivial physics simulation engine, nor well documented, stands out as a complete and powerful physics engine, that supports most of the features any other real-time physics engines comes with. Finally Ammo.js offers a vast amount of features that can be used in a future work, either as an extension of my current implementation or as a new component of the X3DOM framework. 2.6 Related Work Recently there was developed and released by Richard Cabello Three.js [39], a lightweight JavaScript library/api that can be used to create and visually render animated 3D graphics on a HTML5 canvas element, SVG or WebGL. It is a plugin free library thanks to WebGL, which supports various lighting techniques, shaders using OpenGL shading language, basic or user 26

27 defined geometry and 3D math functions. Three.js is presented as a very low level of complexity library even for a beginner graphic creator. In physics, Three.js is supporting some primitive library. However, one can achieve an even more realistic and interactive results combining Three.js with Ammo.js, even though this combination is not supported officially. Another example of Ammo.js usage in a WebGL visual engine is that of CubicVR.js [40]. CubicVR.js is a lightweight and high-performance JavaScript library/api, port of CubicVR 3D Engine developed by Charles J. Cliffe, with a collection of built-in features for the production of high quality real-time 3D graphics. Furthermore another JavaScript HTML5 extension for the development of 3D web applications, named XML3D [41], was developed based on the WebGL rendering API and W3C standards like DOM and CSS. The aim of this open source library/api is to create a plug-in free and seamless integration of 3D content into the web. XML3D data structure is based on the DOM, while the DOM events handles the mouse and touch events as defined by the DOM events specification. In [42] was presented their effort on creating interactive 3D scenes through the implementation of physics simulations. In order to achieve that, they developed a declarative physics annotation framework as a plugin for the browsers that linked the physics properties with the 3D scene s objects. Finally there was developed and released by David Catuhe a JavaScript 3D engine named Babylon.js [43] as a complete JavaScript framework for building 3D games for with HTML5 and WebGL. Babylon.js supports physics via the Cannon.js physics engine which is a hand-written version of Ammo.js. With Babylon.js one can create a complete scene, with lights, cameras, materials and meshes. Also supports an animation engine, a particle system, height maps, mesh cloning, and camera post process effects, rendering layers, video textures and many more. Babylon.js is currently under development but there are a lot of features already added. All the above mention 3D graphic engines and many more like them that seems to rapidly develop have been created based on current standards and innovating technologies for the enrichment of the 3D visually realistic and interactive applications capabilities accessible within the web. All these libraries provide similar functionalities and their visual output is somehow the same as it all comes down to WebGL scripts. The main difference of X3DOM in relation to the most of the above engines is that in case of X3DOM the application or game developer uses a higher level XML-based language in the creation process, while in other the developer has to be familiar enough with WebGL functionalities and methods. While most of the rendering APIs are based on WebGL, there are several cases of browsers that haven t yet supported this technology, like Internet Explorer and Safari. In order to tackle that, X3DOM supports Flash as an alternative backend renderer that can be used in those cases. 27

28 Chapter 3. THEORY BEHIND PHYSICS X3D Rigid Body Physics component was proposed as a custom extension of Xj3D [44] back some ten years ago. Xj3D is a Java project focused on creating a toolkit for VRML97 and X3D content, which over time used as one of the testing grounds for the verification of the X3D specification. The proposed X3D component provided the ability to influence the visual output of the scene graph according to a subset of the laws of physics named rigid body. An object as a rigid body is represented by a mass, a density model, a world space position and orientation, both linear and angular velocities and various other forces applied upon it. In this chapter we analyse the theory of physics behind this implementation, as it is not a trivial operation and a deeper knowledge of the maths behind it is needed. In order to be acquainted with the physics described in the X3D Rigid Body Physics component we will analyse the some basic attributes described in each node element and the physics behind the mathematical operations that drive the physic bodies. 3.1 Rigid Body Physics Firstly we analyse the attributes of the CollidableShape node element which can be seen in the class structure below. CollidableShape : X3DNBodyCollidableNode { SFBool [in,out] enabled TRUE SFNode [in,out] metadata NULL [X3DMetadataObject] SFRotation [in,out] rotation [0,1] SFVec3f [in,out] translation (-, ) SFVec3f [] bboxcenter (-, ) SFVec3f [] bboxsize [0, ) SFNode [] shape NULL [Shape] } Table 3. The X3D CollidableShape node class structure. The CollidableShape node is being used as a parenting system of one or more shape, in which we define the linear and angular position of the each body. The position and orientation of this node is refers at all the particles of the body, as in rigid body physics the body's particles maintain their relative distance between each other. In rigid body we apply these transformations at one point and then re-compute the position of all the remaining particles in the right position. Such a 28

29 point is usually referred as center of mass or pivot point. The linear position, referred in X3D as a translation is represented by a three dimension vector that define the location of a point commonly in a Cartesian coordinate system, while the angular position, defined as an axis-angle rotation in X3D system, is represented by a quaternion-like system, which is defined by a four dimensional vector. While the translation of a body is somehow trivial, the rotation is a more complex operation as it uses rotation quaternions, sometime referred as versors. In mathematics, the number system called quaternions, extend that of complex numbers that are expressed in the form of equation (1), where the is the real part, the imaginary one and is defined by (2). Quaternions were first described in 1843 by the mathematician named Hamilton, who defined a quaternion as the quotient of two directed lines in 3D space or the quotient of two vectors. Quaternions are used in both theoretical and applied mathematics, but found real use alongside the Euler angles in 3D game development, 3D computer graphics and computer vision. Quaternions are being represented in 3D graphics as a vector, composed of the x, y, z components that represent the axis about which the rotation will occur and a float, defined as a w component that represent the amount of rotation that will occur in these axis. The quaternion is defined as shown in equation (3), where x, y, z and w are all real numbers, with magnitude defined by equation (4). For the unit quaternions, the magnitude is 1, as shown in (5) meaning that a formula can be used to check the accuracy of float numbers and re-normalizes in order to prevent errors. (1) (2) (3) (4) (5) In X3D rotation matrix is initially set to (0, 0, 1, 0), which is not indicates a rotation rather than the default state, as angle component is set to zero. In order to manually set the rotation of an object in our scene we have to first calculate every x, y, z, w component separately using the following expressions. 29

30 (6) (7) (8) (9) Where a is the rotation angle and, and are the direction cosines, which represents the angles between the vector and the three coordinate axes. Now let s take a look at the RigidBody node class structure. RigidBody : X3DNode { SFFloat [in,out] angulardampingfactor [0,1] SFVec3f [in,out] angularvelocity (-, ) SFBool [in,out] autodamp FALSE SFBool [in,out] autodisable FALSE SFVec3f [in,out] centerofmass (-, ) SFFloat [in,out] disableangularspeed 0 [0, ) SFFloat [in,out] disablelinearspeed 0 [0, ) SFFloat [in,out] disabletime 0 [0, ) SFBool [in,out] enabled TRUE SFVec3f [in,out] finiterotationaxis [-1,1] SFBool [in,out] fixed FALSE MFVec3f [in,out] forces [] MFNode [in,out] geometry [] [X3DNBodyCollidableNode] SFMatrix3f [in,out] inertia SFFloat [in,out] lineardampingfactor [0,1] SFVec3f [in,out] linearvelocity (-, ) SFFloat [in,out] mass 1 [0, ) SFNode [in,out] massdensitymodel NULL [Sphere, Box, Cone] SFNode [in,out] metadata NULL [X3DMetadataObject] SFRotation [in,out] orientation [0,1] 30

31 SFVec3f [in,out] position (-, ) MFVec3f [in,out] torques [] SFBool [in,out] usefiniterotation FALSE SFBool [in,out] useglobalgravity TRUE } Table 4. The X3D RigidBody node class structure. First of all as a rigid body we describe in physics, a solid body in which any deformation is not applied. This solid body and all its points must be perceived as constant in time regardless all the external forces applied on it, even if such a body cannot exist in real life. In classical physics a physical body is described as a three dimensional body with mass, with energy and a trajectory of position and orientation in space, that last for some duration of time. External forces can be applied upon it, changing the object's position and orientation in time, or influencing the rate in which a body's position changing in time. The body's mass, from Greek word μάζα, is measured in kilogram (kg) in the International System of Units (SI). Mass is a property of the physical body which determines the body's resistance in acceleration by external forces and the strength of the mutual gravitational attraction with other bodies. In order to calculate the mass of an object, we first have to measure the weight of it as we already know and use in our daily routines, well-described by Newtonian physics that mass describes the amount of matter in an object. In order to measure mass we can measure the Inertial mass from the object's resistance in velocity changes via the equation (10), the Active gravitational mass measured from the gravitational force exerted by an object, the Passive gravitational mass measured from the gravitational force experienced by an object in a known gravitational field and finally the Mass- Energy that measures the total amount of energy contained within a body via equation (11). As gravitation or gravity we describe one of the four natural phenomenon in which all physics bodies attract each other. Gravity is experienced and perceived in our everyday life alongside with electromagnetism, another fundamental force, which includes both electricity and magnetism elements as one phenomenon. The other two fundamental forces are weak interaction that is responsible for the radioactive decay, a stochastic process at the level of a single atom with application in radioisotope labelling and strong interaction which is around times stronger of the electromagnetic force and ensures the stability of ordinary matter. (10) (11) times stronger of the gravitational force and it 31

32 As we told earlier, a rigid body might has an angular and a linear velocity, attributes that are being present in the X3D RigidBody component class structure as angularvelocity and linearvelocity. Those two attributes are defined as 3D vectors, in which every component can take values between - and. These values are used every frame and applied to the body in order to provide a constant velocity. Angular and linear velocities are being used in order to control the speed of an object. Linear velocity applies to moving objects and deals with speed in a straight line, while angular velocity specifies the rotational speed of an object in a specified axis. Specifically with velocity we mean the rate of change in position of an object and in order to define it, we need both the magnitude and the direction. In SI system the linear velocity is measured in meters per second, while angular velocity is measured in radians per second. Of course we can determine the linear velocity from the angular velocity of an object by applying the formula (12) and (13), expressed in radian/time and r is the radius of the trajectory, which in case of a spinning body is the radius of the object itself. (12) (13) In RigidBody element we also see a property called inertia defined in its attributes. Inertia is the physical object's resistance in change of its state of motion. Inertia comes from the Latin word iners, which means idle. Western philosophy prior to the Renaissance accepted the theory of motion that Aristotle formulated, a formula misled by the forces of friction and air resistance that act upon any moving object. Based on Aristotle theory, every moving object could come to rest the moment the power that forces to move stops. In physics the body's mass determines the momentum (14) of the body at a given velocity. In equation (14), m represents the inertial mass, which can be calculated using the formula (15), where F is force, m is the inertial mass and α is the body's acceleration. From (14) and (15) we can see that mass doesn't depend on velocity of the body. Inertial mass and gravitational mass are not actually different. Gravitational mass of a body is measured using the gravitational force field, while the inertial mass is measured through the body's acceleration and its resultant speed. Using (15) we can measure the force F needed for a body with mass m to get a linear acceleration a, but if we want to measure the same effect for rotation we have to define a rotational velocity for the same object. This rotation velocity has to be defined in a 3D vector which will contain the spinning rate for each axis. The force that we must to apply to a body in order to apply a rotational acceleration, is called Torque. Torque is symbolized using the (14) (15) 32

33 Greek word τand is defined mathematically as the rate of change of angular momentum of an object, which states that one or both the moment of inertia and angular velocity are changing over time. Torque's formula is represented as (16), where τ is the toque, Ιis the 3x3 inertia tensor matrix and dω is the rotational acceleration. Also the magnitude of torque can be defined as the cross product of the force vector and the lever-arm displacement vector, calculated using the (17), where r is the displacement vector, F is the force applied and θ is the angle between the level arm vector and the force vector. Equation (16) can be written in the following matrix form: (16) (17) (18) Where (19) (20) (21) (22) (23) (24) The elements of the 3x3 inertia tensor matrix are referring to the acceleration around one axis when a torque is applied upon the same or another axis. The diagonal elements,, are referring to the acceleration a body can achieve by applying a torque to the same axis, while the 33

34 other shows the acceleration in an axis by a torque applied on a different axis e.g. with element we define the acceleration around z axis when a torque is applied around the y axis. In 3D environments and physics engines, most of the physical objects are symmetrical in order to avoid complexity. For symmetrical object, the inertia tensor matrix is a bit more simple as only the,, elements have values different form zero while the others have zero values.for a symmetrical body equation (18) could be written as equation (25), where, and is defined by the equation (26).In this case if one want to calculate the torque that needs to be applied in order to accelerate a body in let s say the x axis, for a rotation of we have to multiply the first row of (18) as shown in (27). (25) In X3D RigidBody element, the inertia property defined in its attributes, is a matrix with 9 components, that represent the 3x3 inertia tensor matrix(28), which by default is set to inertia=" " a value that defines the object s mass as symmetrical. The RigidBodyCollection node element class structure is presented below. RigidBodyCollection : X3DChildNode { MFNode [in] set_contacts [] [Contact] SFBool [in,out] autodisable FALSE MFNode [in,out] bodies [] RigidBody SFFloat [in,out] constantforcemix [0, ) SFFloat [in,out] contactsurfacethickness 0 [0, ) SFFloat [in,out] disableangularspeed 0 [0, ) SFFloat [in,out] disablelinearspeed 0 [0, ) SFFloat [in,out] disabletime 0 [0, ) SFBool [in,out] enabled TRUE SFFloat [in,out] errorcorrection 0.8 [0,1] SFVec3f [in,out] gravity SFInt32 [in,out] iterations 10 [0, ) MFNode [in,out] joints [] [X3DRigidJointNode] SFFloat [in,out] maxcorrectionspeed -1 [0, ) or -1 (26) (27) (28) 34

35 SFNode [in,out] metadata NULL [X3DMetadataObject] SFBool [in,out] preferaccuracy FALSE SFNode [] collider NULL [CollisionCollection] } Table 5. The X3D RigidBodyCollection node class structure. As we can see from the RigidBodyCollection class structure, there is defined a 3D vector as gravity. This vector is set by default to (0, -9.8, 0), values that simulate the Earth s standard acceleration due to gravity. Actually according to SI system, the standard gravity is, which means that an object that start falling from rest, ignoring air resistance, will attain a velocity of after 1 second, adding to its velocity for every second of its free fall. With Newton s law of universal gravitation we know the gravity can be formed as shown in equation (29), where m is the mass of the body and g is the gravitational acceleration of an object near the surface of the Earth. Also we can calculate the potential energy, as shown in equation (30), where m is the mass of the body, g is the Earth s gravity and h, is the distance of the object from the Earth s surface. In physics as potential energy we define the energy stored in a physical system and the SI unit for representing this type of energy is the joule (J). Potential energy is associated with gravity and spring forces and it is called that way, as it has the potential to be converted into kinetic energy. The potential energy for near Earth gravity field can be calculated using the equation (31), where m the mass of the body, g the gravitational acceleration of the body due to Earth s gravity and h the distance of the body from the Earth s surface. The potential energy for a linear spring is defined as shown in equation (32), where k is a positive real number that defines the spring and x the amount of distance by which the spring is displaced from its relaxed position. In case of our implementation the gravitational acceleration of objects are being called in each step of our simulation, meaning that in every a fixed size of frames we update the position and rotation of objects due to gravity. Shortly we will analyse a bit further the linear spring systems and the Hooke s law as we present the physics behind some joint type elements. (29) (30) (31) (32) 35

36 The CollisionCollection node element class structure is presented below. CollisionCollection : X3DChildNode { MFString [in,out] appliedparameters "BOUNCE" [] SFFloat [in,out] bounce 0 [0,1] MFNode [in,out] collidables NULL [X3DNBodyCollisionSpace Node,X3DNBodyCollidable Node] SFBool [in,out] enabled TRUE SFVec2f [in,out] frictioncoefficients 0 0 [0, ) SFNode [in,out] metadata NULL [X3DMetadataObject] SFFloat [in,out] minbouncespeed 0.1 [0, ) SFVec2f [in,out] slipfactors 0 0 (-, ) SFFloat [in,out] softnessconstantforcemix [0,1] SFFloat [in,out] softnesserrorcorrection 0.8 [0,1] SFVec2f [in,out] surfacespeed 0 0 (-, ) } Table 6. The X3D CollisionCollection node class structure. Figure 5. The cases of normal force (N). In CollisionCollection class structure we can see the frictioncoefficients attribute, which is defined as a 2D vector, with values from 0 to. That attribute specifies the values of static friction and kinetic friction, between the body and any other surface it will collide. Friction is the force that makes a solid body rest its relative motion when sliding on another surface. Also friction always opposes the motion on one body to another surface since, it is dependent on the 36

37 texture of both the colliding surfaces and on the amount of contact force that pushes the two bodies together. Actually there are five types of friction namely, the dry friction, fluid friction, lubricated friction, skin friction and internal friction. Dry friction is subdivided into static friction referring to two non-moving bodies and kinetic friction referring to moving bodies, the fluid friction describes the friction between two different type of fluids, the lubricated friction describes the friction between two solid bodies separated by a fluid, the skin friction describes the resisting force between a fluid and a surface of a body and finally the internal friction which describes the resisting motion of a solid body while it undergoes deformation. The standard model of frictional resistance force is shown in (33), where µ is the coefficient of friction and N is the force that presses the surfaces together. The higher the µ value, the greater the force of friction it gets, while smaller values correspond to slippery surfaces. Usually the coefficient of static friction is greater than the coefficient of kinetic friction for the same surfaces. The force that presses the surfaces together called normal force (N) in many cases where the body is at rest is just the weight of the body, but in cases where there are applied forces upon the body or it is on an incline, then it is not equal to the weight of the body and has to be calculated separately. In case (a) the body is at rest and the N is equal to the weight and is calculated using the (34), in case (b) there is applied a downward force on the object making the N greater than the weight, calculated using the (35), in case (c) there is applied an upward force on the objects making the N less than the weight, calculated using the (36) and in case (d) the N is less than the weight and can be calculated using the (37). (33) (34) (35) (36) (37) is the parallel to the surface force, opposite to the direction of the applied force that is exerted by each surface on the other that drives them to rest. The standard model of friction is not a precise description of friction as it is a very complex phenomenon but has a practical use and a simple way to calculate the forces applied on colliding surfaces. Finally we will present some attributes that are being used in various joint type constraints. Joints are used in game development process in order to assemble a more complex object from multiple 37

38 rigid bodies. In X3D rigid body specification are being presented 6 different constraining methods, that of BallJoint, MotorJoint, SingleAxisHingeJoint, DoubleAxisHingeJoint, SliderJoint and UniversalJoint. Every single one of those type can be used in various occasions from constraining rigid bodies that form the limbs of a ragdoll figure, to constraining the wheels of a car. Using the constraining methods like BallJoint, SingleAxisHingeJoint and DoubleAxisHingeJoint we can simulate a pendulum system either by limiting the axis freedom or by letting it move freely. Now we are going to present some basic knowledge about pendulum systems and analyse the physics behind it. A pendulum system is composed of a body that is suspended from a pivot so it can swing freely. A pendulum it will always rest into its equilibrium position, so any displacement of the body will stop at some point due to gravity and air friction. The time taken for a complete cycle of the pendulum, is called a period and its value is depended on the length of the pendulum, the strength of gravity and the amplitude, which is the maximum angle that the pendulum swings. In IS system the period is represented as T and is calculated in seconds. The formula of period is given by (38), where is the length of the pendulum and is the gravitational acceleration force. (38) Because the pendulum systems are complicated, there have been some simplifications and assumptions in order to someone study such a system, which lead to the simple pendulum, an idealization of the real pendulum which applies in the following rules. The cord on which the body is attached is massless, the body is a point mass and the motion does not lose energy due to air resistance and cord internal friction. Also the simple pendulum motion occurs in two dimensions, x, y. The differential equation that represents the motion of a simple pendulum is given by (39), where g is the gravitational acceleration force, is the cord s length of the pendulum and is the angular displacement. (39) Such a simple pendulum it could be created using the SingleAxisHingeJointX3D node, which is constraining two rigid bodies with one degree of freedom. Using its attribute called anchorpoint we can create a massless cord, as this attribute defines a 3D vector that can be used as a reference point in world space between the two bodies that are being constrained together. 38

39 As rigid bodies represent physical objects, we can calculate the kinematics from the dynamics. There are two kind of dynamics Forward Dynamics and Inverse Dynamics. Forward Dynamics are used to calculate the movement of the bodies using the forces, while Inverse Dynamics are used in case of constraints being applied upon the objects. There are several methods for solving the IK problems namely cyclic coordinate descent methods, pseudoinverse methods, Jacobian transpose methods, the Levenberg-Marquardt damped least squares methods, the quasi-newton and conjugate gradient methods and neural net and artificial intelligence methods [45]. Bullet physics engine solve IK problems using the Jacobian transpose method. The next Section introduces the fundamental principles of kinematics and the Jacobian transpose method of solving inverse kinematics. 3.2 Kinematics Kinematics is a branch of physics that deals with the motion of system without reference the force and mass and study models that are composed of segments and joints in a parent-child hierarchic structure. In our case segments are the rigid bodies and joints are the links between them that constrain them together. Based on their parent-child relationship any rotation of a joint between two rigid bodies will result in the same rotation of its children. The ability to rotate and translate it is called degree of freedom and explains how a joint can move in space. In three dimensions a single joint can have at maximum a number of six degrees of freedom (6DOF), namely three rotational degrees of freedom and three translational. Also constraints are being added in order to control the rotation and translation of the joints with a maximum and minimum scalar or angle Forward Kinematics In forward kinematics (FK) we determine the absolute position of any joint using a depth-first pattern from the root to the leaf node. First we calculate the absolute position of the joint, that is called end effector, as a function of the joint scalarsθ. represent the array of m joint DOF values and e=[ ], vector represent an array of n DOFs that describe the end effector in world space. If the end effector is a full joint the e would contain 6DOFs (3 translational and 3 rotational). The FK function computes the world space end effector DOFs from the joint DOFs: (40) 39

40 In Figure 6 we demonstrate an example of a 2D robot arm with two 1-DOF rotational joints. l1 θ2 (0,0) θ1 l2 end effector e=[e x,e y ] Figure 6. Example of joint system and the end effector. (41) Inverse Kinematics Inverse kinematics are problems where we know the absolute position for an end effector and we try to find a configuration for the joints such that the end effector is positioned to the given absolute position. IK problems can be solved with two distinct methods, namely analytically and iteratively. Analytical method is precise but the difficulty increases when solving large chains of joints. The iterative methods repeatedly calculate small portions of the problem over time until we find the absolute position of the end effector. To determine the position of the end effector of the hierarchy, we use the Jacobian method. The IK problem formulation is opposite to FK, so from the equation (40), derives a new equation. The goal of IK is to compute the vector of joint DOFs that will cause the end effector to reach the desired goal state. Usually the iterative methods uses the Jacobian matrix which is a linear approximation derived from the relative position such that it describes a partial movement of the end effector. The Jacobian is a vector derivative with respect to another vector in such way that if we have a vector of variables f(x), the Jacobian is a matrix of partial derivatives, one partial derivative for each combination of components of the vectors. With the Jacobian matrix we can relate a change in any component of x to a change in any component of f. (42) 40

41 (43) Just as a scalar derivative of a function f(x) can vary over the domain of possible values for x, the Jacobian matrix varies over the domain of all possible poses for θ. For any given joint pose vector θ, we can explicitly compute the individual components of the Jacobian matrix. If we take the example of Figure 6, then the Jacobian matrix shows how each component of e varies with respect to each joint angle. (44) If there is a vector change in e would be:, that represents a small change in joint DOF values, then the resulting (45) Now if we wanted to move the end effector by a small amount, then would be from equation (46): (46) We can only use the Jacobian as an approximation that is valid near the current configuration, because forward kinematics is a nonlinear function as it involves sine and cosine functions at the input variables, see equation (41). Therefore, we must repeat the process of computing a Jacobian in small steps towards the goal until we get to where we want to be. This step will get end effector (e) closer to some goal value g. (47) 41

42 while (e is too far from g){ compute the Jacobian matrix } invert the Jacobian matrix and compute pick approximation step: compute change in joint DOFs: apply the change to DOFs, move a small step compute new e vector Figure 7. The Jacobian method algorithm of solving IK problems Inverting the Jacobian Matrix If the system has more degrees of freedom in the joints than in the end effector, then it is called under-constrained or redundant and it is likely that there will be an infinite number of solutions. These systems are considered to be solvable, but it may be tricky to find the best solution. In case where there are more degrees of freedom in the end effector than in the joints, then the system is said to be over-constrained, and it is likely that there will not be any possible solution, but we can go as close as possible. Finally if the number of DOFs in the joints equals the number of DOFs in the end effector then the system is called square and we might be able to invert the matrix. But even then as the pose vector changes also does the matrix which may become nonsquare and non-invertable. So just relying on inverting the matrix is generally not going to work. In order to solve non-square over-constrained or under-constrained systems, we use the Pseudo- Inverse method that finds a matrix that effectively inverts a non-square matrix: Another technique is the Jacobian transpose (JT) method in which we take the transpose of the Jacobian matrix, which works pretty well as it is much faster than computing the inverse or pseudo-inverse. With the Jacobian transpose, we can loop through each DOF and compute the change to that DOF directly, rather than computing, storing and inverting the Jacobian in order to compute the change in DOFs in inverse and pseudo-inverse methods. To compute for joint i, we compute the column in the Jacobian matrix as before, and then use: (48) 42

43 As we said earlier Jacobian methods are iterative and in order to iterate towards the solution we must define a step size β. This step size might get us closer to the solution but we have to decide when the iteration should stop. The three main conditions when we should stop the iteration are: (49) Finding a close enough solution or a successful one. Getting stuck in a condition where we can t improve (local minimum) Taking too long to find a solution In the first case we want to get close enough within some tolerance, or iterate until we get within some floating point error range. In the second case, if we get stuck in a local minimum, we have several options. We can accept it as the best solution, or randomize the pose vector a little and try again or send an error to the end effector joint ant try again. Finally at the third case and in real time applications we want to limit the iteration to a maximum number of steps or an actual time in seconds, so in generally if the iteration is taking too long to find a solution we should consider stopping it. If we want to calculate the end effector position in 3D, then the e would be a 3D vector and J a 3xN matrix, with N the number of DOFs. For 1-DOF rotational joints (hinge joint), if we want to know how the world space position e will change if we rotate around the axis, we will need to find the axis and the pivot point in world space. If represents a rotational DOF of a joint, the offset of that joint relative to its parent and the rotation axis relative to the parent, then we can find the world space offset and axis by transforming them by their parent joint s world matrix as following: These transforms as homogeneous vectors would be for as a position vector: as a direction vector: (50) (51) and for. Now that we have the axis and pivot point of the joint in world space, we can use them to find how e would change if we rotated around that axis (52) For a 2-DOF or 3-DOF joint (ball joint), we need to calculate the parent s world matrix, and to include the rotation around the next one or two axes (y and z-axis) as well, as they will rotate the first axis again. In case of a 3-DOF ball joint that rotates in a XYZ order then we have: 43

44 (53) (54) (55) Where and are the y and z rotation matrices respectively. The ball joint s local matrix would be: Where, and are the x, y and z rotation matrices respectively and T(l) is the translation by the joint offset. The ball joint s local matrix would be: When we calculate each axis in world space, then we can use the same equation as in 1-DOF joint case three times, one for each DOF, and compute the derivatives. For translational DOFs the computations are easier and we follow the same methodology as before. For 1-DOF translational joints that translate along an arbiter axis define in its parent space, we use: Furthermore even in cases of 3-DOF translational joints we don t need to follow the same methodology as we did for rotation, because any axis translation doesn t affect the other axes. With translation every change in DOF value results in a simple translation along the world space axis: (56) (57) (58) (59) In the following chapter we analyse the architecture of our implementation, describe all the X3D nodes regarding physics we registered into the X3DOM's core, present all the constraining methods X3D Rigid Body specification has proposed and how we are handling these bodies and joints using Bullet simulation engine. 44

45 Chapter 4. X3D RIGID BODY PHYSICS ARCHITECTURE According to the rigid body physics component proposal [46], this development brings the possibility for content developers to produce "cutting edge" real-time interactive 3D graphic applications. Our implementation of the rigid body physics elements into X3DOM is based on that same specification component. Our work is composed of five phases, the rigid body element registration into X3DOM, the X3D scene parsing, the bullet world construction, the bullet world constraining and finally the realism and interactivity phase. The first phase of our work is the registration of rigid body elements inside the X3DOM s core. The second phase is responsible for the X3D scene parsing of the HTML DOM. In this phase the JavaScript collects all the CollidableShape nodes in the X3D scene and procedurally creates the JavaScript and DOM objects by accessing the CollidableShape, Transform, RigidBody, RigidBodyCollection and CollisionCollection nodes added into X3DOM. In case of joint type nodes the JavaScript is collecting all the available information to create the additional JavaScript and DOM objects that represent them. The third and fourth phases are responsible for the description of the subset of the law physics inside our scene, the construction of the rigid bodies and the constraints between them, using the bullet API. The last phase is the place where the high level of interactivity and realism is applied. Here we define the physics simulation step for the Bullet physics, update our X3D objects that compose our scene using the per frame callback of the X3DOM runtime function, and lastly we define the extra event listeners in the interactive objects of our scene. Figure 8. X3D Rigid Body Physics architecture. 45

46 4.1 Rigid Body Physics Component. Figure 9. X3D Rigid Body Physics component diagram. Based on Rigid Body Physics component of extensible 3D (X3D) we have registered the nodes described in that component inside the X3DOM s core. The newly registered nodes are the CollidableShape, RigidBody, RigidBodyCollection, CollisionCollection, CollisionSensor, BallJoint, MotorJoint, SliderJoint, UniversalJoint, SingleAxisHingeJoint and DoubleAxisHingeJoint and their abstract interfaces X3DNBodyCollidableNode and X3DRigidJointNode have been registered as defined by the specification both in terms of name and structure. With this operation X3DOM became aware of these nodes which lead in an internal method of accessing, comparing and traversing them. The structure of the implemented components regarding the X3DOM core can be seen in the above component diagram, Figure RigidBody node. The RigidBody node describes the properties of a body that can be affected by the physics. This body's geometry shape is defined by a CollidableShape element that RigidBody node uses, which in turn controls the appointed shape defined in a Transform node. The RigidBody node 46

47 defines properties like position and orientation vectors, mass, center of mass and inertia, angular and linear velocity vectors and damping factors for both linear and angular systems. The X3D RigidBody registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block below. Each field is registered using default values defined in the X3D Abstract Specification. x3dom.registernodetype("rigidbody","x3dnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.rigidbody.superclass.call(this, ctx); this.addfield_sffloat(ctx,'angulardampingfactor',0.001); this.addfield_sfvec3f(ctx,'angularvelocity',0,0,0); this.addfield_sfbool(ctx,'autodamp',false); this.addfield_sfbool(ctx,'autodisable',false); this.addfield_sfvec3f(ctx,'centerofmass',0,0,0); this.addfield_sffloat(ctx,'disableangularspeed',0); this.addfield_sffloat(ctx,'disablelinearspeed',0); this.addfield_sffloat(ctx,'disabletime',0); this.addfield_sfbool(ctx,'enabled',true); this.addfield_sfvec3f(ctx,'finiterotationaxis',0,0,0); this.addfield_sfbool(ctx,'fixed',false); this.addfield_mfvec3f(ctx,'forces',[]); this.addfield_mffloat(ctx,'inertia',[1,0,0,0,1,0,0,0,1]); this.addfield_sffloat(ctx,'lineardampingfactor',0.001); this.addfield_sfvec3f(ctx,'linearvelocity',0,0,0); this.addfield_sffloat(ctx,'mass',1); this.addfield_sfrotation(ctx,'orientation',0,0,1,0); this.addfield_sfvec3f(ctx,'position',0,0,0); this.addfield_mfvec3f(ctx,'torques',[]); this.addfield_sfbool(ctx,'usefiniterotation',false); this.addfield_sfbool(ctx,'useglobalgravity',true); this.addfield_mfnode('massdensitymodel', x3dom.nodetypes.shape); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); this.addfield_mfnode('geometry', x3dom.nodetypes.x3dnbodycollidablenode); },{ nodechanged:function(){ if(!this._cf.geometry.nodes){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.x3dnbodycollidablenode)){ this._cf.geometry =this._xmlnode.children[x]; }}} if(!this._cf.massdensitymodel.nodes){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.shape)){ this._cf.massdensitymodel =this._xmlnode.children[x]; 47

48 }}} x3dom.debug.loginfo('rigidbody: '); }})); RigidBodyCollection node. The RigidBodyCollection is used as a container for multiple RigidBody nodes, defined by the same properties like gravity, error correction factors, surface thickness and other switching parameters like "enable" which tells our script if that group of objects will be considered as active. The X3D RigidBodyCollection registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block below. Each field is registered using default values defined in the X3D Abstract Specification. x3dom.registernodetype("rigidbodycollection","x3dchildnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.rigidbodycollection.superclass.call(this, ctx); this.addfield_sfbool(ctx,'autodisable',false); this.addfield_sffloat(ctx,'constantforcemix',0.0001); this.addfield_sffloat(ctx,'contactsurfacethickness',0); this.addfield_sffloat(ctx,'disableangularspeed',0); this.addfield_sffloat(ctx,'disablelinearspeed',0); this.addfield_sffloat(ctx,'disabletime',0); this.addfield_sfbool(ctx,'enabled',true); this.addfield_sffloat(ctx,'errorcorrection',0.8); this.addfield_sfvec3f(ctx,'gravity',0,-9.8,0); this.addfield_sfint32(ctx,'iterations',1); this.addfield_sffloat(ctx,'maxcorrectionspeed',-1); this.addfield_sfbool(ctx,'preferaccuracy',false); this.addfield_mfnode('bodies', x3dom.nodetypes.rigidbody); this.addfield_mfnode('joints', x3dom.nodetypes.x3drigidjointnode); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ if(!this._cf.joints.nodes){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.x3drigidjointnode)){ this._cf.joints =this._xmlnode.children[x]; }}} if(!this._cf.bodies.nodes){ 48

49 for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.rigidbody)){ this._cf.bodies =this._xmlnode.children[x]; }}} x3dom.debug.loginfo('rigidbodycollection: '); }})); CollisionCollection node. The CollisionCollection node acts similar to RigidBodyCollection node, but holds together multiple CollidableShape nodes under the same properties. These properties define the bounce level of the objects, the friction and the softness of the collision, slip factors and the surface speed. The X3D CollisionCollection registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block below. Each field is registered using default values defined in the X3D Abstract Specification. x3dom.registernodetype("collisioncollection","x3dchildnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.collisioncollection.superclass.call(this, ctx); this.addfield_sffloat(ctx,'bounce',0); this.addfield_sfbool(ctx,'enabled',true); this.addfield_sfvec2f(ctx,'frictioncoefficients',0,0); this.addfield_sffloat(ctx,'minbouncespeed',0.1); this.addfield_sfvec2f(ctx,'slipfactors',0,0); this.addfield_sffloat(ctx,'softnessconstantforcemix',0.0001); this.addfield_sffloat(ctx,'softnesserrorcorrection',0.8); this.addfield_sfvec2f(ctx,'surfacespeed',0,0); this.addfield_mfnode('collidables', x3dom.nodetypes.x3dnbodycollidablenode); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ if(!this._cf.collidables.nodes){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.x3dnbodycollidablenode)){ this._cf.collidables =this._xmlnode.children[x]; }}} x3dom.debug.loginfo('collisioncollection: '); }})); 49

50 4.1.4 X3DNBodyCollidableNode abstract node type. The X3DNBodyCollidableNode is the CollidableShape's abstract node type that represents an interface between the visual object in the scene and the rigid body collision geometry object. The X3D X3DNBodyCollidableNode abstract node type registered into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. X3DNBodyCollidableNode : X3DChildNode, X3DBoundedObject { SFBool [in,out] enabled TRUE SFNode [in,out] metadata NULL [X3DMetadataObject] SFRotation [in,out] rotation [0,1] SFVec3f [in,out] translation (-, ) SFVec3f [] bboxcenter (-, ) SFVec3f [] bboxsize -3 [0, ) or } Table 7. X3D X3DNBodyCollidableNode abstract node class structure. x3dom.registernodetype("x3dnbodycollidablenode","x3dchildnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.x3dnbodycollidablenode.superclass.call(this, ctx); this.addfield_sfbool(ctx,'enabled',true); this.addfield_sfrotation(ctx,'rotation',0,0,1,0); this.addfield_sfvec3f(ctx,'translation',0,0,0); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('x3dnbodycollidablenode: '); }})); CollidableShape node. The CollidableShape node is responsible for the representation of the collider's geometry shape. Without it no physics can apply to an object and therefore no interaction with the objects can be performed. In order to match a collider with the correct visual object that will render into the canvas element, we have appended a Transform child node which uses another previously defined Transform inside the scene via the DEF/USE attribute system. CollidableShape node can either be used for the representation of the physical body of a rigid body by defining a Shape 50

51 node, or as a connection reference point to another previously defined CollidableShape node for the RigidBody element. The Transform node is a grouping node that defines the scale, the position and the orientation for all its children. We can refer to and reuse any Transform node in a scene via the DEF/USE attribute system that adds simplicity and performance by having fewer fields in the cloned Transforms. The Transform's child node that is responsible for the visual representation of a geometry shape rendered into the canvas is that of a Shape node. The Shape node has two fields that describes an object, appearance and geometry, which contains respectively an Appearance node and a geometry node. The Appearance node specifies the visual attributes like material and texture of the object, while the geometry node gives all the information about the shape of the geometry. The X3D CollisionShape registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block below. Each field is registered using default values defined in the X3D Abstract Specification. CollidableShape : X3DNBodyCollidableNode { SFBool [in,out] enabled TRUE SFNode [in,out] metadata NULL [X3DMetadataObject] SFRotation [in,out] rotation [0,1] SFVec3f [in,out] translation (-, ) SFVec3f [] bboxcenter (-, ) SFVec3f [] bboxsize -3 [0, ) or SFNode [] shape NULL [Shape] } Table 8. X3D CollidableShape node class structure. x3dom.registernodetype("collidableshape","x3dnbodycollidablenode ", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.collidableshape.superclass.call(this, ctx); this.addfield_sfbool(ctx,'enabled',true); this.addfield_sfrotation(ctx,'rotation',0,0,1,0); this.addfield_sfvec3f(ctx,'translation',0,0,0); this.addfield_sfnode('transform', x3dom.nodetypes.transform); this.addfield_sfnode('shape', x3dom.nodetypes.shape); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ if(!this._cf.transform.node){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.transform)){ 51

52 this._cf.transform =this._xmlnode.children[x]; }}} if(!this._cf.shape.node){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.shape)){ this._cf.shape =this._xmlnode.children[x]; }}} x3dom.debug.loginfo('collidableshape: '); }})); X3DRigidJointNode node. The X3DRigidJointNode is an abstract node type that represents all the joint type nodes and defines basic attributes like the first and second body children node fields. The X3D X3DRigidJointNode abstract node type registered into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. X3DRigidJointNode : X3DNode { SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFNode [in,out] metadata NULL [X3DMetadataObject] } Table 9. The X3D X3DrigidJointNode node class structure. x3dom.registernodetype("x3drigidjointnode","x3dnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.x3drigidjointnode.superclass.call(this, ctx); this.addfield_sfstring(ctx,'forceoutput',""); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ if(!this._cf.body1.node){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.rigidbody)){ this._cf.body1 =this._xmlnode.children[x]; 52

53 }}} if(!this._cf.body2.node){ for(var x inthis._xmlnode.children){ if(x3dom.isa(this._xmlnode.children[x]._x3domnode, x3dom.nodetypes.rigidbody)){ this._cf.body2 =this._xmlnode.children[x]; }}} x3dom.debug.loginfo('x3drigidjointnode: '); }})); The X3D joint type nodes that we are defining into X3DOM s core are: a. BallJoint b. UniversalJoint c. MotorJoint d. SliderJoint e. SingleAxisHingeJoint f. DoubleAxisHingeJoint BallJoint node. Figure 10. The X3D BallJoint constraint type. 53

54 The X3D BallJoint node type represents a joint between two rigid bodies, free from any other constraint, that pivot about a common anchor point. The X3D BallJoint registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. BallJoint : X3DRigidJointNode { SFVec3f [in,out] anchorpoint SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFNode [in,out] metadata NULL [X3DMetadataObject] SFVec3f [out] body1anchorpoint SFVec3f [out] body2anchorpoint1 } Table 10. The X3D BallJoint node class structure. x3dom.registernodetype("balljoint","x3drigidjointnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.balljoint.superclass.call(this, ctx); this.addfield_sfvec3f(ctx,'anchorpoint',0,0,0); this.addfield_sfstring(ctx,'forceoutput',"none"); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('balljoint: '); }})); 54

55 4.1.8 UniversalJoint node. Figure 11. The X3D UniversalJoint constraint type. The X3D UniversalJoint type node represents a joint between two rigid bodies like the BallJoint node, but constrains an extra degree of rotational freedom by keeping the axes perpendicular to each other. The X3D UniversalJoint registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. UniversalJoint : X3DRigidJointNode { SFVec3f [in,out] anchorpoint SFVec3f [in,out] axis SFVec3f [in,out] axis SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFNode [in,out] metadata NULL [X3DMetadataObject] SFFloat [in,out] stop1bounce 0 [0,1] SFFloat [in,out] stop1errorcorrection 0.8 [0,1] SFFloat [in,out] stop2bounce 0 [0,1] SFFloat [in,out] stop2errorcorrection 0.8 [0,1] SFVec3f [out] body1anchorpoint 55

56 SFVec3f [out] body1axis SFVec3f [out] body2anchorpoint SFVec3f [out] body2axis } Table 11. The X3D UniversalJoint node class structure. x3dom.registernodetype("universaljoint","x3drigidjointnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.universaljoint.superclass.call(this, ctx); this.addfield_sfvec3f(ctx,'anchorpoint',0,0,0); this.addfield_sfvec3f(ctx,'axis1',0,0,0); this.addfield_sfvec3f(ctx,'axis2',0,0,0); this.addfield_sfstring(ctx,'forceoutput',"none"); this.addfield_sffloat(ctx,'stop1bounce',0); this.addfield_sffloat(ctx,'stop1errorcorrection',0.8); this.addfield_sffloat(ctx,'stop2bounce',0); this.addfield_sffloat(ctx,'stop2errorcorrection',0.8); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('universaljoint: '); }})); 56

57 4.1.9 MotorJoint node. Figure 12. The X3D MotorJoint constraint type. The X3D MotorJoint node is a constraint that can control the relative angular velocities between two rigid bodies. The X3D MotorJoint registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. MotorJoint : X3DRigidJointNode { SFFloat [in,out] axis1angle 0 [-π,π] SFFloat [in,out] axis1torque 0 (-, ) SFFloat [in,out] axis2angle 0 [-π,π] SFFloat [in,out] axis2torque 0 (-, ) SFFloat [in,out] axis3angle 0 [-π,π] SFFloat [in,out] axis3torque 0 (-, ) SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] SFInt32 [in,out] enabledaxes 1 [0,3] MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFNode [in,out] metadata NULL [X3DMetadataObject] SFVec3f [in,out] motor1axis SFVec3f [in,out] motor2axis SFVec3f [in,out] motor3axis

58 SFFloat [in,out] stop1bounce 0 [0,1] SFFloat [in,out] stop1errorcorrection 0.8 [0,1] SFFloat [in,out] stop2bounce 0 [0,1] SFFloat [in,out] stop2errorcorrection 0.8 [0,1] SFFloat [in,out] stop3bounce 0 [0,1] SFFloat [in,out] stop3errorcorrection 0.8 [0,1] SFFloat [out] motor1angle SFFloat [out] motor1anglerate SFFloat [out] motor2angle SFFloat [out] motor2anglerate SFFloat [out] motor3angle SFFloat [out] motor3anglerate SFBool [] autocalc FALSE } Table 12. The X3D MotorJoint node class structure. x3dom.registernodetype("motorjoint","x3drigidjointnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.motorjoint.superclass.call(this, ctx); this.addfield_sffloat(ctx,'axis1angle',0); this.addfield_sffloat(ctx,'axis1torque',0); this.addfield_sffloat(ctx,'axis2angle',0); this.addfield_sffloat(ctx,'axis2torque',0); this.addfield_sffloat(ctx,'axis3angle',0); this.addfield_sffloat(ctx,'axis3torque',0); this.addfield_sfint32(ctx,'enabledaxes',1); this.addfield_sfstring(ctx,'forceoutput',"none"); this.addfield_sfvec3f(ctx,'motor1axis',0,0,0); this.addfield_sfvec3f(ctx,'motor2axis',0,0,0); this.addfield_sfvec3f(ctx,'motor3axis',0,0,0); this.addfield_sffloat(ctx,'stop1bounce',0); this.addfield_sffloat(ctx,'stop1errorcorrection',0.8); this.addfield_sffloat(ctx,'stop2bounce',0); this.addfield_sffloat(ctx,'stop2errorcorrection',0.8); this.addfield_sffloat(ctx,'stop3bounce',0); this.addfield_sffloat(ctx,'stop3errorcorrection',0.8); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('motorjoint: '); }})); 58

59 SliderJoint node. Figure 13. The X3D SliderJoint constraint type. The X3D SliderJoint node represents a joint between two rigid bodies constrained along a single axis. The X3D SliderJoint registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. SliderJoint : X3DRigidJointNode { SFVec3f [in,out] axis SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFFloat [in,out] maxseparation 1 [0, ) SFNode [in,out] metadata NULL [X3DMetadataObject] SFFloat [in,out] minseparation 0 [0, ) SFFloat [in,out] stopbounce 0 [0,1] SFFloat [in,out] stoperrorcorrection 1 [0,1] SFFloat [in,out] separation SFFloat [out] separationrate } Table 13. The X3D SliderJoint node class structure. 59

60 x3dom.registernodetype("sliderjoint","x3drigidjointnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.sliderjoint.superclass.call(this, ctx); this.addfield_sfvec3f(ctx,'axis',0,1,0); this.addfield_sfstring(ctx,'forceoutput',"none"); this.addfield_sffloat(ctx,'maxseparation',1); this.addfield_sffloat(ctx,'minseparation',0); this.addfield_sffloat(ctx,'stopbounce',0); this.addfield_sffloat(ctx,'stoperrorcorrection',1); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('sliderjoint: '); }})); SingleAxisHingeJoint node. Figure 14. The X3D SingleAxisHingeJoint constraint type. The X3D SingleAxisHingeJoint node that represent a type of joint like the traditional door hinge, which define a single axis about which the rigid bodies rotate. The X3D SingleAxisHingeJoint registered node into the X3DOM's core and its default attribute values can be seen in the 60

61 JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. SingleAxisHingeJoint : X3DRigidJointNode { SFVec3f [in,out] anchorpoint SFVec3f [in,out] axis SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFFloat [in,out] maxangle π SFNode [in,out] metadata NULL [X3DMetadataObject] SFFloat [in,out] minangle - π SFFloat [in,out] stopbounce 0 [0,1] SFFloat [in,out] stoperrorcorrection 0.8 [0,1] SFFloat [out] angle SFFloat [out] anglerate SFVec3f [out] body1anchorpoint SFVec3f [out] body2anchorpoint } Table 14. The X3D SingleAxisHingeJoint node class structure. x3dom.registernodetype("singleaxishingejoint","x3drigidjointnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.singleaxishingejoint.superclass.call(this, ctx); this.addfield_sfvec3f(ctx,'anchorpoint',0,0,0); this.addfield_sfvec3f(ctx,'axis',0,0,0); this.addfield_sfstring(ctx,'forceoutput',"none"); this.addfield_sffloat(ctx,'maxangle',90); this.addfield_sffloat(ctx,'minangle',-90); this.addfield_sffloat(ctx,'stopbounce',0); this.addfield_sffloat(ctx,'stoperrorcorrection',0.8); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('singleaxishingejoint: '); }})); 61

62 DoubleAxisHingeJoint node. Figure 15. The X3D DoubleAxisHingeJoint constraint type. The X3D DoubleAxisHingeJoint node, just like the previous one represents a hinge joint but this time with two independent axes that are located around a common anchor point. The X3D DoubleAxisHingeJoint registered node into the X3DOM's core and its default attribute values can be seen in the JavaScript code block and node class structure below. Each field is registered using default values defined in the X3D Abstract Specification. DoubleAxisHingeJoint : X3DRigidJointNode { SFVec3f [in,out] anchorpoint SFVec3f [in,out] axis SFVec3f [in,out] axis SFNode [in,out] body1 NULL [RigidBody] SFNode [in,out] body2 NULL [RigidBody] SFFloat [in,out] desiredangularvelocity1 0 (-, ) SFFloat [in,out] desiredangularvelocity2 0 (-, ) MFString [in,out] forceoutput "NONE" ["ALL","NONE",...] SFFloat [in,out] maxangle1 π [-π,π] SFFloat [in,out] maxtorque1 0 (-, ) SFFloat [in,out] maxtorque2 0 (-, ) 62

63 SFNode [in,out] metadata NULL [X3DMetadataObject] SFFloat [in,out] minangle1 - π [-π,π] SFFloat [in,out] stopbounce1 0 [0,1] SFFloat [in,out] stopconstantforcemix [0, ) SFFloat [in,out] stoperrorcorrection 0.8 [0,1] SFFloat [in,out] suspensionerrorcorrection 0.8 [0,1] SFFloat [in,out] suspensionforce 0 [0, ) SFVec3f [out] body1anchorpoint SFVec3f [out] body1axis SFVec3f [out] body2anchorpoint SFVec3f [out] body2axis SFFloat [out] hinge1angle SFFloat [out] hinge1anglerate SFFloat [out] hinge2angle SFFloat [out] hinge2anglerate } Table 15. The X3D DoubleAxisHingeJoint node class structure. x3dom.registernodetype("doubleaxishingejoint","x3drigidjointnode", defineclass(x3dom.nodetypes.x3dnode,function(ctx){ x3dom.nodetypes.doubleaxishingejoint.superclass.call(this, ctx); this.addfield_sfvec3f(ctx,'anchorpoint',0,0,0); this.addfield_sfvec3f(ctx,'axis1',0,0,0); this.addfield_sfvec3f(ctx,'axis2',0,0,0); this.addfield_sffloat(ctx,'desiredangularvelocity1',0); this.addfield_sffloat(ctx,'desiredangularvelocity2',0); this.addfield_sfstring(ctx,'forceoutput',"none"); this.addfield_sffloat(ctx,'maxangle1',90); this.addfield_sffloat(ctx,'minangle1',-90); this.addfield_sffloat(ctx,'maxtorque1',0); this.addfield_sffloat(ctx,'maxtorque2',0); this.addfield_sffloat(ctx,'stopbounce1',0); this.addfield_sffloat(ctx,'stopconstantforcemix1',0.001); this.addfield_sffloat(ctx,'stoperrorcorrection1',0.8); this.addfield_sffloat(ctx,'suspensionerrorcorrection',0.8); this.addfield_sffloat(ctx,'suspensionforce',0); this.addfield_sfnode('body1', x3dom.nodetypes.rigidbody); this.addfield_sfnode('body2', x3dom.nodetypes.rigidbody); this.addfield_mfnode('metadata', x3dom.nodetypes.x3dmetadataobject); },{ nodechanged:function(){ x3dom.debug.loginfo('doubleaxishingejoint: '); }})); 63

64 4.2 Parsing the X3D Scene. Figure 16. The two classes constructed in order to store, control and bind the X3D elements with Bullet API. Initially our JavaScript is checking the HTML s body for an X3D Scene element and then it continues inside the scene s children searching for CollidableShape nodes, the one responsible for the representation for the collider's geometry shape. At first we collect all the CollidableShape nodes in the X3D scene and procedurally create an Array of JavaScript objects by accessing the CollidableShape, RigidBody, RigidBodyCollection and CollisionCollection nodes that we implemented into X3DOM. In case of existing joint type nodes the JavaScript is collecting all the available information and create an additional JavaScript Object Array to store them. The connection between those nodes is performed via the X3D DEF/USE attribute that is defined in all our rigid body elements. Specifically the CollidableShape uses an already defined Transform in our scene that is being used by the RigidBody and CollisionCollection node elements. In their turn RigidBody is defined as a child of a RigidBodyCollection, while the CollisionCollection as a child of the CollisionSensor. In case of a joint, there are one or more extra joint type node defined as a sibling of the RigidBody. All joint type nodes use two CollidableShape nodes that have to be earlier defined into the scene and into their RigidBody. In Figure 16 we present the two classes that were created in order to manipulate and bind the X3D elements with the Bullet API, whereas in Figure 17we illustrate using a component diagram the connection between the X3D elements of a scene in order for physics to work. 64

65 Figure 17. A component diagram that shows the connection between the X3D Rigid Body Component elements. 4.3 Building the Physics Simulation World The third phase of our implementation is defined as the simulation world builder as it creates the physics world. In order to add physics using Ammo.js, we need first to create and set up several Ammo.js objects. We need a collision configuration, which is responsible for the collision detection algorithms, collision detection and the collision manifold pool size, a collision dispatcher that handle collision pairs and a broadphase that uses two dynamic AABB bounding volume hierarchies, one for static objects and another for moving object. Also we have to define a constraint solver and a discrete dynamic world that controls the simulation of all rigid bodies 65

66 using the above Ammo.js objects and algorithms. This dynamic world is used to append any rigid body, joint or collision object in our simulation process. In Figure 18, we present the code block that configures and creates such a world by using the mentioned Ammo.js objects. Figure 18. The initialization of the physics simulation world. All the JavaScript objects that were created in the previous phase now are being used by Ammo.js classes for the construction of the physical geometry models. Ammo.js supports all the physical geometry models defined by the X3D specification, like Box, Sphere, Cone, Cylinder and complex user-defined shapes. For the construction of the shapes, our JavaScript is using all the necessary Ammo.js constructors with attributes that we have collected at phase 2 in Section 3.2, from the RigidBody, RigidBodyCollection, CollisionCollection and the CollidableShape elements. All the objects that are being created at this phase and prior to appending them in our simulation world, follows the same methodology described below. Initially we define a new transform object in Ammo.js that stores the position and orientation coordinates according to the X3D object's translation and rotation. Then we create a new Ammo.js object based on defined shape passing the needed attributes like size and radius. With the new shape we can set up margin options and calculate its local inertia. In order for the object to be part of our simulation we have to create a rigid body object, which will control the collision shape as solid body. The rigid body is created by passing to a RigidBody constructor all the needed objects like a motion state based on transform object, a mass, the local inertia and the shape's physical object. At this point we can configure our rigid body according to the attributes described in RigidBody, RigidBodyCollection and CollisionCollection elements in our X3D scene, like angular and linear velocities, friction and restitution. All rigid bodies are added into the dynamic world for the simulation, but also we keep them in an Array so we can iterate over them and keep track of their position and rotation coordinates to update the scene graph. We present and analyse an example of a shape created using X3D attributes and Ammo.js constructors, in order to make it as simple as possible. At first we will present the X3D tag elements that composes the rigid body of our example and afterwards the Ammo.js constructors used in our code. 66

67 In our HTML X3D scene we first define a Transform grouping node that is composed of a shape with an appearance specifying the color and texture of the shape and a Shape node, in our case a Box. It is essential to first define the Transform node as it is used afterwards in the CollidableShape node as a child, a connection that is needed in order to be able to drive the visual object rendered in our screen from the physical object that is being used by Ammo.js. <Transform DEF='Floor' translation='0 10 0' rotation=' '> <Shape> <Appearance> <Material diffusecolor='1 0 0' specularcolor=' '/> <ImageTexture containerfield='texture' url='"texture/texture.jpg"'/> </Appearance> <Box size=' '/> </Shape> </Transform> The next element that we define in our scene is the CollidableShape node, a grouping node that as we said earlier it uses the previously defined Transform node and a Shape node that describes the collider's shape. The rotation and translation of the CollidableShape node is the initial position of the object constructed by Ammo.js as well. Transform's position and rotation may be different at start but in the first frame they are overridden by that of CollidableShape. Also we have to mention that the physical geometry (shape) of the Transform element can differ from that of CollidableShape's in both the shape and size, as the first one is the visual object and the latter is its collider's boundaries. <CollidableShape DEF='Floor_Col' containerfield='children' enabled='true' rotation=' ' translation='0 10 0'> <Transform USE='Floor' containerfield='physics'/> <Shape containerfield='shape'> <Box size=' '/> </Shape> /CollidableShape> We now have successfully represented the visual part and the collider shape of the object inside our scene, but in order to define the physical attributes, we have to create a RigidBody element that will describe the physical characteristics of the object. This rigid body alongside the rest of the rigid bodies in our scene are being grouped inside a RigidBodyCollection element, that append some basic attributes in every rigid body in this group, that affect theirs simulation accuracy and characteristics. The RigidBody element is using as a child the CollidableShape that we created earlier, a connection that used to passes the attributes from the RigidBody element to the physical body. These attributes describes the rigid body's angular and linear velocity, center of mass, mass, local inertia, and other parameters used in both the construction phase of the object and the simulation phase. <RigidBodyCollection DEF='BODY_COLLECTION' containerfield='children' autodisable='false' constantforcemix='0.0001' contactsurfacethickness='1' 67

68 disableangularspeed='0' disablelinearspeed='0' disabletime='0' enabled='true' errorcorrection='0.8' gravity=' ' iterations='10' maxcorrectionspeed='-1' preferaccuracy='false'> <RigidBody DEF='BODY_Floor' containerfield='bodies' position=' ' angulardampingfactor='0.001' angularvelocity='0 0 0' autodamp='false' autodisable='false' centerofmass='0 0 0' disableangularspeed='0' disablelinearspeed='0' disabletime='0' enabled='true' finiterotationaxis='0 1 0' fixed='true' inertia=' ' lineardampingfactor='0.001' linearvelocity='0 0 0' mass='0' orientation=' ' usefiniterotation='false' useglobalgravity='true'> <CollidableShape USE='Floor_Col' containerfield='geometry' enabled='true' rotation=' ' translation='0 0 0'/> </RigidBody> </RigidBodyCollection> Finally we append our CollidableShape node inside a CollisionCollection element, that is used as a grouping node for all the CollidableShapes in the scene. Inside this element attributes like bounce, surface speed and friction are defined. As in Extensible 3D (X3D) rigid body physics component the CollisionCollection is defined inside a CollisionSensor, likewise in X3DOM we have registered the very same node in order to have the right hierarchy. <CollisionSensor DEF='COLLISION-OUTPUT' enabled='true'> <CollisionCollection DEF='COLLISION-JOINTS-GROUP' bounce='0.2' containerfield='collidables' minbouncespeed='1.0' appliedparameters='bounce' enabled='true' frictioncoefficients=' ' slipfactors='0 0' softnessconstantforcemix='0.0001' softnesserrorcorrection='0.8' surfacespeed='0 0'> <CollidableShape USE='Floor_Col' containerfield='collidables' enabled='true' rotation=' ' translation='0 0 0'/> </CollisionCollection> </CollisionSensor> Now that we have fully presented all the node elements that composes a physical object in the X3D scene, we can continue in describing the methodology of the objects physical shape creation using Ammo.js. Firstly by iterating over our list of physical objects, stored into the CollidableShapes array, we continue to a switch function in order to create every single one object based on its geometry shape. A case of a box shape is being presented in the following lines. We first check whether the rigid body is enabled or fixed in order to set correctly the mass of the body. With the enabled attribute disabled or the fixed attribute enabled, the physical body's mass is set to zero else the body's mass is set by the mass attribute defined within the RigidBody element. All physical bodies that are being created within the bullet world, whether they have a mass zero or greater, are part of the simulation. The difference between these two is that a body with zero mass will only act as a static collider, which means that its position will not be affected by other objects, where a body with a mass will affect and be affected by other bodies. 68

69 if(!collidableshapes[cs].rigidbody._vf.enabled CollidableShapes[cs].RigidBody._vf.fixed){ mass =0; } else{ mass = CollidableShapes[cs].RigidBody._vf.mass; } In order to define the body's position and rotation within the simulation world we use the bttransform class that supports rigid transforms and then we use the setidentity function to set that transformation to the identity. With the setbasisfunction we then set the basis matrix of the rotation and with the two functions setorigin and setrotation we initialize the origin vector translation and the quaternion of the rotation based on the X3D Transform's attribute of the translation and rotation respectively. starttransform =new Ammo.btTransform(); starttransform.setidentity(); starttransform.setbasis(collidableshapes[cs].rigidbody._vf.inertia); starttransform.setorigin(new Ammo.btVector3( CollidableShapes[cs].CollidableShape._x3domNode._vf.translation.x, CollidableShapes[cs].CollidableShape._x3domNode._vf.translation.y, CollidableShapes[cs].CollidableShape._x3domNode._vf.translation.z)); var rot =new x3dom.fields.quaternion.parseaxisangle(collidableshapes[cs].collidableshape.rotation); CollidableShapes[cs].Transform._x3domNode._vf.rotation.x = rot.toaxisangle()[0].x; CollidableShapes[cs].Transform._x3domNode._vf.rotation.y = rot.toaxisangle()[0].y; CollidableShapes[cs].Transform._x3domNode._vf.rotation.z = rot.toaxisangle()[0].z; CollidableShapes[cs].Transform._x3domNode._vf.rotation.w = rot.angle(); starttransform.setrotation(new Ammo.btQuaternion(CollidableShapes[cs].CollidableShape._x3domNode._vf.rotation.x, CollidableShapes[cs].CollidableShape._x3domNode._vf.rotation.y, CollidableShapes[cs].CollidableShape._x3domNode._vf.rotation.z, CollidableShapes[cs].CollidableShape._x3domNode._vf.rotation.w)); Then we define abttransform object namely "centerofmass", based on the body's center of mass, and a btvector3 that defines the body's local inertia, namely "localinertia", based on the RigidBody's inertia field. if(collidableshapes[cs].rigidbody._vf.centerofmass!= null){ centerofmass =new Ammo.btTransform(startTransform.getRotation(), new Ammo.btVector3(CollidableShapes[cs].CollidableShape._x3domNode._vf.translation.x+Collida bleshapes[cs].rigidbody._vf.centerofmass.x, CollidableShapes[cs].CollidableShape._x3domNode._vf.translation.y+CollidableShapes[cs].Rigi dbody._vf.centerofmass.y, 69

70 CollidableShapes[cs].CollidableShape._x3domNode._vf.translation.z+CollidableShapes[cs].Rigi dbody._vf.centerofmass.z)); } else{ centerofmass = starttransform; } if(collidableshapes[cs].rigidbody._vf.inertia){ if(collidableshapes[cs].rigidbody._vf.inertia[0]+ CollidableShapes[cs].RigidBody._vf.inertia[1]+ CollidableShapes[cs].RigidBody._vf.inertia[2]==CollidableShapes[cs].RigidBody._vf.inertia[3] + CollidableShapes[cs].RigidBody._vf.inertia[4]+ CollidableShapes[cs].RigidBody._vf.inertia[5]==CollidableShapes[cs].RigidBody._vf.inertia[6] + CollidableShapes[cs].RigidBody._vf.inertia[7]+ CollidableShapes[cs].RigidBody._vf.inertia[8]==1){ localinertia =new Ammo.btVector3(0,0,0); } else{ localinertia =new Ammo.btVector3( CollidableShapes[cs].RigidBody._vf.inertia[0]+ CollidableShapes[cs].RigidBody._vf.inertia[1]+ CollidableShapes[cs].RigidBody._vf.inertia[2], CollidableShapes[cs].RigidBody._vf.inertia[3]+ CollidableShapes[cs].RigidBody._vf.inertia[4]+ CollidableShapes[cs].RigidBody._vf.inertia[5], CollidableShapes[cs].RigidBody._vf.inertia[6]+ CollidableShapes[cs].RigidBody._vf.inertia[7]+ CollidableShapes[cs].RigidBody._vf.inertia[8]); } } else{ localinertia =new Ammo.btVector3(0,0,0); } In order to define the shape of the box inside the physics simulation world we use the btboxshape class that creates a box primitive around the origin point by using the half extends of the X3D box s size field values. The btboxshape constructor is defined as following. btboxshape::btboxshape(const btvector3 & boxhalfextents). Figure 19. The btboxshape class inheritance diagram. Afterwards, we calculate its local inertia based on the mass and the local inertia we defined previously, using the calculatelocalinertiafunction that is inherited from the btcollisionshape class to each shape class. Also the setmargin function was used in order to set the shape's surface thickness. 70

71 void btboxshape::calculatelocalinertia ( btscalar btvector3 & ) mass, inertia Table 16. The Bullet's btboxshape constructor. boxshape =new Ammo.btBoxShape(new Ammo.btVector3(CollidableShapes[cs].CollidableShape._x3domNode._cf.shape._x3domNode._ cf.geometry.node._vf.size.x/2, CollidableShapes[cs].CollidableShape._x3domNode._cf.shape._x3domNode._cf.geometry.node. _vf.size.y/2, CollidableShapes[cs].CollidableShape._x3domNode._cf.shape._x3domNode._cf.geometry.node. _vf.size.z/2)); boxshape.calculatelocalinertia(mass, localinertia); boxshape.setmargin(collidableshapes[cs].rigidbodycollection._x3domnode._vf.contactsurfac ethickness); To this point we have created a transform object that describes the geometrical shape and some basic attributes like mass, inertia, position and rotation. In order to define the shape as a rigid body object inside the simulation world, we have to use the btrigidbodyconstructioninfostructure that provides the information of a rigid body. Along-side the btrigidbodyconstructioninfo we can use the btdefaultmotionstate class to synchronize the world transform between physics and graphics objects. By providing a motion state initialize the rigid body object to the world coordinates that we defined to the transform object. Finally we use the btrigidbodyconstructioninfo object that stores the entire object's information with the btrigidbody class in order to create the final rigid body object. The btrigidbody class is the main class for rigid body objects and is derived from the btcollisionobject, that is used to manage collision detection objects by keeping a pointer to the btcollisionshape class, that provides an interface for the collision shapes. The btrigidbody class gives all the necessary functions to define physical attributes like damping, linear and angular velocities, gravitational pull, center of mass and the friction Coefficients. Within the Bullet physics engine there are defined three types of rigid bodies, namely dynamic, fixed and kinematic rigid bodies. Dynamic rigid bodies have a mass greater than zero and its motion is controlled by the rigid body dynamics, where fixed objects have zero mass and are not moveable. Finally the kinematic rigid bodies are bodies without mass which can be moved only by a user interaction that triggers Bullet to calculate the object's velocity based on the previous and the current world transform. Bullet engine in order to lower its processing time and save resources automatically deactivates the dynamic rigid bodies when their velocity is below a threshold. All the deactivated objects can be activated again as Bullet continues to detect collision detection for all the rigid body objects in the simulation world. motionstate =new Ammo.btDefaultMotionState(startTransform); rbinfo =new Ammo.btRigidBodyConstructionInfo(mass, motionstate, boxshape, localinertia); 71

72 rbinfo.m_friction= CollidableShapes[cs].CollisionCollection._x3domNode._vf.frictionCoefficients.x; rbinfo.m_rollingfriction= CollidableShapes[cs].CollisionCollection._x3domNode._vf.frictionCoefficients.y; boxammo =new Ammo.btRigidBody(rbInfo); if(collidableshapes[cs].rigidbody._vf.autodamp){ boxammo.setdamping(collidableshapes[cs].rigidbody._vf.lineardampingfactor, CollidableShapes[cs].RigidBody._vf.angularDampingFactor); }else{ boxammo.setdamping(0,0); } boxammo.setangularvelocity(new Ammo.btVector3(CollidableShapes[cs].RigidBody._vf.angularVelocity.x, CollidableShapes[cs].RigidBody._vf.angularVelocity.y, CollidableShapes[cs].RigidBody._vf.angularVelocity.z)); boxammo.setlinearvelocity(new Ammo.btVector3(CollidableShapes[cs].RigidBody._vf.linearVelocity.x, CollidableShapes[cs].RigidBody._vf.linearVelocity.y, CollidableShapes[cs].RigidBody._vf.linearVelocity.z)); if(collidableshapes[cs].collisioncollection._x3domnode._vf.bounce!= null){ boxammo.setrestitution(collidableshapes[cs].collisioncollection._x3domnode._vf.bounce); }else{ boxammo.setrestitution(1.0); } if(collidableshapes[cs].collisioncollection._x3domnode._vf.frictioncoefficients!= null){ boxammo.setfriction(collidableshapes[cs].collisioncollection._x3domnode._vf.frictioncoeffi cients.y); }else{ boxammo.setfriction(1); } if(collidableshapes[cs].rigidbody._vf.disablelinearspeed && CollidableShapes[cs].RigidBody._vf.disableAngularSpeed){ boxammo.setsleepingthresholds(collidableshapes[cs].rigidbody._vf.disablelinearspeed, CollidableShapes[cs].RigidBody._vf.disableAngularSpeed); } if(collidableshapes[cs].rigidbody._vf.useglobalgravity){ boxammo.setgravity(new Ammo.btVector3(CollidableShapes[cs].RigidBodyCollection._x3domNode._vf.gravity.x, CollidableShapes[cs].RigidBodyCollection._x3domNode._vf.gravity.y, CollidableShapes[cs].RigidBodyCollection._x3domNode._vf.gravity.z)); boxammo.setflags(0); }else{ boxammo.setflags(1); } 72

73 boxammo.setcenterofmasstransform(centerofmass); All the rigid bodies are being stored into an array, in which we will iterate in order to update their world coordinates. if(updaterigidbody!= null){ bulletworld.removerigidbody(rigidbodies[updaterigidbody]); bulletworld.addrigidbody(boxammo); boxammo.geometry = CollidableShapes[cs]; rigidbodies.splice(updaterigidbody,1,boxammo); } else{ bulletworld.addrigidbody(boxammo); boxammo.geometry = CollidableShapes[cs]; rigidbodies.push(boxammo); } Just like the way we created the physical shape of the X3D Box shape within the Bullet simulation world, we present the constructors used in all the rest of the X3D shapes we can create. The X3D 3D geometrical shapes as specified in extensible 3D (X3D) specification under the Geometry3D component, are Box, Cone, Cylinder, Sphere and IndexedFaceSet. The first four geometrical shapes have an equivalent constructor in Bullet Engine so are somehow trivial to be constructed. The latter one, named IndexedFaceSet, due to its nature we can access its vertices easily by accessing its points field and dynamically create a mesh collider similar to the complex X3D model. Some extra information regarding the shapes constructors and mechanisms are presented below. The Sphere shape is being created within Bullet with the btsphereshape class that implements an implicit sphere that is centered on a local origin and has a specified radius. Its constructor is thebtsphereshape::btsphereshape(btscalar radius), which takes as input the radius of the sphere. In our case we fuel the constructor with the radius value taken from the radius field of the X3D sphere. Figure 20. The btsphereshape class inheritance diagram. In case of Cone geometrical shapes we use the btconeshape class, which implements a cone shape primitive, centered around on a local origin and aligned with the Y axis. Additionally there are two more classes namely, btconeshapex and btconeshapez that can be used in cases we want the cone to be aligned around the X axis and Z axis respectively. Its constructor is defined as btconeshape::btconeshape(btscalar radius, btscalar height), which takes as input the radius of the cone s base and its height. 73

74 Figure 21. The btconeshape class inheritance diagram. For Cylindrical geometrical shapes we use the btcylindershape class, which implements a cylinder shape primitive, centered around on a local origin and aligned with the Y axis. Additionally there are two more classes namely, btcylindershapex and btcylindershapez that can be used in cases we want the cylinder to be aligned around the X axis and Z axis respectively. Its constructor is defined asbtcylindershape::btcylindershape (constbtvector3 &halfextents), which takes as input a 3D vector with the half extents. At this case the half extents are referring to the radius and the height of the cylinder. In order to create a physical X3D cylinder shape within Bullet, the btvector3 must be complemented with (radius, height/2, radius) of the X3D shape. Figure 22. The btcylindershape class inheritance diagram. Finally for IndexedFaceSet and IndexedTriangleSet elements that define complex mesh geometries we use the btconvexhullshape class, which implements an implicit convex hull of an array of vertices. A set of points is defined as convex if it contains the line segments connecting each pair of its points. The convex hull of a given set X may be defined as 74

75 a) The minimal convex set containing X b) The intersection of all convex sets containing X c) The set of all convex combinations of points in X d) The union of all simplexes with vertices in X The btconvexhullshape constructor is describes as: btconvexhullshape::btconvexhullshape ( const btscalar * points = 0, int numpoints = 0, int stride = sizeof(btvector3) ) Table 17. The Bullet's btconvexhullshape constructor. Using this constructor things can get difficult as we have to define the number of bytes in memory between each point, the number of points and for each point a consecutive btscalar (x,y,z). In our implementation we used the addpoint method, with which we add to the constructor one point at a time. Using this technique we are able to algorithmically compress our mesh and add only the vertices needed. For the collision detection of the convex shapes Bullet Engine provides a general and fast collision detector based on the Gilbert Johnson Keerthi distance algorithm (GJK) that is a method of determining the minimum distance between two convex sets, supported within the localgetsupportingvertex method. void btconvexhullshape::addpoint ( const btvector3 & bool ) point, recalculatelocalaabb = true Table 18. The btconvexhullshape's addpoint function constructor. Figure 23. The btconvexhullshape class inheritance diagram. 75

76 That convex hull object we created then must be added as a child within a compound shape in order to be able to move. The btcompoundshape class allows us to store multiple btcollisionshapes and move concave bodies. For static complex shapes we can alternative use the btbvhtrianglemeshshape for better results, but in our case the compound object will act as an external grouping node which will be used for the object s movement. The btcompoundshape constructor takes as input an optional Boolean variable for the dynamic aabb tree calculation as see here btcompoundshape::btcompoundshape(boolenabledynamicaabbtree=true).we present the appropriate code-block that illustrates the creation of the convex hull object using an X3D IndexedFaceSet shape. Figure 24. The btcompoundshape class inheritance diagram. var convexhullshape =new Ammo.btConvexHullShape(); for(var p in CollidableShapes[cs].CollidableShape._x3domNode._cf.shape._x3domNode._cf.geometry.node. _cf.coord.node._vf.point){ convexhullshape.addpoint(newammo.btvector3(collidableshapes[cs].collidableshape._x3do mnode._cf.shape._x3domnode._cf.geometry.node._cf.coord.node._vf.point[p].x, CollidableShapes[cs].CollidableShape._x3domNode._cf.shape._x3domNode._cf.geometry.node. _cf.coord.node._vf.point[p].y, CollidableShapes[cs].CollidableShape._x3domNode._cf.shape._x3domNode._cf.geometry.node. _cf.coord.node._vf.point[p].z),true); } var compoundshape =new Ammo.btCompoundShape(); compoundshape.addchildshape(starttransform, convexhullshape); compoundshape.setmargin(collidableshapes[cs].rigidbodycollection._x3domnode._vf.contac tsurfacethickness); compoundshape.createaabbtreefromchildren(); compoundshape.updatechildtransform(0,new Ammo.btTransform(new Ammo.btQuaternion(0,0,0,1),new Ammo.btVector3(0,0,0)),true); 76

77 4.4 Constraining the Rigid Bodies. The X3D rigid body specification under component support level 2 defines multiple constraint types, like BallJoint, UniversalJoint, SliderJoint, SingleAxisHingeJoint, DoubleAxisHingeJoint and MotorJoint. In the description of the Section 3.2, we mentioned that in case one or more joint type nodes exists, we keep track them on a separate Array. After the completion of the third phase, Section 3.3, the created objects can be constrained, either with the world or with one another. We will consecutively proceed to present the procedure followed to achieve this, but first we have to present the class types used in every case. The BallJoint joint type is created using the point to point constraint method, which uses two rigid bodies and constraints them along a common pivot point which describes the "ballsocket" in local space coordinates. For the UniversalJoint type we use Ammo.js universal constraint, which describes two rotational degrees of freedom based on axis taken from the two constrained rigid bodies. In case of SliderJoint we use the Ammo.js slider constraint, that constraints a rigid body to rotate and translate on a single axis and in conjunction with another body. SingleAxisHingeJoints and DoubleAxisHingeJoints are created using the hinge constraint, which constraint two rigid bodies to act as a hinge as their name dictate. The only difference between them is that in second case we use two rotational degrees of freedom in contrast to the first that we use only one. Lastly in MotorJoint type we use the generic 6Dof constraint, which is a general type of constraint that can be uses in most cases. This type of constraint can be uses to lock or free any of the six degrees of freedom. By using this constraint we limit the rotation motor axis based on our X3D MotorJoint element. In order to achieve this constraining of the rigid bodies we iterate over the joint array we created in a previous phase and based on the joint type we call the corresponding class from Ammo.js. The rigid bodies can be found by accessing the children elements and all extra attributes like anchor point, axis freedom and angle limit from the actual X3D joint type element. By iterating over our joint object list and then over our rigid body object array we can find the correct rigid bodies stored in the list compared with the RigidBody children nodes of any joint. Then the only thing left is to create the constraint and add them into the simulation process by appending it in our dynamic world. Some points of the methodology followed are being presented below The two sibling rigid bodies used by the joint element node are being stored in the object1, object2 variables respectively by comparing each rigid body's definition stored within the "rigidbodies" array with the rigid body used by the joint element using the X3DOM scene access interface. if(rigidbodies[j].geometry.rigidbody._def && rigidbodies[j].geometry.rigidbody._def == JointShapes[js].Joint._cf.body1.node._DEF){ 77

78 var object1 = rigidbodies[j]; } if(rigidbodies[j].geometry.rigidbody._def && rigidbodies[j].geometry.rigidbody._def == JointShapes[js].Joint._cf.body2.node._DEF){ var object2 = rigidbodies[j]; } Then by accessing the nodename attribute of the joint element we switch to the desired joint type method and access the different constructors in order to constrain our rigid bodies. The methodology followed and the constraining class used in each X3D joint type are being presented below. The following figure shows the inheritance diagram for all the rigid body constraining methods Bullet supports (Figure 25). Figure 25. The inheritance diagram of Bullet s rigid body constraining methods. BallJoint The BallJoint type node is a point to point constraint that represents a joint between two rigid bodies, free from other constrains, that pivot about a common anchor point that describes the 'ballsocket' location in local space and thus we used the btpoint2pointconstraint class. Point to point constraint limits the translation so that the local pivot points of 2 rigid bodies match in world space. 78

79 The btpoint2pointconstraint constructor as specified by the Bullet Engine API. btpoint2pointconstraint::btpoint2pointconstraint ( btrigidbody & btrigidbody & const btvector3 & const btvector3 & ) rba, rbb, pivotina, pivotinb Table 19. The Bullet's btpoint2pointcontraint constructor. The rba and rbb are the aforementioned object1 and object2, the pivotina is a vector representing the anchorpoint attribute of the X3D joint element, while the pivotinb is the same vector with a negative sign. In the X3D code block showing the use BallJoint element presented below the object1 is representing the BODY_J1 rigid body, the object2 is the BODY_J2 rigid body, the pivotina is (0,2,0) and finally the pivotinb is (0,-2,0). Figure 26. An example of the X3D BallJoint element. The newballjoint object in the code-block below represents the constraint that was created using the btpoint2pointconstraint constructor, which we later add to the simulation world. var newballjoint =new Ammo.btPoint2PointConstraint(object1, object2, new Ammo.btVector3(JointShapes[js].Joint._vf.anchorPoint.x, JointShapes[js].Joint._vf.anchorPoint.y, JointShapes[js].Joint._vf.anchorPoint.z), new Ammo.btVector3(-JointShapes[js].Joint._vf.anchorPoint.x,- JointShapes[js].Joint._vf.anchorPoint.y,-JointShapes[js].Joint._vf.anchorPoint.z) ); bulletworld.addconstraint(newballjoint); UniversalJoint UniversalJoint has been developed using the Bullet btuniversalconstraint class. The Universal Joint has 2 rotational degrees of freedom, similar to Euler rotations around Z (axis 1) and Y (axis 2). The description from the ODE manual: Given axis 1 on body 1, and axis 2 on body 2 that is perpendicular to axis 1, it keeps them perpendicular. 79

80 The btuniversalconstraint constructor as specified by the Bullet Engine API. btuniversalconstraint::btuniversalconstraint ( btrigidbody & rba, btrigidbody & rbb, const btvector3 & anchor, const btvector3 & axis1, const btvector3 & axis2 ) Table 20. The Bullet's btuniversalcontraint constructor. The rba and rbb are the two rigid bodies, the anchoris a vector representing the anchorpoint attribute of the X3D joint element, while the axis1 and axis2are the X3D axis1 and axis2 vectors respectively. In the X3D code block below showing the UniversalJoint element, the rba is representing the BODY-1 rigid body, the rbb is the BODY-2 rigid body, the anchor is (0,0,0) and finally the axis1, axis2 are (0.7071, , 0.0) and (0.0, 0.0, 1.0) respectively. Figure 27. An example of the X3D UniversalJoint element. The newuniversaljointobject in the code-block below represents the constraint that was created using the btuniversalconstraint constructor, which we later add to the simulation world. var newuniversaljoint =new btuniversalconstraint(object1, object2, new Ammo.btVector3(JointShapes[js].Joint._vf.anchorPoint.x, JointShapes[js].Joint._vf.anchorPoint.y, JointShapes[js].Joint._vf.anchorPoint.z), new Ammo.btVector3(JointShapes[js].Joint._vf.axis1.x, JointShapes[js].Joint._vf.axis1.y, JointShapes[js].Joint._vf.axis1.z), new Ammo.btVector3(JointShapes[js].Joint._vf.axis2.x, JointShapes[js].Joint._vf.axis2.y, JointShapes[js].Joint._vf.axis2.z) ); bulletworld.addconstraint( newuniversaljoint ); SingleAxisHingeJoint & DoubleAxisHingeJoint SingleAxisHingeJoint and DoubleAxisHingeJoint constraint types have been developed using the Bullet bthingeconstraint class. Hinge constraint between two rigid bodies each with a pivot point that describes the axis location in local space axis defines the orientation of the hinge axis. Hinge constraint, or revolute joint restricts one or two additional angular degrees of freedom, so the body can only rotate around one axis, the hinge axis. This can be useful to represent doors or wheels rotating around one axis. The user can specify limits and motor for the hinge. 80

81 There are two bthingeconstraint constructors as specified by the Bullet Engine API, the first take as input the two rigid bodies along-side their pivot point and axes and the latter the two rigid bodies along-side their transform. bthingeconstraint::bthingeconstraint ( btrigidbody & rba, btrigidbody & rbb, const btvector3 & pivotina, const btvector3 & pivotinb, const btvector3 & axisina, const btvector3 & axisinb, bool usereferenceframea = false ) Table 21. The Bullet's bthingeconstraint first constructor. bthingeconstraint::bthingeconstraint ( btrigidbody & rba, btrigidbody & rbb, const bttransform & rbaframe, const bttransform & rbbframe, bool usereferenceframea = false ) Table 22. The Bullet's bthingeconstraint second constructor. In both the SingleAxisHingeJoint and DoubleAxisHingeJoint cases the rba and rbb are the two rigid bodies used by the constraint, the pivotina is a vector representing the anchorpoint attribute of the X3D joint element and pivotinb the same vector with a negative sign. The axisina and axisinb are different used between the two cases. In SingleAxisHingeJoint the axisina and the axisinb are the same vector that is defined by the X3D axis attribute while in DoubleAxisHingeJoint those two are set similar to axis1 and axis2 X3D attributes. In the two X3D code blocks below that shows the SingleAxisHingeJoint and DoubleAxisHingeJoint elements, the rba is representing the BODY_J1 rigid body and the rbb is the BODY_ J2 rigid body. In SingleAxisHingeJoint type the pivotina and pivotinb are (0,2,0) and (0,-2,0) respectively and the axisina, axisinb are (1, 0, 0). Figure 28. An example of the X3D SingleAxisHingeJoint element. 81

82 Figure 29. An example of the X3D DoubleAxisHingeJoint element. The newsingleaxishingejoint object in the code-block below represents the constraint that was created using the bthingeconstraint constructor, which we later add to the simulation world. var newsingleaxishingejoint =new bthingeconstraint(object1, object2, new Ammo.btVector3(JointShapes[js].Joint._vf.anchorPoint.x, JointShapes[js].Joint._vf.anchorPoint.y, JointShapes[js].Joint._vf.anchorPoint.z), new Ammo.btVector3(-JointShapes[js].Joint._vf.anchorPoint.x,- JointShapes[js].Joint._vf.anchorPoint.y,-JointShapes[js].Joint._vf.anchorPoint.z), new Ammo.btVector3(JointShapes[js].Joint._vf.axis.x, JointShapes[js].Joint._vf.axis.y, JointShapes[js].Joint._vf.axis.z), new Ammo.btVector3(JointShapes[js].Joint._vf.axis.x, JointShapes[js].Joint._vf.axis.y, JointShapes[js].Joint._vf.axis.z),false ); newsingleaxishingejoint.setlimit(jointshapes[js].joint._vf.minangle, JointShapes[js].Joint._vf.maxAngle,0.9,0.3,1.0); bulletworld.addconstraint(newsingleaxishingejoint); The newdoubleaxishingejoint object in the code-block below represents the constraint that was created using the bthingeconstraint constructor, which we later add to the simulation world. var newdoubleaxishingejoint =new bthingeconstraint(object1, object2, new Ammo.btVector3(JointShapes[js].Joint._vf.anchorPoint.x, JointShapes[js].Joint._vf.anchorPoint.y, JointShapes[js].Joint._vf.anchorPoint.z), new Ammo.btVector3(-JointShapes[js].Joint._vf.anchorPoint.x,- JointShapes[js].Joint._vf.anchorPoint.y,-JointShapes[js].Joint._vf.anchorPoint.z), new Ammo.btVector3(JointShapes[js].Joint._vf.axis1.x, JointShapes[js].Joint._vf.axis1.y, JointShapes[js].Joint._vf.axis1.z), new Ammo.btVector3(JointShapes[js].Joint._vf.axis2.x, JointShapes[js].Joint._vf.axis2.y, JointShapes[js].Joint._vf.axis2.z),false ); newdoubleaxishingejoint.setlimit(jointshapes[js].joint._vf.minangle1, JointShapes[js].Joint._vf.maxAngle1,0.9,0.3,1.0); bulletworld.addconstraint(newdoubleaxishingejoint,true); 82

83 MotorJoint The X3D MotorJoint constraint has been created using the btgeneric6dofconstraint Bullet class. The btgeneric6dofconstraint object is a constraint between two rigid bodies each with a pivot point that describes the axis location in local space. The btgeneric6dofconstraint constructor as specified by the Bullet Engine API. btgeneric6dofspringconstraint::btgeneric6dofsp ringconstraint ( btrigidbody & rba, btrigidbody & const bttransfor m & const bttransfor m & bool rbb, frameina, frameinb, Table 23. The Bullet's btgeneric6dofspringconstraint constructor. ) uselinearreferencefr amea The frameina and frameinb represent the local axis location and basis in the reference frame of the rigid bodies rba and rbb respectively. These frames represent the axis when the axis angle is set to zero, so it might need some extra configurations to be done when the two bodies have a starting angle different than zero. Also the two frames are local space frame which means that they always stay in the same orientation and position relative to the center of the object. The uselinearreferenceframea is set to true, as we need to create a parent-child system with the frameina acting as the parent transform and the frameinb as the child. ThebtGeneric6DofConstraint can be used in order to create any system using the 6 degree of freedom. This constraint is able to leave any of the 6 degree of freedom free or locked. Translational motors are not supported yet in btgeneric6dofconstraint, a case that does not apply in angular motors. All the configurations of the angular limits are being performed using the btrotationallimitmotorstructure that can be accessed through the btgeneric6dofconstraint.getlimitmotor method. The possible angular limit ranges are being seen in the following table. AXIS MIN ANGLE MAX ANGLE X -PI PI Y -PI/2 PI/2 Z -PI PI Table 24. The angular limit ranges of Bullet's btgeneric6dofspringconstraint. 83

84 Note that according to the X3D Rigid Body Physics specification in section 3, MotorJoint all axis are set by default to zero and can take values that are defined in [-π,π] space, which in case of the Y-axis configuration of the 6Dof constraint that doesn t apply. Using the getrotationallimitmotor structure we can set the lower and upper limit values that are responsible for the behavior of the axis. There are three states that can be created that will lock, limit between two values or set free the axis. In general for each axis, a) If lower limit = upper limit, then the axis is locked b) If lower limit < upper limit, then the axis is limited between the specified values c) If lower limit > upper limit, then the axis is free and has no limits The above actions are being performed while the constraint is being created by accessing the X3D MotorJoint element s motor3axis attribute using the X3DOM s _vf internal method for accessing the attributes. The btgeneric6dofconstraint has one Rotational Motor configuration per axis that can be accessed with the btrotationallimitmotor (int index) function. That means that for x axis the index=0, for y axis index=1 and for the z-axis index=2. In order to configure the Rotational Motor we must always set the m_enablemotor attribute to true. Using the m_targetvelocity attribute we set the velocity parameter being defined by the X3D axistorque attribute and the maximum force of the motor with the m_maxmotorforce. Finally the m_lolimit and m_hilimit attributes are constraining the object within their ranges, locked or free them. In most cases one axis must be free and the others limited so that the Motor can be work properly. The following code block displays the rotational motors configuration. if(jointshapes[js].joint._vf.motor3axis.x!=0){ newgearjoint.getrotationallimitmotor(0).m_enablemotor =true; newgearjoint.getrotationallimitmotor(0).m_targetvelocity = JointShapes[js].Joint._vf.axis1Torque; newgearjoint.getrotationallimitmotor(0).m_maxmotorforce =100.0; newgearjoint.getrotationallimitmotor(0).m_lolimit = JointShapes[js].Joint._vf.axis3Angle; newgearjoint.getrotationallimitmotor(0).m_hilimit =0.0; } else{ newgearjoint.getrotationallimitmotor(0).m_enablemotor =false; newgearjoint.getrotationallimitmotor(0).m_targetvelocity =0; newgearjoint.getrotationallimitmotor(0).m_maxmotorforce =0.0; newgearjoint.getrotationallimitmotor(0).m_lolimit =0.0; newgearjoint.getrotationallimitmotor(0).m_hilimit =0.0; 84

85 } if(jointshapes[js].joint._vf.motor3axis.y!=0){ newgearjoint.getrotationallimitmotor(1).m_enablemotor =true; newgearjoint.getrotationallimitmotor(1).m_targetvelocity = JointShapes[js].Joint._vf.axis2Torque; newgearjoint.getrotationallimitmotor(1).m_maxmotorforce =100.0; newgearjoint.getrotationallimitmotor(1).m_lolimit = JointShapes[js].Joint._vf.axis3Angle; newgearjoint.getrotationallimitmotor(1).m_hilimit =0.0; } else{ newgearjoint.getrotationallimitmotor(1).m_enablemotor =false; newgearjoint.getrotationallimitmotor(1).m_targetvelocity =0; newgearjoint.getrotationallimitmotor(1).m_maxmotorforce =0.0; newgearjoint.getrotationallimitmotor(1).m_lolimit =0.0; newgearjoint.getrotationallimitmotor(1).m_hilimit =0.0; } if(jointshapes[js].joint._vf.motor3axis.z!=0){ newgearjoint.getrotationallimitmotor(2).m_enablemotor =true; newgearjoint.getrotationallimitmotor(2).m_targetvelocity = JointShapes[js].Joint._vf.axis3Torque; newgearjoint.getrotationallimitmotor(2).m_maxmotorforce =100.0; newgearjoint.getrotationallimitmotor(2).m_lolimit = JointShapes[js].Joint._vf.axis3Angle; newgearjoint.getrotationallimitmotor(2).m_hilimit =0.0; } else{ newgearjoint.getrotationallimitmotor(2).m_enablemotor =false; newgearjoint.getrotationallimitmotor(2).m_targetvelocity =0; newgearjoint.getrotationallimitmotor(2).m_maxmotorforce =0.0; newgearjoint.getrotationallimitmotor(2).m_lolimit =0.0; newgearjoint.getrotationallimitmotor(2).m_hilimit =0.0; } The X3D specification for the Rigid Body Physics are describing the motoraxis fields as the axis vectors of the corresponding axis, where if the value is 0,0,0 then the axis is disabled and the motor does not apply force or torque along that axis. Specifically the motor1axis field is anchored to the global frame, the motor2axis field is anchored to the first body s frame of reference and the motor3axis field to the second body s frame of reference. In our implementation we choose to use only the third motoraxis field as we currently create only motors where the second rigid body is experiencing torque or some other kind of force. 85

86 At the following X3D MotorJoint example, the rba is the rigid body named BODY_B1, the rbb is the BODY_B6, the reference frames, frameina and frameinb, of the two rigid bodies rba and rbb can be accessed using the getworldtransform() method. In this system the motor3axis vector is (0,0,1), which means that the Z-axis is enabled and the BODY_B1 is rotating around the BODY_B6 as it is applied a torque defined by the axis3torque field that has a value of 750Nm, that changes the BODY_J1 body s angular velocity. Figure 30. An example of the X3D MotorJoint element. The newgearjoint object in the code-block below represents the constraint that was created using the btgeneric6dofconstraint constructor, which we later add to the simulation world. var newgearjoint =new btgeneric6dofconstraint( object1, object2, object1.getworldtransform(), object2.getworldtransform(),true); newgearjoint.enablefeedback(true); bulletworld.addconstraint( newgearjoint,true); SliderJoint SliderJoint has been used using the Bullet btsliderconstraint class. The slider constraint allows the body to rotate around one axis and translate along this axis. The btsliderconstraint uses the following constructor as specified by the Bullet Engine API. btsliderconstraint::btsliderconstraint ( btrigidbody & rba, btrigidbody & rbb, const bttransform & frameina, const bttransform & frameinb, bool uselinearreferenceframea ) Table 25. The Bullet's btsliderconstraint constructor. 86

87 At the following X3D SliderJoint example, the rba is the rigid body named BODY-SL1, the rbb is the BODY-SL1, while the frames frameina and frameinb represent the two reference frames of the rigid bodies rba and rbb respectively. Figure 31. An example of the X3D SliderJoint element. The newsliderjoint object in the code-block below represents the constraint that was created using the btsliderconstraint constructor, which we later add to the simulation world. var newsliderjoint =new Ammo.btSliderConstraint(object1, object2, object1.getworldtransform(), object2.getworldtransform(),true); newsliderjoint.setlowerlinlimit(0.1); newsliderjoint.setupperlinlimit(0.5); newsliderjoint.setloweranglimit(0.1); newsliderjoint.setupperanglimit(0.5); newsliderjoint.setframes(object1.getworldtransform(), object2.getworldtransform()); bulletworld.addconstraint(newsliderjoint); 4.5 Realism and Interactivity. In this section we describe the functions that take place when all the rigid bodies are created and constrained using the Bullet physics library API and appended into our X3D scene. We first create an update function that is called every frame using the X3DOM build in function that is a common operation to the WebGL per-frame callback. In this function we define an internal simulation step, namely stepsimulation, which is a member function of the btdiscretedynamicsworld that provides the discrete rigid body simulation, and is responsible for the control of the data flow we pass from Ammo.js in X3D scene each frame. This step simulation is used in order to iterate and update the position and rotation of all the rigid bodies of the scene prior the render, which in their turn control a CollidableShape node. The btdiscretedynamicsworld::stepsimulation()function displayed in Table 26, takes as input a timestep that defines the amount of time needed to step the simulation, a maxsubsteps that defines the maximum number of steps that Bullet is allowed to take each time we call it and the fixedtimestep that describes the size of the internal step. In order to have the correct frame rate in our implementation we have to find the appropriate maximum and minimum frame rates at 87

88 which our examples can behave normal. At all cases the timestep must be less than maxsubsteps*fixedtimestep, otherwise we will start losing time. Some things we have to know first is that the timestep and fixedtimestep are measured in seconds and not in milliseconds, so the time we get using the btclock::gettimemilliseconds() function using the basic Bullet clock, namely btclock that measures accurate time in seconds, has to be converted into seconds by dividing the time by 1000 before passing it to stepsimulation. Also we have to know that the size of fixedtimestep is affecting the accuracy of the simulation. The lower the size of the fixedtimestep, the more accurate the simulation will be. This is happening because each internal sub-step takes time for computation, so if we want to double the accuracy of the simulation, we have to double the size of maxsubsteps, that will double the CPU power for the same simulation time. If maxsubsteps is set to zero, then it will run the simulation with exactly the timestep we pass in the function, instead of a number of ticks equal to fixedtimestep, so its frame rate independent and will lead to abnormally results. On the other hand if we pass a maxsubstep value equal or bigger than one, then Bullet interpolates movement for us. That means that if we set fixedtimestep to a value of 4 units and a timestep of 5 units then the simulation will do exactly one tick and estimate the remaining movement by 1/4. For our implementation because every case we were tested was different we wanted to create a way to control the simulation in respect to physics simulation frame rate and accuracy. In order to achieve that we decided to cap our simulation frame rate between 60fps and 10fps.In stepsimulation function we defined the timestep as 1/60 th of a second, kept the default value of the fixedtimestep at 1/60 th of a second and the maxsubsteps at 1 as this value met the requirements of the equation 1 above. But in order to control the frame rate we created a variable namely accl that was used to alter the accuracy of the simulation based on the X3D scene. This was done by multiplying the two variables, namely timestep and fixedtimestep with accl, so the bigger the value of accl, the faster the physics simulation we output at X3D scene but the less accurate it would be. The default value of the accl variable was set to a value of one so the Bullet will produce one simulation step every one tick at default settings. That means that if we multiply the timestep with an accl=2, we double the simulation step, but will also decrease the simulation resolution to half, as we also multiply the fixedtimestep with the same variable. (42) int btdiscretedynamicsworld:: stesimulation ( btscalar timestep, ) int maxsubsteps = 1, btscalar fixedtimestep = btscalar(1.)/btscalar(60.) Table 26. The btdiscretedynamicsworld stepsimulation constructor. 88

89 Furthermore as we wanted to create a more interactive feeling in our implementation and not be seen only as an animation output of pre-computed physics, we added to all the non-static X3D shapes the appropriate mouse event listeners that enable us a new level of interactivity. Alongside the event listeners we have used the new X3DOM moveable component, Figure 32, which enables us to move X3D objects within our scene based on the viewpoint projection matrix. The moveable component defines an internal method of mouse interactivity with objects, which was used in our implementation for the awareness of the interactive objects of the user s activity. Figure 32. Dynamically creating moveable objects and attaching them event listeners. User interaction with the scene s rigid bodies is limited to grab, drag and release. These DOM element changes are triggering the X3DOM to redraw the scene, but for the Bullet part of our implementation we have to manually recreate the scene or a part of it. In order to update the X3D and the physics simulation worlds, we iterate over the objects, find the one picked or moved by the user and reconstruct their rigid body components alongside their siblings in case they are part of a joint hierarchy. We then re-position and instantiate the same object inside the scene, based on the mouse position. Recreating an object and its constraints is not the optimal solution when it comes to real-time simulations as it leaves behind unused Bullet objects, which have to be cleaned because they tend to slow down the simulation and rendering time. The cleaning process of the simulation world will result in smooth and high frame rates in both the physics world and X3D one. For this to be achieved we are removing the unused rigid bodies and constraints using the removeconstraint(bttypedconstraint*constraint) function and the removerigidbody(btrigidbody * body) function that are both member functions of the btdynamicworld Bullet class. By adding this layer of interactivity into the X3D scene and by forcing Bullet to update the position and rotation of the rigid bodies that are part of any joint hierarchy, we are able to interact with joints in real-time and observe their behaviouras they are trying to find their 89

90 equilibrium. Bullet handles this operation on constrained rigid bodies using the build Jacobian function, a member function of the bttypedconstraint class, with which it calculates the Jacobian determinants that describes the movement of the body towards its equilibrium state based on the external forces. Figure 33. The Update function responsible for the movement of rigid bodies. 90

91 Chapter 5. EXPERIMENTAL EVALUATION For the purposes of our work with X3DOM we have created various scenarios scenes, in order to cover every possible rigid body state and all the constraining types. For all the simulations and benchmark tests we were using the following browser versions: Google Chrome 33.0 [47], Mozilla Firefox 29.0 [48], Opera 20.0 [49] and Maxthon [50]. The benchmark computer s characteristics were: CPU: Inter Core i7-3630qm 2.40GHz, GPU: AMD Radeon HD 7600M Series 2GB, RAM: 4GB, OS: Windows 8.1. In our benchmark test, we have chosen to not include Microsoft Internet Explorer and Apple Safari browsers as they do not support WebGL render functionalities in X3DOM environments yet, but rather fallback to the Flash renderer. In [51], there was presented an in depth comparison of some popular web browsers in conjunction with X3DOM's rendering capabilities, that highlights different not only between browsers but between versions of the browsers and in conjunction to the operation system. For our tests, we have created four X3D scenes, which include basic rigid body physics examples. The first scene as seen in Figure 34 comprises of 8 rigid bodies, constrained with BallJoints in doublets in a way that they create some sort of a chain. Figure 34. The first example: a scene of a pendulum system created using BallJoints. At first we defined a starting point of this chain by pinning the first rigid body, with zero mass, to the world, which acts as a static Ammo.js object with no influence by other objects. All 91

92 intermediate rigid bodies are set to ignore world gravity, have a mass of 0.1 kg each and are being influenced only by the last rigid body, which has a mass of 2 kg. The whole pendulum system is created not in an equilibrium position but rather with amplitude, so it will start immediately simulating an oscillation after the page finishes loading. This example comprises of 8 RigidBody and 7 BallJoint elements defined in a RigidBodyCollection node. Also there are 8 CollidableShape nodes used by the RigidBody elements, which control the position and rotation of 8 transform elements in our scene that drive our final visual output. The second example, Figure 35, used for our measurements is an extended version of the previous example. We have replaced the final sphere shape with an IndexedFaceSet, which was created in Ammo.js as a convex hull model and using the inline method we have imported an external X3D file into our scene node. Figure 35. The second example: a scene of two colliding convex hull rigid bodies constrained using the BallJoint and MotorJoint joint type. That X3D file that we have loaded in our scene is composed of 6 rigid bodies, one defined as static and used as the other sibling rigid body for the four rigid bodies constrained by the BallJoint node type and the one with the MotorJoint. We also apply a torque along the Z axis in the last rigid body constrained by the MotorJoint, which is also an IndexedFaceSet object, which 92

93 forces it to rotate around the static body and collide with the rest of the bodies. Inside the X3D file we have also defined the appropriate RigidBodyCollection and CollisionCollection nodes that complete the X3D physics scene. As soon as simulation starts, the two X3D scene systems, the one defined in our HTML page and the other inside the inline X3D starts colliding. The results shown in Figure 36were collected from 10 continuous simulations for every case and in each browser. In detail for the gathered fps rate of each browser we measured the average frame rate for the first 2000 frames of each simulation in each test example scene and then we computed the average rate of all those simulations. Figure 36. A cross-browser X3D scene loading time comparison in HTML and XHTML cases. Measurements show that there is no significant difference between the HTML and XHTML file formats regarding X3DOM's FPS rate (Figure 36). Furthermore in Figure 37 we observe a small delay in scene loading time in the case of XHTML files in Mozilla Firefox. With respect to the loading time, we should note that we had disabled the cache of each browser when our tests were measured. 93

94 Figure 37. A cross-browser X3DOM frame rate comparison in HTML and XHTML cases. A third example, Figure 38, was constructed in order to measure the fps rate in respect to the number of rigid bodies in a scene. For that case we created a scene with a confined space where a MotorJoint constraint controls a ball by applying in every single frame a torque along the Y axis. That confined space is constructed using 6 boxes which are placed in the right places in order to assemble the walls of our hollow box. We then dynamically append new boxes inside that area over time, in order to measure the browser capabilities in respect to frame rate. For our benchmark we create one rigid body every frame in random position inside the container, then we passes it to the simulation process by adding it to the Ammo.js dynamic world and in X3D scene by appending the appropriate node elements. Then we collected the frame rate each time we added a body in our scene, a process followed for the 1000 bodies. We repeated the same simulations five times in each browser in order to get an average score between the measurements. Our benchmark statistics are being visualized in Figure 39andFigure 40, where we can clearly see that Google Chrome performance is better than every other browser we tested, closely followed by the Opera browser. Firefox s performance seems to be significant lower than the previous two, but a lot better than Maxthon s fps rate. 94

95 Figure 38. The third example: a motor joint constrained sphere interacting with free rigid bodies dynamically created in real-time. Figure 39. A cross-browser line chart showing the frames per second in respect to the number of rigid bodies. 95

96 Figure 40. A cross-browser column chart showing the frames per second display rate in cases of 10, 50, 100, 200 and 500 rigid bodies. The final example, Figure 41, which completes our benchmarking tests, is comprised of a fully dynamic scene, starting only with two static rigid bodies, one for the ground representation and the other for the definition of the first link of a joint. In this test we dynamically append rigid bodies in our scene and in our simulation, which first are linked and constrained by a single axis hinge joint, limited to a Y axis rotational freedom. Newly created rigid bodies are being constrained with the last object appended in the scene. In simple words we are creating a never ending chain of rigid bodies, in order to test browser s frame rate. Ammo.js now has to take into consideration the movement of every single object in the scene and uses the Jacobian determinant function to solve the differential equation systems near the equilibrium point. Rigid bodies are created in every frame and in parallel we measure the X3DOM s frame rate and Ammo.js time in millisecond needed to calculate the physics. Those two measurements, Figure 42 and Figure 43, have been collected separately, as in the second case we turned off every visually rendered moving object, in order to measure the Ammo.js frame rate in every browser, using the same internal step for all the physics simulation. For our test we captured the average frame rate in each browser by simulating the scene in total 10 times. The first 5 were used in order to measure the X3DOM frame rate using its built-in function, whereas with the last 5 simulations we measured Ammo s average frame rate, using the clock built-in function that returns the time in milliseconds. Figure 42and Figure 43 show the cross-browser fps rate in respect to the number of rigid bodies constrained with a joint. In Figure 44we can see five snapshots of our captured data in a comparison of physics and render fps rate of the same scene as measured in our tests in the case of Chrome browser. 96

97 Figure 41. The fourth example: dynamic real-time creation of constrained rigid bodies using single axis hinge joint. Figure 42. A cross-browser line chart showing X3DOM s frame rate in respect to the number of joints. 97

98 Figure 43. A cross-browser line chart showing Ammo s frame rate in respect to the number of joints. Figure 44. Physics and render frame rate comparison in Chrome browser in cases of 50, 100, 200, 500 and 1000 joints. 98

99 Chapter 6. SHOWCASE At this chapter we present some X3D scenes created throughout the development process of our implementation. Altered versions of the benchmarking test scenes presented in Chapter 5 and some others created to illustrate the various constraining methods and the in-depth interactive feeling of the physics in X3D environments can be seen in our project website 4. Figure 45. A complex scene with multiple rigid bodies, static colliders, forces and joints. The first example, Figure 45, was developed in order to illustrate the complexity of high level of interactivity scenes with high frame rate that we can achieve using the X3D technology enhanced with our physics implementation. At this example we have created a scene that is composed with lots of static colliders that acts as walls for our free rigid bodies. At the tip of the tube we append at the start of our simulation ten X3D boxes that represent our crates, which have a rigid body component attached on. These rigid bodies influenced by gravity starts to drop down till they slide across the plane, from where we a force of Nm acts upon them based on their position in a way that makes them crash at the other side of the wall. Next they slide down from

100 that point until a new force will be applied upon them that will make them cross the final plane of the scene. All the rigid bodies at this state could crash upon the three wrecking balls that swing across that plane, based on a torque that is applied every time the pre-defined amplitude is reached. Finally the crate that touches the blue net, that lies beneath the plane, or whenever its time is over, it gets destroyed. Every rigid body start with a life of 5000 units, a value that decreases by 1, with every frame passed. At every point the simulation world will only have ten rigid bodies, which will be replenished whenever one gets to be destroyed. Figure 46. A system of a MotorJoint with a torque that acts upon four rigid bodies constrained using BallJoints. The following scene, Figure 46, is composed of six spheres that are constrained with MotorJoint and BallJoint constraints. The yellow sphere is static and acts as the reference point in which all the others will be attached with. The red ball is being used by a MotorJoint element alongside the yellow sphere and a torque forces it to rotate around the Z-axis of the yellow sphere. The remaining four spheres coloured green, have much smaller mass than the red sphere and have been constrained alongside the yellow sphere with the use of a BallJoint node. As all the spheres, except the yellow one, have rigid body component attached and their mass is greater than zero will be influenced by gravity and any other force acts upon them. The red sphere rotating around the yellow one will hit the other spheres in numerous occasions changing their position and 100

101 orientation and slowing down, but because the torque is applies every frame it will never stop. The spheres constrained with the BallJoint will always try to find their equilibrium state. Figure 47. A complex scene of two rigid bodies constrained together using the UniversalJoint that have their initial velocity forces them to travel over a wall of inactive rigid bodies. The scene shown in Figure 47 is composed of multiple static colliders that are responsible for containing the rest of the scene s objects. Furthermore the scene has eight boxes that are inactive rigid bodies piled up in order to form a kind of wall and two spheres that have initial linear velocities towards the wall and a mass greater than the boxes. The linear velocity described within the X3D linearvelocity field is being applied as a force in the start of the simulation, so when the spheres collide with the boxes loses some of their kinetic energy and start to slow down and at some point due to the frictional forces and impacts on colliders stop moving. The final example scene, Figure 48 that was constructed during the development of the physics support implementation for X3D environments is a simple example that consists of six objects, all of them are active rigid bodies and one is being used as the starting point of the chain that they create. The starting object is pinned in the world and has a zero mass but it can be moved by the user, a case that will obligate all others to follow its position. The rigid bodies are being constrained in doublets using the SingleAxisHingeJoint method and can freely rotate around the 101

102 Z-axis. Initially the system finds its equilibrium state as there are no external forces and any interactivity in that scene is being performed by the user activity. Each sphere that is constrained with another one acts as a container for one IndexedFaceSet out of the five that create the word MClab. With the ability to move the spheres around we can see in action the Bullet simulation engine controlling the rigid bodies based on their limited degree of freedom described by the SingleAxisHingeJoint node. Figure 48. A chain of rigid bodies created using the SingleAxisHingeJoint constraint. 102

103 Chapter 7. CURRENT RESEARCH AND FUTURE WORK Our implementation of physics support for X3DOM aims in enabling the development of highly realistic Web-based simulations and interactive real-time 3D applications and games based on X3D technology. X3DOM physics support creates a new testing ground for several potential physics-driven systems. Based on our implementation, some of the future work that can be done could be the implementation of a physics-driven particle system based on the Particle Systems component of the extensible 3D (X3D) specification into X3DOM. Actually, we have already made the first steps towards to this implementation. Based on our physics framework we have started to implement in our system some particle system features based on the Particle Systems component X3D specification. At this state we have constructed an example scene illustrating the visual capabilities of our implementation. Furthermore we have developed some particle features like life, color, collision detection, particle re-generation and particles burst creation. In our tests we had created particles using the PointSet node rendering component and other basic X3D shapes for their representation. Each particle is driven by physics, but more complex examples using a group of particles as a physical object can be created. In Figure 49 and Figure 50, the two cases of particles can be seen in action. In both examples our scene has more than 300 particles at any given point with an average 35 fps, which is good enough at this point if we consider that every particle is a rigid body influenced by forces, like gravity, collision impacts with the floor and other rigid bodies and impulses created by the user via the particle control panel we have created shown at the right of each figure. Figure 49. An X3D(OM) Particle System based on our current work. Particles are being rendered using the X3D PointSet node rendering component. 103

104 Figure 50. An X3D(OM) Particle System based on our current work. Particles are being rendered using basic X3D shapes. In example (a) we use boxes while in (b) we use spheres. Another potential research direction could be the creation of different physics sub-system inside X3DOM, that of a Soft Body simulation system. Such a system is already supported by Ammo.js: by registering new X3D(OM) nodes and attributes that describe deformable bodies, and in collaboration with our current work, we can create even more complex and realistic simulation applications. Finally, an implementation of Fluid Dynamics could also be incorporated, either based on the aforementioned Soft Body system, or as a separate autonomous system. In the meantime, however, we should keep in mind that the core of our engine is Bullet 2.82, which is written in C++, and the Ammo.js implementation is merely a JS port. To the extent that C++ remains the de facto language for such frameworks, for our code to be properly maintained, new Bullet versions (including the upcoming Bullet 3.0) will have to be systematically ported to JS. We can honestly expect, however, that in the future a pure, native JS physics engine will appear, as more and more technologies become web-oriented. In any case, X3DOM can now claim to feature a working real-time interactive physics component, which brings it yet another step closer to supporting fully immersive 3D games for the web. 104