[x3d-public] [X3D-Ecosystem] proposal for new X3D node: InlineGeometry
John Carlson
yottzumm at gmail.com
Sat Feb 21 19:07:34 PST 2026
In X3DGeometryNode:
SFNode [in,out] inline NULL [X3DUrlObject]
Delegation, above ^^^^^
But I like a separate node better. I side with abstract inheritance!
Is it possible to add a live HTML page as a dynamic MovieTexture? This can
obviously be in the Full profile.
John
On Sat, Feb 21, 2026 at 8:34 PM John Carlson <yottzumm at gmail.com> wrote:
> Also colorIndexes, and color values.
>
> It does seem like we might be spawning a whole crop of new inline geometry
> nodes parallel to normal geometry nodes.
>
> It’s almost like we need an “optional” inline interface on geometry node
> types, like an SFBool which turns on or off url object interfaces. Which
> may indicate that geometry nodes should have a delegate node, like
> an inline field.
>
> Composition over inheritance?
>
> Your call!
>
> John
>
> On Sat, Feb 21, 2026 at 8: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/20260221/9c47c522/attachment-0001.html>
More information about the x3d-public
mailing list