[x3d-public] [X3D-Ecosystem] proposal for new X3D node: InlineGeometry
John Carlson
yottzumm at gmail.com
Sun Feb 22 16:16:33 PST 2026
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/24319462/attachment-0001.html>
More information about the x3d-public
mailing list