[x3d-public] proposal for new X3D node: InlineGeometry
Don Brutzman
don.brutzman at gmail.com
Sat Feb 21 16:44:09 PST 2026
Thanks for all feedback received. I've worked with Dick to draft a
proposed node definition. Current version follows.
- 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. Recommended support by X3D browsers include
ASCII and binary encodings for the STL format (see STL
<../bibliography.html#STL>) and the PLY polygonal geometry format (see PLY
<../bibliography.html#PLY>), respectively. Other file types can be
optionally supported by a browser.
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
<../references.html#RFC2077>), provide a registered content type (e.g.,
model/stl, text/plain etc.) (see IANA_MEDIA <../references.html#IANA_MEDIA>
and IANA_STL <../references.html#IANA_STL>), and can be determined with
some form of content negotiation (see RFC9110 <../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.
EXAMPLE
Shape {
geometry InlineGeometry { url [ "MyFavoriteMesh.stl" ] }
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.
Implementation, evaluation and improvement are welcome. Have fun with
InlineGeometry! 😃
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Tue, Feb 10, 2026 at 10:17 AM Don Brutzman <don.brutzman at gmail.com>
wrote:
> STL and PLY files are commonly used ways to define mesh geometry, often
> for rendering or for additive manufacturing. These formats are described at
>
> - Wikipedia: STL (file format)
> <https://en.wikipedia.org/wiki/STL_(file_format)>, a file format for
> 3D CAD models
> - Wikipedia: PLY (file format)
> <https://en.wikipedia.org/wiki/PLY_(file_format)> or Polygon File
> Format
>
> Typically if an X3D author wants to use such assets to load a mesh, they
> must be converted into an X3D graph. That is because the existing X3D
> Inline node results in an X3DChildNode rather than geometry. Pseudo-X3D
> example:
>
> X3D
> Scene
> children [
> WorldInfo title="MyImportedMeshModel"
> Group (
> Shape
> geometry *I**ndexedFaceSet DEF="ConvertedFromStlOrPly"*
> * Coordinate etc.*
>
> All of these gyrations require the use of a converter. Incidentally here
> are two excellent converters:
>
> - Castle Online Converter for 3D and 2D Models
> - https://castle-engine.io/convert.php
>
> and
>
> - X_ITE Free Online X3D File Format Converter
> - https://create3000.github.io/x_ite/laboratory/x3d-file-converter/
>
> Suggestion: why don't we define a new X3D node *InlineGeometry* that
> supports direct loading of STL or PLY geometry files, simplifying the
> current import process. Possible node interface would be something like
>
>> *InlineGeometry* : X3DGeometryNode, X3DUrlObject {
>> SFTime [in,out] autoRefresh 0.0 [0,∞)
>> SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,∞)\
>> SFString [in,out] description ""
>> SFBool [in,out] load TRUE
>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> MFString [in,out] url [] [URI]
>> }
>>
>> Am thinking that implementers of such a node might use any internal
> representation that they like: IndexedFaceSet, TriangleSet,
> IndexedStripSet, etc. etc. How the geometry gets rendered doesn't much
> matter to an end user, they just want the mesh to show up from the STL or
> PLY file.
>
> Example usage:
>
> Shape
> appearance Appearance (USE="FancyPaint")
> geometry* InlineGeometry (url="MyFavoriteMesh.stl")* # direct
> loading eliminates need for conversion
>
> One conceivable alternative is to create a Coordinate node, but that
> approach is insufficient since Coordinate only contains points and all
> connectivity information for the mesh gets lost. So that won't work, we
> should stick to X3DGeometryNode as the result of the inline geometry import.
>
> Restriction: apparently a recent develop some people are extending PLY
> file format to store gaussian splat information... we likely want to
> exclude such atypical functionality, instead waiting to take advantage of
> emerging glTF support for gaussian splats.
>
> Relevant X3D Architecture specification links:
>
> - X3D Architecture draft 4.1, 11 Rendering component, 11.3.5
> X3DGeometryNode
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/rendering.html#X3DGeometryNode>
> - X3D Architecture draft 4.1, 9 Networking component, 9.3.2
> X3DUrlObject
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#X3DUrlObject>
>
> I've started a Mantis issue to keep track of distilled commentary, to help
> ensure that we carefully and effectively consider such a powerful
> capability.
>
> - Web3D Mantis issue tracker 1522: proposed X3D node: InlineGeometry
> - https://mantis.web3d.org/view.php?id=1522
>
> All feedback welcome. What do you think?
>
> Have fun with X3D mesh interoperability! 😃 💠
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260221/b9bda777/attachment.html>
More information about the x3d-public
mailing list