[x3d-public] X3Dng Specification Document

[Andreas Plesch]

Date: Thu, 3 Nov 2016 17:55:16 -0700

> From: Leonard Daly <Leonard.Daly at realism.com>
> To: X3D Public <x3d-public at web3d.org>
> Subject: [x3d-public] X3Dng Specification Document
> Message-ID: <26bfe7d1-7876-e1f6-0581-f5fdb5e2066e at realism.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> I have formally submitted the "X3D Next Generation" specification
> document for Working Group review. The document is also publicly
> available at http://tools.realism.com/specification/x3d-next-generation.
> This document describes how X3D (as declarative 3D) is integrated into
> the HTML and DOM environment. Many new nodes are added to bring some
> capabilities up to current industry practice.
>
> This document is the initial public draft and may be updated or revised
> at any time. The version submitted to the WG is a copy of this content
> taken on 2016-11-03.
>

Thanks for taking on this large task and putting together a lot of good
material in this initial public draft covering many aspects.

I wonder if there is a way break up the large set of revisions into a
progression of incremental steps to get tangible results (eg. a new spec.)
sooner. So perhaps there could be X3D NG after a X3D V4.0 ?

Is it possible to divorce the introduction of (some) new nodes from HTML5
integration and event revisions ?

Just thinking about ways to make this task more manageable.

Here are some more specific reflections after reading:

Events:
x3dom (and cobweb) still uses x3d (style) events for routing:
https://github.com/x3dom/x3dom/blob/master/src/nodes/Core/X3DNode.js#L233
So there may be still a need for x3d events in addition to only using dom
events if only for performance reasons. x3dom calls x3d events 'messages'
and never implemented timestamping as it does not have a need. (Test route
loops ?).

GeoElevationgrid:
is marked deprecated or excluded from the full HTML profile, presumably
because it is considered similar to Elevationgrid. However, it is probably
the most used node in the Geospatial component and an equivalent geometry
cannot easily be generated by Blender or automatic index generation of
GeoCoordinates in an IndexedFaceset.
With regards to Elevationgrid, I find that my implementation of an
equivalent component for A-Frame is relatively popular, more so than my
implementation of IndexedFaceset. So for the casual user base there is
probably demand and space for such a node.

Color Interpolation: [minor]
perhaps consider RGB and HSV (and other color spaces) either as
alternatives for COLOR interpolation space (perhaps called COLORRGB and
COLORHSV) or as alternative for LINEAR algorithm for COLOR interpolation
space.

-Andreas

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161105/14768cb4/attachment.html>