Serializing a brep to a json string (using Newtonsoft.Json.JsonConvert) appears to generate different output strings when that Brep class is from RhinoCommon vs Rhino3dm. I have a simple C# console project which uses Rhino3dm to create a simple Brep which contains a single PlaneSurface. I serialize that brep to JSON, pass the json string to a Compute endpoint exposed from a plugin I wrote. The compute endpoint deserializes the JSON string back into a Brep (using RhinoCommon now,) and then reserializes it again, using the same version of Newtonsoft, and sending the resulting string back to the caller. Both the original json string and the returned string are saved to text files, and here is a comparison (deltas in red):
It appears that the value of the “opennurbs” attribute has changed, as well as an early chunk of serialized data.
My hope was that perhaps I could perform naive change detection by comparing serialized json strings without having to instantiate the Brep class and check DataCRC, particularly as the File3dm version of Brep does not expose DataCRC method.
Is this result surprising to anyone? Is it possible I just have DLL version differences? Or does Brep actually encode some sort of timestamp value or machine identifier? Is that different “opennurbs” value significant?
Different versions of opennurbs write different data when serializing. The most common case is that a newer version of opennurbs will write some new data that didn’t exist in an older version. For example, we added many new object attribute properties in Rhino 8 and these properties need to be saved in the 3dm file.
It seems that the compute.geometry project (in my local RhinoCompute instance) is using Rhino.Inside 7.0.0, which in turn uses RhinoCommon 7.0.20314.3001. On the Rhino3dm side, how would I determine which underlying OpenNurbs version it’s calling?
Gotcha. So how would I go about ensuring that RhinoCommon (in the compute instance) and Rhino3dm (in my API code) are using the same OpenNurbs version? I tried upgrading the Rhino NuGet packages in the compute.geometry project from 7.0’s to latest stable 7.29’s, but it caused the compute.geometry to exception out at startup with a DLL loading / lookup error.
I don’t have a good answer for this as we haven’t ever needed to sync our rhino3dm releases exactly with Rhino service releases.
As far as compute.geometry; even though you are referencing RhinoCommon 7.0, the actual RhinoCommon version while executing depends on the specific service release of Rhino installed.
