X3D-Edit 4.0 · X3dSourceFilePalette — Complete Grok

Web3D Consortium · NetBeans Platform · Java + XSLT + XML · v4.0.40 (Nov 2025) · Apache NetBeans 28 · OpenJDK 25

What X3D-Edit / X3dSourceFilePalette is

A full-featured, open-source 3D scene authoring environment built on the Apache NetBeans platform. The X3dSourceFilePalette module provides the drag-and-drop node insertion palette — the author's primary composition interface. The broader system wraps X3D validation, multi-format conversion, and live preview into a single IDE.

Java / XML / XSLT NetBeans plugin + standalone app X3D v3.0–v4.0 ISO/IEC 19775 standard 24,000+ downloads since 2023

Format support

.x3dX3D XML encoding (primary)

.x3dvClassicVRML encoding

.x3dbX3D compressed binary

.wrlVRML97 (backwards compat)

.jsonX3D JSON encoding

.exiEfficient XML Interchange binary

.javaX3DJSAIL Java source

.pyPython x3d.py source

.htmlX3DOM / X_ITE embedded HTML5

Validation layers

DTDelement names, parent-child, DEF/USE NMTOKEN

XML Schemastrict typed field validation, value bounds

Schematronsemantic rules (cross-node logic)

X3D TidyXSLT-based cleanup and correction

X3DJSAILprogrammatic runtime validation

SAXON XSLTprimary transform engine

native Java XSLTfallback engine option

Key Java packages

org.web3d.x3d.jsailConcrete POJO scene graph implementation

org.web3d.x3d.jsail.CoreX3D, Scene, head, meta, component, unit, WorldInfo

org.web3d.x3d.jsail.fieldsSF/MF typed field objects (SFVec3f, MFInt32, etc.)

org.web3d.x3d.saiAbstract SAI interfaces (ISO spec bindings)

org.web3d.x3d.paletteNetBeans palette, customizer panels per node

org.web3d.x3d.typesX3D type constants, profile/component definitions

X3DJSAIL is autogenerated from the X3D Unified Object Model (X3DUOM) XML via the XSLT stylesheet CreateX3dSceneAccessInterfaceJava.xslt — the source for 500+ concrete classes is never hand-edited.

System layers

Author edits .x3d XML

→

NetBeans text editor (syntax highlight)

→

X3dSourceFilePalette (drag-drop nodes)

↓ validate

DTD / Schema / Schematron

→

X3D-Tidy XSLT cleanup

→

X3DJSAIL runtime validation

↓ convert / export

SAXON XSLT engine

→

target format (.java / .py / .json / .html)

↓ preview

embedded Xj3D viewer

X3DOM / X_ITE in browser

external player

X3DUOM → X3DJSAIL generation pipeline

X3D XML Schema (.xsd)

→

BuildSpec*.xslt

→

X3dUnifiedObjectModel-4.0.xml

↓

CreateX3dSceneAccessInterfaceJava.xslt

→

500+ Java class files

→

X3DJSAIL.jar

The X3DUOM XML is the single source of truth. Every node's field names, types, access modes, default values, tooltips, and parent-child constraints all flow from it. Changes to the X3D spec → edit the schema → re-run XSLT → regenerate all code.

NetBeans module structure

X3dSourceFilePalettePalette panel — drag-drop node insertion

X3dEdit module suiteTop-level NetBeans module wrapper

Xj3D integrationEmbedded Java-based X3D viewer (modified fork)

X3dValidatorCheckmark button → multi-layer QA pipeline

X3dPreferencesPlayer/tool paths, visualization widgets, CAD filters, XML Security

CORS server moduleAuto-launch localhost http server for X_ITE rendering

X3D Examples archivesDownload wizard → several thousand example scenes

OpenJDK 24+ JAXP entity expansion issue

A 2024 JDK change restricts JAXP entity expansion by default — the large X3D XML DOCTYPE definition exceeds the limit. Required config patch: add -J-Djdk.xml.entityExpansionLimit=5000 to netbeans.conf. This is a known active issue and a good example of where the active maintenance focus has been recently.

The XSLT stylesheet library

The heart of X3D-Edit's conversion power. A large set of XSLT stylesheets bundled in the plugin, invoked via SAXON (default) or native Java XSLT. Each stylesheet transforms a source .x3d into a different target representation. This is the "transpiler" layer of the X3D ecosystem.

Format conversion stylesheets

X3dToJava.xslt

Produces X3DJSAIL Java source that, when compiled and run, re-creates the exact X3D scene. Round-trip engineering.

→ .java

Key pattern: each X3D node becomes a Java new SomeNodeObject().setField1(v).setField2(v) chain. Method chaining (fluent API). Large arrays are split into multiple init methods to stay under the 64KB Java method limit. Used for thousands of regression tests in CI builds. The X3dToJava.xslt is also how X3DJSAIL itself was bootstrapped — the stylesheet uses X3DUOM to generate the JSAIL source.

X3dToPython.xslt

Produces Python x3d.py library source that re-creates the scene. Companion to X3dToJava.xslt.

→ .py

Output: Python script using the x3d.py package (pip-installable). Same round-trip pattern as Java. Run the .py to regenerate the .x3d. Enables Python-native scene building workflows. Important for the Blender integration angle — connecting io_scene_x3d (Python) with X3DJSAIL (Java) via this stylesheet is a natural bridge.

X3dToJson.xslt

Converts .x3d XML to the X3D JSON encoding. Supports forthcoming X3D JSON standard.

→ .json

Drops DOCTYPE (expected — XSLT can't carry it). Uses Saxon expand:off for default attribute handling. JSON encoding maps XML attributes → JSON object fields, XML children → arrays. Used extensively in web3D toolchains (X3DOM, X_ITE). The JSON encoding spec was co-authored by Roy Walmsley and Don Brutzman (Web3D 2016 paper).

X3dToVrml97.xslt

Backwards compatibility to VRML97 .wrl format. Warns in-output for X3D features with no VRML97 equivalent.

→ .wrl

Any X3D scene fitting the Immersive Profile will convert cleanly. Features beyond Immersive (CAD, GeoSpatial, H-Anim, DIS, physics, etc.) emit embedded warnings. The stylesheet embeds console output to report conversion difficulties.

X3dToX3dvClassicVrmlEncoding.xslt

Converts to ClassicVRML (.x3dv) — the curly-brace text encoding of X3D (not VRML97 but similar syntax).

→ .x3dv

ClassicVRML is the "classic" text encoding for X3D — semantically identical to XML X3D but using VRML-style brace syntax. Verified for syntax correctness using Castle Model Converter and Castle Model Viewer in CI.

X3dToX3domX_ITE.xslt / X3dToXhtml.xslt

Produces a self-contained HTML5 page with X3D inline. X3DOM and X_ITE (formerly Cobweb) are two web renderers.

→ .html

X3DOM and X_ITE both render X3D directly embedded in HTML5 via WebGL, with no plugin. X3dToXhtml.xslt is the tagset pretty-printer with cross-linked DEF/USE/ROUTE indexing — useful for documentation. X3dToX3domX_ITE.xslt produces the live interactive page.

X3dTidy.xslt

Semantic cleanup and correction. Fixes common errors — does not just pretty-print. Available as menu item X3D → Conversions → X3D Tidy.

→ cleaned .x3d

Checks and corrects things like: NULL value handling, field default value normalization, DEF/USE consistency, coordinate system inconsistencies. The result is a corrected .x3d. Complements but does not replace schema/Schematron validation (those report errors; Tidy fixes them).

X3dExtrusionCrossSectionToSvg.xslt

Visualizes Extrusion node cross-section profiles as SVG. A specialized geometry inspection tool.

→ .svg

Extracts the crossSection point array from an Extrusion node and renders it as a 2D SVG diagram. Extremely useful for debugging complex extrusion paths. Also shows spine path and scale. Represents the pattern of using XSLT for geometry-specific diagnostics.

X3dModelMetaToMarkdown.xslt

Extracts all meta name=value pairs from an X3D model's head and produces a Markdown documentation file.

→ .md

Useful for automated documentation generation. Meta tags in X3D head carry title, description, author, license, created date, etc. This stylesheet makes them into human-readable Markdown docs. Supports CI documentation pipelines.

EXI binary encoding

X3D supports EXI (Efficient XML Interchange) — a W3C standard for binary XML encoding that dramatically reduces file size and parse time. Two EXI engines supported:

EXIficient (default) OpenEXI (alternate)

Files can be loaded via CommandLine -fromEXI or X3D.loadFromFileEXI(). The X3D JSON encoding uses gzip internally; EXI is the more aggressive binary option targeting bandwidth-constrained delivery (IoT, web streaming).

X3DJSAIL — the programmatic API

A Plain Old Java Object (POJO) implementation of the full X3D scene graph. 500+ concrete classes, autogenerated from X3DUOM. Implements both org.web3d.x3d.jsail (concrete) and org.web3d.x3d.sai (abstract ISO binding interfaces).

X3D object (root) capabilities

Serialization methods

toFileX3D, toFileJava, toFilePython, toFileJSON, toFileClassicVRML, toFileVRML97, toFileX3DOM, toFileX_ITE, toFileHtmlDocumentation, toFileMarkdown, toFileEXI, toFileGZIP, toFileZIP

Pattern: every method calls toFileStylesheetConversion(filename, stylesheet, params) internally. SAXON is invoked as a Java library, not a command-line process. Outputs can be round-trip verified: .x3d → .java → compile → run → new .x3d → diff against original. The round-trip test suite does exactly this on thousands of example scenes nightly in CI.

Validation methods

validationReport(), toStringSchematron(), toStringX3DTidy(), isValid(), findNodeByDEF(), findNodeByName()

validationReport(): comprehensive check of all nodes, fields, types, parent-child relationships. Returns multi-line diagnostic string. findNodeByDEF() walks the scene graph recursively to locate a node by its DEF attribute — useful for programmatic scene modification. isValid() returns boolean after running all checks.

Method pipelining (fluent API)

All setter methods return the same object (this), enabling chained method calls. Example: new Transform().setDEF("MyXfm").setTranslation(1,2,3).setChildren(...)

The fluent API is baked into every JSAIL class — each set*() returns X3DObject (or the concrete subclass). This allows the generated Java output from X3dToJava.xslt to be compact and readable. It's also key to making X3DJSAIL usable as a scene construction library without verbose intermediate variable assignment.

CommandLine utility

java org.web3d.x3d.jsail.CommandLine — standalone JAR access to all X3DJSAIL capabilities via CLI switches.

Supports: -validate, -toX3D, -toXML, -toClassicVrml, -toJava, -toJSON, -toPython, -toVRML97, -toHTML, -toX3DOM, -toX_ITE, -toMarkdown, -toEXI, -toGZIP, -toZIP, -canonical, -fromEXI, -fromGZIP, -fromZIP, -Schematron, -Tidy, -X3DUOM, -hints, -regexes, -tooltips. The CommandLine class is also embedded in every Java file produced by X3dToJava.xslt so each generated program is also self-executing.

ConfigurationProperties

Static singleton controlling all X3DJSAIL runtime behavior. Key settings:

XSLT_ENGINE_SAXON / _NATIVE_JAVAwhich XSLT engine to use

EXI_ENGINE_EXIFICIENT / _OPENEXIwhich EXI engine to use

indentCharacter, indentIncrementserialization whitespace

showDefaultAttributeswhether to emit attributes that match X3D defaults

deleteIntermediateFilescleanup after XSLT temp files

omitTrailingZerosfloat formatting cleanup in output

propertiesFileNameload custom X3DJSAIL.properties file

SF/MF field type system

X3D has a rich type system — all 40+ field types are implemented as Java objects in org.web3d.x3d.jsail.fields:

SFBool / MFBoolSFInt32 / MFInt32SFFloat / MFFloat SFDouble / MFDoubleSFVec2f / MFVec2fSFVec3f / MFVec3f SFVec4f / MFVec4fSFRotation / MFRotationSFColor / MFColor SFColorRGBA / MFColorRGBASFString / MFStringSFNode / MFNode SFImage / MFImageSFMatrix3f / MFMatrix3fSFMatrix4f / MFMatrix4f

Each field object includes regex-based validation, isNMTOKEN() name checks, and interoperability naming convention checks. FieldObjectTests.java has hundreds of tests covering every method of every field type.

X3dSourceFilePalette — node categories

The palette organizes all X3D nodes by X3D profile component. Each node has a custom customizer panel (a Swing JPanel specific to that node) with field editors, tooltips from X3D Tooltips, and a "Check" QA button.

Core / scene graph nodes

X3DSceneheadmetacomponentunit WorldInfoGroupTransformSwitchInline LODStaticGroupCollision DEF / USEROUTEProtoDeclareProtoInterface ProtoBodyProtoInstanceExternProtoDeclare

Geometry 3D

BoxConeCylinderSphere IndexedFaceSetIndexedTriangleSetIndexedTriangleFanSetIndexedTriangleStripSet TriangleSetTriangleFanSetTriangleStripSet ElevationGridExtrusion IndexedLineSetLineSetPointSet

Geometry 2D

Arc2DArcClose2DCircle2DDisk2D Polyline2DPolypoint2DRectangle2DTriangleSet2D

Appearance / Materials

AppearanceMaterialTwoSidedMaterial PhysicalMaterialUnlitMaterial ImageTextureMovieTexturePixelTexture MultiTextureTextureCoordinateTextureTransform ComposedShaderPackagedShaderProgramShaderShaderPartShaderProgram ComposedCubeMapTextureGeneratedCubeMapTextureImageCubeMapTexture

PhysicalMaterial and UnlitMaterial are X3D v4 additions — the PBR material model. This is what io_scene_x3d currently lacks on export.

Animation / Interpolation

TimeSensor PositionInterpolatorOrientationInterpolator ScalarInterpolatorColorInterpolator NormalInterpolatorCoordinateInterpolator EaseInEaseOutSquadOrientationInterpolatorSplinePositionInterpolator

Sensors

TouchSensorPlaneSensorCylinderSensorSphereSensor KeySensorStringSensor VisibilitySensorProximitySensor TransformSensorLoadSensor

Advanced / Specialized profiles

GeoLocationGeoLODGeoMetadataGeoPositionInterpolatorGeoTouchSensorGeoViewpoint HumanoidJointSegmentSiteHAnimMotion CADAssemblyCADFaceCADLayerCADPart EspduTransformSignalPduReceiverPduTransmitterPdu NurbsCurveNurbsSurfaceNurbsSetNurbsPatchSurface VolumeDataIsoSurfaceVolumeDataSegmentedVolumeData

XML Security — digital signatures + encryption

A distinctive capability not found in most X3D tools. X3D-Edit can embed W3C XML Digital Signature (ds:) and XML Encryption (xenc:) namespaces directly into X3D scenes. The preferences panel configures keystore paths, passwords, and certificate aliases.

Use cases: scene provenance authentication (prove a scene came from a trusted source), IP protection of X3D content for enterprise deployments, signed X3D assets in supply chains. The tool validates signatures on import and embeds them on export.

Current known issue (GitHub): digital signature validation fails for signed X3D files even when ds: and xenc: namespaces are declared — under investigation.

ROUTE event tracing

When the Trace checkbox is enabled on any node, X3D-Edit inserts a Script node immediately after it that intercepts and logs all events through that ROUTE connection. Output goes to the browser console with timestamps and event values. Useful for debugging complex animation and sensor networks.

This is implemented as XSLT — the Trace option adds the Script node template inline in the XML. Sensors, interpolators, and ROUTE destinations all support it.

Visualization widgets

X3D-Edit can auto-insert visualization helper geometry into scenes during authoring. Configure via X3D-Edit Visualization Preferences. Examples include: axis indicators for coordinate frames, bounding box helpers, skeleton visualization for H-Anim Humanoid, sensor zone indicators for proximity/visibility sensors.

CAD Distillation Filter (CDF)

Parameters for geometry reduction/distillation targeted at CAD data coming in from engineering tools (via COLLADA or direct CAD export). The CDF preferences let you control level-of-detail reduction, polygon budget limits, and simplification threshold. Feeds into the CADGeometry profile nodes (CADAssembly, CADFace, CADLayer, CADPart).

H-Anim humanoid animation (X3D v4 update)

Full support for the H-Anim 2.0 Humanoid Animation specification. Nodes include: Humanoid, Joint, Segment, Site, and the newer HAnimMotion node (X3D v4 addition) for motion capture data. X3D-Edit provides customizer panels for each, with skeleton preview in the Xj3D viewer.

HAnimMotion is notable — it represents a channel-based motion capture encoding directly in the scene graph, without requiring external BVH files. This is new in v4.

DIS profile — Distributed Interactive Simulation

X3D has a full profile for military and training simulation via IEEE 1278 DIS (Distributed Interactive Simulation) PDUs (Protocol Data Units). Nodes: EspduTransform, SignalPdu, ReceiverPdu, TransmitterPdu, DISEntityManager, DISEntityTypeMapping.

This ties X3D scenes directly into live simulation networks — a 3D object's position is updated in real time by incoming DIS PDUs over the network. X3D-Edit originated at the Naval Postgraduate School, which explains this focus.

GeoSpatial profile

Nodes for geographically-referenced 3D content: GeoLocation, GeoLOD, GeoViewpoint, GeoPositionInterpolator. Supports multiple coordinate systems: GD (Geographic), UTM, GC (Geocentric). Allows X3D scenes to be anchored to real-world coordinates with correct datum handling.

CORS server + X_ITE workflow

A recently added feature. X3D-Edit can auto-launch a CORS-compliant HTTP server on localhost (configured as a user preference). This enables rendering X3D scenes in X_ITE (formerly Cobweb) directly in the browser without same-origin policy errors. The workflow is: download examples → enable CORS autolaunch → open .x3d → auto-preview in X_ITE in browser. Key for the modern web-delivery use case.

X3D Canonical Form

X3DJSAIL supports serialization to X3D Canonical Form — a normalized, deterministic XML representation used for comparison, diffing, and digital signature. Canonical form eliminates whitespace variations, normalizes attribute ordering, and makes round-trip comparison reliable. Invoked via toStringX3D() with canonical flag or CommandLine -canonical.

Recent development themes (2024–2025)

Based on release notes, README changelogs, and issue tracker activity. X3D-Edit v4.0.37–v4.0.40.

Java OpenJDK 24/25 compatibility + JAXP entity expansion fix breaking change

JDK-8343022 — OpenJDK 24 restricted JAXP entity expansion by default. X3D DOCTYPE is large enough to hit the new 1000-entity limit. Required adding -J-Djdk.xml.entityExpansionLimit=5000 to netbeans.conf. Active recent maintenance focus.

Apache NetBeans 25/26/27/28 quarterly upgrades ongoing

X3D-Edit follows NetBeans release cadence (quarterly). Each major NetBeans update requires rebuilding and re-signing the NBM plugin module. Now at NetBeans 28 + OpenJDK 25.0.1 for the Nov 2025 build.

CORS localhost http server integration new feature

Auto-launch CORS server on localhost as a user preference. Enables seamless X_ITE-in-browser preview without manually starting a web server. Part of a push to improve the web delivery workflow for X3D content.

X3D version 4.0 validation support complete complete

Full v4 Schema, Schematron rules, and new node support (PhysicalMaterial, UnlitMaterial, HAnimMotion, unit element with conversion factors). X3DJSAIL tracking v4 standard throughout 2024-2025.

X3dSourceFilePalette module — name alignment ongoing in progress

README notes "not all names aligned, not all source applied, work ongoing" for the palette module. Active work harmonizing node/panel class naming conventions after the migration from SourceForge to GitHub Maven-based build.

XML Security digital signature validation bug open issue

Signed X3D files with ds:/xenc: namespace declarations fail validation even when properly signed. Issue open in GitHub tracker. The signing side works; the verification side has a namespace resolution failure.

unit element editor panel — angle/length/mass/force new feature

X3D v4 unit command lets scenes declare non-meter coordinate units. New editing panel provides reference conversion factors. Lets authors work in feet, inches, or other units with automatic conversion documentation.

Maven Central deployment + GitHub trusted plugin migration complete

Full move from SourceForge build system to GitHub + Maven Central. Plugin is now a trusted entry in the Apache NetBeans Plugin Portal (over 24,000 downloads since May 2023).

Connection points to io_scene_x3d (Blender)

These are where X3D-Edit's Java ecosystem and the Blender Python addon can meet.

PBR material bridge

X3D-Edit now has PhysicalMaterial + UnlitMaterial (X3D v4). io_scene_x3d has no PBR export. Direct opportunity.

Idea: Extend io_scene_x3d export to traverse Blender's Principled BSDF node tree and emit X3D v4 PhysicalMaterial nodes (baseColor, metallic, roughness, emissiveColor, normalTexture, occlusionTexture). The X3D-Edit customizer panel for PhysicalMaterial documents exactly which fields exist and their valid ranges — use it as your spec reference. X3DJSAIL's PhysicalMaterial class gives you the complete field list programmatically.

H-Anim armature export

Blender armatures map naturally to H-Anim Joint/Segment hierarchy. Export path is currently missing from io_scene_x3d.

Idea: Walk Blender's armature bones → emit X3D Humanoid/Joint/Segment tree. HAnimMotion (X3D v4) can encode keyframe animation directly. X3D-Edit has full editing support for these nodes. Would enable round-trip Blender ↔ X3D for character animation, and connection to web-based X3D character viewers via X3DOM/X_ITE.

X3dToPython.xslt output → Blender

X3D-Edit can export .x3d → .py (Python using x3d.py). That Python could potentially drive io_scene_x3d directly.

Idea: The Python x3d.py package and Blender's io_scene_x3d both operate in the X3D space but from different angles. A bridge script that translates x3d.py scene objects into bpy.data calls (essentially an in-memory importer without the XML parse step) would enable programmatic scene building in X3D terms that directly populates a Blender scene.

ROUTE animation import (io_scene_x3d TODO)

import_x3d.py has ROUTE_IPO_NAMESPACE infrastructure but animation is never built. X3D-Edit fully supports ROUTE authoring.

Gap: X3D has TimeSensor + PositionInterpolator/OrientationInterpolator + ROUTE → this is a keyframe animation system. Blender's action system maps to this 1:1. The ROUTE_IPO_NAMESPACE in the importer was designed for exactly this — it's just never wired to bpy.data.actions. X3D-Edit's interpolator nodes show the exact data layout needed.

EXI binary I/O for performance

X3D-Edit supports EXI (compact binary XML). Large Blender exports would benefit enormously from EXI encoding.

Idea: For large architectural/engineering scenes exported from Blender, EXI encoding can reduce file size 10x+ vs plain XML X3D. Adding EXI write support to io_scene_x3d would require either a Python EXI library (rare) or a subprocess call to X3DJSAIL's CommandLine -toEXI. The latter is practical as a post-export step.

GeoSpatial + Blender GIS integration

Blender has growing GIS/geospatial workflows. X3D GeoLocation/GeoLOD could be the bridge to web delivery.

Idea: Blender scenes with real-world coordinates (from GIS imports like BlenderGIS addon) could export X3D GeoLocation nodes, placing geometry at real-world lat/lon/alt. X3D-Edit has full GeoSpatial profile editing support. The web viewer (X_ITE, X3DOM) can then render these scenes against virtual globes.

DIS simulation export

X3D DIS profile connects 3D objects to live simulation networks. Blender models destined for simulation use.

Niche but powerful: Defense, training, and simulation users use Blender to create 3D assets that end up in real-time simulation environments. Exporting Blender objects with EspduTransform wrappers would let them drive position/orientation directly from DIS PDUs over UDP in real time. NPS (where X3D-Edit originated) actively works on this use case.

X3D Canonical Form for diffing

Use X3D Canonical Form to reliably compare Blender export outputs across commits or settings changes.

Testing idea: Running X3DJSAIL's canonical serialization on io_scene_x3d outputs would give deterministic, diffable output regardless of floating-point formatting, attribute ordering, or whitespace. Extremely useful for building a regression test suite for the Blender exporter — compare canonical form of expected output against actual output.