[x3d-public] [SOLUTION] X3dToJson.xslt, -colorRamp object/array Holger's VolumeEmitter.x3d
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Tue Jul 5 07:52:16 PDT 2022
The field colorRamp was renamed color in X3D4. So you need to be able to handle both.
* X3D4 Architecture, 40.4.5 ParticleSystem
* https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/particleSystems.html#ParticleSystem
* “NOTE the original name for the ParticleSystem color field in X3D version 3 is colorRamp.”
I checked various stylesheets and they seemed to be consistent.
We still can use examples in the archives for this component to facilitate regular testing.
Comprehensive list of such changes is found online, following some other hints.
* X3D Scene Authoring Hints, containerField, Field name changes for improved consistency in X3D4
* https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
<https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges> 🔖 Field name changes for improved consistency in X3D4
Completed work for X3D Version 4 <https://www.web3d.org/x3d4> and X3D Unified Object Model (X3DUOM) <https://www.web3d.org/specifications/X3DUOM.html> makes a number of candidate optimizations possible and (in most cases) desirable. Consistent X3D scene-graph architecture across multiple file encodings and programming-language bindings is important.
The following consistency changes to SFNode/MFNode field names in X3D4 have the potential to reduce the number of containerField variations by more than half. Further simplification benefits are foreseen for X3D4 implementations, X3D authors, and X3D Ontology field disambiguation.
1. <https://www.web3d.org/x3d/content/X3dTooltips.html#ComposedCubeMapTexture> ComposedCubeMapTexture: make six sets of field names identical to <https://www.web3d.org/x3d/content/X3dTooltips.html#TextureBackground> TextureBackground for contained textures, e.g. back becomes backTexture, top becomes topTexture, etc.
2. <https://www.web3d.org/x3d/content/X3dTooltips.html#DISEntityManager> DISEntityManager: when typically containing <https://www.web3d.org/x3d/content/X3dTooltips.html#DISEntityTypeMapping> DISEntityTypeMapping, change that unnecessarily different containerField='mapping' and rename as containerField='children' instead.
3. <https://www.web3d.org/x3d/content/X3dTooltips.html#LoadSensor> LoadSensor: change unnecessarily different field name containerField='watchList' and rename as containerField='children' instead. Child node restrictions can achieve a functionally equivalent effect and improve the object-oriented design.
4. <https://www.web3d.org/x3d/content/X3dTooltips.html#ParticleSystem> ParticleSystem: change unnecessarily different field names colorRamp, texCoordRamp and rename as regular defaults color, texCoord instead.
Related: see issue Mantis <https://www.web3d.org/member-only/mantis/view.php?id=1322> 1322 to allow TextureCoordinateGenerator as an alternative to TextureCoordinate for that child node.
Not accepted for X3D4: nodes with working functionality but proposed design refinements were not workable.
* <https://www.web3d.org/x3d/content/X3dTooltips.html#CADFace> CADFace issue Mantis <https://www.web3d.org/member-only/mantis/view.php?id=1234> 1234 to change unnecessarily different containerField='shape' and rename as containerField='children' instead. This change was rejected since the field can only contain a single SFNode, making it functionally different that MFNode children.
* <https://www.web3d.org/x3d/content/X3dTooltips.html#CollidableShape> CollidableShape: issue to change field name containerField='shape' (which has different semantics than CADFace shape field) and rename as containerField='children' instead. This change was rejected since the field can only contain a Shape node and has accessType initializeOnly, making it functionally different.
* <https://www.web3d.org/x3d/content/X3dTooltips.html#Collision> Collision: typed content-model definitions for a proxy node (containerField='proxy') might be insufficiently strict [X3DChildNode]. Mantis issue Mantis <https://www.web3d.org/member-only/mantis/view.php?id=1149> 1149 considered node-type restrictions "matching CADFace shape field" instead, i.e. [Shape|LOD|Transform]. This issue was reviewed but not approved, with no change applied.
* <https://www.web3d.org/x3d/content/X3dTooltips.html#GeoLOD> GeoLOD: see issue Mantis <https://www.web3d.org/member-only/mantis/view.php?id=920> 920 to change unnecessarily different field name containerField='rootNode' and rename as containerField='children' instead. Also enter Mantis issue to implement object interface <https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject> X3DUrlObject.
* <https://www.web3d.org/x3d/content/X3dTooltips.html#GeoMetadata> GeoMetadata: has <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/geospatial.html#GeoMetadata> X3DUrlObject object interface applied for consistency, so no changes in field names necessary.
For model authors and software implementers, few changes are needed for upgrading X3D and browsers from X3D3 to X3D4. These changes require modified parsers, validation tools and converters for proper handling. Performing this one-time effort now, when progressing from X3D3 to X3D4, means that future authors and modelers have a more streamlined and consistent interface, with less legacy baggage from earlier evolutions of the language.
These improvements support slight improvements to X3D4 authoring and animation. Issue resolution is tracked by X3D Working Group email summary X3D4 finalization endgame: Field naming reconciliation decision <http://web3d.org/pipermail/x3d-public_web3d.org/2020-December/014254.html> and Mantis <https://www.web3d.org/member-only/mantis/view.php?id=1331> 1331.
These changes to field names (for a handful of affected nodes) received close scrutiny by Web3D Consortium members with corresponding technical review by the X3D Community. Companies, institutions, agencies and individuals are invited to Join Web3D Consortium <https://www.web3d.org/join> to participate and influence this important continuing evolution of X3D.
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 https:// faculty.nps.edu/brutzman
From: John Carlson <yottzumm at gmail.com>
Sent: Monday, July 4, 2022 4:44 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org>; holger.seelig at gmail.com
Subject: [SOLUTION] X3dToJson.xslt, -colorRamp object/array Holger's VolumeEmitter.x3d
Good news, leaving colorRamp out of X3dToJson.xslt seems to have fixed the particle system issue in Holger's example, VolumeEmitter.x3d when converting to JSON.
Patch below:
$ diff /c/x3d-code/www.web3d.org/x3d/stylesheets/X3dToJson.xslt <http://www.web3d.org/x3d/stylesheets/X3dToJson.xslt> X3dToJson.xslt
600c600
< ($fieldName = 'color') or ($fieldName = 'colorRamp') or ($fieldName = 'coord') or
---
> ($fieldName = 'color') or ($fieldName = 'coord') or
Looks like a pretty clean fix. I can check in as desired, or we can hopefully leave the email as a key for later (no guarantees I will keep my stylesheet around).
It looks like other color fields in other nodes may also have a type that start with MF, but I'm not sure if they're containerFields.
On Mon, Jul 4, 2022 at 6:15 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com> > wrote:
Re: colorRamp for color in X3dToJson.xslt:
<xsl:variable name="SFNodeType" select="
[snip]
($fieldName = 'color') or ($fieldName = 'colorRamp') or ($fieldName = 'coord') or
[snip]
<xsl:if test="not($SFNodeType) or //AllX3dElementsAttributes">
<xsl:text>[</xsl:text>
</xsl:if>
Investigations into X3DUOM:
<field name="color"
synonym="colorRamp"
type="MFNode"
accessType="initializeOnly"
acceptableNodeTypes="X3DColorNode"
description="The color field contains Color|ColorRGBA nodes as a series of color values to be used at the given colorKey points in time."/>
Suggestion to leave colorRamp out of the boolean expression above (will test to see if it works). Note that name="color" fields vary between many types, including MFNode, MFColor, MFColorRGBA ( I didn't do an exhaustive search).
Note that the colorRamp is in a ParticleSystem, and other .xslt files seem to address it.
I'm going to test the suggestion, and get back to you, to see if we can close this issue.
John
On Mon, Jul 4, 2022 at 5:45 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com> > wrote:
Ajv JSON schema reports on VolumeEmitter.json (potential issue in X3dToJson.xslt):
Can only validate version 4.0 presently. Switching version to 4.0.
=================================================
File: VolumeEmitter.json
Error reading VolumeEmitter.json
keyword: required
instancePath: /X3D/Scene/-children/4/ParticleSystem
message: must have required property @USE
params: {"missingProperty":"@USE"}
file: VolumeEmitter.json
version: 3.3
keyword: type
instancePath: /X3D/Scene/-children/4/ParticleSystem/-colorRamp
message: must be array
params: {"type":"array"}
file: VolumeEmitter.json
version: 3.3
keyword: oneOf
instancePath: /X3D/Scene/-children/4/ParticleSystem
message: must match exactly one schema in "oneOf"
params: {"passingSchemas":null}
file: VolumeEmitter.json
version: 3.3
=============================================================================================
Source file: https://github.com/create3000/Library/blob/main/Tests/Components/ParticleSystems/VolumeEmitter.x3d <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcreate3000%2FLibrary%2Fblob%2Fmain%2FTests%2FComponents%2FParticleSystems%2FVolumeEmitter.x3d&data=05%7C01%7Cbrutzman%40nps.edu%7Ccaae589fa74b47a32b0308da5e17291c%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637925751277317620%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Swk4q42C38KM6XVh5akxVxsmIvRa1E8OsgdNZchdKPQ%3D&reserved=0>
Note changes to VolumeEmitter.json to make it play well with JSON schema (not sure if correct or not):
$ diff ../X3DJSONLD/src/main/Library/Tests/Components/ParticleSystems/VolumeEmitter.json VolumeEmitter.json
6c6
< "JSON schema":"https://www.web3d.org/specifications/x3d-4.0-JSONSchema.autogenerated.json",
---
> "JSON schema":"https://www.web3d.org/specifications/x3d-4.0-JSONSchema.json",
170c170
< "-colorRamp":
---
> "-colorRamp": [
175c175,176
< },
---
> }
> ],
233c234
< }
\ No newline at end of file
---
> }
On Mon, Jul 4, 2022 at 5:27 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com> > wrote:
As previously posted:
"Changed subject to be more focused on what's not working. Thanks for the effort on VolumeEmitter.x3d, which despite not passing the x3d validator, products of the XML are passing jsonlint and python. Note that the VolumeEmitter.json passes jsonlint (and I guess the jshint and jslint or whatever you use), but it does not pass the Ajv validator. Will respond on the other thread if something comes up."
Apparently it pays to have a non-empty schema!
Changes:
diff --git a/x3d-4.0-JSONSchema.json b/x3d-4.0-JSONSchema.json
index 5834443..abfcd9f 100644
--- a/x3d-4.0-JSONSchema.json
+++ b/x3d-4.0-JSONSchema.json
@@ -1,7 +1,7 @@
{
"$schema": "https://json-schema.org/draft/2020-12/schema <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjson-schema.org%2Fdraft%2F2020-12%2Fschema&data=05%7C01%7Cbrutzman%40nps.edu%7Ccaae589fa74b47a32b0308da5e17291c%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637925751277474370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cnsb4PPBbjuB9gAmS9esr%2BD9HWzB2Qo7AMgYHixFLOg%3D&reserved=0> ",
"$id": "https://www.web3d.org/specifications/x3d-4.0-JSONSchema.json",
- "title": "X3D V4.0 JSON Schema, generated 2022/05/24 17:50:41",
+ "title": "X3D V4.0 JSON Schema, generated 2022/07/04 17:13:07",
"description": "Experimental JSON Schema for X3D V4.0",
"type": "object",
"properties": {
@@ -19398,8 +19398,10 @@
"type": "number"
},
"@fieldOfView": {
- "$comment": "MFFloat inputOutput",
+ "$comment": "SFVec4f inputOutput",
"type": "array",
+ "minItems": 4,
+ "maxItems": 4,
"prefixItems": [
{
"default": -1,
@@ -19418,9 +19420,7 @@
"type": "number"
}
],
- "items": {
- "type": "number"
- }
+ "items": false
},
"@jump": {
"default": true,
Sorry for confusion!
John
On Sun, Jul 3, 2022 at 11:24 PM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> > wrote:
[Changed subject line for readability/searchability – this is about OrthoViewpoint fieldOfView]
1. Invalid source XML in your .x3d excerpt: simple types should not have commas within them.
* OrthoViewpoint fieldOfView='-1.5, -1.5, 1.5, 1.5'
2. OrthoViewpoint fieldOfView is defined as MFFloat in specification but ought to be SFVec4f, since it must always have four numbers defining ordered values (minimum_x, minimum_y, maximum_x, maximum_y).
I am somehow locked out of mantis and so can’t verify what we previously said about this (if anything). Seems like a simple specification erratum.
Correlation confirmation: TextureProjectorParallel has fieldOfView SFVec4f. Meanwhile Viewpoint GeoViewpoint and TextureProjector have SFFloat.
3. I think that the various fieldOfView types are handled in the stylesheet s correctly now, checked in.
I have also applied a tentative fix to X3D DOCTYPE, Schema, Tooltips and X3DUOM, but will wait to deploy any updates (including X3DJSAIL, X3DPSAIL) until checking mantis to confirm status.
Thanks John for reporting this error, very helpful.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
From: x3d-public <x3d-public-bounces at web3d.org <mailto:x3d-public-bounces at web3d.org> > On Behalf Of John Carlson
Sent: Sunday, July 3, 2022 12:10 AM
To: X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org> >; holger.seelig at gmail.com <mailto:holger.seelig at gmail.com>
Subject: [x3d-public] X3dToJson.xslt, X3dToPython.xslt, create3000/Library Test ParticleSystem possible issues. Though may not pass!
Don,
Here are some issues with various X3dTo*.xslt:
grep fieldOfView VolumeEmitter.py
VolumeEmitter.py: OrthoViewpoint(description='OrthoViewpoint',fieldOfView=-1.5,-1.5,1.5,1.5),
$ grep fieldOfView VolumeEmitter*
VolumeEmitter.json: "@fieldOfView":-1.5,-1.5,1.5,1.5
VolumeEmitter.x3d: fieldOfView='-1.5, -1.5, 1.5, 1.5'/>
In the JSON, the MFFloat is does not appear to be an array, with [] around the numbers.
In the python, there's no tuple or list markers denoting a tuple or list
Note in the XML, both the "," and the space is separating the floats in the MFFloat. I haven't seen that the MFBools with ", " as separators is working, but perhaps the problem is more general.
Links to XML below.
====================================================
Holger,
I fully realize that these are test samples, and they may not pass, thus when I convert x3d to python and run, these errors may appear (which may be totally valid).
BoundedPhysicsModel.py
x3d.py package 4.0.64.1 loaded, have fun with X3D Graphics!
Traceback (most recent call last):
File "C:\Users\john\X3DJSONLD\src\main\python\net\x3djsonld\Library\Tests\Components\ParticleSystems\BoundedPhysicsModel.py", line 82, in <module>
emitter=ConeEmitter(position=(0,-3,0),direction=(1,4,0),angle=0.4,speed=0.2,mass=3200),
File "C:\Users\john\X3DJSONLD\venv\lib\site-packages\x3d\x3d.py", line 29419, in __init__
self.direction = direction
File "C:\Users\john\X3DJSONLD\venv\lib\site-packages\x3d\x3d.py", line 29450, in direction
assertLessThanEquals('direction', direction, 1)
File "C:\Users\john\X3DJSONLD\venv\lib\site-packages\x3d\x3d.py", line 1847, in assertLessThanEquals
assert isLessThanEquals(value, maximum), fieldName + '=' + str(value) + ' fails assertLessThanEquals maximum=' + str(maximum)
AssertionError: direction=(1, 4, 0) fails assertLessThanEquals maximum=1
PointEmitter.py
x3d.py package 4.0.64.1 loaded, have fun with X3D Graphics!
Traceback (most recent call last):
File "C:\Users\john\X3DJSONLD\src\main\python\net\x3djsonld\Library\Tests\Components\ParticleSystems\PointEmitter.py", line 92, in <module>
WindPhysicsModel(speed=0.8,gustiness=0.8,turbulence=2),
File "C:\Users\john\X3DJSONLD\venv\lib\site-packages\x3d\x3d.py", line 99589, in __init__
self.turbulence = turbulence
File "C:\Users\john\X3DJSONLD\venv\lib\site-packages\x3d\x3d.py", line 99643, in turbulence
assertZeroToOne('turbulence', turbulence)
File "C:\Users\john\X3DJSONLD\venv\lib\site-packages\x3d\x3d.py", line 1818, in assertZeroToOne
assert isZeroToOne(value), str(fieldName) + '=' + str(value) + ' fails assertZeroToOne requirements: value(s) must be in range [0..1]'
AssertionError: turbulence=2 fails assertZeroToOne requirements: value(s) must be in range [0..1]
SurfaceEmitter.py
x3d.py package 4.0.64.1 loaded, have fun with X3D Graphics!
Traceback (most recent call last):
File "C:\Users\john\X3DJSONLD\src\main\python\net\x3djsonld\Library\Tests\Components\ParticleSystems\SurfaceEmitter.py", line 50, in <module>
MetadataSet(DEF='children',name='children',reference='http://titania.create3000.de <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftitania.create3000.de%2F&data=05%7C01%7Cbrutzman%40nps.edu%7Ccaae589fa74b47a32b0308da5e17291c%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637925751277474370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bzoete5DEh5g0KpzRPEVUm8sNQwfrpjNpOoO8Vv96PA%3D&reserved=0> ',
TypeError: MetadataSet.__init__() got an unexpected keyword argument 'appearance'
Original XML here: Library/Tests/Components/ParticleSystems at main · create3000/Library (github.com) <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcreate3000%2FLibrary%2Ftree%2Fmain%2FTests%2FComponents%2FParticleSystems&data=05%7C01%7Cbrutzman%40nps.edu%7Ccaae589fa74b47a32b0308da5e17291c%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637925751277474370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9q3CPSVjQue58GzgcOu2JCVqhJBDz0hd%2FqgucYPZnew%3D&reserved=0>
Attached generated python code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220705/2960a036/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220705/2960a036/attachment-0001.p7s>
More information about the x3d-public
mailing list