Mesh refactor #63
Mesh refactor #63
Conversation
|
Hey @bathal1 |
|
This PR will be merged once the corresponding changes to Mitsuba will be included in the upcoming release. |
|
Thanks 🙏 |
|
Hi, If you really need the add-on to work in Blender 3.6 or downgrading Blender is not a viable option, you could try to use the addon from source. Note that this will require building Mitsuba 3 from source as well, and it's known to be brittle in some cases. |
|
@bathal1 Since the new mitsuba is released, I am wondering if there is a timeline for merging this? I am happy to take this initiative if you can't allocate time to this. |
|
I tested this branch with mitsuba 3.4.0. @bathal1 It seems to export correct mesh. Is there any other work required for merging this? Is there any other planned work for a new release? |
- few fixes to get end-to-end tests working - some enums changes in sampling pattern as of 3.5+ - for Windows 3.5+, the new release of Mitsuba ensures we avoid OpenEXR dll collisions (see [here](mitsuba-renderer/mitsuba3#929) for more details)
bathal1
force-pushed
the
mesh_refactor
branch
from
91e3257
to
cb62981
Compare
Description
This PR addresses compatibility issues caused by data layout changes in Blender's mesh representation for the exporter add-on. With these changes, the exporter should now support versions 3.4 and 3.5 of Blender, which should make it easier to support the upcoming LTS version.
The mesh layout in blender is progressively moving from an array of structs to a struct of arrays format (more detail here, so we need to reflect those changes when interpreting blender data pointers in the mesh exporter.
This PR fixes #58 . In order for these changes to be fully reflected in the exporter, we would need to have a new release of the Mitsuba PyPI package and update the dependency in the addon.