[x3d-public] Everit summary, auto-generated versus roy's, X3DUOM min/max for rotation. RFE for X3DUOM

John Carlson yottzumm at gmail.com
Fri Apr 2 13:01:30 PDT 2021


Addign comments to JSON schema will require some research.

This is not a simple solution until we can find a way to comment 
sub-schemas.

There is $comment in draft-07, but I think it's intended for string 
values, not subschemas.

John

On 4/2/21 2:30 PM, Don Brutzman wrote:
> Hi John. As discussed today, SFRotation normalization is perhaps 
> desirable but often not observed in content (meaning X3D models).
>
> This is especially true for conversion outputs which can be pretty 
> sloppy.
>
> So let's support such cleanup but not make that the default for 
> validation.  You might want both options in JSON Schema (with one 
> commented out).
>
> I did find a normalize() method for SFRotation in X3DJSAIL.
>
>     /**
>      * Utility method to normalize this rotation value: unit length 
> for axis-angle vector, angle in range [0-2pi] radians, rotation with 
> zero-length axis is reset to DEFAULT_VALUE.
>      * @return {@link SFRotation} - namely <i>this</i> same object to 
> allow sequential method pipelining (i.e. consecutive method 
> invocations on the same object).
>      */
>     public SFRotation normalize()
>     {
>         float length = (float) Math.sqrt(SFRotation[0]*SFRotation[0] + 
> SFRotation[1]*SFRotation[1] + +SFRotation[2]*SFRotation[2]);
>         if (length == 0.0f)
>         {
>             SFRotation = java.util.Arrays.copyOf(DEFAULT_VALUE, 
> DEFAULT_VALUE.length); // must be separate copy
>             System.out.println ("SFRotation.normalize(): zero-length 
> axis encountered, reset entire SFRotation to DEFAULT_VALUE: " + 
> DEFAULT_VALUE);
>         }
>         else
>         {
>             SFRotation[0] = SFRotation[0] / length;
>             SFRotation[1] = SFRotation[1] / length;
>             SFRotation[2] = SFRotation[2] / length;
>             while (SFRotation[3] < 0.0f)
>                    SFRotation[3] += 2.0f * Math.PI;
>             while (SFRotation[3] >= 2.0f * Math.PI)
>                    SFRotation[3] -= 2.0f * Math.PI;
>         }
>         return this;
>     }
>
> Will add corresponding normalize() method for MFRotation that simply 
> walks through the list of contained SFRotation values.
>
> Will similarly add such functionality in X3DUOM documentation, X3D 
> regex alternative, X3DPSAIL x3d.py.  Possibly X3D Schematron and 
> X3dTidy as well (insofar as possible with string manipulation).
>
> ... and some fine day, if someone picks up the Chisel open source, we 
> can confirm (or add) normalization options there as well.
>
> If we listen closely, am maybe hearing a swamp draining in the far-off 
> distance...
>
> Thanks for your many efforts.
>
> On 4/1/2021 9:06 PM, John Carlson wrote:
>>  From what I see online, the @rotation X,Y,Z should be normalized.
>> Therefore, the min/max ranges in Roy's X3D JSON schema should be 
>> maintained.
>>
>> I will go ahead and copy/paste Roy's rotation sub-schema into the X3D
>> JSON schema generator, in hopes that the normalization requirements will
>> fit into X3DUOM at some point.
>>
>> Thanks,
>>
>> John
>>
>> On 4/1/21 8:53 PM, John Carlson wrote:
>>> Is rotation "normalization" something the schematron finds? This seems
>>> like something valuable that we don't want to lose. 
>
> all the best, Don



More information about the x3d-public mailing list