This post introduces XSeen - a declarative language built on A-Frame and X3D to achieve the desire of a fully declarative 3D/VR language that runs in the web browser. In this initial release the language supports some X3D and some A-Frame nodes and capabilities. It is possible to combine the two to produce results that are the available in either.

I attended my first Silicon Valley VR Expo last week. It was very different than VRLA. As might be expected, this one is more focused on tech; though there were plenty of content discussions. Fortunately, the expo floor was not as loud as VRLA and I had many conversations with vendors.

This is the fifth in a series discussing the next generation of X3D and addresses the needs and requirements for X3D for the display of 3D, AR, and VR content in the current ecosystem of display devices and environments. The 3D content is displaying in a larger ecosystem of including the user’s computer, browser, Internet, and originating server. As such it needs to work cooperatively within the environment and with other content already displaying in that environment.

This is the fourth in a series discussing the next generation of X3D. Archiving and long-term storage has always been a strong point of X3D. The ability to read and play content from years or even decades ago makes it unsurpassed in the 3D world. X3D has human-readable formats that can be used for archiving so that the content does not require special software to unpack and display the file contents. It is important to keep the long-term storage and access capability while along X3D to stay current with advances in display technology.

This is the third in a series discussing the next generation of X3D. The current architecture of X3D does not support the industry standards in modeling, archival, and user experience. It uses a single primary file with additional external resources loaded as needed including other X3D files or media (images, audio, video, and scripts). The capabilities made available in the X3D files are either insufficient (e.g., lack of deformable skin animation) or in conflict with the major display environment (e.g., Scripts). This post describes a systems architecture with implications for content architecture that addresses these issues.

This is one in a series examining the purpose of X3D - where is it's niche in the electronic ecosystem and what function does it perform. The series also looks at where X3D needs to evolve to best serve the ecosystem. This post looks at animation. It was motivated by issues involving deformable skins that are needed to animate non-mechanical models.

X3D and VRML have been an international standard since 1997. They define a means to model and texture 3D geometry, animate it, and provide user interaction. As an International Standard (VRML: ISO/IEC 14772, and X3D: ISO/IEC 19775-19777) these have provided extraordinarly stable and long-lasting formats. Content developed 20 years ago still runs today. That is an important legacy that should not be lost. At the other end of the timescale (today), there are environments and capabilities that could not have been imagined when the first standard was approved. X3D needs to keep a foot in the ancient past (as far as computer time goes) and current so that history is not lost.

X3D defines localized audio sources and a generalized background source. The localized audio can be positioned in the environment and its range defined. The background audio permiates everywhere.

Imagine the situation where every house lock is made by one of three manufactures - Ambroid, Microlock, and Orange. All of the locks take your fingerprint to open, but each analyzes your fingerprint a little differently. Now the police need to enter your home (with justification). They do not have a fingerprint match, so they require Orange to create a keyhole for every lock that when using the proper key, the door will open.