[x3d-public] STL File Format for 3D Printing - Simply Explained | All3DP

[Michalis Kamburelis]

2017-08-14 12:21 GMT+02:00 Roy Walmsley <roy.walmsley at ntlworld.com>:
> Thanks for following up with this Michaelis. I was particularly interested
> to note that you permit an Inline node to read an STL file (as well as
> others, perhaps). I assume you simply specify the STL file in the URL, and
> your code selects an appropriate reader depending on the file extension
> and/or reading the header.
>

Yes, I allow to use a variety of formats there. See
https://castle-engine.sourceforge.io/x3d_extensions.php#section_ext_inline_for_all
. You just do

  Inline { url "my_file.stl" }

and it works. The type of file is detected depending on the MIME type
reported by WWW server, or just looking at the extension. (I don't
analyze the file contents to detect the 3D format, at least not now.)

I also allow to specify any 3D model inside Anchor node :)

> "Each specified URL shall refer to a valid X3D file that contains a list of
> children nodes, prototypes and routes at the top level as described in
> 10.2.1 Grouping and children node types. The results are undefined if the
> URL refers to a file that is not an X3D file, or if the X3D file contains an
> invalid scene."
>
> To permit loading of file types other than formal X3D files this text would
> have to be modified.
>

This paragraph says that "results are undefined if the URL refers to a
file that is not an X3D file". So, if I understand the meaning of
"results are undefined", the specification actually allows the
implementation to interpret other file formats. It does not say "It is
an error if the URL refers to a file that is not an X3D file".

I know, it's just a "formal" difference :) In practice, it's very
natural for both authors and my implementation to just allow there
other 3D formats. For my engine, everything is loaded as an X3D node
graph in memory.

Regards,
Michalis