Difference between revisions of "Purpose of X3D"

Revision as of 13:46, 12 October 2016

Introduction

This page was created to capture all the comments on the e-mail trail on the public wiki under the subject line "Purpose of X3D"

Len Daly, 6th October 2016

http://web3d.org/pipermail/x3d-public_web3d.org/2016-October/005256.html

I have been struggling with this topic for several months -- what is the purpose of X3D in the electronic ecosystem of the 21st century. The Consortium says that "X3D is a royalty-free open standards file format and run-time architecture to represent and communicate 3D scenes and objects using XML" [1]. As an ISO standard, X3D needs to have a long shelf-life, contain 3D models, animation, and interactivity; and communicate this within and between systems using XML. To do this effectively, it needs to stay current with industry practices while maintaining an ability to communicate information from the past.

There is no question about X3D's handling of old data. To my knowledge there is no other 3D system that can display models, animation, and interaction from 15+ years ago. In the Internet age where half-life appears to be around 18 months, that is a remarkable achievement.

X3D has not kept up with current practices in modeling, animation, rendering, or interaction. Work on the most recent update to X3D (V3.3 - 2013) started back in 2009 and the document was mostly completed in 2010. The most advanced feature is 3D volume rendering. Work on particle systems and physics is several years before that. The standard for animation of any model is with bones and rigs - whether that model is a character, a tree, or a machine. All current renders use shaders (code that runs on a graphics card) to create highly realistic (or fantastic) surface appearance. Work on upgrading interaction to support mobile devices (including multi-touch), head-mounted-displays including game controllers, paddles, LEAP interfaces, and other specialized devices is just beginning.

So back to my question -- what is X3D for? In 20 years time will the only content for X3D be 35 years old? Current content not created explicitly for X3D won't work because X3D does not support much more than static modeling.

I have collected several choices. These are described below in more or less least to most complex (aka work). There are a lot of other options, more towards bottom of the list. If you have other contributions, please feel free to state so along with what you think it would take to get there from X3D V3.3.

 1) X3D is for static models only (no texture). This is a very good match. There are just a few things that X3D doesn't handle and most of those are having to deal with interchange with other formats.
 2) X3D is for static models + appearance. X3D needs to expand to make full use of appearance shaders of all sorts.
 3) X3D is for models including animation. X3D needs to expand to include at least the current practice of skeletal structure plus rigging (attaching surface weights to various joints). This is not H-Anim, but broader as it includes models that are not even at all human, human-like, animals, or even "living".
 4) X3D is for runtime display. X3D needs to include all major 3D formats. It needs to run AND use interface mechanisms of all major platform types, including phones/tablets, HMDs, desktops, etc. It needs to run in a browser: it needs to run as an app.
 5) X3D is everything. Well, think about that for a moment. That means all of the above need to be done. It also needs to be widely adopted, and this needs to be completed in the next 12-18 months. It would probably take a team of 20-50 people working on a specification, implementations, conversion, integration applications, marketing, etc. to accomplish this. Advocates for this choice need to have a reality check.

Given that we have maybe 7 part time people (right now) where does X3D go?

Mitch Williams, 6th October 2016

http://web3d.org/pipermail/x3d-public_web3d.org/2016-October/005257.html

The value of X3D is that it is robust and established so that it is finding applications, and can be supported across multiple platforms.

It has generation tools such as Blender or conversion tools such as exported from 3DS Max. It’s a popular file format for 3d printers. And it is one of the 3 files types for building VR content in Samsung’s GearVR virtual reality system (with Unity and Unreal being the other 2).

The idea that people can easily create VR without programming, or take content designed for 3d printers but can now be viewed in VR or the Web makes X3D a nice cross-platform file format.

John Carlson, 6th October 2016

http://web3d.org/pipermail/x3d-public_web3d.org/2016-October/005258.html

Frankly, since cobweb supports prototypes, scripts, VRML, and it seems DOM interactions, we should start supporting cobweb heavily.

Doug Sanden, 6th October 2016

http://web3d.org/pipermail/x3d-public_web3d.org/2016-October/005259.html

6) it is what it is. Any sentence that attempts to explain/summarize/abstract it is just for newcomers, and doesn't control what it is.

This option allows you/us to work incrementally as market demand provides some pull for new features, new platforms, new file formats, and to adjust positiong relative to other market choices.

Where someone might feel confounded/confused/in-a-conundrum is if they try and make a big/dramatic/sudden jump/move in positioning/claims/product based on some higher level abstraction. A return to incrementalism can solve that.

more..

For example, I like what Holger, Andreas et al are doing with the v3.3 series: giving it new life.

I have personally refrained from suggesting new nodes lately, and Protos_II -an architecture for abstracting plug-in node types so they can refer to Abstract Node interfaces and have no first-node-is-concrete-node requirement. I'm saving these great ideas because if v4 doesn't run in a native browser like freewrl, I'm going to split off and do an unofficial 3.4+ series with other native and cobweb browser developers and screw web3d.org board of directors who can go rot in XXXX.

One way to merge the 'branches' is to keep the nodes abstract -not DOM or xml- and have separate documents for saying any DOM or xml -or x3dv or wrl- treatments, if that is still possible/practical. So much of the past series was about protos and routing and scripts - too bad there isn't better mapping to those in x3dom. Maybe a bit more abstraction of things in the old core, in such a way that you can still get to things like IMPORT/EXPORT following documents one way, or Selectors following another chain of documents. Refactoring of the old core. While preserving its mapping to .wrl, .x3dv, .x3d -and x3dom and cobweb-SAI- via layers of documents describing more specific implementation details. So if new nodes or components or core treatments are added abstractly, they can still trickle down into various concrete implementations. allowing end users to experience a 'forever archive and forever relevant' promise simultaneously.

SUMMARY: refactor old specs to abstract core that will be implemented differently in different spec branches, keeping a single series of abstract specs for all implementations: wrl x3dv x3d x3dom so all implementations benefit from new nodes and components