[x3d-public] InlineGeometry node and PLY format support in Castle Game Engine
Don Brutzman
don.brutzman at gmail.com
Tue Apr 7 14:51:57 PDT 2026
Thanks for references Michalis. Here is an example test scene.
- X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Additive
Manufacturing, Teapot Inline Geometry Ply
- Loading a classic teapot model in PLY format
-
https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/AdditiveManufacturing/TeapotInlineGeometryPlyIndex.html
Implementation and evaluation always helps... Note significant differences
in rendering due to implicit choices for *creaseAngle*:
-
https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/AdditiveManufacturing/TeapotInlineGeometryPlyCastle.png
-
https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/AdditiveManufacturing/TeapotInlineGeometryPlySunrize.png[image:
image.png] [image: image.png]
Currently the author has no settings to adjust the handling of the mesh.
Suggestion: might we consider adding creaseAngle as a field for
InlineGeometry node? It is defined in the specification as follows.
- X3D Architecture 4.1 draft — ISO/IEC 19775-1:202x — 11 Rendering
component
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/rendering.html#CommonGeometryFields>
11.2.3 Common geometry fields
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/rendering.html#CommonGeometryFields>
-
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/rendering.html#CommonGeometryFields
The *creaseAngle* field affects how default normals are generated. If the
> angle between the geometric normals of two adjacent faces is less than the
> crease angle, normals shall be calculated so that the faces are shaded
> smoothly across the edge; otherwise, normals shall be calculated so that a
> lighting discontinuity across the edge is produced. Crease angles shall be
> greater than or equal to 0.0 angle base units.
>
EXAMPLE A crease angle of 0.5 angle base units means that an edge between
> two adjacent polygonal faces will be smooth shaded if the geometric normals
> of the two faces form an angle that is less than 0.5 angle base units.
> Otherwise, the faces will appear faceted.
However, typically an author has no idea on what might be an appropriate
value, unless they do extensive sleuthing on an unchanging piece of
geometry. Thus we might pick a default value for *creaseAngle* field that
always results in smooth shading.
- SFFloat [ ] creaseAngle 3.14159 [0,+inf)
Further descriptions found in X3D tooltips.
- X3D Tooltips in English version 4.0 (with X3D version 4.1 draft),
IndexedFaceSet.creaseAngle
<https://www.web3d.org/x3d/tooltips/X3dTooltips.html#IndexedFaceSet.creaseAngle>
-
https://www.web3d.org/x3d/tooltips/X3dTooltips.html#IndexedFaceSet.creaseAngle
*[creaseAngle accessType initializeOnly
<https://www.web3d.org/x3d/tooltips/X3dTooltips.html#accessType>, type
SFFloat <https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFFloat> CDATA
<https://www.web3d.org/x3d/tooltips/X3dTooltips.html#CDATA> "0"] [0,+∞)
<https://www.web3d.org/x3d/tooltips/X3dTooltips.html#RangeIntervals>*
creaseAngle defines angle (in radians) for determining whether adjacent
polygons are drawn with sharp edges or smooth shading. If angle between
normals of two adjacent polygons is less than creaseAngle, smooth shading
is rendered across the shared line segment.
*Hint:* in Interchange profile only 0 and π radians supported.
*Hint:* creaseAngle=0 means render all edges sharply, creaseAngle=3.14159
means render all edges smoothly.
*Hint:* radian units for angular measure
https://en.wikipedia.org/wiki/Radian
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Mon, Apr 6, 2026 at 5: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/20260407/071bcaf8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 172990 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260407/071bcaf8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 159864 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260407/071bcaf8/attachment-0003.png>
More information about the x3d-public
mailing list