Scale Factor in Speckle Schema

Does anyone know where I can find any scale factor information in streams? Rhino or revit could model in either millimetres, centimetres or metres but Unity only really works well with metres.

I have a hack right now where I scale all objects in a stream by 0.001 but that assumes that the stream is in millimetres. I want to be able to read what scale factor a stream is so that my code can be scale agnostic in rather than need to know it myself before hand.

Any ideas?

Hey @pablothedolphin, they’re actually stored at the stream level. See: https://hestia.speckle.works/api/streams/xxTNRBXwn?fields=baseProperties for an example coming out of Revit, and https://hestia.speckle.works/api/streams/S5yQz2Z65?fields=baseProperties for an example coming out of Rhino/gh:

  "baseProperties": {
            "units": "Meters",
   //...

Best way would be to lowercase everything and assume the unit name is spelled in a sane manner. There’s no enforcement on the client or server side, so you might get streams with parsecs as a unit :slight_smile:

Ah and further to that: don’t forget the good ol’ imperial system (feet!). Revit loves it, and there’s a few users still stuck on that nonsensical inferior system.

Thanks, @dimitrie! So is there absolute certainty that SpeckleStream.baseProperties.units will always have some value in it regardless of the source client? Or will I need a fallback assumption?

It’s not enforced. Check if it exists, and fallback to something sane!

SpeckleStream.BaseProperties is a dynamic instead of a Dictionary<string,object> like SpeckleObject.Properties which means it’ll only support JIT compilation and not AOT.

Is there a reason for this and can it be changed into a dictionary?

Yeah, it’s dynamic because I didn’t know what will go into it at the time at all, and once we figured it out we never went back to type-safe-ify it. Changing it now might break backwards compatibility in ways I can’t really fathom fully. Is dynamic a blocker for unity?

yeah any use of dynamic won’t work on iOS at all and I only just fixed all the previous known blocks for building to iOS :sob:

that being said, it seems that the base properties is actually just a JObject under the hood. So changing it from dynamic to JObject SHOULD maintain backwards compatibility since it was a JObject the whole time?

Reminds me of another weird ios quirk. Depends on how people use it. I wouldn’t mind changing to JObjects (this is what newtonsoft uses internally, string -> jobjects and arrays -> actual objects), but to sleep easy it would need some testing beforehand, namely:

  • make sure rhino and gh plugins behave not worse than they are now :smiley:
  • revit and dynamo same
  • GSA
  • other parts of speckle too - i would @channel on #devtalk with a pr to see if devs react.

Another way - could forcing the stream object’s deserialisation to a separate JObject, out of which one can extract the needed baseProperties work? To weigh re option one…

For now I’ve made the change myself in my custom build of Speckle 1.8.0 and this seems to have resolved the issue for me. I’ll hold off on making a pull request into speckle core since it’s a low priority at the moment and the changes I’ve made are really tiny and easy to replicate across versions (for now).

Thanks @dimitrie!

1 Like