Bastien Montagne
730b5057a7
This usage of the whole USD `USDStageReader` as 'cache handle' feels a bit... uncomfortable to me. It implicitely assumes that all data in this owned by the reader (or has a lifetime that contains the whole handle lifetime). IMHO, if such struct is expected to have a long lifetime, it should be documented, and probably needs better design for sub-data handling then. Am curious to know if there is a good reason why the handle itself is not a simple trivial class, able to re-generate an actual complete USD reader on demand? Or maybe we need to find a better place to store the `wmJobWorkerStatus` data? Anyway, for now this PR addresses the issue by ensuring that the `worker_status` stored in the `USDImportParams` is not `nullptr` before trying to access it for the reports. This is more of a short-term solution though, imho there should be a way to pass a reportlist to this codepath, and ensure the `wmJobWorkerStatus` is always valid? Pull Request: https://projects.blender.org/blender/blender/pulls/114337
Blender
Blender is the free and open source 3D creation suite. It supports the entirety of the 3D pipeline-modeling, rigging, animation, simulation, rendering, compositing, motion tracking and video editing.
Project Pages
Development
License
Blender as a whole is licensed under the GNU General Public License, Version 3. Individual files may have a different, but compatible license.
See blender.org/about/license for details.