[x3d-public] CylinderSensor in Schema needs limits for three angle fields; schema design checkpoints
Don Brutzman
brutzman at nps.edu
Wed Dec 9 07:18:48 PST 2015
On 12/9/2015 3:25 AM, Roy Walmsley wrote:
> Don,
>
> Reference: Specification 19775-1 20.4.1 CylinderSensor (see http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#CylinderSensor)
>
> In the Schema the definition for the CylinderSensor node has three fields related to angle, namely diskAngle, maxAngle, and minAngle. In the abstract specification all three of these fields have specific limit on the value. These are missing from the Schema. Below is my proposed solution:
>
> <xs:attributename="diskAngle"default="0.26179167">
><xs:simpleType>
><xs:restrictionbase="SFFloat">
> <xs:minInclusivevalue="0"/>
> <xs:maxExclusivevalue="1.5708"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:attribute>
etc.
Excellent observations Roy. However we should have a couple of design-philosophy checkpoints first.
1. Angles outside these bounds are still geometrically valid and useful.
In practice, programs will often generate angles that are not normalized [0,2pi) or [-pi,pi) or whatever a fields bounds are.
In general software APIs and graphics hardware cards are forgiving about such values. That way scenes render and interact without inscrutable halting errors thwarting end users.
Possible approaches:
a. strict compliance via X3D Schema limits, as you propose, and
b. Schematron warnings
We could justify putting such limits into schema based on best detectability of potential errors that might otherwise go unnoticed. Over time this would also encourage tools to "do the right thing."
Some might object that it is too draconian for players. Though player insistence on schema validity is not a requirement.
Worth discussion, perhaps on the x3d-public list (cc:ed).
2. When putting pi-related values, absolute values need to be rounded up so that close-enough values do not fail validity due to roundoff vagaries.
3. I've resisted the urge to propagate lots of special simple types in the schema because I think it makes maintenance and manipulation harder. Modifying individual schema attributes as you have done seems best.
So. A number of these limits exist in the X3D Schema already. On balance, most productive approach appears to be inclusion of such limits in schema to encourage the broadest possible quality assurance (QA) of X3D scene content.
Further rationales or different opinions are welcome.
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
More information about the x3d-public
mailing list