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

[Michalis Kamburelis]

I think Andreas expressed in a clear way what I also mentioned during
teleconference :)

Basically:

- Castle Game Engine / view3dscene supports a lot of model formats (
https://castle-engine.io/creating_data_model_formats.php ). All these
model formats can be converted to X3D (
https://castle-engine.io/view3dscene.php#section_converting ). All
these model formats can be used within X3D Inline.

- ... but it does *not* mean that model formats like OBJ or STL should
be mentioned in the X3D specification. These model formats are
popular, but they are also problematic. Their specifications (official
or not) are not actively maintained, and the model formats have a
number of deficiencies (e.g. STL models are inherently bad for some
operations because vertexes are not indexed, and STL has only
geometry, OBJ lacks a lot of important features including animations
etc.).

We need to be careful what model formats we mention in the X3D
specification. E.g. as "suggestions" or "recommendation" to support in
Inline. Because these recommendations will exist for many years, and
people could read these recommendations as "endorsement" --- "X3D
specification recommends that X3D is integrated with format XXX, so
using XXX must be a good idea". And I do not recommend anyone to use
STL or OBJ :) For a long-term, efficient, feature-rich format, X3D or
glTF are the solution.

Regards,
Michalis

pt., 3 sty 2020 o 20:59 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> > 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org