Has SetCustomUnitSystem changed between versions?

Hi,

I’ve been trying to put together a version of my software with the “latest” 8.x openNURBS library. I finally got it all together this afternoon, but a bunch of my tests failed. When I started digging into the failures, the failures were in openNURBS custom units handling. This led to an extremely confusing debugging session, as I couldn’t understand how my code for this could ever have worked; it was obviously wrong.

Long story short:
In the 8.x branch, to get correct results I have to set

on_units.SetCustomUnitSystem (L"name", desired_unit.LengthInMeters ());`

In “openNURBS 7.0” (commit a59f3b7565355d80fdddb95b80a52c740806e248) it has to be

on_units.SetCustomUnitSystem (L"name", 1.0 / desired_unit.LengthInMeters ());

But that itself was a change: git history shows that I changed it to that in March 2018, and prior to that it was
on_units.SetCustomUnitSystem (L"name", desired_unit.LengthInMeters ());

It’s hard to be sure, but I think this older version had actually been passing tests for about three years before that “fix” of switching to sending the reciprocal of the length in meters to SetCustomUnitSystem.
I guess what I’m trying to find out here is if what I’m seeing represents a change in openNURBS’s behavior between versions?

double ON_UnitSystem::MetersPerUnit() const
{
// NOTE WELL:
//   https://mcneel.myjetbrains.com/youtrack/issue/RH-60700
//   For standard units, this function returns the WRONG value (inverse of the correct value).
//   The reason is the Rhino 6 VRay plug-in assumes the incorrect value is returned
//   and V6 VRay does not work correctly in Rhino 7 if the correct value is returned.
//   After some discussion (see the bug above), we will leave the inverse bug in
//   ON_UnitSystem::MetersPerUnit(), deprecate ON_UnitSystem::MetersPerUnit(),
//   and add a new function that returns the correct answer.
if (ON::LengthUnitSystem::CustomUnits == m_unit_system)
{
// correct answer for custom units - V6 behavior.
return m_meters_per_custom_unit; //
}

// For standard units, the inverse of the correct answer is returned
// to preserve V6 bug so VRay works in Rhino 7.
return 1.0/ON_UnitSystem::MetersPerUnit(ON_DBL_QNAN);
}


I’ve just found this comment, which makes me think there definitely has been a change in behavior, I’m just not sure what it is / what is correct. What is the proper current approach for dealing with custom units?

Thanks,

Sol

Hi @colomon,

Please review this issue and let me know if you have any questions.

– Dale

I think that does the trick! Let me dig in and see if that makes things work the way I expect them to.

Thanks,

Sol