[x3d-public] remove SF/MFInt32 ?

[Andreas Plesch]

Thanks for thinking this through more thoroughly, starting from a
rather vague idea.

On Fri, Apr 6, 2018 at 2:28 PM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
>  2018-04-06 19:41 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
> ...
> Hm, I do agree that "type strictness" of X3D is not the main argument
> here. You are right, I can see that sometimes you could even benefit
> from easily passing float to/from int, while now you need to put nodes
> in-between.
>
> Note that InstantReality has an extension
> http://doc.instantreality.org/documentation/nodetype/Converter/ .
>
> >
> >>
> >> More importantly, what happens with MFInt32? If it's now MFFloat, then
> >> we get a performance hit when reading a long list of coordinates (like
> >> IndexedFaceSet.coordIndex), because now we have to call round() on
> >> every list item.
> >
> >
> > I believe this would be a one time operation during loading which would be
> > barely noticeable on a modern system, even for large IFSs. The parsing of
> > the string to a number in the first place likely takes much longer.
> >
>
> 1. The parsing is indeed a problem for performance, and it probably
> costs more than "rounding a float". But to make this rounding happen
> early (at parsing or at glTF->X3D conversion) you need a way to mark
> the field "this is MFInt32". Otherwise, you will need to introduce a
> new field marked "this is MFFloat, but round it to integers at
> loading". Or make "IndexedFaceSet.coordIndex" a special case.

Yes, it would be in effect a special or marked case, eg. the type
conversion happens implicitly.

For x3dom, actually no change would be necessary as long as the
provided floats are round numbers.

> <sidenote>
> We want to eliminate this parsing by using binary mesh formats. Like
> glTF and ExternalGeometry/Shape. Or (older but already standardized)
> X3D binary encoding format. But I realize that, for now, most X3D
> content is parsed from text files (X3D in XML or classic encoding).
> </sidenote>
>
> 2. You can "embed" an X3D renderer, like Castle Game Engine or
> probably any other X3D renderer, to build or animate X3D graph by code
> in your own applications. In which case (right now) you can just use
> integers, from start to finish. If coordIndex would be defined as
> simple MFFloat, then you would need to provide floats.
>
>   This is an untypical but important use-case for me. People are
> building procedurally-generated worlds or games, or machines, using
> Castle Game Engine. So our API wants to allow defining
> "IndexedFaceSet.coordIndex" efficiently.

Ok, this is a good point. On the other hand an X3D engine still could
accept integer type numbers and internally treat them as integers from
start to finish for these float fields. Think a generic SFNumber
field.

>   This use-case is also relevant to X3D used directly: a Script that
> can send MFFloat value to "IndexedFaceSet.set_coordIndex".

This is actually what effectively needs to happen now in X3D scripts
which are written in js.

>   Note that this point is relevant even for JavaScript (when used as a
> scripting or renderer language). JavaScript doesn't have a "real
> integer" type for scalars, but it has a "real integer" type for lists
> (Int16Array, Int32Array etc.). There lists are actually stored as
> native integers, as far as I know.

Yes, the TypedArrays are for efficient use of native types. x3dom does
not actually use the TypedArrays for MF fields, I believe, until they
are submitted to webgl. Not really sure why not since mostly you can
treat TypedArrays as regular arrays in js. Perhaps TypedArrays were
experimental when x3dom got started.

-Andreas



-- 
Andreas Plesch
Waltham, MA 02453