XML serializer omits containerField for nodes in a non-default field (HAnim skeleton, PBR/unlit textures)

[EUPHEMEME]

A quick human note: I hit this building HAnim and PBR scenes programmatically with x3d.py — the output validates against the schema but renders wrong, so it took a while to track down. Minimal repros below; happy to help with a fix.

Summary

When a node is supplied through a typed field whose containerField differs from that node type's default containerField, X3D(...).XML() emits the child without any containerField attribute. Conformant parsers then route the child into the node's default container — the wrong field — so the node is silently dropped or misfiled. The output still passes XSD schema validation.

Environment: x3d 4.0.65.4 (pip install x3d), Python 3.12.

This affects every node type that may legally appear in more than one parent field, e.g.:

• HAnimJoint (default children) placed in skeleton / joints
• HAnimSegment (default children) placed in segments
• ImageTexture (default texture) placed in baseTexture / emissiveTexture / normalTexture / … of PhysicalMaterial / UnlitMaterial

Reproduction 1a — HAnim skeleton

from x3d import x3d as X
h = X.HAnimHumanoid(DEF="H", name="h", version="2.0",
        skeleton=[X.HAnimJoint(DEF="r", name="humanoid_root",
                  children=[X.HAnimSegment(DEF="s", name="seg")])])
print(h.XML())

Actual — the root joint carries no containerField:

<HAnimHumanoid DEF='H' name='h'>
  <HAnimJoint DEF='r' name='humanoid_root'>
    <HAnimSegment DEF='s' name='seg'/>
  </HAnimJoint>
</HAnimHumanoid>

Expected — the skeleton root joint must carry containerField='skeleton':

  <HAnimJoint DEF='r' name='humanoid_root' containerField='skeleton'>

Impact: players that render HAnimHumanoid via its skeleton field place the joint into the default children field instead and render nothing — the whole humanoid is invisible, with no warning. Reproduced in two independent conformant X3D 4.0 players (Castle Model Viewer 5.3 and X_ITE); the figure appears only after containerField='skeleton' is added by hand.

Reproduction 1b — PBR / unlit textures

from x3d import x3d as X
print(X.Appearance(material=X.UnlitMaterial(emissiveColor=[1,1,1],
        emissiveTexture=X.ImageTexture(url=["t.png"]))).XML())
print(X.Appearance(material=X.PhysicalMaterial(baseColor=[1,1,1],
        baseTexture=X.ImageTexture(url=["t.png"]))).XML())

Actual: each ImageTexture is emitted with no containerField.
Expected: containerField='emissiveTexture' (resp. 'baseTexture').
Impact: the texture inherits ImageTexture's default containerField texture, which PhysicalMaterial/UnlitMaterial do not define as a field — so it is dropped and the surface renders untextured (flat base color). Reproduced in Castle Model Viewer 5.3 and X_ITE.

Control (correct) — node in its default field

X.HAnimJoint(DEF='j', children=[X.HAnimSegment(DEF='s')]).XML()
# HAnimSegment's default containerField IS 'children', so omission is correct here.

The bug appears only when the field's container differs from the node default — exactly the case the typed field keyword should disambiguate.

Diagnosis

After construction the child's containerField is never set from the field it was placed in:

j = X.HAnimJoint(DEF="r", name="root")
X.HAnimHumanoid(skeleton=[j])
print(repr(getattr(j, "containerField", "<none>")))   # -> '<none>'

Also, x3d.py exposes no containerField setter: the constructor rejects a containerField= kwarg and a post-construction attribute assignment is ignored at XML() time — so string post-processing of the serialized output is currently the only workaround.

Suggested fix

When serializing (or when assigning a typed SFNode/MFNode field), set each child's containerField to the field's container name whenever it differs from the child type's default containerField.

Net effect

Programmatically built HAnim humanoids and PBR scenes serialize to XML that passes XSD validation yet renders incorrectly, because containerField routing is not part of schema validation.

[vincentmarchetti]

Please look to the github repo https://github.com/vincentmarchetti/x3dpy_containerfield which has intention of addressing this problem. In particular, the release-1-0-0 product https://github.com/vincentmarchetti/x3dpy_containerfield/releases/download/rel-1-0-0/x3d_package_build.zip is a drop-in replacement for the x3d package which emits a containerField XML attribute in the situations you detail in "Suggested fix"

I want to emphasize that though the repo contains all kinds of python scripts and references to running Java, all you need to do to test this in your application is substitute the replacement build of x3d package as distributed in release.

[coderextreme]

Thanks for being on top of this, vince.

[vincentmarchetti]

The release I mentioned earlier (release-1-0-0) was prepared for X3D V 4.0 which did not include EnvironmentLight, so the Python -> X3D encoding won't work for your scenes using that node, It should work for the HAnim example you gave as examples of the problem to be solved.

I will prepare a release based on the X3DUOM for X3D 4.1, which does include EnvironmentLight.

[brutzman]

Immediate response: don't include either EnvironmentLight (v4.1) or PhysicallyBasedMaterial (v4.0) (at least not yet) since they are not as widely deployed as classic nodes like DirectionalLight and Material. That lets you focus on what you want to accomplish, rather than feature support.

A further concern is that none of the required HAnim naming rules for DEF and name are being followed. Getting this right will be an important next step for x3d_mcp rules.

[vincentmarchetti]

I have built the x3dpy_containerfield package with the X3D 4.1 (Experimental) Unified Object Model, supporting the proposed EnvironmentLight node.

Release is at https://github.com/vincentmarchetti/x3dpy_containerfield/releases/tag/rel-1-1-0-beta

I have not tested it with a Pythons script using the EnvironmentLight node ; please post your Python code , particularly if there's a faIlure in using it to generate X3D

[coderextreme]

Alexander, the containerField issue is being tracked here as well: https://sourceforge.net/p/x3d/tickets/117/ (#65 too, first we have to get containerFields in place) Thanks for bringing up the issue. John

…

On Thu, Jun 18, 2026 at 4:37 AM Alexander Hoffman ***@***.***> wrote: *EUPHEMEME* created an issue (Web3DConsortium/Python-SAI#2) <#2> Summary When a node is supplied through a typed field whose containerField differs from that node type's *default* containerField, X3D(...).XML() emits the child *without any containerField attribute*. Conformant parsers then route the child into the node's *default* container — the wrong field — so the node is silently dropped or misfiled. The output still passes XSD schema validation. *Environment:* x3d 4.0.65.4 (pip install x3d), Python 3.12. This affects every node type that may legally appear in more than one parent field, e.g.: - HAnimJoint (default children) placed in skeleton / joints - HAnimSegment (default children) placed in segments - ImageTexture (default texture) placed in baseTexture / emissiveTexture / normalTexture / … of PhysicalMaterial / UnlitMaterial Reproduction 1a — HAnim skeleton from x3d import x3d as Xh = X.HAnimHumanoid(DEF="H", name="h", version="2.0", skeleton=[X.HAnimJoint(DEF="r", name="humanoid_root", children=[X.HAnimSegment(DEF="s", name="seg")])])print(h.XML()) *Actual* — the root joint carries no containerField: <HAnimHumanoid DEF='H' name='h'> <HAnimJoint DEF='r' name='humanoid_root'> <HAnimSegment DEF='s' name='seg'/> </HAnimJoint> </HAnimHumanoid> *Expected* — the skeleton root joint must carry containerField='skeleton': <HAnimJoint DEF='r' name='humanoid_root' containerField='skeleton'> *Impact:* players that render HAnimHumanoid via its skeleton field place the joint into the default children field instead and render *nothing* — the whole humanoid is invisible, with no warning. Reproduced in two independent conformant X3D 4.0 players (Castle Model Viewer 5.3 and X_ITE); the figure appears only after containerField='skeleton' is added by hand. Reproduction 1b — PBR / unlit textures from x3d import x3d as Xprint(X.Appearance(material=X.UnlitMaterial(emissiveColor=[1,1,1], emissiveTexture=X.ImageTexture(url=["t.png"]))).XML())print(X.Appearance(material=X.PhysicalMaterial(baseColor=[1,1,1], baseTexture=X.ImageTexture(url=["t.png"]))).XML()) *Actual:* each ImageTexture is emitted with no containerField. *Expected:* containerField='emissiveTexture' (resp. 'baseTexture'). *Impact:* the texture inherits ImageTexture's default containerField texture, which PhysicalMaterial/UnlitMaterial do not define as a field — so it is dropped and the surface renders untextured (flat base color). Reproduced in Castle Model Viewer 5.3 and X_ITE. Control (correct) — node in its default field X.HAnimJoint(DEF='j', children=[X.HAnimSegment(DEF='s')]).XML()# HAnimSegment's default containerField IS 'children', so omission is correct here. The bug appears only when the field's container differs from the node default — exactly the case the typed field keyword should disambiguate. Diagnosis After construction the child's containerField is never set from the field it was placed in: j = X.HAnimJoint(DEF="r", name="root")X.HAnimHumanoid(skeleton=[j])print(repr(getattr(j, "containerField", "<none>"))) # -> '<none>' Also, x3d.py exposes no containerField setter: the constructor rejects a containerField= kwarg and a post-construction attribute assignment is ignored at XML() time — so string post-processing of the serialized output is currently the only workaround. Suggested fix When serializing (or when assigning a typed SFNode/MFNode field), set each child's containerField to the field's container name whenever it differs from the child type's default containerField. Net effect Programmatically built HAnim humanoids and PBR scenes serialize to XML that *passes XSD validation* yet renders incorrectly, because containerField routing is not part of schema validation. — Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAFMJ5ZCJZHNZGIZCJP6BF35AOZ7HA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBWHEYTCMBZGMZDDJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMJ57NUKGNX4YMMDBJFV35AOZ7HAVCNFSNUABFKJSXA33TNF2G64TZHM2DAMBSG4ZTINZTHNEXG43VMU5TINRZGEYTAOJTGIY2C5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>