[x3d-public] Fascinating Discussion on WebVR List

[Joe D Williams]

> Would it be ideal to separate X3D into MVC?  Where would the lines 
> be drawn?

Hi John,
In HTML, one big line is CSS, another is DOM scripts. CSS is used to 
style content and layout and even actually be content at times. DOM 
scripts are used to change CSS and content. One way is to build 
something very complete then only show the parts that are used at the 
time. In html, this works but has meant adding a whole new level of 
support for handling page updates. The idea that CSS has the words 
cascading in it must mean something. Maybe that in order to update the 
document by changing the applied CSS, the browser must process a 
detailed default and author-defined hierarchy of content organization 
in the expected ssquence. Not sure but this seems like the DOM's first 
real taste of running a complex ordered set of sychronized events to 
produce the next frame. Before this, html didn't much need the 
time-stamped event cascade operations of X3D.

On this list I heard from an MVC in X3D candidate at NPS and he seemed 
happy.

Peitso, Loren (CIV) <lepeitso at nps.edu>

"Agreed, this is how I am managing my dissertation.  I am writing a 
generalized distributed, networked, physical Model; X3D graphical 
objects are managed by the Model updating a Map, and the value data is 
communicated into Xj3d via the SAI, providing the View;  the 
Controller is provided via external inputs feeding the Model, or 
providing the Xj3D browser camera/scene viewing input."

might check and see.

> separate X3D into MVC?

My hopes would be that if we depend upon the current capabilities of 
X3D to compose and to navigate a complex scene showing only the 
elements of interest at that time for that transaction, then most of 
what is needed is in X3D or can be prototyped. Whether that can 
migrate to <x3d> ... </x3d> is expected but maybe not completely 
known. Some 'internal' X3D tools for MVC may be implemented by 
'external' stuff, like DOM scripts and CSS.

Thanks and Best,
Joe



----- Original Message ----- 
From: "John Carlson" <yottzumm at gmail.com>
To: "Joe D Williams" <joedwil at earthlink.net>
Sent: Saturday, October 22, 2016 9:35 PM
Subject: Re: [x3d-public] Fascinating Discussion on WebVR List


> Would it be ideal to separate X3D into MVC?  Where would the lines 
> be drawn?
>
> On Oct 23, 2016 12:14 AM, "John Carlson" <yottzumm at gmail.com> wrote:
>
>> Joe, I think the idea would be to limit the use of CSS in HTML to 
>> IDs and
>> classes.   Perhaps by ROUTEing to CSS.   Separate the view-model 
>> from the
>> model and implement the controller declaratively.  No I don't know 
>> the best
>> way to do these things and would have to defer to others.   There's
>> probably a good reason for doing web pages differently from 3D, but 
>> I don't
>> know the reason.
>>
>> On Oct 22, 2016 7:48 PM, "Joe D Williams" <joedwil at earthlink.net> 
>> wrote:
>>
>>> Do we have perfectly good scene graphs already in .js with glTF 
>>> and X3D
>>>> JSON?
>>>>
>>>
>>> Yes we do. For authoring there is some internal structures 
>>> required. JSON
>>> for X3D uses the x3d scenr graph structure. But for glTF, in a way 
>>> it is
>>> not to ilmportant until there is a live api.
>>>
>>> FOr the webVR, Leonard seems to be following closely in this. Tony 
>>> Parisi
>>> is right in there with his deep knowledge, and Sandy Ressler 
>>> checked in.
>>> And Don B is also in there.
>>> Have a look at the mailing list, it looks like an effort to get a 
>>> higher
>>> level focus by forming a group to examine opportunities.
>>>
>>> https://mail.mozilla.org/pipermail/web-vr-discuss/2016-Octob
>>> er/001735.html.
>>>
>>> If they are working on VR, then where is web3D MAR efforts aimed? 
>>> I would
>>> say that few commenting on the list know VRML or X3D or X3DOM or 
>>> Cobweb in
>>> detail or what it takes to run a complex simulation. One comment 
>>> blamed
>>> VRML's failure in that it could not be scripted(?), and some do 
>>> not believe
>>> in a declarative approach anyway. Javascript frameworks are king 
>>> for some
>>> of these folks and they still believe that the browser only needs 
>>> a few
>>> built-in features and .js can handle the rest.
>>>
>>> If you want a hint of what some group thought about mixing CSS and 
>>> 3D
>>> syntax, look at A-frame.
>>>
>>> example of advanced geometry:
>>>
>>> <a-entity
>>>  geometry="
>>>    primitive: torus;
>>>    radius: 1;
>>>    radiusTubular: 0.1;
>>>    segmentsTubular: 12;"
>>>  material="
>>>    color: #EAEFF2;
>>>    roughness: 0.1;
>>>    metalness: 0.5;"
>>>  rotation="10 0 0"
>>>  position="-3 1 0">
>>> </a-entity>
>>>
>>> I mean where did 'they' start to get something that looks like 
>>> that? Does
>>> an entity have class? Real CSS fans on that team. I hope it can be
>>> validated somehow. metalness is so descriptive. Anyone familiar 
>>> with X3D
>>> syntax should feel left out of the process taken to discover this 
>>> wonderous
>>> mix. The styling IS the content! Well I guess we can say that it 
>>> is
>>> declarative. What can be changed in runtime? OOh, I see, this:
>>>
>>> <script ... > ...
>>> var scene = document.querySelector('a-scene');
>>> var cylinder = document.createElement('a-cylinder');
>>> cylinder.setAttribute('color', '#FF9500');
>>> cylinder.setAttribute('height', '2');
>>> cylinder.setAttribute('radius', '0.75');
>>> cylinder.setAttribute('position', '3 1 0');
>>> scene.appendChild(cylinder);
>>> ...
>>>
>>> must give you something like this:
>>>
>>> <a-entity
>>>  geometry="
>>>    primitive: cylinder;
>>>    height: 2;
>>>    radius: 0.75;'"
>>>  material="
>>>    color: #FF9500;"
>>>  position="3 1 0">
>>> </a-entity>
>>>
>>> so natural. Proves there is nothing that can't be done given 
>>> enough
>>> javascript.
>>> You want advanced animation using another version of advanced 
>>> geometry?:
>>>
>>> <a-cube
>>>  color="#0095DD"
>>>  rotation="20 40 0"
>>>  position="0 1 0">
>>>  <a-animation
>>>    attribute="rotation"
>>>    from="20 0 0"
>>>    to="20 360 0"
>>>    direction="alternate"
>>>    dur="4000"
>>>    repeat="indefinite"
>>>    easing="ease">
>>>  </a-animation>
>>> </a-cube>
>>>
>>> Yeah, that makes it turn all the way around for as long as you 
>>> wish.
>>> You want more advanced stuffs? You get:
>>>
>>> requestAnimationFrame(render);
>>>
>>> which will let you collect one or a series of events (i guess) to 
>>> make
>>> sure you get a render of your animation each frame.
>>> You make your own event system so Hey, you can also do (and 
>>> realistically
>>> probably will need to do) all the animations in pure .js. You 
>>> wanna use the
>>> same animation of two or more things? me not know, they didn't 
>>> show me.
>>> To me, a-frame shows what you can take your own browser and your 
>>> own
>>> javascript engine and probably make almost any syntax serve for 
>>> making
>>> spinning (using euler-type angles even) tennis shoes and the like.
>>>
>>> <a-light
>>>  type="directional"
>>>  color="#FFF"
>>>  intensity="0.5"
>>>  position="-1 1 2">
>>> </a-light>
>>>
>>> I still think it is very lazy to do stuff like this where you must 
>>> name
>>> the actual thing you are working with using a "type" attribute on 
>>> some base
>>> element. Fortunately the rest of html and any of x3d don't do 
>>> that.
>>>
>>> Sorry, just a first impression. A-frame is not a serious 
>>> competitor to
>>> X3DOM and certainly not X3D. .
>>>
>>> Unless somebody takes the focus from simple games and ui to 
>>> realistic
>>> simulations they will be working toward DOM6 or so to get the 
>>> structure and
>>> functions of X3D. A 'standard' scene graph is dismissed as being 
>>> too
>>> confining. Although the extensions to get CSS running live in the 
>>> live DOM
>>> gives the idea that much can be done to improve the DOM for 
>>> realtime
>>> styling of real interactive pages, and thus leading to the idea 
>>> that 3D
>>> scenes can work with enough high performance .js piled in.
>>>
>>> glTF I don't think is 'native' yet and still requires a download, 
>>> I
>>> think. Not sure.
>>>
>>> All Best,
>>> Joe
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: "John Carlson" 
>>> <yottzumm at gmail.com>
>>> To: "Joe D Williams" <joedwil at earthlink.net>
>>> Sent: Saturday, October 22, 2016 12:26 AM
>>> Subject: Re: [x3d-public] Fascinating Discussion on WebVR List
>>>
>>>
>>> Do we have perfectly good scene graphs already in .js with glTF 
>>> and X3D
>>>> JSON?
>>>>
>>>> On Oct 22, 2016 3:23 AM, "John Carlson" <yottzumm at gmail.com> 
>>>> wrote:
>>>>
>>>> On Oct 22, 2016 1:09 AM, "Joe D Williams" <joedwil at earthlink.net> 
>>>> wrote:
>>>>> >
>>>>> >
>>>>> > An important part of this seems to be discussion of VR needing 
>>>>> > a
>>>>> scenegraph that the html browser DOM doesn't have.
>>>>> > The javascriptmeisters say don't bother with a scenegraph in 
>>>>> > the
>>>>> browser, we can handle it in .js.
>>>>>
>>>>> How do they propose to handle it in . js and which would be 
>>>>> performant
>>>>> enough?   Isn't this essentially cobweb?
>>>>>
>>>>>
>>>>
>>>
>