[x3d-public] [x3d] Status of ComposedShader node in DTD/Schema V3.3

[Max Limper]

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