[x3d-public] [SOLUTION] X3dToJson.xslt, -colorRamp object/array Holger's VolumeEmitter.x3d
John Carlson
yottzumm at gmail.com
Tue Jul 5 08:08:27 PDT 2022
Yes, I realized after some work a few hours ago that I had to override
colorRamp with color and textCoordRamp with texCoord
I had be prototyping code, but here's the gist from x3djsonld.py:
if k in ("-colorRamp"):
k = "-color"
key = k[1:]
if k in ("-texCoordRamp"):
k = "-texCoord"
key = k[1:]
We've nearly exhausted Holger's ParticleSystem/ examples. She needs to
stay within bounds, and we need an MFBool solution that doesn't have ,,
together in python.
Thanks! I hope the reference to xsl analyze-string helps!
On Tue, Jul 5, 2022 at 9:52 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> 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. *ComposedCubeMapTexture*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#ComposedCubeMapTexture>:
> make six sets of field names identical to *TextureBackground*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#TextureBackground> for
> contained textures, e.g. back becomes backTexture, top becomes
> topTexture, etc.
> 2. *DISEntityManager*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#DISEntityManager>:
> when typically containing *DISEntityTypeMapping*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#DISEntityTypeMapping>,
> change that unnecessarily different containerField='mapping' and
> rename as containerField='children' instead.
> 3. *LoadSensor*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#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. *ParticleSystem*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#ParticleSystem>:
> change unnecessarily different field names colorRamp, texCoordRamp and
> rename as regular defaults color, texCoord instead.
> Related: see issue Mantis 1322
> <https://www.web3d.org/member-only/mantis/view.php?id=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.
>
> - *CADFace*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#CADFace> issue
> Mantis 1234 <https://www.web3d.org/member-only/mantis/view.php?id=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.
> - *CollidableShape*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#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.
> - *Collision*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#Collision>: typed
> content-model definitions for a proxy node (containerField='proxy')
> might be insufficiently strict [X3DChildNode]. Mantis issue Mantis 1149
> <https://www.web3d.org/member-only/mantis/view.php?id=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.
> - *GeoLOD* <https://www.web3d.org/x3d/content/X3dTooltips.html#GeoLOD>:
> see issue Mantis 920
> <https://www.web3d.org/member-only/mantis/view.php?id=920> to change
> unnecessarily different field name containerField='rootNode' and
> rename as containerField='children' instead. Also enter Mantis issue
> to implement object interface *X3DUrlObject*
> <https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject>
> .
> - *GeoMetadata*
> <https://www.web3d.org/x3d/content/X3dTooltips.html#GeoMetadata>: has
> *X3DUrlObject*
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/geospatial.html#GeoMetadata> 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 1331
> <https://www.web3d.org/member-only/mantis/view.php?id=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
> 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> 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> 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> 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> 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'
>
>
>
> 1. 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.
>
>
>
> 1. 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
>
> 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:* x3d-public <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>;
> 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/e6524d83/attachment-0001.html>
More information about the x3d-public
mailing list