HOLGER >>================================= in short the UNIT statement is simply an information for the editor how to display the values. The values in the saved X3D file still have the standard units but plus the unit statement. That means for a browser like FreeWrl there is nothing to do. I came to this decision as it is impossible to implement a unit conversion within the nodes. Especially SFRotation.angle would be very impossible to convert. Second, for a browser like FreeWrl or Cobweb (X_ITE) which is in JavaScript and where every little second is important it would mean a huge overhead in converting the values. Think about a geometry morph animation. On the other hand for a editor like Titania it easy to convert and display the values in the desired unit. /HOLGER <<========================================== Sept 21, 2017 Holger, Thanks. A few ideas to get everyone synchronized (assuming that's needed/desired/good): a) UNIT length feet .3048 applied = true - might work in x3d where you can add attributes easily x but won't work in classic vrml x3dv where a fixed number of attributes are expected - maybe a PUBLISHED units true statement? b) UNIT length feet 1.0 - if its applied, change the factor to 1.0 - then editors can still use the named units -like 'feet' for input box units, and use built-in factors like .3048 to convert/apply before saving the file - and browsers/tools applying units factors=1 at runtime will get the same look as those skipping units for b) think it would mean: Titania: - ignore factors in input file if you don't have a way to apply factors during parsing - but use the unit names like feet, kilograms/kg/slugs, to look up and apply factors and unit hints to input boxes. - then save scenefiles with UNIT statements factors == 1.0 Cobweb - no change, assuming all scenes have all units applied / set to 1.0 But there's still something missing: a tool/utility/cloud-service to read a scene with non-1.0 factors, apply the factors, and write the scene with factors = 1 What do you think? -Doug