Scale Factor in Speckle Schema

Help Speckle v1 (old)
1

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?

2

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.

3

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?

4

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

5

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?

6

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?

7

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?

8

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…

9

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