[x3d-public] InlineGeometry node and PLY format support in Castle Game Engine
Don Brutzman
don.brutzman at gmail.com
Thu Apr 9 15:33:24 PDT 2026
Good points all in this thread, lots to consider here as we strive for
simple effectiveness.
Any geometry type might be returned... if there was an <InlineGeometry
url="MyExpensiveCadModel.x3d#QuadSetOfInterest"/> it seems likely a QuadSet
would be returned.
A creaseAngle field might lead to much downstream confusion, even if a
satisfactory specification definition was crafted.
A much-simpler possible field to express author intent: a 'smooth' field
declaring a hint for applying smooth versus sharp shading, if possible.
- SFBool [in out] smooth TRUE
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Thu, Apr 9, 2026 at 2:12 PM Michalis Kamburelis <
michalis at castle-engine.io> wrote:
> To Don's idea of "creaseAngle as a suggestion":
>
> I'm not against it (and I would support it in CGE as much as we could :)
> ). But as a hint, it could be problematic, as users will find it is not
> reliable and could have "wrong expectations".
>
>
> - E.g. X_ITE generates IndexedTriangleSet from PLY mesh, while CGE
> generates (right now!) IndexedFaceSet. This means that users could have
> wrong expectations from X_ITE -- creaseAngle, for PLY, in X_ITE would not
> work.
>
>
>
> - ( Unless X_ITE changes algorithm to use IndexedFaceSet. But forcing
> this would be bad -- a browser should have a choice what geometry type to
> use here, not be forced to use IndexedFaceSet . Which geometry type
> is more suitable -> depends on internal optimizations. )
>
>
>
> - If CGE changes our algorithm (which I reserve the right to do! we
> had in the past occasions when it made sense to change geometry types for
> terrains), then suddenly we will have bugreports
> "InlineGeometry.createAngle for PLY worked in Castle Model Viewer version
> 5, but no longer works in version 6". This will make users unhappy:)
> Explaining to users that "InlineGeometry.creaseAngle was always
> supposed to be only a hint, never guarantee" will not be of much help --
> because users will then have models that depended on the old behavior, and
> will consider the new behavior a regression.
>
>
> Also: browsers should be "consistent by default" anyway. We should to
> "what is expected by given format". Which means that, if PLY models are (by
> convention) displayed with smooth normals (when no explicit normals are
> provided) -> then all viewers, X_ITE and CGE, should display them by
> default with smooth normals. (Which is what happens now, after my change
> yesterday:) ).
>
> IOW, I'm not against InlineGeometry.creaseAngle (as long as default would
> be "-1" meaning "no override")... but it doesn't achieve that much (we need
> to make our defaults consistent anyway), and may in fact give wrong
> expectations to users (when it will work only in certain browsers/versions).
>
> To Joe: I'm afraid making the geometry type depending on profile would be
> surprising to users, and would not really solve the issue discussed here :)
>
> Both browsers (X_ITE and CGE) support both geometry types (
> IndexedTriangleSet and IndexedFaceSet). It's not a question of support.
> Both browsers choose to load PLY as most optimal format, which may be a
> different decision for each browser. This should not be influenced by
> profile of enclosing file, this would be quite non-standard (as the profile
> also doesn't influence regular Inline).
>
> Regards,
> Michalis
> On Thursday, April 9th, 2026 at 03:09, Don Brutzman via x3d-public <
> x3d-public at web3d.org> wrote:
>
> Please re-read my suggestions from earlier today. Apologies for not being
> clearer.
>
> I was trying to express that creaseAngle might be a hint from the author,
> regardless of original inlined geometry mesh type and also independent of
> the browsers choice of geometry (IFS, triangles, etc.). It is a way for
> author to express whether smooth rendering is desired.
>
> For example, a literal creaseAngle might be literally unusable if browser
> chooses to return a TriangleSet, but the browser might add Normal values to
> address smooth/sharp edges.
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
>
>
> On Wed, Apr 8, 2026 at 5:30 PM Joe D Williams via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> Choice of IFS or ITS could be a choice of Profile.
>>
>> IFS is simple profile, rendering 1 for IFS and rendering 3 for ITS.
>>
>> Joe
>>
>> -----Original Message-----
>> From: Michalis Kamburelis via x3d-public <x3d-public at web3d.org>
>> Sent: Apr 8, 2026 1:17 PM
>> To: Holger Seelig <holger.seelig at yahoo.de>
>> Cc: Michalis Kamburelis <michalis at castle-engine.io>, Extensible 3D (X3D)
>> Graphics public discussion <x3d-public at web3d.org>
>> Subject: Re: [x3d-public] InlineGeometry node and PLY format support in
>> Castle Game Engine
>>
>> Hm, good point about the geometry type and so, the creaseAngle not being
>> that much useful...
>> Indeed the difference in look between X_ITE and CGE is then because of
>> different geometry choice.
>>
>> - Castle Game Engine converts PLY mesh into IndexedFaceSet, where the
>> creaseAngle (default 0, so flat shading) decides the look. I've done it
>> because PLY meshes have polygons and we have already handling for
>> possibly-concave polygons (which I understand PLY may have) at
>> IndexedFaceSet. So we generate PLY -> IndexedFaceSet, set
>> IndexedFaceSet.convex=FALSE, and we're done.
>>
>>
>> - ( To be clear, this decision is not set in stone. My past
>> experience with e.g. terrains showed that sometimes changing the generated
>> primitive/geometry type is useful, for unforeseen reasons :) So this is
>> _not_ a guarantee that CGE will always read PLY to IndexedFaceSet, and not
>> e.g. IndexedTriangleSet. )
>>
>>
>> - If X_ITE converts PLY mesh into IndexedTriangleSet, then
>> creaseAngle doesn't exist (IndexedTriangleSet.normalPerVertex decides, and
>> it's either all flat or all smooth).
>>
>> Indeed we're not going to reconcile this with creaseAngle.
>> I think in the end, it comes down to the underlying formats -- is there
>> any spec, or just a hint / consensus, how should normals for PLY models be
>> generated? Does everyone create smooth meshes then, like X_ITE? If the
>> consensus is to generate smooth normals -> then the fix is just on CGE
>> side, we can trivially change our PLY -> IndexedFaceSet to set
>> creaseAngle>=pi and then CGE and X_ITE will be consistent. Seems like this
>> is the simplest way to go :)
>> Hm, done in
>> https://github.com/castle-engine/castle-engine/commit/bbbfc016ed179b2009cf8194dd692b81adf1f6e3
>> :) PLY teapot from
>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/AdditiveManufacturing/TeapotInlineGeometryPlyIndex.html
>> is now smooth in our rendering.
>> Regards,
>> Michalis
>> On Wednesday, April 8th, 2026 at 21:00, Holger Seelig <
>> holger.seelig at yahoo.de> wrote:
>>
>> If the teapot is faceted in Castle, it’s more likely because a different
>> geometry was used. X_ITE converts the PLY teapot into an
>> IndexedTriangleSet, which, as mentioned earlier, does not have a
>> creaseAngle field.
>> If InlineGeometry has a creaseAngle field, it gives the impression that
>> the creaseAngle can be set for the loaded geometry, but this is only
>> possible in the rarest of cases.
>> Best regards,
>> Holger
>> —
>> Holger Seelig
>> holger.seelig at yahoo.de
>>
>>
>> Am 08.04.2026 um 20:49 schrieb Holger Seelig via x3d-public <
>> x3d-public at web3d.org>:
>> I would like to point out that only 4 of the 32 X3DGeometryNode's have a
>> creaseAngle field. On the other hand, why is creaseAngle preferred here?
>> The solid field or ccw can also be useful, but they are not available on
>> all X3DGeometryNode's either.
>> Best regards,
>> Holger
>> —
>> Holger Seelig
>> holger.seelig at yahoo.de
>>
>>
>> Am 08.04.2026 um 18:13 schrieb Michalis Kamburelis via x3d-public <
>> x3d-public at web3d.org>:
>> Confirming Don's observations -- the difference in rendering of Teapot
>> from PLY in
>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/AdditiveManufacturing/TeapotInlineGeometryPlyIndex.html
>> seems to come from difference in creaseAngle.
>> In Castle Game Engine, when we load PLY -> we leave
>> "IndexedFaceSet.creaseAngle" at default in X3D, which is 0, which results
>> in flat shading (
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/geometry3D.html#IndexedFaceSet
>> ).
>> Note that PLY files _can_ provide their own, explicit normal vectors. In
>> which case there would be non inconsistency. But, well, this PLY model (
>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/AdditiveManufacturing/teapot.ply
>> ) does not provide normals. It only has vertex positions.
>> Introducing "InlineGeometry.creaseAngle" makes sense to me.
>> Internally, I would also allow loading options as URL anchor, so one
>> could load "xxx.ply#crease-angle=123" thus it would be possible to
>> influence creaseAngle also for models loaded through "Inline", like
>> """Inline { url "model.ply#crease-angle=123" />"""
>> Compared to Don prose, I would say to allow an option to _don't change
>> the underlying value (or browser default)_. Because when we inline e.g. X3D
>> geometry, then (possibly) it already has a useful creaseAngle? So I would
>> define it like:
>> """
>> InlineGeometry {
>> ...
>> creaseAngle initializeOnly -1
>> }
>> creaseAngle determines the the automatic calculation of normal vectors
>> for the imported geometry. It is only used if all of the below are true:
>>
>> 1. Given creaseAngle is >= 0. The default, -1, means to use
>> creaseAngle specified in the imported model (if the format of it allows
>> creaseAngle, like X3D allows) or browser-specific default.
>> 2. Imported geometry results in X3D geometry with creaseAngle, e.g.
>> in IndexedFaceSet. For other geometry types, like PointSet, creaseAngle is
>> ignored.
>> 3. Imported geometry doesn't have explicit normal values. E.g. if PLY
>> file has explicit normal provided, then these are used, and the creaseAngle
>> value doesn't matter.
>>
>>
>> """
>> Regards,
>> Michalis
>> On Tuesday, April 7th, 2026 at 23:52, Don Brutzman <
>> don.brutzman at gmail.com> wrote:
>>
>> 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.png> <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
>> <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#InlineGeometry 9.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
>>>>> <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
>>>>>
>>>>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> 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/20260409/e02ee907/attachment-0001.html>
More information about the x3d-public
mailing list