<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Message: 4<br>
Date: Fri, 11 Nov 2016 10:08:32 -0800<br>
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
Subject: Re: [x3d-public] dual use of script tag in HTML environment<br>
Message-ID: <<a href="mailto:b33aef12-be8b-8384-7926-b57ee82b669f@realism.com">b33aef12-be8b-8384-7926-<wbr>b57ee82b669f@realism.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
Andreas,<br>
<br>
> I am trying to make cobweb and cobweb_dom html5 compatible, so there<br>
> is no requirement to use xhtml. xhtml is not used much at all and may<br>
> face extinction.<br>
><br>
> The implication for x3d spec. is that it would be better to have the<br>
> field definitions in an attribute rather as in child nodes. Something like<br>
> <script ... fields=' "inputOnly SFBool isOver" "outputOnly SFColor<br>
> diffuseColor_changed" '><br>
> That would be also more concise.<br>
<br>
This would get really messy if a field were inputOnly MFString and you<br>
needed to specify multiple values in form '"v1" "v2" "v3" ...'. Also if<br>
there are a lot of fields, especially with a large collection of values<br>
(e.g., MFVec3D) you could run into attribute value character limitations.<br></blockquote><div><br></div><div>I had a feeling that this was already discussed at length, probably at the </div><div>time when the xml encoding was developed.</div><div><br></div><div>To clarify, the MFString case would be fields=' "inputOnly MFString myString ' "a" "b" "c" ' " "nextField" '</div><div><br></div><div>where ' "a" "b" "c" ' is the initialValue of myString .</div><div><br></div><div>This is indeed quite messy and hard to parse. The only way around that I </div><div>can think of is to not be able to specify initialValues explicitly. Instead, common</div><div>default values for each type would be defined, and scripts required to initialize</div><div>to other values if necessary. This is a deeper change but I would say it is more natural</div><div>to initialize field values in the script.</div><div><br></div><div>If limitations to the length of attribute values would be a concern, they would need</div><div>to be a concern for the <field> nodes as well as for MFVec3f fields in general</div><div>which need to have long lists for complex geometries. If there is a situation </div><div>where this limitation plays a role, the script itself could initialize to long values.</div><div><br></div><div>But given that currently this suggestion would only benefit cobweb, I doubt that there</div><div>is enough motivation to advance such an amendment. Unless there is enough of a</div><div>benefit to x3d authors in general which may or may not be the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If X3D is to be declarative, then all programming nodes (i.e., Script<br>
and Shader) should be eliminated and new nodes added that provide for<br>
the most commonly needed features.<br></blockquote><div><br></div><div>The existence of the script node points to an observation that often a mix of declarative and</div><div>imperative programming is desired by many.</div><div><br></div><div>Currently, in cobweb the script node has the benefit of being part of the event cascade</div><div>which is mostly useful for time accurate simulations, eg. a script can rely on the timestamp</div><div>and that all other elements of the world are synchronized to that exact timestamp.</div><div>Another benefit is that it performs a little better than DOM scripts which need to go through</div><div>the DOM but not better than external scripts which use the SAI without going through the</div><div>DOM.</div><div><br></div><div>Custom shaders need to be in the form of webgl programs. x3dom has</div><div><a href="http://doc.x3dom.org/author/Shaders/CommonSurfaceShader.html">http://doc.x3dom.org/author/Shaders/CommonSurfaceShader.html</a></div><div>which is attempt to capture the most commonly used shaders in a few parameters.</div><div>But I feel that many shader users would want to go beyond that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Programmatic access and support can be added through new capabilities<br>
that allow scripts to access scene information, but not be controlled by<br>
the event system. Perhaps some nodes that convert events back and forth<br>
to direct access would solve much of the problem.<br></blockquote><div><br></div><div>That sounds interesting. Did you start to think about something more specific ?</div><div><br></div><div>Andreas</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>