[x3d-public] proposal for new X3D node: InlineGeometry

[Don Brutzman]

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/20260210/f8f5fc88/attachment.html>