[x3d-public] InlineGeometry node and PLY format support in Castle Game Engine
John Carlson
yottzumm at gmail.com
Wed Apr 8 19:37:32 PDT 2026
Can confirm that Michalis new Model Viewer works with different PLY color
property names and opacity is working too! I tried the same model he did.
Great job!
John
On Mon, Apr 6, 2026 at 7:26 PM Michalis Kamburelis <
michalis at castle-engine.io> wrote:
> As for black points reported by John in some PLY files: Fixed.
>
> I added to Castle Game Engine / Castle Model Viewer support for reading
> color values from PLY through alternative properties. Details and links to
> more explanation in commit
> https://github.com/castle-engine/castle-engine/commit/c6d9acc08aa7a20e991b140d1379e265ea496faf .
> Screenshot attached.
>
> Note: All this is doing is adding alternative way to read colors from PLY,
> which lands in X3D per-vertex colors (Color or ColorRGBA node).
>
> I'm not entering the Gaussian Splat discussion in related thread(s) :), as
> I have to educate myself better about Gaussian Splats first. Tomorrow's
> Khronos lecture seems like a good opportunity to start learning.
>
> Regards,
> Michalis
>
>
>
> On Monday, April 6th, 2026 at 20:49, John Carlson via x3d-public <
> x3d-public at web3d.org> wrote:
>
> Sorry I meant I was able to see black point clouds without color (Michalis
> apparently uses different properties?).
> On Mon, Apr 6, 2026 at 1:00 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> I agree that the PLYs that I worked with weren’t suitable for X3D. Either
>> my parser was off, or there were negative color values, negative scales
>> etc. I thought a second person could look at the same files and make better
>> progress. I was able to view black points clouds (no clouds) from the PLY
>> files in castle. I can probably change the property in the PLY file to
>> achieve color in the point cloud. The point is, I don’t know if there’s
>> standard PLY color properties.
>>
>> Thanks,
>>
>> John
>>
>> On Mon, Apr 6, 2026 at 12:18 AM Don Brutzman <don.brutzman at gmail.com>
>> wrote:
>>
>>> 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/20260408/916eaf9b/attachment-0001.html>
More information about the x3d-public
mailing list