[x3d-public] [x3d] Status of ComposedShader node in DTD/Schema V3.3
Max Limper
max.limper at igd.fraunhofer.de
Thu Aug 20 05:29:46 PDT 2015
Hi,
a very simple "gooch" shader is available as part of this x3dom tutorial:
http://doc.x3dom.org/tutorials/lighting/customShader/index.html
Best,
Max
On 18.08.2015 03:24, Don Brutzman wrote:
> [cc: x3d-public as originally intended]
>
> Another key point from meeting, offered numerous times before: we need
> more examples!!
>
> The only 2 examples we have are the following, and... neither seems to
> work. :(
>
> http://www.web3d.org/x3d/content/examples/Basic/Shaders/
>
> Does anyone out there have example scenes with shaders that can be
> used for testing and comparison?
>
> ==============================================================================================
>
>
> Thanks for the good discussion on the weekly schema/DTD call today,
> Roy. Real-time responses from our review follow.
>
> On 8/10/2015 7:40 AM, Roy Walmsley wrote:
>> Don,
>>
>> I have been reviewing the ComposedShader node. Unfortunately …. I
>> have some comments. Sorry to spoil the party.
>
> Improvements always welcome!
>
>> *_Specification 19775-1_*
>>
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shaders.html#ComposedShader
>>
>>
>> My only concern with the abstract specification is, perhaps, due to
>> limitations in my understanding. It is simply the about the
>> accessibility of thefield definitions to any of the ShaderPart
>> children. Do you have an example that illustrates usage of the
>> ComposedShader node?
>
> ComposedShader contains field definitions and ShaderPart nodes, which
> in turn are portions of programs.
>
> Presumably the ComposedShader parent allows access to field
> definitions throughout it's composed subprograms. In fact it says:
>
> "All access to the shading capabilities is defined through a single
> interface that applies to all parts."
>
>> *_DTD_*
>>
>> The definition of the ComposedShader node in V3.3 of the DTD (line
>> 2657) reads:
>>
>> <!ELEMENT ComposedShader ( (field)*, (IS?), (%MetadataNodes;)?,
>> (ShaderPart|%WildcardNodes;)* ) >
>>
>> Great! No problems with that!
>>
>> Except… I note that this requires /field/ children to be first,
>> exactlyas per /X3DShaderNode/.
>
> Yes, agreed. This matches Script node. Rationale: a tool needs to
> know what the fields are before it can define IS/connect links.
> Besides consistency, this approach permits single-pass loading and
> construction of the scenegraph, which is a design goal for maximum
> performance.
>
>> *_Schema_*
>
> The following illustrates that this set of definitions is quite
> convoluted,and typically not consistent with other design patterns in
> the specification.
>
> Suggested approach to resolve all this in the schema:
>
> a. We don't need to change X3DShaderNode definition to derive from
> anythingelse, since actual inheritance from X3DAppearanceChildNode
> only carries along metadata field.
> b. ComposedShader gets modified to match specification content model.
> c. Also look at each of the other nodes implementing X3DShaderNode
> (PackagedShader and ProgramShader) to ensure they each have the
> correct models.
> d. Recheck each of the specification-annex build files to ensure that
> any special autogeneration rules (if needed) are correct.
>
>> The definition of the ComposedShader node in V3.3 of the Schema
>> commencesat line 11072.
>>
>> Essentially, it correctly extends /X3DShaderNode/. It has a child
>> model content of any number of ShaderPart or Prototype nodes. Where
>> are the /field/ children? They seem to be completely absent.
>>
>> At this point I searched the Mantis issues and found nothing
>> relevant. I also had a look at the latest 19776-1 and noted it did
>> have /field/ in the child content model. But then it was specifically
>> added by the BuildSpecificationXmlEncodingFromSchema.xslt file. But
>> there are other issues there, somore on that below.
>>
>> I then create a simple test scene containing
>>
>> <Shape>
>>
>> <Box></Box>
>>
>> <Appearance>
>>
>> <ComposedShader>
>>
>> <fieldname="test"accessType="inputOnly"type="SFInt32"></field>
>>
>> <ShaderPart>
>>
>> </ShaderPart>
>>
>> </ComposedShader>
>>
>> </Appearance>
>>
>> </Shape>
>>
>> and incorporate it into my test file harness with validation by the
>> Schema V3.3. As expected, it fails to validate in XMLSpy because of
>> the presenceof the /field/. Without that line it passes validation.
>>
>> So, how do we rectify this? I think the important question is “Do
>> fielddefinitions need to come first?”. If yes, then ComposedShader
>> cannot be derived from extensions from X3DNode, because /field/ would
>> never come first. But in this instance, /field/ could come after both
>> IS and Metadata* children, since the /field/ definitions would only
>> be used by the ShaderPart or Prototype children. In this latter case
>> the changes are more straightforward and only involve the addition of
>> /field/ to the child content model. SoI would suggest the following
>> solution for the child content model:
>>
>> <xs:sequenceminOccurs="0">
>> [...]
>>
>> I tested this implementation in my V3.4 of the Schema. The test file
>> described above now passes validation.
>
> If we have a sequence consisting of field, IS, and a choice of
> ShaderPart |ProtoInstance, it should work pretty well.
>
> As you note, the choice of ShaderPart | ProtoInstance can occur with
> repetitions of minOccurs="0" maxOccurs="unbounded".
>
> So the following two lines get added:
> <xs:element ref="field" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element ref="IS" minOccurs="0"/>
> as follows:
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="X3DShaderNode">
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:annotation>
> <xs:documentation>parts</xs:documentation>
> </xs:annotation>
> <xs:element
> ref="field" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element ref="IS"
> minOccurs="0"/>
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> <xs:element ref="ShaderPart"/>
> <xs:element ref="ProtoInstance">
> <xs:annotation>
> <xs:documentation>Appropriately typed substitution
> node</xs:documentation>
> </xs:annotation>
> </xs:element>
> </xs:choice>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
> But this hits the same wall: our Schema puts IS|metadata under
> X3DNode, which means our IS definition is duplicated and not allowed.
>
> So the question now becomes what do we let float without direct
> inheritancefrom X3DNode: either from X3DShaderNode, or simply from
> ComposedShader node.
>
> So I think we have two potential paths remaining:
> i. Only modify ComposedShader inheritance and content model; or else
> ii. Modify inheritance and content model for X3DShaderNode,
> ComposedShader, PackagedShader and ProgramShader consistently together.
>
> This is a good stopping point to pause and consider! We certainly are
> farther down the road to understanding all of the implications.
>
>> *_Specification 19776-1_*
>>
>> See section 6.2.36 in the latest version distributed by Dick. I
>> reproduceit below.
> [...]
>
> As noted earlier, the rest can follow once the preceding issue is
> sorted out.
>
> all the best, Don
--
Dipl.-Inform. Max Limper
Visual Computing System Technologies
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstraße 5 | 64283 Darmstadt
Phone: +49 6151 155-554 | Fax: -196
max.limper at igd.fraunhofer.de
More information about the x3d-public
mailing list