[x3d-public] X3Dv4 progress; PointProperties and points/lines/mesh, OBJ,

[Andreas Plesch]

> Date: Fri, 3 Jan 2020 10:21:36 -0800
> From: Don Brutzman <brutzman at nps.edu>

[snip]
> f. OBJ (and STL and PLY) support: prior discussions showed these could be supported in X3Dv4.  All of these formats are well supported in model converters to/from X3D Shapes and each matches to geometry and appearance information (in various combinations).
>
> Reference:
>         [x3d-public] X3D minutes 6 SEP 2019: DICOM discussion, overview diagram review, ISO meeting highlights, API progress, defer STL/OBJ support
>         http://web3d.org/pipermail/x3d-public_web3d.org/2019-September/011251.html
>
> view3DScene (CastleGameEngine) supports OBJ and STL as allowable Inline formats.
>
>         https://michalis.ii.uni.wroc.pl/view3dscene-snapshots
>
>         view3dscene, 4.2. Converting to VRML/X3D
>         https://castle-engine.io/view3dscene.php#section_converting
>
>         Support for the STL format for 3D models (commonly used for 3D printing)
>         https://castle-engine.io/wp/2017/03/29/support-for-the-stl-format-for-3d-models-commonly-used-for-3d-printing
>
> Wondering, doesn't 3DMD have special expertise in this area? (cc: Chris)
>
> Suggestion: if someone might write such loaders in X3DOM and X_ITE, we might add each of these formats to X3Dv4.  This would be really great because it allows an author to add authoritative metadata to such models.  Plus all the other benefits of X3D become available to users of such legacy model formats.  If that happens, we will add spec prose to X3Dv4 documenting such support.
>
> We also discussed how wonderful people feel when they pay for worthy capabilities.  8)

I am not sure that providing glTF loading support for X3D should mean
exploring other formats even if they are widely used. obj and STL are
very different from glTF.

Here are wikipedia entries for obj and stl formats as they provide
good summaries:

https://en.wikipedia.org/wiki/Wavefront_.obj_file
https://en.wikipedia.org/wiki/STL_(file_format)

STL would be geometry only which seems doable. There is a binary
encoding. Only require support the ASCII encoding in the X3D spec. ?
But I am not sure if convenience of loading is a sufficient reason to
expand to other formats.

OBJ can be very complex including parametric geometries:
http://www.martinreddy.net/gfx/3d/OBJ.spec
http://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf
http://paulbourke.net/dataformats/obj/

Material (.mtl) files can require ray tracing, reflections, and glass effects.

It seems for spec. inclusion it would be necessary to define a subset
of features which need to be supported. An appropriate subset may be
those features supported by castle and by the three.js loader:
https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/OBJLoader.js
It looks like only these lines are handled by three.js:
v? (vertex information)
f (polygons)
g (groups)
o (object)
l (lines)
p (points)
usemtl
mtllib
s (smooth)

and these by castle:
https://github.com/castle-engine/castle-engine/blob/81971a0b2ebb86cbbffb1dd270984c1888d8f001/src/x3d/x3dloadinternalobj.pas

v?
f
g
mtllib
usemtl

I guess no lines and points. Illumination models not supported in either.

Overall, I would be worried about the overhead in maintaining formats
in X3D browsers which are complex on the one hand or too simple on the
other hand, especially if there are external converters to X3D already
available. Perhaps web3d.org could provide a converter service using
castle or meshlab ?

--
Andreas Plesch
Waltham, MA 02453