[x3d-public] Shader parameters

[John Carlson]

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?
On Feb 6, 2016 7:24 PM, "John Carlson" <yottzumm at gmail.com> wrote:

> ---------- Forwarded message ----------
> From: "John Carlson" <yottzumm at gmail.com>
> Date: Feb 6, 2016 7:23 PM
> Subject: RE: [x3d-public] Topics for Discussion at JSON meeting:
> SFNode/MFNode field/fieldValue content, ProtoBody, regexes
> To: "Roy Walmsley" <roy.walmsley at ntlworld.com>
> Cc:
>
> 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?
>
> John
> On Feb 6, 2016 7:05 PM, "Roy Walmsley" <roy.walmsley at ntlworld.com> wrote:
>
>> Don,
>>
>> 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?
>>
>> Roy
>>
>> -----Original Message-----
>> From: Don Brutzman [mailto:brutzman at nps.edu]
>> Sent: 06 February 2016 23:11
>> To: Roy Walmsley; John Carlson
>> Cc: x3d-public at web3d.org
>> Subject: Re: [x3d-public] Topics for Discussion at JSON meeting:
>> SFNode/MFNode field/fieldValue content, ProtoBody, regexes
>>
>> Testing reconsideration:  using "-value" for children SFNode/MFNode
>> content inside a fieldValue can be improved.
>>
>> Better: use "-children" instead.  Common semantics, simpler encoding
>> rules, easier to remember, less failure prone.
>>
>> Next version (test suite in progress) will use "-children" instead of
>> "-value" for contained content.
>>
>> Test suite conversion checks appear to be performing well, update should
>> be complete late tonite.
>>
>> Examples attached.  As always, comments are welcome.
>>
>> 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.
>>
>>
>> On 2/5/2016 7:04 PM, Don Brutzman wrote:
>> > Summary: Once again the X3D JSON design is looking pretty solid, and
>> our tool suites are pretty powerful at detecting edge-case issues.
>> >
>> > On 2/5/2016 10:37 AM, Don Brutzman wrote:
>> >> [correction: shifted to x3d-public]
>> >> [...]
>> >> On 2/4/2016 10:56 AM, Roy Walmsley wrote:
>> >>> Topics for Discussion for JSON encoding meeting February 5^th 2016 at
>> 1000 PST, 1800 GMT.
>> >>> [...]
>> >>> 2) *Encoding of node fields in ‘field’ and ‘fieldValue’ elements
>> >>> within Script and Prototypes.* [...snip/shuffle...] Illustration of
>> >>> 2) above is in X3D Example Archives: Basic, CAD, Cad Geometry Extern
>> >>> Prototypes (see
>> >>> http://www.web3d.org/x3d/content/examples/Basic/CAD/_pages/page02.ht
>> >>> ml)
>> >>>
>> >>> 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’.
>> >>>
>> >>> A similar issue arises with default values for node fields within the
>> field element.
>> >
>> > OK this change is worth close scrutiny to avoid confusion later.
>> >
>> > For <field> and <fieldValue>, when the "@value" attribute is used for
>> simple types, everything works OK.
>> >
>> > For <field> and <fieldValue>, with contained SFNode/MFNode content or
>> contained comments or contained ROUTEs, the key is now "-value" (hyphen
>> instead of ampersand).
>> > [...]
>>
>> Summary, revising the prior sentence:
>>
>> 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.
>>
>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160206/d1b3f6d0/attachment-0001.html>