ODA Upgrade

[FJThiel]

Description

The bouncer is currently running on Teigha_2024.8, which prevents files from the 2025 versions of the autodesk tools to be imported. This necessitates an update of the ODA version. It is expected that some things might break in the process that will need to be fixed.

Goals

• [x] The bouncer should still accept previous file versions.
• [x] The bouncer should accept 2025 file versions.

Tasks

• [x] Add new Teigha/ODA version as dependency to the build system, replacing the previous version.
• [x] Fix compile issues that are most likely arise with the new version.
• [x] Fix runtime issues that are likely to arise with the new version.
• [x] Test with old formats for regression issues.
• [x] Test with new formats to ensure compatibility.

Related Resources

Product Ticket: #384

[FJThiel]

@sebjf @carmenfan

So, the new ODA version does not come in VC14 anymore, so we will need to upgrade the Visual Studio toolchain, which also means upgrading the boost pre-builts... how far up would you like to go? VC15 (VS 2017), VC16 (VS 2019), or even VC17 (VS 2022)? Might be a chance to go all the way up?

Edit: Just realised that this brings us back to the auto-ptr issue because I can't upgrade the toolchain without upgrading boost, which will remove the auto_ptr again, which will crash the mongo driver again. This might be a dead end until we have upgraded the mongo driver in #697

2nd Edit: There might be a way around this by using the newer toolchain, but forcing compilation in the C++ 14 standard. Not elegant, but I will investigate whether this might be a stopgap.

[FJThiel]

I actually managed to compile it with the original Boost pre-builts, 142 toolchain, and forced C++ 14. Still need to try this with the new Teigha version, but we might just get this working without throwing too much over.

[carmenfan]

@FJThiel 😢

I have up to VS2022 installed and I think we're all using the same prebuilt libraries, so as long as you can get a version of VC to work with the whole thing and redistribute any libraries that has been updated, it's all good. We don't use windows in production so it's mainly just an issue between you me and @sebjf

That's assuming we are not running into similar issues with linux... 😆

[FJThiel]

Okay, in that case I would like to go all the way up to VS22's toolchain (VC17, msvc 143) so we don't need to do this again for a few more years.

[FJThiel]

Changes noticed so far:

• Methods returning RepoBSON crash the compiler optimisation. I added a shim in form of pragmas that enable the compiler optimisation for these methods. No further action planned at the moment since @sebjf plans to refactor the RepoBSON soon anyway.
• Creation of the Gi context has changed slightly with a dedicated method being added instead of the generic createObject()
• Retrieving of group labels has changed slightly with a dedicated method being added them.

[FJThiel]

@sebjf @carmenfan

When comparing models in the viewer with their representation in Revit, with some models I see colours being off and/or transparency and textures getting lost. Is this just how things are with some files or something that I should dig deeper into?

[carmenfan]

Do you mean comparing to uploading a previous revit version or comparing to opening the model in Revit

If it's the former probably should have a quick sanity check, if it's the latter then as long as it's consistent with the previous revit version upload then it's probably out of scope

[FJThiel]

For the moment I was just comparing them with Revit. They are the Revit sample files because I figured if something has the new 2025 features in it that could cause problems, it would be them. The downside would be that I have no earlier upload to compare to.

Or so I thought. Just saw that Autodesk offers earlier versions of some on their webpage, so I am going to use them for comparison now!

[FJThiel]

Comparison with 2024 samples did not show any visual difference for the Revit files.

Only thing of note: Both, old and new bouncer throw a warning for some models: [WARNING]: Unrecognised model units: Feet and fractional inches Out of scope for this task, but maybe we should extend our ModelUnits enum in the future because right now these models get imported with units marked as unknown.

[FJThiel]

Also leaving this here in the unlikely case that it becomes an issue in the future:

For the new version, the test with the sampleHouse.rvt failed because instead of 1341 mesh nodes, there are only 1339 returned. Close inspection of the mesh nodes produced by new and old bouncer revealed that these missing nodes belong to a group of four mesh nodes with the group name "Pad 2_490319". The new bouncer produced only two of them, but these two are larger. Summed together, the number of faces is identical and the number of vertices is down by 12.

It was also found that these were not the only nodes affected. All in all, 44 groups were found where the number of faces has been altered. Across the whole set, the new version has 255 faces less and 269 vertices more. However, compared to the whole, this is a minuscule change. Both about 0.1%.

Given that there is no visual apparent change, this is most likely just a minor change how the ODA libraries process the mesh before handing it to us.

[FJThiel]

Because of the behaviour described in the previous comment, a test in the AssetGenerator project needs to be altered.

The change is part of #5 of that project and will need to merged in with the PR of this issue.

[FJThiel]

No visual difference with Navisworks files either.

[FJThiel]

DWG and DGN look the same as well.