[x3d-public] [X3D-Ecosystem] proposal for new X3D node: InlineGeometry
Don Brutzman
don.brutzman at gmail.com
Sun Feb 22 17:17:02 PST 2026
If there is open-source Java and Python versions of source code that reads
an STL or PLY file, and turns a mesh into X3DJSAIL or x3d.py data
structures for X3D (for example IndexedFaceSet or whatever), then I am
willing to integrate such methods into those two libraries.
InlineGeometry reduces the need to convert STL or PLY, but there will
always be a use case for authors that want to turn such files into usable
X3D source.
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Sun, Feb 22, 2026 at 4:16 PM John Carlson <yottzumm at gmail.com> wrote:
> This is kind a blue sky feature that could aid in Inline* and URL
> conversion.
>
> Another idea, provide mapping parameters to conversion routines (probably
> not in X3DPSAIL or X3DJSAIL) such that *Texture, InlineGeometry or Inline
> URLs are mapped from one URL to another, and local file might be created if
> it doesn’t already exist, and applicable conversions are applied.
>
> What I’m thinking of is a quick way for an author to map URLs from one
> value to another value, say in X3D-Edit, as part of a (batch) scene
> overhaul/conversion process, like converting InlineGeometry STL files to
> X3D Inlines, automating the conversion process as much as possible.
>
> Sounds kind of complex, but perhaps worth doing, if authors are interested
> in this feature.
>
> Holger, Michalis, x3d-tidy and castle-model-converter might take -I
> (input) file and -O (output) file pairs on the command line to replace URLs
> without going into an authoring tool.
>
> This seems super complex and I don’t have a real use case. This might be
> extended to images as well. I could see the feature used to batch convert
> image URLs, but tools like Perl apply better for this.
>
> Just a random thought,
>
> John
>
> On Sun, Feb 22, 2026 at 5:04 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> Yes, I realize that. The idea was to make the fields available without
>> specifying them in the .x3d. I don’t know how that works. Read-only
>> fields. They are “initialized” by values in STL, etc. no manipulation or
>> animation implied. A read-only bounding box might be useful as well.
>> On Sun, Feb 22, 2026 at 1:56 PM Don Brutzman <don.brutzman at gmail.com>
>> wrote:
>>
>>> The answer to your question is right there in the draft specification
>>> prose.
>>>
>>> - X3D Architecture draft v4.2, 9 Networking component, 9.4.3
>>> InlineGeometry
>>> -
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#InlineGeometry
>>>
>>> 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.
>>>
>>>
>>> There are no fields in the InlineGeometry node interface to manipulate
>>> underlying geometry because each browser gets to decide how to tesselate an
>>> external geometry file.
>>>
>>> Suggestion: if you want the functionality of a Coordinate node, use a
>>> Coordinate node. Similarly for indexed geometry nodes, Normal and Tangent,
>>> Color and whatnot. Careful design of strongly typed X3D scene graphs is
>>> important. Online examples often provide excellent patterns for success.
>>>
>>> all the best, Don
>>> --
>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>> Relative Motion Consulting https://RelativeMotion.info
>>>
>>>
>>> On Sat, Feb 21, 2026 at 6:10 PM John Carlson <yottzumm at gmail.com> wrote:
>>>
>>>> Don,
>>>>
>>>> I wonder how InlineGeometry might interoperate with HAnimHumanoid
>>>> through
>>>> HAnimHumanoid.skinCoord? So if the entire skin is in a STL file, how
>>>> would we reference points inside the STL file through skinCoord?
>>>>
>>>> Could we have read-only field values in InlineGeometry for coordIndex,
>>>> points, and vectors, normals and tangents?
>>>>
>>>> I’m not sure if InlineGeometry is suitable as is for HAnimHumanoid
>>>> skin, unless it’s a corpse.
>>>>
>>>> Adding HAnim group.
>>>>
>>>> John
>>>> On Sat, Feb 21, 2026 at 6:45 PM Don Brutzman via X3D-Ecosystem <
>>>> x3d-ecosystem at web3d.org> wrote:
>>>>
>>>>> 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 <http://../bibliography.html#STL>) and the PLY polygonal geometry
>>>>> format (see PLY <http://../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 <http://../references.html#RFC2077>), provide a registered
>>>>> content type (e.g., model/stl, text/plain etc.) (see IANA_MEDIA
>>>>> <http://../references.html#IANA_MEDIA> and IANA_STL
>>>>> <http://../references.html#IANA_STL>), and can be determined with
>>>>> some form of content negotiation (see RFC9110
>>>>> <http://../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
>>>>>>
>>>>> --
>>>>> X3D-Ecosystem mailing list
>>>>> X3D-Ecosystem at web3d.org
>>>>> http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260222/bd24d58a/attachment-0001.html>
More information about the x3d-public
mailing list