<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On the topic of mentioning or allowing or recommending other model or animation formats for direct use iin x3d scenes, we might be informed by hanim use of a marginally documented format. In part 2 of hanim we show how to convert the skeleton definition and animation details from a typical ‘motion data’ file for use in a ‘standard’ hanim character. </p><p class=MsoNormal>So, the ideas for this include lots of info about the source file contents that describe the motion capture model, relationships to a the target hanim model, and how to actually process the source file for use in the x3d user code.</p><p class=MsoNormal> </p><p class=MsoNormal><a href="https://www.web3d.org/documents/specifications/19774-2/V2.0/index.html">https://www.web3d.org/documents/specifications/19774-2/V2.0/index.html</a></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Joe</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:michalis.kambi@gmail.com">Michalis Kamburelis</a><br><b>Sent: </b>Friday, January 3, 2020 3:15 PM<br><b>To: </b><a href="mailto:andreasplesch@gmail.com">Andreas Plesch</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] X3Dv4 progress;PointProperties and points/lines/mesh, OBJ,</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I think Andreas expressed in a clear way what I also mentioned during</p><p class=MsoNormal>teleconference :)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Basically:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Castle Game Engine / view3dscene supports a lot of model formats (</p><p class=MsoNormal>https://castle-engine.io/creating_data_model_formats.php ). All these</p><p class=MsoNormal>model formats can be converted to X3D (</p><p class=MsoNormal>https://castle-engine.io/view3dscene.php#section_converting ). All</p><p class=MsoNormal>these model formats can be used within X3D Inline.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- ... but it does *not* mean that model formats like OBJ or STL should</p><p class=MsoNormal>be mentioned in the X3D specification. These model formats are</p><p class=MsoNormal>popular, but they are also problematic. Their specifications (official</p><p class=MsoNormal>or not) are not actively maintained, and the model formats have a</p><p class=MsoNormal>number of deficiencies (e.g. STL models are inherently bad for some</p><p class=MsoNormal>operations because vertexes are not indexed, and STL has only</p><p class=MsoNormal>geometry, OBJ lacks a lot of important features including animations</p><p class=MsoNormal>etc.).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We need to be careful what model formats we mention in the X3D</p><p class=MsoNormal>specification. E.g. as "suggestions" or "recommendation" to support in</p><p class=MsoNormal>Inline. Because these recommendations will exist for many years, and</p><p class=MsoNormal>people could read these recommendations as "endorsement" --- "X3D</p><p class=MsoNormal>specification recommends that X3D is integrated with format XXX, so</p><p class=MsoNormal>using XXX must be a good idea". And I do not recommend anyone to use</p><p class=MsoNormal>STL or OBJ :) For a long-term, efficient, feature-rich format, X3D or</p><p class=MsoNormal>glTF are the solution.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Regards,</p><p class=MsoNormal>Michalis</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>pt., 3 sty 2020 o 20:59 Andreas Plesch <andreasplesch@gmail.com> napisał(a):</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> > Date: Fri, 3 Jan 2020 10:21:36 -0800</p><p class=MsoNormal>> > From: Don Brutzman <brutzman@nps.edu></p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> [snip]</p><p class=MsoNormal>> > 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).</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > Reference:</p><p class=MsoNormal>> >         [x3d-public] X3D minutes 6 SEP 2019: DICOM discussion, overview diagram review, ISO meeting highlights, API progress, defer STL/OBJ support</p><p class=MsoNormal>> >         http://web3d.org/pipermail/x3d-public_web3d.org/2019-September/011251.html</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > view3DScene (CastleGameEngine) supports OBJ and STL as allowable Inline formats.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> >         https://michalis.ii.uni.wroc.pl/view3dscene-snapshots</p><p class=MsoNormal>> ></p><p class=MsoNormal>> >         view3dscene, 4.2. Converting to VRML/X3D</p><p class=MsoNormal>> >         https://castle-engine.io/view3dscene.php#section_converting</p><p class=MsoNormal>> ></p><p class=MsoNormal>> >         Support for the STL format for 3D models (commonly used for 3D printing)</p><p class=MsoNormal>> >         https://castle-engine.io/wp/2017/03/29/support-for-the-stl-format-for-3d-models-commonly-used-for-3d-printing</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > Wondering, doesn't 3DMD have special expertise in this area? (cc: Chris)</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > 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.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > We also discussed how wonderful people feel when they pay for worthy capabilities.  8)</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> I am not sure that providing glTF loading support for X3D should mean</p><p class=MsoNormal>> exploring other formats even if they are widely used. obj and STL are</p><p class=MsoNormal>> very different from glTF.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> Here are wikipedia entries for obj and stl formats as they provide</p><p class=MsoNormal>> good summaries:</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> https://en.wikipedia.org/wiki/Wavefront_.obj_file</p><p class=MsoNormal>> https://en.wikipedia.org/wiki/STL_(file_format)</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> STL would be geometry only which seems doable. There is a binary</p><p class=MsoNormal>> encoding. Only require support the ASCII encoding in the X3D spec. ?</p><p class=MsoNormal>> But I am not sure if convenience of loading is a sufficient reason to</p><p class=MsoNormal>> expand to other formats.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> OBJ can be very complex including parametric geometries:</p><p class=MsoNormal>> http://www.martinreddy.net/gfx/3d/OBJ.spec</p><p class=MsoNormal>> http://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf</p><p class=MsoNormal>> http://paulbourke.net/dataformats/obj/</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> Material (.mtl) files can require ray tracing, reflections, and glass effects.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> It seems for spec. inclusion it would be necessary to define a subset</p><p class=MsoNormal>> of features which need to be supported. An appropriate subset may be</p><p class=MsoNormal>> those features supported by castle and by the three.js loader:</p><p class=MsoNormal>> https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/OBJLoader.js</p><p class=MsoNormal>> It looks like only these lines are handled by three.js:</p><p class=MsoNormal>> v? (vertex information)</p><p class=MsoNormal>> f (polygons)</p><p class=MsoNormal>> g (groups)</p><p class=MsoNormal>> o (object)</p><p class=MsoNormal>> l (lines)</p><p class=MsoNormal>> p (points)</p><p class=MsoNormal>> usemtl</p><p class=MsoNormal>> mtllib</p><p class=MsoNormal>> s (smooth)</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> and these by castle:</p><p class=MsoNormal>> https://github.com/castle-engine/castle-engine/blob/81971a0b2ebb86cbbffb1dd270984c1888d8f001/src/x3d/x3dloadinternalobj.pas</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> v?</p><p class=MsoNormal>> f</p><p class=MsoNormal>> g</p><p class=MsoNormal>> mtllib</p><p class=MsoNormal>> usemtl</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> I guess no lines and points. Illumination models not supported in either.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> Overall, I would be worried about the overhead in maintaining formats</p><p class=MsoNormal>> in X3D browsers which are complex on the one hand or too simple on the</p><p class=MsoNormal>> other hand, especially if there are external converters to X3D already</p><p class=MsoNormal>> available. Perhaps web3d.org could provide a converter service using</p><p class=MsoNormal>> castle or meshlab ?</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> --</p><p class=MsoNormal>> Andreas Plesch</p><p class=MsoNormal>> Waltham, MA 02453</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> _______________________________________________</p><p class=MsoNormal>> x3d-public mailing list</p><p class=MsoNormal>> x3d-public@web3d.org</p><p class=MsoNormal>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>x3d-public mailing list</p><p class=MsoNormal>x3d-public@web3d.org</p><p class=MsoNormal>http://web3d.org/mailman/listinfo/x3d-public_web3d.org</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>