[x3d-public] remove SF/MFInt32 ?

Andreas Plesch andreasplesch at gmail.com
Fri Apr 6 13:00:04 PDT 2018

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

>   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 Plesch
Waltham, MA 02453

More information about the x3d-public mailing list