[x3d-public] InlineGeometry node and PLY format support in Castle Game Engine
Don Brutzman
don.brutzman at gmail.com
Sun Apr 5 22:17:53 PDT 2026
Thank you Michalis for implementing the draft InlineGeometry node. Having
both Castle Game Engine and (already supporting) X_ITE/Playground/Sunrize
is definitely accelerating our design, implementation and evaluation of
LOA-5 bone segments for HAnim. Tests of your Castle Model Viewer beta
release look good on this end.
Repeating a prior reply: "Gaussian Splat PLYs" (whatever that means) does
not seem like a good use of effort. There is a lot of ongoing
developmental work on gaussian splat formats by various companies that are
nonstandard, inconsistent, possibly unstable, and often proprietary. Some
happen to use .ply as a container. A prudent approach is to wait and see
what glTF does once things stabilize. Using Inline with glTF 2.0 (in json
or glb) is already in X3D 4.0, extension support by browsers is optional,
so that is a reasonable future path if consensus ever emerges.
The draft X3D specification for InlineGeometry describes rationale and
includes references for the PLY format.
- X3D Architecture 4.1 draft — ISO/IEC 19775-1:202x — 9 Networking
component
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#InlineGeometry>
9.4.3 InlineGeometry
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#InlineGeometry>
-
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#InlineGeometry9.4.3
InlineGeometry
InlineGeometry : X3DGeometryNode, X3DUrlObject {
SFTime [in,out] autoRefresh 0.0 [0,infinity)
SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,infinity)
SFString [in,out] description ""
SFBool [in,out] load TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFString [in,out] url [] [URI]
}
InlineGeometry loads geometry from an external file. The result provides
a polygonal mesh, set of lines, point cloud, parametric surface, or other
geometry.
The *url* field can support loading a variety of file formats defining
polygonal mesh geometry. When the *url* field contains no values ([]),
no default geometry is provided. Required Recommended support by X3D
browsers includes both ASCII and binary encodings for the STL format (see
STL
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/bibliography.html#STL>)
as well as the PLY polygonal geometry format (see PLY
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/bibliography.html#PLY>),
respectively. Other file types can be optionally supported by a browser.
TODO: consider "required support" of STL/PLY formats rather than
"recommended support" since numerous open-source conversion implementations
are available, no IPR considerations pertain, and STL/PLY formats are the
primary use case.
If the *url* field refers to an X3D file or a VRML97 file, the first
geometry node found in that file (excluding both prototype declarations and
prototype instances) is used to provide the InlineGeometry contents. X3D
browsers shall recognize *url* fields that end with "#*DEFname*" to mean
the geometry node with DEF label of *DEFname* in the given X3D or VRML97
file.
The run-time system can support any number of 3D model resource types as
long as those follow the available Model Primary Content Type for
Multipurpose Internet Mail Extensions (MIME) model definition (see
RFC2077
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#RFC2077>),
provide a registered content type (e.g., model/stl, text/plain etc.)
(see IANA_MEDIA
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#IANA_MEDIA>
and IANA_STL
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#IANA_STL>),
and can be determined with some form of content negotiation (see RFC9110
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#RFC9110>).
Support is recommended for both text and binary encodings associated with a
given model format, when so defined.
NOTE Experimental variations of PLY format used for Gaussian Splat
rendering are not expected for InlineGeometry. Such capabilities are better
supported by Inline node loading of glTF models.
EXAMPLES
Shape {
geometry InlineGeometry { url [ "MyFavoriteMesh.stl" ] }
appearance USE FancyPaintAppearance # previously defined
}
Shape {
geometry InlineGeometry { url [ "HelloWorld.x3d#TextMessage" ] }
appearance USE FancyPaintAppearance # previously defined
}
Editors notes.
- Are better authoritative references possible for STL and PLY? See Mantis
1522 <https://mantis.web3d.org/view.php?id=1522>.
- InlineGeometry results differ from an Inline node, which produces
an X3DChildNode scene subgraph implementing the X3DBoundedObject
interface.
An Inline node cannot be used as the *geometry* field of a Shape.
- Results from browser loading may be any kind of polygonal mesh or
parametric surface (e.g. IndexedFaceSet, TriangleSet, Extrusion,
etc.) but
cannot be further manipulated or animated by events from the scene.
- Direct loading of such geometry files eliminates the need for prior
model conversion into X3D, and adds flexibility when applying
Appearance to
the result.
- The "#*DEFname*" syntax directly matches EXTERNPROTO URL semantics
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#EXTERNPROTOURLSemantics>
considerations.
Not requiring IMPORT/EXPORT statements provides greater backwards
compatibility with legacy models, avoiding unnecessary complications and
possible ambiguity.
- Composition of online addresses and parameter values within a
*url* field
offers the possibility of invoking an online server to perform
file-format
conversions. See email thread [x3d-public] Inline > type field > for
loading / converting / parsing other content
<https://web3d.org/pipermail/x3d-public_web3d.org/2026-March/022355.html>
for
further discussion. Such additional functionality supports the use cases
under consideration by Metaverse Standards Forum (MSF) 3D Web
Interoperability
<https://metaverse-standards.org/domain-groups/3d-web-interoperability>
Working
Group.
Worth reading: the original PLY definition first defined in 1994 by Greg
Turk at Stanford University., references above.
- [PLY
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/bibliography.html#PLY>
]
-
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/bibliography.html#PLY
- Wikipedia, PLY (file format), 26 February 2026.
https://en.wikipedia.org/wiki/PLY_(file_format)
and
1. Greg Turk. "The PLY Polygon File Format"
<https://web.archive.org/web/20161204152348/http://www.dcs.ed.ac.uk/teaching/cs4/www/graphics/Web/ply.html>.
Archived from the original
<http://www.dcs.ed.ac.uk/teaching/cs4/www/graphics/Web/ply.html> on
2016-12-04.
2. Greg Turk. "The PLY Polygon File Format (extended)"
<https://gamma.cs.unc.edu/POWERPLANT/papers/ply.pdf> (PDF).
and
- PLY - Polygon File Format <https://paulbourke.net/dataformats/ply/>
https://paulbourke.net/dataformats/ply
Improvements to draft specification, especially with implementation and
evaluation, are always welcome.
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Sun, Apr 5, 2026 at 6:39 PM John Carlson via x3d-public <
x3d-public at web3d.org> wrote:
> Hi, Michalis, Seeing Gaussian Splat PLYs renderered with humanoid
> animation would be cool to see. With your expertise in binary formats and
> binary PLY, probably an easy next step!
>
> John
>
> On Sun, Apr 5, 2026 at 8:05 PM Michalis Kamburelis via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> With big thanks to Don who provided information and pushed me to
>> implement it!:)
>>
>> 1. We support now InlineGeometry in Castle Game Engine and Castle Model
>> Viewer.
>>
>> - I tested on a few examples, and made our own:
>> https://github.com/castle-engine/demo-models/tree/master/x3d/inline_geometry
>>
>> - You can refer to a geometry from any model format we support,
>> including X3D, glTF, STL, PLY...: https://castle-engine.io/model_formats
>>
>> 2. We support now loading models in a PLY format.
>>
>> - ASCII and binary versions.
>>
>> - Faces or without faces (point cloud, i.e. just our PointSet).
>>
>> - Testcases include
>> https://github.com/castle-engine/demo-models/tree/master/ply and
>> https://sketchfab.com/3d-models/kaktus-ply-7b7cc7188f17468595506500e186a9c0
>> .
>>
>> More information and screenshots about both features in our news post on
>> https://castle-engine.io/wp/2026/04/06/support-for-ply-model-format-and-inlinegeometry-node/
>> .
>>
>> They are available to test right now if you download
>> - the "snapshot" version of Castle Model Viewer
>> https://castle-engine.io/castle-model-viewer
>> - or full engine from https://castle-engine.io/download .
>>
>> Regards,
>> Michalis
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260405/b9731787/attachment-0001.html>
More information about the x3d-public
mailing list