[x3d-public] remove SF/MFInt32 ?

[Andreas Plesch]

Thanks for chiming in, Don, considering first principles.

>From a hardware/software perspective, I think it is impossible to not
recognize the large evolution from early VRML times to today which ought to
be reflected somehow in X3D.

Another way to approach the question if there is an opportunity or if such
an idea is just a distraction, is to consider why there is not a SFInt16 or
SFInt8 type. The thinking at the time may have been that there is a need
for integers for indices but also a need to keep it simple and only have a
single one, int32. On the other hand, for floats let's have both 32 and
64bit.

Ist there a time when this reasoning becomes obsolete and there is a call
for a higher level of abstraction ? Can a browser be smart enough to decide
how numbers are internally represented for various purposes so an author
does not have to be concerned about that ?

Reconsidering, a first step may be to simply rename SF/MFInt32 to SF/MFInt
and leave it up to the browser how many different integers it can represent
?

To ease such a transition both names can coexist for a while.

-Andreas





On Sun, Apr 8, 2018, 7:29 PM Don Brutzman <brutzman at nps.edu> wrote:

> Appreciate the thoughtful inquiry, thanks colleagues.  A few more points:
>
> a. Hardware. X3D is designed to run across an exceptionally wide range of
> devices in a performant way.  The original scene graph was designed when
> every single triangle counted, and we have been diligent about maintaining
> graphics-performance rigor throughout its evolution, so X3D is efficient.
> Many computing hardware platforms are quite necessarily strict about the
> handling of integers/floats/doubles based on memory, processing
> performance, and power consumption.
>
> b. Software.  X3D is designed to run across an exceptionally wide range of
> programming and processing environments.  Thus if a JavaScript
> implementation wants to treat all numbers equivalently, or defer
> typecasting until data gets transferred to hardware, or whatever, that is
> OK and doesn't impede other implementations.  The X3D abstract
> specification describes functionality of rendering and interaction, not
> reference software implementations.
>
> c. Data or code.  X3D is designed to be workable both as a file encoding
> or as a programming-language binding with functional equivalence.  The X3D
> Unified Object Model work is capitalizing on that... more to follow once we
> get through HAnim updates, venture into C++/C#/Python programming, etc. etc.
>
> d. Disclaimer: I think that typing is incredibly valuable because it
> reveals errors.  Many such errors are otherwise undetectable, so typing is
> an important aspect of model Quality Assurance (QA).
>
> e. Portability of reusable models.  So feel free to pursue X3D generation,
> presentation and interaction using the best implementation approach you
> want... YMMV.  Also know that portability of X3D scenes across all of these
> other platforms/formats/languages/methodologies can (and typically will)
> work equivalently when deploying valid X3D model content.
>
> Have fun with X3D!  8)
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180410/35db0d52/attachment.html>