I have this simplifed way of unit testing RhinoCommon-based software which is comparing the Actual/Expected geometries by comparing the JSON strings obtained in serialization. When comparing Breps that way, I noticed that while the geometry is identical, the jsons are not. Guessing this is caused by one of the breps added to the Display Pipeline, hence it’s data also contains a display mesh underneath? That’s my guess at least. Is there any way to make sure those 2 breps serialize the same way without adding the other mesh to the pipeline ?
We could add a function to let you delete the underlying meshes that a brep holds on to. Would that work? Also note, that this would only be added to Rhino 8.
2 Likes
I created this script and can concur I see the same thing.
Test_105.gh (15.7 KB):
Could you use GeometryBase.GeometryEquals on the actual Geometry, or does it have to be JSON?
https://developer.rhino3d.com/api/rhinocommon/rhino.geometry.geometrybase/geometryequals
2 Likes
Would Save/Load get rid of the (temporary?) mesh visual cache?
Basing a check on JSON seems a little brittle; I’d be tempted to agree with CSykes that using an API-supported geometrical equivalency seems preferable.
I will stick with that… will require a bit of more work but as @Nathan_Bossett said it’s a very brittle concept to use JSON for that purpose (imagine object with a CreatedOn timestamp for instance).
Will use the GeometryEquals method for my purpose as it’s suggested below. Given JSON web-friendliness maybe it’s worth having a ClearCachedMeshes method to make it a bit more lightweight.
Would an optional flag on the JSON-generating call named something like ‘OmitCachedData’ be more general?
That would also be cleaner internally for nesting calls down the object tree to serialize.
Sure, one could pass some RhinoSerializationSettings instance down the line.
1 Like
I added a wish for this feature to our bugtracker
https://mcneel.myjetbrains.com/youtrack/issue/RH-78409/IncludeMeshes-option
1 Like