Sync to modern FindOpenVDB.cmake

[dankamongmen]

I don't personally understand why we're shipping our own copies of these files; we ought IMHO be getting them from the installed system (i.e. /usr/{local}/lib/cmake/OpenVDB), where they're guaranteed to match the installed libopenvdb. Regardless, we probably want a more modern version of FindOpenVDB and its new dependency, FindBlosc. With this change, I can build on Debian Unstable.

If you really want to support OpenVCB 5 (quite old), we'll want to test this against such a vintage installation. I unfortunately do not have a setup on which to do so.

With the existing files, attempting to build on e.g. Debian Unstable gets a failure about libilmbase, which hasn't existed in some time (replaced by OpenEXR):

-- Could NOT find OpenVDB (missing: OpenVDB_LIB_COMPONENTS openvdb) (found suitable version "10.0.1", minimum required is "5.0")
-- OpenVDB ABI Version: 10
CMake Warning at cmake/modules/FindOpenVDB.cmake:346 (message):
  IlmBase::Half can not be found!
Call Stack (most recent call first):
  cmake/modules/FindOpenVDB.cmake:368 (just_fail)
  CMakeLists.txt:562 (find_package)


CMake Error at CMakeLists.txt:567 (message):
  OpenVDB could not be found with the bundled find module.  You can try to
  specify the find module location of your OpenVDB installation with the
  OPENVDB_FIND_MODULE_PATH cache variable.


-- Configuring incomplete, errors occurred!
[schwarzgerat](1) $

[dankamongmen]

Oh, it looks like perhaps you want to always use the "8.2 patched" specified in deps/OpenVDB/OpenVDB.cmake? If so, you probably want to keep these synced to it...? In which case this PR should be killed.

Is there any reason you're sticking with "8.2 patched"? Was the reasoning perhaps from a previous time, and now 10.x is suitable? I'd be happy to update the deps/ entry.

[MackBambu]

You can refer to this discussion about OpenVDB version issues; it might be helpful.
#2606
We need to ensure consistency in build dependencies across different systems. If you're willing to assist with upgrading to the new version of OpenVDB, we would greatly appreciate it.

[dankamongmen]

@MackBambu got it, will do! i'm eagerly looking forward to being able to build from source on Debian Unstable. It looks like any fixes for this would be best put through Prusaslicer, which Bambu Studio would then pull in? What's the preferred workflow there? I only have Bambu machines, but would prefer any generic fixes indeed go to the open source root project.

[MackBambu]

@MackBambu got it, will do! i'm eagerly looking forward to being able to build from source on Debian Unstable. It looks like any fixes for this would be best put through Prusaslicer, which Bambu Studio would then pull in? What's the preferred workflow there? I only have Bambu machines, but would prefer any generic fixes indeed go to the open source root project.

Steps for Updating Dependencies:

1.Select a stable official version as the base. If any modifications to the dependency code are needed, apply them as patches to keep changes isolated and manageable.
2.Fork the Bambu Studio source code and make modifications in your own branch.
3.Use the build_all workflow on GitHub to build and test across Windows, macOS, and Linux, ensuring successful builds and functionality on all three platforms.
4.Submit a pull request for review. We will conduct final testing before approving the changes.

[dankamongmen]

1.Select a stable official version as the base. If any modifications to the dependency code are needed, apply them as patches to keep changes isolated and manageable. 2.Fork the Bambu Studio source code and make modifications in your own branch. 3.Use the build_all workflow on GitHub to build and test across Windows, macOS, and Linux, ensuring successful builds and functionality on all three platforms. 4.Submit a pull request for review. We will conduct final testing before approving the changes.

thanks, but do you think i maybe ought do this work with PrusaSlicer, and then count on it coming into BambuStudio when you next pull from there (i understand BS to be derived from PS, but perhaps i am wrong)?

[MackBambu]

thanks, but do you think i maybe ought do this work with PrusaSlicer, and then count on it coming into BambuStudio when you next pull from there (i understand BS to be derived from PS, but perhaps i am wrong)?

You can work directly on Bambu Studio, but if you prefer working from PrusaSlicer, that's also fine. We will cherry-pick relevant code from PrusaSlicer when appropriate.