Property access changes the serialization of GeometryBase (ex. "Brep.IsSolid")

I have been serializing GeometryBase objects to compute hash strings. Recently, I noticed that if I access properties of a geometry, it will have an affect on object serialization and result in different outcomes if I compute a hash.

For example:

  • I have a Brep and compute a hash for the object using serialization (4fa8603475f75dfd1745830587cca1f1abf6cb90)
  • I then test the Brep.IsSolid property.
  • If I then compute the hash after running this property, the hash changes (c890a47d91032434862f8f6a0d17734d8c16e5c0)

The way I have been getting around it is Duplicating the Brep and then testing that property so I preserve the original geometry exactly.

Even so, this seems an odd behavior if I am checking a property (as opposed to using a method, for example) - this leads me to believe that checking the property is changing something about the object itself. Is this the case? Is this a bug or a feature?


Breps cache a m_is_solid flag after the first time the expensive IsSolid test is performed. This information is also saved with the Brep which is why you are seeing a different result.

@stevebaer - Ah, I see. Wouldn’t it be more appropriate to call IsSolid as a method vs a property then? I wouldn’t expect that a property, in the strictest sense, to be computationally expensive or have this kind of side effect (re: new information saved) on the object itself. In contrast, I would expect that a method would potentially have this kind of effect.

Maybe… that was a decision I had to make when designing the SDK and it is too late to go back. That said this is only computationally expensive once.