<div dir="auto">Use the Script.url field to specify external JS scripts using “internal” namespaces—no extra “X3D.” in front of classes and field classes.</div><div dir="auto"><br></div><div dir="auto">I don’t know if MF fields are JavaScript arrays or X3D.MF…</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Apr 20, 2026 at 8:19 PM <<a href="mailto:cbullard@hiwaay.net">cbullard@hiwaay.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
We are developing MCCF (Multi-Channel Coherence Field), an open-source<br>
simulation system that uses X3D 4.0 as its spatial visualization layer.<br>
Repository: <a href="https://github.com/artistinprocess/mccf" rel="noreferrer" target="_blank">https://github.com/artistinprocess/mccf</a><br>
<br>
We have been working through X_ITE 11.6.6 external SAI behavior and have<br>
reached a point where we need clarification before proceeding further.<br>
John Carlson has been helpful and we are grateful. This post summarizes<br>
our findings and asks for precise documentation or correction.<br>
<br>
---<br>
<br>
## What We Have Confirmed Working<br>
<br>
Through systematic testing, the following external SAI patterns produce<br>
correct visual results in X_ITE 11.6.6 (Firefox and Edge, Windows 11):<br>
<br>
```javascript<br>
// Scalar fields — requires X3D. typed constructor<br>
node.intensity = new X3D.SFFloat(0.9); // ✓ visual update <br>
confirmed<br>
node.transparency = new X3D.SFFloat(0.3); // ✓ visual update <br>
confirmed<br>
<br>
// Vector fields — requires X3D. typed constructor<br>
node.translation = new X3D.SFVec3f(x, y, z); // ✓ visual update <br>
confirmed<br>
<br>
// String fields — plain array works<br>
node.string = ["text"]; // ✓ visual update <br>
confirmed<br>
```<br>
<br>
John Carlson confirmed the `X3D.` namespace prefix requirement for <br>
external<br>
SAI. This diverges from the W3C SAI specification which defines global<br>
constructors (`new SFColor(r,g,b)` etc.) but is consistent with X_ITE's<br>
approach of namespacing its types to avoid global namespace pollution.<br>
<br>
---<br>
<br>
## What Does Not Work<br>
<br>
The following assignments are accepted without error, the internal <br>
object<br>
state updates (confirmed via console inspection of Symbol-keyed <br>
properties<br>
including `X_ITE.Color3.r/g/b`), but **no visual update occurs**:<br>
<br>
```javascript<br>
// Color fields — value stored internally but no visual redraw<br>
mat.emissiveColor = new X3D.SFColor(r, g, b); // ✗ no visual update<br>
mat.diffuseColor = new X3D.SFColor(r, g, b); // ✗ no visual update<br>
mat.set_emissiveColor = new X3D.SFColor(r, g, b); // ✗ no visual update<br>
<br>
// Light color — same behavior<br>
light.color = [r, g, b]; // ✗ no visual update<br>
light.color = new X3D.SFColor(r, g, b); // ✗ no visual update<br>
<br>
// Light intensity — value stored, no visual update<br>
light.intensity = new X3D.SFFloat(0.9); // ✗ darkens scene <br>
instead<br>
```<br>
<br>
Console inspection confirms the color values ARE stored in the X_ITE<br>
internal object (`Symbol("X_ITE.Color3.r"): 0.588` etc.) but the<br>
renderer does not update. Our hypothesis is that external SAI color<br>
assignments do not propagate the dirty flag to the parent Shape or<br>
Appearance node, so the render loop does not know to redraw.<br>
<br>
---<br>
<br>
## Our Questions<br>
<br>
**1. Is there a documented external SAI pattern for color field updates<br>
that triggers a visual redraw in X_ITE?**<br>
<br>
We have tried `emissiveColor`, `set_emissiveColor`, plain arrays, and<br>
`X3D.SFColor`. All store the value without visual effect. Is there a<br>
correct approach we are missing, or is this a known limitation?<br>
<br>
**2. Does X_ITE require the parent Appearance or Shape node to be marked<br>
dirty for Material property changes to render?**<br>
<br>
If so, is there a documented way to trigger that from external SAI — for<br>
example, a touch() method, a scene refresh call, or a property on the<br>
Appearance node that forces a render pass?<br>
<br>
**3. Is the `X3D.` prefix requirement for typed constructors documented<br>
anywhere in X_ITE's documentation or source?**<br>
<br>
We found it through testing and John's guidance, but we cannot find it <br>
in<br>
X_ITE's GitHub or the Web3D documentation. A canonical reference would<br>
help other developers and would help us understand what other type<br>
differences exist between spec SAI and X_ITE external SAI.<br>
<br>
---<br>
<br>
## The Script Node Workaround — and Why It Does Not Scale<br>
<br>
We are aware that internal X3D Script nodes can update Material color<br>
properties and trigger correct visual updates. We have tested this <br>
approach<br>
and it works.<br>
<br>
However, for our use case — a narrative simulation system that generates<br>
multiple X3D scenes programmatically with different geometry and <br>
character<br>
configurations — the Script Node approach introduces a significant<br>
maintenance burden:<br>
<br>
- Every generated scene must include the same Script Node boilerplate<br>
- The Script Node must be aware of all Material DEF names in that scene<br>
- As scenes become more complex (H-Anim humanoids, richer environments)<br>
the Script Node grows proportionally<br>
- Programmatic scene generation (we use Python/Flask with the x3d PyPI<br>
package) must maintain the Script Node in sync with scene content<br>
<br>
We are not opposed to the Script Node pattern if it is the correct<br>
architectural approach. But before committing to it across our entire<br>
scene generation pipeline we want to confirm there is no cleaner path<br>
through external SAI that we have missed.<br>
<br>
---<br>
<br>
## Summary<br>
<br>
We have an open-source system that is working well in most respects.<br>
The field simulation, HotHouse dynamics, constitutional arc, and avatar<br>
positioning all work correctly via external SAI. The one remaining gap<br>
is Material color updates driven by simulation state.<br>
<br>
We are pausing development of the color update path until we have<br>
clarification. We would rather wait for the right answer than build on<br>
an undocumented workaround.<br>
<br>
Any guidance — including confirmation that external SAI color updates<br>
simply do not work in the current X_ITE version and are on the roadmap —<br>
would be valuable.<br>
<br>
Full technical documentation of our findings is in `X3D_KNOWN_ISSUES.md`<br>
in the repository: <a href="https://github.com/artistinprocess/mccf" rel="noreferrer" target="_blank">https://github.com/artistinprocess/mccf</a><br>
<br>
Thank you for your time and for maintaining X_ITE and the X3DJSONLD <br>
tools.<br>
<br>
Len Bullard<br>
with Claude (Anthropic)<br>
<a href="https://github.com/artistinprocess/mccf" rel="noreferrer" target="_blank">https://github.com/artistinprocess/mccf</a><br>
</blockquote></div></div>