Difference between revisions of "Purpose of X3D"

Revision as of 14:07, 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

Joe Williams, 6th October 2016

http://web3d.org/pipermail/x3d-public_web3d.org/2016-October/005260.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" [2]. 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.

OK, that works for me.

To do this effectively, it needs to stay current with industry practices while maintaining an ability to communicate information from the past.

I think the best and maybe only way X3D can effectively stay current with industry (best) practices is when industry and academia contributes the royalty-free techniques and technology. For example, various image processing techniques that may be proprietary and only can do only on certain $$ stations. If info is open, X3D can implement available and desirable open techniques and technology.

See CAD and HAnim and Medical for latest.

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.

Yes, and one that can be maintained as long as it is general and widely usable.

X3D has not kept up with current practices in modeling, animation, rendering, or interaction.

Here is where we need the list of old vs new.

modeling, animation, rendering, or interaction.

Great, those would seem to be the big ones. In all cases I would like to keep the focus on realtime. All other needs for animation and rendering for video or film can be accomplished if we carry on with a robust realtime system where robust means confident author controlled event ordering.

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.

Maybe the most advanced for X3D means latest for which open free access backed by a working implementation is obtained.

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.

True and for X3D HAnim we expose it all including skin and animation bindings. The bones are HAnim Segments and the HAnim Joint is directly exposed to the user.

Here the term rigs will mostly mean binding the 'skin' mesh to various Joints (same as 'bones' in this) or other mesh animation devices (Displacer) or coordinate or whatever interpolaters so that the surface features move as desired when the skeleton is animated by Joint rotation (same as bone orientation), or if just a mesh feature is animated independently.

A more simple form of a rig would be where only Segment (same as bone, if you wish) geometries are used and no skin.

Doesn't matter, X3D HAnim does all that.

Of course we can also create and rig a deformable mesh skin to a skeleton by nominating vertices from various segment geometries.

All current renders use shaders (code that runs on a graphics card) to create highly realistic (or fantastic) surface appearance.

That is why X3D has some interfaces dedicated to shaders. We should try to pick up support for any 'new' shaders used by the cl, webcl, gl, and webgl.

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.

Yes, see MARS stuff, and also CAD advances. Not to mention GEO

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.

What features are missing from X3D in order to support content that will need to be created 5 years from now?

Certainly we can see that X3D uses best practices currently available free for use in X3D that can produce immersive interactive simulations. We may be seeing new ideas about GPU runtime storage of data such as animations, and new ideas about how to organize the user code for more direct GPU (parallel) processing. X3D scripts and shaders should have WebGL probably need CL and WebCL for future computational modeling enhancements.

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.

I think there are couple of different types of shaders

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".

Please have a solid look at X3D HAnim.

include at least the current practice of skeletal structure plus rigging (attaching surface weights to various joints).

What part(s) of that is not fully specified in X3D HAnim?

skeletal structure

OK, best practice by X3D.

skeletal structure plus rigging

OK, best practice by X3D.

(attaching surface weights to various joints).

Well, the idea is accomplishing movement of one or a set of vertices by weighted rotation of bound Joint(s). For example, if the weight is 0.5 then the vertex would be moved according to 0.5 of the Joint(s) rotation.

I think this is the most simple capability since various weighting equations may be use, but this is all linear.

> This is not H-Anim,

what? X3D uses best practice skeletal structure and animation hierarchy with both skin and segment geometry and the complete documentation for the weighted skin bindings. Some might be confused at first if they have access to Joint rotation rather than hidden behind bone orientation (luckily they are the same) and the tediously complete documentation of the bindings.

What do you need that is not there in HAnim now?

4) X3D is for runtime display. X3D needs to include all major 3D formats.

And those major formats are:

it is interesting that right now we are dealing with importing a 'major' animation data format for use in X3D. I think we will find that when we want to import another data structure than is native in X3D, we first need to settle on some 'standard' form of the input. That is mostly hard to do but is necessary in order to provide the X3D standard output.

Currently the best target formats to include is the gl and the cl, Collada, and glTF (including SRC). X3D should have a running project to track their progress and encourage implementation by X3D toolmakers. Almost full-time work for somebody. :

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.

Once there was a long way between what we could expect from a higher performance desktop or dedicated workstation and what we expect from our phones. How to keep up?

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.

Well, fortunately the HAnim is not so far off as you portray above. So those people worried about that can look at deeper stuff missing than the basic set of features (in five objects) we have.

Advocates for this choice need to have a reality check.

Also a good virtual reality check, for available technology and techniques.

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

Well, pick something that would improve the way you can use X3D. Join a working group or create a new one and start a Working Draft and some sort of implementation or proof of that feature set. If it is good, then it will advance within the consortium. If people or resources are outside the consortium member structure, then ask x3d wg or bod for options.

i still think there will be need for a sort of 2 levels for X3D.

First is the stand-alone desktop features and performance available from an optimized X3D runtime running in the host OS for max performance.

Second is the x3d runtime available when running as a web page under control of the browser. For sure this is getting better all the time but still, for our our own entertainment and the (at least) order of magnitude improvement running standalone, incidentally supporting html as some elements of the scene, and we want to maintain the truly robust, high performance event system concept of a standalone X3D browser running the scene.

John Richardson, 6th October 2016

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

Cobweb has problems with IE11 related to certain of the examples. Details have been forwarded to Holger…J…J

Firefox seems OK on Windows 7 Professional.

Cobweb will not work with Safari on Macintosh El Capitan.

The X3DOM examples will load in Safari, at least so far…J…J

Doug Sanden, 6th October 2016

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

IE deprecated, Edge OK? more.. if this weighs against cobweb-like solutions in the minds of web3d v4 spec developers/sponsors, I've noticed on windows 10 IE is not shown automatically (its on the system, you have to hunt for it) and Edge is the default browser. Edge seems to be working ok with cobweb, what little I've tried. more.. But native plugins -like ActiveX Cosmo, Cortona and AxFreewrl- don't run in Edge. There's a movement away from non-sandboxed 'native code' plugins / apps. By sandbox that means the app -if carrying malicious code- can't get to your hard drive in general (just a sandbox area where temp files for the app are created, and where downloaded files can be stored locally) and can't get into operating system state in general. Windows Store has sandboxed apps aka uwp/winRT. (a derivitive of freewrl runs in uwp). Android apps are sandboxed (a few derivitives of freewrl run in Android with NDK or Java frontends).

Andreas Plesch, 6th October 2016

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

Leonard focused on what kind of 3d content x3d should be able to express in the future: postprocessing shaders, all formats for which three.js loaders are available ...

Orthogonal to content would be what 3d experience platforms x3d should be able to support: web, desktop, vr, ar, non-interactive rendering ...

Another axis might be groups of people both on the application development side and on the consumer side x3d should target: industry, science, government, simple games, mobile, art...

Another dimension in a sense is community building, PR, outreach, organizational structure around x3d: consortium, membership, openness ...

Not sure defining this space is helpful but identifying x3d's natural position in it may help figuring out its purpose.

Would a narrower purpose help x3d's relevance? A-frame only targets VR on the web, for example.

Another way to project into the future may be to explore the change in purpose and use from vrml days to now. Is there such a change?

Substituting purpose with value, archival quality, stability, abstractness, multiple encodings, multiple implementations come to mind which future x3d versions need to keep in mind.

X3dom and Cobweb as npm packages may help with immediate popularity.