Purpose of X3D

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.

John Carlson, 6th October 2016

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

Considering we only used to be able to get a single X3D browser on some platforms, I think cobweb's progress has been amazing.

Cécile Muller, 7th October 2016

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

X3DOM is already on npm: https://www.npmjs.com/package/x3dom. Although it's probably not the latest version as it appears last updated 10 months ago.

Doug Sanden, 7th October 2016

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

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.

.web3dit image file format I have a text-only image format .web3dit (i=image t=text (vs xml or json)) I could donate. Handles 2D, cube and 3D textures. Then web3d would have its own image format too. (Its really just pixeltexture in a separate file, with a few tricks). I use it for round-trip testing. But if you are desperate for web3d to own texture file formats it might be a good starting point. https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/opengl/LoadTextures.c L.620-905

Given that we have maybe 7 part time people (right now) where does X3D go? 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.

IDEA: onus shifting: When someone proposes something new, they also submit refactored specs. For example if I propose a change to rendering modulation, Protos_II, .web3dit image file format - I would need to also submit refactored specs pages that show how the old would keep working/stay valid in specs, while allowing the new.

David Murphy, 7th October 2016

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

with the resurgence of interest in VR (mainly since the introduction of the Oculus Rift), I too have wondered about the place of X3D in this quickly evolving space.

For VR developers the choices seem to be, to either use games engines, with sophisticated graphics capabilities, etc. (e.g. UE4 and Unity), or scene graph languages (X3D, Java3D, O3D, OSG, etc.).

WebGL gives us access to the host GPU, which is a fabulous addition to our technology stack. However, it is not a ‘friendly' development language (not easily scalable, reusable, and not as accessible to non-programmers). Hence, declarative libraries such as three.js, babylon.js, etc. ( https://en.wikipedia.org/wiki/List_of_WebGL_frameworks ) have emerged to address those shortcomings.

Then we have Mozilla's A Frame, which is a web-first entity-component-system framework for three.js. Designed to work with WebVR, which integrates VR hardware and systems.

So, I hope to see X3D evolve to work with WebGL (let’s dispense with the need for these scene graph libraries) and WebVR (access to hardware and systems).

I have never viewed X3D as a file format, for me it has always been a scene description language with additional features.

X3D is a standard and must interoperate with other standards, e.g. glTF, COLLADA, mpeg. The capabilities of X3D (extensibility + features) and the declarative nature of the language are what makes X3D attractive to develop in (and teach in my case). The guarantee of a standardised version, and interoperability with other standards are what makes X3D viable.

Joe Williams, 7th October 2016

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

For example if I propose a change to ...

As I understand how the process works, you would want to propose the feature to the x3d-public and at some point directly to the X3D working Group, where we could get member consensus to incorporate the idea. Then an existing or new working group would produce a consensus Working Draft that described changes and additions to the standard, and at least one (open preferred) running example. Those deliverables would be examined by the X3D WG and when consensus agreement is reached the proposal would be forwarded to the BOD for approval.

With approval of the bod the originators or Web3D editor(s) would upgrade the Working Draft to what is called a Committee Draft (CD) and would then apply to ISO to create a project with a description and timetable accompanied by the Committee Draft (CD). The ISO member nations and member organizations (of which Web3D is one) would review the proposal and CD text and art then formally submit their comments and vote to approve or disapprove the concept.

If CD is approved for advancement, then all comments are incorporated and new documentation is fully integrated into the standard to create the next draft to be considered. This is called the Draft International Standard (DIS) which is again is passed from the originating wg to the X3D wg, then to the Bod for approval. Now we must also examine second and subsequent implementations actually running in multiple X3D tools. If approved again by Web3D, the DIS is submitted to ISO and the members again provide comments and a vote to go ahead or drop.

The comments from DIS are incorporated into what should be the final product, called FDIS Final Draft International Standard. This is again run through the web3d approval process (originating wg, X3D wg, and bod) and resubmitted to ISO. If DIS comments have been appropriately dealt with, then the document should get to final status as IS, International Standard.

So yes it is complex and tedious dealing with general and technical inputs and comments from a wide range of interested parties over what might be a long period of time but that is also what keeps the standard more or less immune to manipulation and false paths.

Yves Piguet, 7th October 2016

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

If I understand correctly, x3dom doesn't follow this path. Am I correct? Is it because of the complexity and tediousness? What's the feeling of people involved with X3D ISO standardization?

My next question would be about the kinds of "proposals" I've made. I guess they have zero chance of being considered. I had a vague hope that the more modest yet useful ones might have triggered the interest of someone who could have pushed them forward, but even that seems crazily optimistic.

Andreas Plesch, 7th October 2016

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

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

X3DOM is already on npm: https://www.npmjs.com/package/x3dom Although it's probably not the latest version as it appears last updated 10 months ago.

ok, that's great. Here are npm download stats:

https://npm-stat.com/charts.html?package=x3dom&from=2015-10-05&to=2016-10-05

36 per month on average, eg. about one per day, is more than I thought given that npm downloaders would be in the more professional developer category.

Mitch Williams, 7th October 2016

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

FYI:

X3D is used inside Samsung’s GearVR. I’m part of the X3D development team for GearVR.

It’s still a work in progress but you can render X3D scenes and animations plus interactivity with the TouchSensor.

Don Brutzman, 7th October 2016

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

Had a misunderstanding earlier this week - Cobweb on "Microsoft Edge" means Windows 10, not earlier Windows running Internet Explorer 11 in "Edge mode". Screenshot attached.

http://titania.create3000.de/cobweb

Differences may have more to do with Javascript 6 feature support than 3D graphics compatibility. The X3D Examples now make it easy to show X3DOM running fine in all HTML browsers, with Cobweb coverage getting closer and closer.

Of course IE problems solve themselves over time, naturally but there are a LOT of platforms which are IE-only so somebody may want to help Holger with that big opportunity now.

Step by step we are deploying everywhere. Legacy Windows with Internet Explorer is partially conquered, everything else just works.

Useful metric for all our work: "assume success, then what?" Welcome to the new playing field.

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

John “double smiley” Richardson

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

anywhere we want, of course.

I'm heading for Open Web Platform (OWP) without losing any of the places we've been before. First law of engineering: "if it ain't broke, don't fix it."

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

agreed John - support for X3D Immersive Profile (aka VRML97 capabilities) was tipping point to integrate Cobweb as native viewing mode for all X3D example archives (rather than plugin). Well worth the work.

It will be interesting to see if the X3DOM community resumes work on adding support for essential X3D nodes and components. Much potential progress has been dormant for over a year. Many "lessons learned" appear to be sitting on the table.

Considering we only used to be able to get a single X3D browser on some platforms, I think cobweb's progress has been amazing.

Amen brother!

Tom Sparks, 7th October 2016

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

we have ExternProtoDeclare node to define new nodes.

But you have brought up one of my bugbears with X3D, there is so much research build upon X3D/VRML97, but it seam like the source code get discarded once the paper is written.

some examples that should/could be added to X3D: "Remote Rendering of Massively Textured 3D Scenes Through Progressive Texture Maps", J-E. Marvie and K. Bouatouch "A Vrml97-X3D Extension for Massive Scenery Management in Virtual Worlds" - Web3D 2004, Jean-Eudes Marvie and Kadi Bouatouch "Interactive Walkthrough of Large 3D Models of Buildings on Mobile Devices", Alessandro Mulloni, Daniele Nadalutti and Luca Chittaro "Streaming and Synchronization of Multi-User Worlds Through HTTP/1.1", Jean-Eudes Marvie, Pascal Gautron, Pascal Lecocq, Olivier Mocquard and François Gérard

ps: I have contacted the authors