[x3d-public] remove SF/MFInt32 ?

Michalis Kamburelis michalis.kambi at gmail.com
Fri Apr 6 10:02:43 PDT 2018

"2018-04-06 17:22 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
> Here is a somewhat radical idea to simplify X3D a bit. Since x3dom is
> javascript it does not really distinguish between SFInt32 and SFFloat, and
> lives pretty well with it. So why not consider completely removing the
> SF/MFInt32 from the spec. in general ?
> The integer fields are used in not very many nodes: Switch,
> IntegerSequencer, LOD (level_changed) come to mind. A replacement with
> SFFloat would mean adding rounding or truncation to nearest integer in the
> spec. language but probably not more than that.
> The advantages are that it is an opportunity to make the spec. leaner, and
> help with some node communication issues.
> The disadvantages are that it would be a backwards incompatible change, and
> may have a minor performance impact.

This is a limitation of JavaScript (there are no separate "integer" or
"float" types, just "number"), but all other programming languages
have separate integer / float types. So I would a bit reluctant to do

Equating "SFFloat == SFInt32" would mean we have less strict typing
when it comes to checking ROUTE connections. All SFFloat fields/events
could be then connected with SFInt32. E.g. in my opinion it is good
that right now you are forced to animate "Switch.whichChoice" with
"IntegerSequencer", and you cannot do it with "ScalarInterpolator".
And it allows X3D specification to avoid making some general rules
whether we round (with round(0.75)=1.0), or truncate (ceil).

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.


More information about the x3d-public mailing list