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

[Don Brutzman]

[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
-- 
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

_______________________________________________
x3d mailing list
x3d at web3d.org
http://web3d.org/mailman/listinfo/x3d_web3d.org