[x3d-public] Feature comparison of glTF and X3D as Interchange Formats

Don Brutzman brutzman at nps.edu
Fri Sep 22 18:15:43 PDT 2017


Suggestion: such a table is much more informative when actual capabilities are compared.  If needed, reduction sub-profiles can be in the footnotes instead.

Incidentally none of the X3D players out there are only implementing Interchange Profile.  Immersive Profile is essentially VRML97, a 20-year-old and well-established capability.

Also not clear why you are talking about glTF not having a run time when you show a glTF example with animation.   Again best to compare actual capabilities.

Of interest in the morph animation category, aside from the dolphin example (by high school student) is sophisticated model animation in this recent tweet sent to public and hanim lists:

	https://twitter.com/NAS6_oxo/status/907215190218833920
	mikumikudanceからデータを拝借してhtml化 #html #x3dom #mikumikudance
	http://nas6.net/mikutest.htm
	http://nas6.net/mikuanitest.htm
	http://nas6.net/mikuanitest2.htm


On 9/22/2017 9:26 AM, Leonard Daly wrote:
> Michalis,
> 
> I think I now understand your concerns. I did not want to imply that the comparison included all X3D capabilities. I tried to make that clear though additional text prior to the table and footnotes, but perhaps not clear enough. Do you have any suggestions for making it clearer that the comparison does not include all X3D capabilities?
> 
> 
> Leonard Daly
> 
> 
> 
>> My intention was not that I want to compare specific X3D and glTF browsers.
>>
>> I was pointing the fact that if the goal of the table is to help people in choosing the format (X3D or glTF), then comparing "X3D Interchange profile" vs "complete glTF specification" is not perfect. You choose a subset of X3D specification (I think all X3D browsers implement something more than Interchange), and compare it with the full glTF specification (that is unlikely supported by most glTF readers).
>>
>> I do not have a solution to this problem, I know that designing a "fair"
>>
>> - subset of glTF and
>> - ‎superset of X3D Interchange
>>
>> ...would be hard (lot of work, hard to do it objectively, and outside of what you wanted to describe).
>>
>> I'm only pointing that the current table should not be used as a simple guideline "what I can practically do with X3D vs glTF". And I fear it will be taken as such -- the title of the page is "glTF/X3D Comparison", and the fact that it's limited to X3D Interchange profile may be lost to some people (or not understood, if someone is coming from outside of X3D community and doesn't know that "Interchange profile" is a bare minimum in practice).
>>
>> I hope that this explains my intentions better.
>>
>> As for the "runtime" -- I see that my understanding of this word was different than yours, so please disregard my notes about them.
>>
>> Regards,
>> Michalis
>>
>> 22.09.2017 4:46 AM "Leonard Daly" <Leonard.Daly at realism.com <mailto:Leonard.Daly at realism.com>> napisał(a):
>>
>>     Michalis,
>>
>>     To compare X3D's runtime with glTF is not an appropriate comparison. It has nothing to do with the heaviness or lightness of X3D's runtime, but the fact that glTF does not have one.
>>
>>     If the work flow is to ingest models and make modifications, then the runtime capabilities are irrelevant to the extent that those capabilities do not impose requirements on the importing tool.
>>
>>     Since the addition of components of a profile is strictly a browser choice, it does not have any place in a comparison of specifications. This comparison was not to establish test cases for bench marking various browser that support glTF or X3D (or both). This was strictly a comparison of features that are in the specification.
>>
>>     If you want to see a comparison of browsers please feel free to go ahead and design and do the testing. It is beyond my available time right now.
>>
>>
>>     Leonard Daly
>>
>>
>>
>>
>>>     2017-09-21 23:40 GMT+02:00 Leonard Daly<Leonard.Daly at realism.com> <mailto:Leonard.Daly at realism.com>:
>>>>     Since higher level X3D
>>>>     Profiles include a lot of run time and glTF does not include any, it would
>>>>     not be a fair comparison -- it wouldn't even be relevant. Someone might need
>>>>     to work in a specific environment which would preclude X3D's runtime.
>>>     But an X3D browser can implement the parts of X3D responsible for the
>>>     missing features (vs glTF, in your table) without "a lot of run time".
>>>     I know that it's more-or-less what I'm doing myself (details below).
>>>
>>>     If you consider some X3D browsers as "heavier" on resources than some
>>>     glTF browsers, then you should point and
>>>     compare these specific browsers, and mention that browser X (which
>>>     happens to use X3D) is heavier on resources than browser Y (which
>>>     happens to use glTF). As far as standards go, saying that X3D requires
>>>     "heavier runtime" for the same features is not true, in my experience.
>>>
>>>     I actually do implement in my X3D browser various features that you
>>>     list as missing in your table (since they are indeed missing from the
>>>     Interchange profile). I'm quite sure that implementing these features
>>>     does not make the runtime "heavy", at least not more than implementing
>>>     them using glTF would be.
>>>
>>>     Some details:
>>>
>>>     - Implementing [Indexed]QuadSet nodes (which is part of CAD component,
>>>     and provides "Quad surface model" feature in your table) is very easy,
>>>     and it does not require anything special from the runtime. It's just
>>>     another geometry node. (Some APIs, like OpenGLES, may not support
>>>     quads, but you don't pass polygons from IndexedFaceSet straight as
>>>     polygons to OpenGLES either.)
>>>
>>>     - Using shaders is something that all renderers do already, regardless
>>>     if it reads X3D or glTF. Exposing shaders to the X3D author is
>>>     relatively easy, and it does not require any "heavy runtime", you just
>>>     copy some data from X3D shader nodes to your renderer shaders.
>>>
>>>     - Implementing animations (using morph and joints) is indeed not
>>>     trivial (to do it efficient). But it's the same level of difficulty as
>>>     doing it with glTF.
>>>
>>>     - Implementing bump mapping etc. using X3D CommonSurfaceShader is the
>>>     same level of difficulty as implementing these features using glTF.
>>>     The input format doesn't really matter here much.
>>>
>>>     Regards,
>>>     Michalis
>>>
>>
>>     -- 
>>     *Leonard Daly*
>>     3D Systems & Cloud Consultant
>>     LA ACM SIGGRAPH Chair
>>     President, Daly Realism - /Creating the Future/
>>
>>
> 
> -- 
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman



More information about the x3d-public mailing list