[x3d-public] [x3d] Ideas for discussion during V4.0

Don Brutzman brutzman at nps.edu
Mon Dec 7 17:00:10 PST 2015 

Andreas, thanks for these excellent ideas.

Please advise if you might be willing to join us on a weekly X3D teleconference to ensure that your points are well understood.  Open invitation, whenever convenient.  We continue to find such dialog very helpful.

When we get into details, respecting intellectual property rights (IPR) becomes even more critical than usual.  In order to protect the IPR integrity of X3D so that it cannot be later attacked via lawsuit, we are always careful to only work with open or member-contributed technologies... so some of the things you mention may or may not be viable.

That said, we are also always interested in interoperability, so other closed technologies sometimes become actionable in that manner.

We will always be open to good suggestions and public review.  Meanwhile I encourage anyone who is interested in the future of X3D to join Web3D Consortium, participate in the X3D Working Group and encourage further support.

Thanks once again for your steady and seriously valuable contributions, looking forward to further progress together.


On 11/30/2015 9:46 PM, Andreas Plesch wrote:
> Here are couple of ideas for discussion. Most of those likely have been looked at and repeatedly but getting them on a page helped may help (as it did for me).
>
> 1) start from use cases:
>
> - Fraunhofer may have the best insight into how x3d is or would be actually used for real applications on the web.
>
> - find good applications of other declarative 3d web languages such as scenejs or xml3d or GLAM
>
> - many applications will want to use a mix of declarative and imperative programming partly due to the fact that web programmers are used to imperative ( although the climate seems to change due to web frameworks and web components.)
>
> - many will see x3d just as static 3d content (Shape) format to be imported into a webgl canvas controlled by three.js or exported from blender
>
> - good, visual x3d editors/generators are key: game engines (unity) have those for their content; titania, x3dedit
>
> - what if anything is needed to integrate with web frameworks (angular, react)
>
> 2) incremental evolution vs. restructuring
>
> - structural changes where there is overlap with the web platform: events, scripting (follow x3dom)
> - or start from scratch like GLAM, base next x3d on GLAM
> - protos ? Web components are not (yet?) ready to replace protos;
>
> 3) minimalist vs. rich
>
> - have a smaller core component ?
> - the richer, the harder it will be to be accepted by web browsers.
>
> 4) the competition for 3d on the web
>
> - hard to beat three.js: well known and application programmers like it.
> - but still early: full x3d actually not tested on web since not really available; cobweb only starts to change that now
> - how successful is x3dom; may be much more widely used if available as packet through one of the js managers (npm and such);
> - what are FHG plans for x3dom ? There is probably enough critical mass (apps like Shapeway) to justify foreseeable support.
>
> 5) v4 vs. future
>
> - should there be both a x3d v4 and a x3d ng living standard ?
> - is the goal to get native support by web browsers like html5?
> - did browser makers (Mozilla, Google, MS) voice any ideas for 3d on top of webgl at some point ?
>
> Apologies for the long list, hopefully it can contribute to a constructive discussion.
>
> Andreas
>
>
> Subject: Re: [x3d-public] [x3d] Ideas for discussion during V4.0
>
>          Concepts: Name scopes and node name conflicts
> Message-ID: <565B94E7.4060204 at noegenesis.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Being not a deeply technical computer graphics person, but being a
> member of the Board as a Professional Member representative, I wanted to
> voice my opinion regarding the direction of X3D 4.0 as I interpret it
> from Don's post below.
>
> To remain a viable and robust 3D standard for years to come, and to in
> fact be an archival 3D standard, X3D must remain relevant.  When I say
> relevant, that means to be easy to understand, to take advantage of
> current technology trends and to be widely adopted. Whereas X3D has
> weathered many ups and downs in the 3D industry over the past 25 years,
> outlasting numerous 3D files formats and initiatives, it is a completely
> different environment now.
>
> The democratization of 3D content is upon us, fueled by decades of video
> game technology providing the impetus for better and better software
> tools, higher and higher performance graphics hardware, and a culture
> that now demands 3D experiences both within and without of the video
> gaming experience.  These forces have permeated the mobile industry,
> which is rapidly becoming the hardware platform of choice.  WebGL has
> enabled 3D within browsers without a plugin, making the browser an ideal
> distribution vehicle for 3D data and content, regardless of the device.
> Soon all mobile devices will be 3D content generators, thanks to built
> in 3D cameras, and virtual reality displays, thanks to Cardboard and
> GearVR (and others to come).
>
> In my opinion, X3D cannot wait out the 3D storm this time, because
> forces influencing this industry are going to fundamentally change how
> 3D fits into society, (think 3D printing, VR videos, etc.). X3D must
> adapt to meet this change, and with the web being the ideal distribution
> vehicle, X3D must adapt to the HTML environment.  Don's post to me
> speaks instead to a stay the course strategy, maintaining paradigms in
> contradistinction to HTML.  There are key concepts in X3D which clash
> with HTML, and if not reconciled, this will be to X3D's detriment and
> potential road to irrelevance.  Why?  Simple: Compare the number of web
> developers to the number of X3D developers; the difference is several
> orders of magnitude! This is the target audience of X3D, and they will
> not tolerate learning 2 different ways to do many of the functions
> necessary to create a dynamic 3D environment.  Some may say that
> different vertical industries will create their own proprietary
> applications and that web development is irrelevant, and I argue that
> while that is true, the volume and value of those applications pale in
> comparison to web applications within any industry.  Being part of one
> of the biggest vertical industries (healthcare) as an IT executive, I
> can tell you that off-the-shelf technology based on the web/cloud is the
> preferred choice.  Web applications are easier to maintain, easier to
> implement and easier to have personnel trained on their use.
>
> Many may argue that this approach can endanger backwards compatibility,
> which is critically important for an */archival/* standard, but to that
> I say that members of the Consortium are very smart and capable of doing
> things that people say never could happen, like having polygons and
> voxels living together (gasp!) in the same scene.  They can develop
> converters for old content so that 20 year old content still runs on the
> newest browsers.
>
> Many may say that web developers aren't our target audience, which to
> that I say, are you interested in protecting some academic institutions
> and a small portion of industrial applications from from vendor lock-in,
> or do you want to protect the majority of content developers, consumers
> and the majority of industrial applications from this lock-in (whose
> savings would then be passed on to the consumer)?  I choose the latter.
>
> The way forward does not lack suggestions: Leonard Daly has done a
> significant amount of thinking and work on providing a vision of a
> possible X3D 4.0 that blends well with HTML concepts, Tony Parisi has
> developed GLAM, another "declarative language for creating 3D web
> content" and Kristian Sons' post on November 26 with subject: "XML3D 5.0
> and X3D V4.0" (XML3D being another declarative 3D web language) provides
> great lessons learned on some ways that X3D can adapt HTML concepts.
> The Consortium can co-opt all the best from these suggestions to provide
> a phenomenal 3D standard for the future.
>
> I have been involved in some form with the Consortium for 20 years, from
> the VeRGe meetups organized by Linda Jacobson and Timothy Childs in the
> 90s, to founding a startup using VRML technology in 2000, to
> representing the Consortium at SIGGRAPH and Professional Members on the
> Board for the last several years.  I want the Consortium to succeed in
> its original mission to provide an open, ISO ratified, royalty free,
> archival standard that is like an HTML for 3D on the web.  To achieve
> that mission, the Consortium needs to make X3D a web native language.
>
> Thank you,
>
> Michael Aratow, MD
> Board of Directors, Web3D Consortium
> Chief Medical Information Officer, San Mateo Medical Center
> CEO, VRecover
>
>
>
>
>
>
>
> Subject:        Re: [x3d-public] [x3d] Ideas for discussion during V4.0
> Concepts: Name scopes and node name conflicts
> Date:   Wed, 18 Nov 2015 09:28:26 -0800
> From:   Don Brutzman <brutzman at nps.edu>
> Organization:   Naval Postgraduate School
> To:     Roy Walmsley <roy.walmsley at ntlworld.com>
> CC:     X3D Graphics public mailing list <x3d-public at web3d.org>, X3D
> Graphics Working Group <x3d at web3d.org>
>
>
>
>
> [cc: x3d-public]
>
> Thanks for the excellent leading questions and deep exploration in
> today's X3D working group teleconference.
>
> Questions and my first-cut responses follow.
>
> On 11/18/2015 2:40 AM, Roy Walmsley wrote:
>   > Some things to consider and/or discuss re X3D V4.0 during X3D WG meeting.
>   >
>   > ?What is DOM?
>
> DOM is the simplest possible API for accessing and traversing an
> HTML/XML tree structure, with accessors typically getting/setting nodes
> and attributes using string values.
>
> DOM also includes several event models that are associated with
> navigating a tree, and passing values from one node to another.
>
> DOM bindings have been formally specified for JavaScript and Java. No
> doubt a number of libraries exist in other languages as well.
>
> The essential stability of the data structures, and the potential
> flexibility of the event-passing mechanisms, are the key to DOM's
> long-running stability, popularity and effectiveness.
>
>   > ?What specification(s) should we be normatively considering?
> (http://www.w3.org/TR)
>
> DOM level 3 has been a stable W3C Recommendation for 10 years
> http://www.w3.org/TR/DOM-Level-3-Core
>
> DOM behavior is central to HTML5 design.
>
> 3 Semantics, structure, and APIs of HTML documents
> http://www.w3.org/TR/html5/dom.html#dom
>
> DOM level 4 is where DOM refinements are heading.  The editors include
> critical individuals in this long evolution.  Based on current status,
> it is pretty far down the W3C Process towards final approval.
>
> W3C DOM4, W3C Proposed Recommendation 6 October 2015
> http://www.w3.org/TR/dom/
>
> An important working document, but not normative, is the "DOM Living
> Standard" by the whatwg
> https://dom.spec.whatwg.org
>
> Of course "living" standard/document is a euphemism that actually means
> "unstable" or "nonstandard."
>
> I believe our strategy should be:
>
> a. Let HTML5 be HTML5 and let X3D be X3D.  Each is well defined.
> b. Let X3D v4 add minimal general capabilities that provide a clean
> elegant stable alignment with HTML5 and DOM level 4.
> c. The essence of this alignment is event passing between HTML5 DOM and
> X3D event graph.
> d. Do not add any functionality to X3D that breaks the current event
> model, or might have to change in the future when further DOM
> embellishments occur.
>
> Suggest that the next question to explore is:
>
> - What is SAI?  What are differences between "internal" and "external" SAI?
>
> In short, SAI reconciled internal event passing and external event
> passing with the series of X3D API specifications.
>
> No longer needed:  External Authoring Interface (EAI).  Nevertheless
> interesting (and possibly helpful) approaches were specified there.
>
>   > ?How does DOM compare to SAI?
> (http://www.w3.org/TR/DOM-Level-3-Core/introduction.html and
> http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/concepts.html#General).
> Are they conceptually different?
>
> Comparing/contrasting each of these approaches with DOM APIs for tree
> manipulations and event passing will be fruitful.
>
> X3DOM (and presumably Cobweb) provide existence proofs that event
> passing between each is possible and can be pretty simple.
>
> Key X3D constructs:  ROUTEs, Inline IMPORT/EXPORT.
>
> Also important parts of event-model review (identified by Joe) are
> Script directOut functionality, the notion of a render frame (time step)
> and event cascades, loop-breaking rule, etc.
>
> Since many events between X3D and DOM will be related to user
> interaction, closely aligned topics are javascript callbacks, browser
> render loops, etc. etc.
>
> Our eventual X3D v4 specification solution will define DOM constructs
> with equivalent 2-way functionality.
>
>   >  Should SAI be renamed / substituted by DOM?
>
> No.  Such a change would likely break X3D event semantics, either now or
> in the future.  That outcome is not acceptable.
>
> Comparisons between SAI, EAI and DOM will let us assess what needs to be
> specified to align X3D and DOM.
>
>   > ?What does the DOM say about namespaces? How have MathML and SVG been
> incorporated?
>   >
>   > ?Can we point to examples that illustrate difficulties?
>   >
>   > ?What practical steps should we take to progress?
>
> Worthy questions deserving further elaboration.  We need to include CSS
> and Javascript in that review as well.
>
> If/when we do this correctly, X3D rises to the level of being an
> effective addition that integrates well within the Open Web Platform (OWP).
> http://www.w3.org/wiki/Open_Web_Platform
>
> Precise terminology and descriptions are critical ingredients for
> effective design.  Thanks for all due diligence on these central topics.
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151129/584481fe/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 29 Nov 2015 20:08:56 -0500
> From: Andreas Plesch <andreasplesch at gmail.com>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] [X3D-Public] camera, random path on a sphere
> Message-ID: <o48ahpi5264e3y3nyvxi4kn9.1448845736086 at email.android.com>
> Content-Type: text/plain; charset="utf-8"
>
> On November 29, 2015, at 2:01 PM, x3d-public-request at web3d.org wrote:
>
>> Message: 2
>> Date: Sun, 29 Nov 2015 13:01:06 -0600
>> From: John Carlson <yottzumm at gmail.com>
>
>> I have taken the viewpoint tour from Joe's linked VRML below and put it into my JSON loader.? See a stripped down version of my loader at: http://coderextreme.net/X3DJSONLD/>Below as text is the X3D for doing a random tour based Joe?s original viewpoint tour.? I don?t have a link for this because I want people to view in on their desktop.? Note that it doesn?t do a great circle tour as I would want.? Is there something in GeoVRML or GeoX3D that does a Great Circle Interpolator?? Thanks!
>
>
> John,
>
> I added an SFBool option onGreatCircle for GeoPositionInterpolator in x3dom when I implemented the node. This is non-standard. The standard says somewhere that interpolators interpolate linearly.
>
> Not sure how this can be used in a non-geospatial scene, however, especially without a script node. I guess you could use the geocentric geoSystem and wrap the viewpoint in a transform to scale it down to how you need it. For example, to get positions on a sphere of 10  m radius you would need to divide coordinates by ca. 637000 .
>
> It might also work to  just provide non-geospatial coordinates to GeoPositionInterpolator with the GC geoSystem as long as they are located on a sphere centered at the origin. The interpolated coordinates should still be on the same sphere.
>
> Cobweb does not support geospatial last time I checked.
>
> Hope this helps,
>
> Andreas
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151129/e47b476a/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 80, Issue 58
> ******************************************
>
>
>
>


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

More information about the x3d-public mailing list