[x3d-public] procedure for timely resolution of straightforward X3D specification issues

[Yves Piguet]

Leonard,

Thank you very much for your detailed answer.

> The X3D WG has decided not to pursue a V3.4 specification, but going direct to V4.0. The biggest thing in V4.0 is full support for running in a web browser.
> 
> I have been working on a proposal for V4.0. It is at http://tools.realism.com/specification/x3d-v40 This is not a complete document, but extends the V3.3 document. This is currently a work in progress so there are areas that are not complete and insufficiently specified. I am interested in hearing from people who wish to contribute.

Thanks. Very interesting.

Don, sorry for my inappropriate use of the word "closed" for the X3D Consortium. I just wished something similar to the drafts of W3C so that everybody can have an idea of the future. Leonard's documents are perfect.

>> What I think would be very useful is rationales for the decisions behind X3D. The X3D xml-based format, for instance, seems to be by far the preferred official format, relegating VRML classic to some historic artifact. I assume this means that nobody is supposed to write X3D in a text editor. Standard-compliant JSON obviously isn't meant to be written or read by hand, except for debugging.
> 
> There are parts of X3D (e.g., modeling, complex animation) that probably should never be written by hand -- it's too easy to mess up and too difficult to maintain. Other parts are good to keep in human-readable systems. Going into V4.0 the XML version does make sense because that integrates directly into HTML.

I wonder if this reason is crucial enough. Inline SVG or MathML is useful to avoid too many small external files, but 3D is less common: typically it's for figures in a technical document, or (more or less) full-window or full-screen immersion. Inline X3D could be useful if HTML itself can be nested in lieu of Text nodes, but that won't be easy without commitment from major html browsers.

The position of xml as a universal format is less clear than 15 years ago: html5 is html, not xhtml, and relies heavily on non-xml technologies such as css.

From a technical point of view, X3D can also be embedded as ClassicVRML in HTML script elements using a JavaScript library.

>> With the buzz around VR headsets promised for 2016 and all related VR developments on the software side, X3D should be in a good position to be an important piece of the puzzle. 
> 
> I agree. We need contributors.
> 
>> I'm not sure it will.  Here are three ideas I humbly share:
>> 
>> - Make developing with X3D more fun by reducing its verbosity. For example put more emphasis on VRML classic (renaming it?), and simplify some recurring constructs (Shape, Transform, Script or interpolator nodes required even for trivial things such as converting an SFFloat angle to an SFRotation).
>> 
> 
> The focus has been to incorporate X3D directly into HTML. This is a more XML-like approach. This approach allows (but does not require) integration with the DOM. Using ClassicVRML into an HTML document makes it look more like user-content for display, rather than 3D instructions.

The risk I see with promoting mainly the XML encoding, and replacing the VRML event model, is that X3D will be a hidden format with a steep learning curve. Less people will play with it directly and ask for it. With VRML, you can quickly have some cool interactive shapes to play with or animate. I don't think X3D can win on the output quality (or coolness or wow factor or whatever), because demos or games written directly with WebGL can always look better. If the step from X3D 3.4 to 4.0 is too large, fighting against concurrent formats (A-frame etc.) will be difficult.

> I am interested in how you would simplify the recurring constructs.

You could allow the fields of Transform and Appearance directly in X3DGeometryNode, for instance. But if the future lies mainly in XML, and other formats like JSON not meant to be authored by hand, it doesn't matter much.

> You might wish to take a look at the new proposed node Animate, which includes interpolators. The description is at http://tools.realism.com/specification/x3d-v40/changes-additions-x3d-v33/animate.

I will, thanks.

>> - A large, cool application, such as a totally distributed version of Second Life. Simplicity should be one of the goals to create a community quickly. Most of the pieces are already available.
> 
> This has been discussed. At least to the understanding of the people involved in the discussion, this type of project is far more complex and difficult than it initially appeared to be. If you have specific ideas on how this could be done, please post them.

I haven't thought a lot about it. Maybe an architecture similar to hypertext, based on HTTP, with some kind of doors to replace hyperlinks, and APIs yet to be designed to let visitors be visible as avatars, communicate and move assets around. I don't know. You must be right, it's difficult. I'm more interested in virtual devices (shapes + simulated behavior) than in immersive virtual worlds.

Yves