[x3d-public] X3D V4 Draft Requirements Proposal
Joe D Williams
joedwil at earthlink.net
Tue Mar 28 11:48:17 PDT 2017
> Would it be possible to implement the SAI over DOM?
The idea here is that the <x3d> ... </x3d> fragment operates an
'internal' event system to support features like timers,
interpolators, sensors, routes, you know, the 'live' interactive scene
stuff. Not independently, but to the extent we wish the host DOM to
interact with the scene, we support the 'external' DOM event system.
Conceptually, the 'internal' event system, supported by interactive
SAI including scripts and prototypes, supports certain interfaces that
allow the host 'external' event system to interact with the 'internal'
event system of the <x3d> fragment.
So, if we can't maintain the basic interactive <x3d> 'internal' event
system for the standard methods of anmation and interaction found in
X3D, then, well, no realistic fun to be had If however, we help
extend html ability to work with embedded fragments that are
interactive with the host dom, then we have something very useful.
> I know that this is not written well.
Yeah, the stuff is hard, but a central idea is how to map an html
read-only to x3d iniiialzeonly?
>> I believe the HTML5 Custom Elements spec ...
I hope we are not in that category. not <x3d-x3d> no nevvvverrrr.
>> d) All X3D nodes shall support all HTML Global Attributes
>>
>> Is this equivalent to requiring that X3D nodes need to derive from
>> HTMLElement as defined in the DOM ?
>
> Interesting point. If so, I wonder what else that requires for each
> X3D
> node.
Yes, there must be a set of global attributes, a set of global events,
and a set of global styles. With the idea that <x3d> is an html
document fragment then maybe x3d gets to define standard html/dom/css
'external' interfaces to the fragment and a similar or different set
of html/dom/css 'internal' interfaces to nodes internal to the
fragment. The 'internal' html/dom/css globals depend upon how the
<x3d> 'internal' scenegraph allows access to the 'external' dom and
support for standard x3d interactive events.
But still that is only for the 'top' or root-of-all-roots context. The
x3d Inline is adding to <x3d> all the potential complications that the
object node added to html. That is, the inline and object elements do
the same features - to provide an embedded (child) execution context
with possibly a whole different (sub)set of rules than the host
context. Of course the rules for communication between the host and
child context was carefully controlled.
So x3d in html implementors have already thought of these details and
are showing actually fantastic results. The only question the x3d in
html standards-track has to ask is: What would you do if you started
from scratch Now? What x3d simulation and animation features can
authors and users hope to be 'built-in' to html5+ w3c browsers in 5
years?
I mean built-in using the idea that <x3d> is processed like native
html code and xed intensive stuffs like simulations, animations, and
interactions would have high-performance 'native' impleentations.
The last five years has brought a lot forward. I don't think the webgl
guys are giving up so web authors and x3d implemetations will have
that available on all platforms. The support of script in html has
improved a lot, so that say 10 years ago an x3d plugin viewer had no
choice but to bring in its own scripting engine - not worth trying to
share the host's - but now there is a much better chance of sharing
script execution context between document fragments(?).
Again, what would they do now?
I guress there is a chance that the most current answer(s) will come
from down-under. No, not that - I mean the future meetings in
aussielandia.
>
> Deformable skin from joint animation calculations are typically
> carried
> out on the GPU. Too much for serial processors. I'm sure there are
> other
> items.
Hi again, your basic lesson for this is still the original scripted
boxman in the examples. That is how it gets done. If optimized for a
GPU, then they may have a rule that for their best efficiency for this
would be maybe that it is desired that you actually assign each vertex
to four (or sets of four) joints. But that is just convenience and
optimization for a target player in a target although common gpu
platform. My point would be that x3d specs would not need to specify
that every vertex has to have weights for four joints in order to work
as expected.
Don, I lost your comment to this thread, but to me, your's are again
the main spirit. X3D does not need to leave anything behind in these
next steps of becomes what to me looks like it wants to be a
well-behaved, widely accepted, technically competent, and most of all
friendly to auhors and users - that is the x3d fragment entity part of
a w3c document playing freely in a w3c web browser.
Thanks and Best,
Joe
----- Original Message -----
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: <x3d-public at web3d.org>
Sent: Monday, March 27, 2017 9:56 PM
Subject: Re: [x3d-public] X3D V4 Draft Requirements Proposal
> On 3/27/2017 8:05 PM, Andreas Plesch wrote:
>> Hi Leonard,
>>
>> this is a good, demanding list. Some quick comments below.
>
> Thanks Andreas. Comments below. Some extra stuff removed for
> clarity.
>
>
>>
>>
>> 1) Look "like" HTML (5).
>> a) Elements (nodes in X3D-speak) shall be case independent
>> b) Attributes (fields in X3D-speak) shall be case
>> independent
>> c) X3D nodes shall not have name conflicts with any
>> HTML-defined elements
>>
>>
>> I believe the HTML5 Custom Elements spec requires a prefix-name
>> format
>> for element names. While allowing lowercase should we also allow
>> 'x3d-transform' format alternative names ?
>
> In that case, each node would be aliased with a HTML5 Custom Element
> compatible name. I don't know the answer. It might depend on how
> "integrated" the spec is with HTML.
>
>
>>
>>
>> d) All X3D nodes shall support all HTML Global Attributes
>> (https://www.w3schools.com/tags/ref_standardattributes.asp
>> <https://www.w3schools.com/tags/ref_standardattributes.asp>)
>>
>>
>> Is this equivalent to requiring that X3D nodes need to derive from
>> HTMLElement as defined in the DOM ?
>
> Interesting point. If so, I wonder what else that requires for each
> X3D
> node.
>
>
>> 2) Function "like" HTML (5).
>> a) All nodes shall be fully integrated with the DOM [This
>> may
>> need to
>> change if certain nodes need to remain hidden from the DOM. For
>> example,
>> the manner which X3DOM implements Inline.]
>> b) The scene graph does not need to be DOM (or a portion of
>> it).
>>
>>
>> Not sure I can follow here.
>
> X3DOM keeps a separate scene graph from the DOM. The rendering
> occurs
> from the scene graph. Changes to the DOM cause changes to the scene
> graph and vice versa. I did not want to preclude that operation.
>
>
>>
>> c) Changes to the DOM shall be reflected in the scene graph
>> d) Changes to the scene graph shall be reflected in the DOM
>>
>>
>> Using the DOM to maintain and reflect state is often considered
>> slow.
>> Could d) be optional ? Changes to the scene graph cause events
>> which
>> can be listened to if required. (This is why cobweb-dom does not
>> reflect back interpolator output to the DOM at this point).
>
> Perhaps it is better to set all current fields that are initialized
> to
> be (generally) non-updated. If you want to see a particular value,
> you
> need to listen to the appropriate event. Certain events would cause
> the
> initialized fields to be updated. I know that this is not written
> well.
>
>
>>
>> e) Events are handled as HTML events
>> f) DOM is the external (i.e., from the web page) API to the
>> scene graph
>>
>>
>> X3dom does it that way. One could add that this external API could
>> be
>> implemented using the SAI thereby guaranteeing X3D event flow
>> determinism.
>
> Would it be possible to implement the SAI over DOM? I am concerned
> about
> having more than one fundamental API. It will cause confusion and
> errors.
>
>
>>
>>
>> 3) X3D shall support the evolving web standards for flat-3D
>> (WebGL), VR
>> (WebVR) and AR (nothing yet).
>>
>>
>> I still want to complete my diff between webvr draft standard and
>> x3d.
>> However, it looks like the webvr standard already evolved quite a
>> bit.
>
> I'd like to see that when you are done.
>
>
>>
>> 5) Additional features shall be added
>> a) Deformable-skin joint based animation
>> b) Support for multiple geometry formats, including OBJ,
>> glTF
>>
>>
>> I have a pretty good idea about gltf2 support in x3dom, see my
>> x3dom
>> GitHub issue. But since it is quite a bit of work, it will be some
>> time/use case.
>>
>> c) Increased Material support with a standard library of
>> pre-defined
>> shaders
>>
>>
>> Three.js has good shaders including for PBR. But again quite a bit
>> of
>> work. Not sure if Fraunhofer is that engaged since there may be
>> commercialization interest.
>
> Including programmable shaders in declarative language and not
> providing
> pre-defined operations seems like a poor choice. This is an attempt
> to
> start to rectify it.
>
>
>>
>> d) Mechanism to navigate a scene without a pointing device
>> e) Mechanism to touch or select objects without a pointing
>> device
>>
>>
>> Or with wand or controller.
>>
>> f) Review other 3D/VR display technologies (XML3D, A-Frame,
>> GLAM,
>> etc.) to determine if there are features that should be
>> included
>>
>>
>> The three.js examples are also inspiring. Postprocessing of the
>> rendered frame in another shader stage comes to mind. There are
>> probably many more modern graphics methods which need some support.
>> Ambient occlusion ssao ? Motion blur ? Distance defocus ?
>>
>> Generally, the vrml spec. was written before the advent of powerful
>> GPUs (massively parallel super computers) where it now can be
>> faster
>> to repeat the same fragment shader operation for each pixel
>> (perhaps a
>> million times) rather than update data between cpu and gpu once.
>> Not
>> sure what the consequences exactly are other than being shader
>> friendly in some way.
>
> Deformable skin from joint animation calculations are typically
> carried
> out on the GPU. Too much for serial processors. I'm sure there are
> other
> items.
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
--------------------------------------------------------------------------------
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
More information about the x3d-public
mailing list