<p dir="ltr">FYI Shaders implicitly take mesh as the explicit normal,  position and texcoord of the mesh TTBOMK.  Thus if you wanted to render an IFS with spherical mesh, you would specify an X3DOM sphere with an subdivision attribute--unfortunately AFAIK, X3D does not have subdivision. And then twerp the mesh in the shader.  If this doesn't work, I would like to specify an equation or set of equations to twerp the surface.  I don't want to have to drop into script to twerp the surface, with all the coordindex, coordinate and normal info.  This is similar to FX3D and FVRML.  Perhaps I could have one equation per script?  Can we optionally put the equation inside the shader to see if the shader does a better job at displaying the equation?</p>
<div class="gmail_quote">On Feb 6, 2016 7:24 PM, "John Carlson" <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">---------- Forwarded message ----------<br>From: "John Carlson" <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>Date: Feb 6, 2016 7:23 PM<br>Subject: RE: [x3d-public] Topics for Discussion at JSON meeting: SFNode/MFNode field/fieldValue content, ProtoBody, regexes<br>To: "Roy Walmsley" <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>><br>Cc: <br><br type="attribution"><p dir="ltr">I don't think that Shader fields should take arbitrary SFNodes and MFNodes except in the case of textures.  And I would like to be able to update  Shader fields in X3DOM besides textures.  Timo?</p>
<p dir="ltr">John</p>
<div class="gmail_quote">On Feb 6, 2016 7:05 PM, "Roy Walmsley" <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Don,<br>
<br>
I don't have any problem with that. What about for default values within a field in a ProtoInterface? Or a Shader? Or a Script?<br>
<br>
Roy<br>
<br>
-----Original Message-----<br>
From: Don Brutzman [mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>]<br>
Sent: 06 February 2016 23:11<br>
To: Roy Walmsley; John Carlson<br>
Cc: <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
Subject: Re: [x3d-public] Topics for Discussion at JSON meeting: SFNode/MFNode field/fieldValue content, ProtoBody, regexes<br>
<br>
Testing reconsideration:  using "-value" for children SFNode/MFNode content inside a fieldValue can be improved.<br>
<br>
Better: use "-children" instead.  Common semantics, simpler encoding rules, easier to remember, less failure prone.<br>
<br>
Next version (test suite in progress) will use "-children" instead of "-value" for contained content.<br>
<br>
Test suite conversion checks appear to be performing well, update should be complete late tonite.<br>
<br>
Examples attached.  As always, comments are welcome.<br>
<br>
p.s. here's one comment:  i had great trouble getting "-value" to work properly.  "-children" fell right into place and seems like an obvious improvement, since the earlier "-value" was an arbitrary choice.<br>
<br>
<br>
On 2/5/2016 7:04 PM, Don Brutzman wrote:<br>
> Summary: Once again the X3D JSON design is looking pretty solid, and our tool suites are pretty powerful at detecting edge-case issues.<br>
><br>
> On 2/5/2016 10:37 AM, Don Brutzman wrote:<br>
>> [correction: shifted to x3d-public]<br>
>> [...]<br>
>> On 2/4/2016 10:56 AM, Roy Walmsley wrote:<br>
>>> Topics for Discussion for JSON encoding meeting February 5^th 2016 at 1000 PST, 1800 GMT.<br>
>>> [...]<br>
>>> 2) *Encoding of node fields in ‘field’ and ‘fieldValue’ elements<br>
>>> within Script and Prototypes.* [...snip/shuffle...] Illustration of<br>
>>> 2) above is in X3D Example Archives: Basic, CAD, Cad Geometry Extern<br>
>>> Prototypes (see<br>
>>> <a href="http://www.web3d.org/x3d/content/examples/Basic/CAD/_pages/page02.ht" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/content/examples/Basic/CAD/_pages/page02.ht</a><br>
>>> ml)<br>
>>><br>
>>> Find the ProtoInstance named ‘IndexedQuadSet’. It has two fieldValue children. The second has the name ‘coord’, and a child Coordinate node. When converted into JSON this Coordinate node is allocated to a field /-coord/, which is the default containerField name for this node. This is incorrect. It should be allocated to the /-value/ field. This is because the element fieldValue has attributes of ‘name’ and ‘value’.<br>
>>><br>
>>> A similar issue arises with default values for node fields within the field element.<br>
><br>
> OK this change is worth close scrutiny to avoid confusion later.<br>
><br>
> For <field> and <fieldValue>, when the "@value" attribute is used for simple types, everything works OK.<br>
><br>
> For <field> and <fieldValue>, with contained SFNode/MFNode content or contained comments or contained ROUTEs, the key is now "-value" (hyphen instead of ampersand).<br>
> [...]<br>
<br>
Summary, revising the prior sentence:<br>
<br>
For <field> and <fieldValue>, with contained SFNode/MFNode content or contained comments or contained ROUTEs, the key is now "-children" as with most other child content.<br>
<br>
all the best, Don<br>
--<br>
Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
<br>
</blockquote></div>
</div>
</blockquote></div>