Fix: FBX fails to export materials on geometry nodes objects #104530
No reviewers
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#104530
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Mysteryem/blender-addons:fbx_fix_geometry_nodes_mat_export_pr"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
For only the FBX exporter, fixes #104516.
The exporter would always get the materials to export from the original,
non-evaluated, object, but Geometry nodes, when applied, replace the
materials of the object and mesh/curve/etc., so the wrong materials
would be exported.
Now, when modifiers are applied on export, the materials of the
evaluated object are checked against the materials of the original
object. When the materials differ, the materials of the evaluated object
are set into the
override_materials
of the ObjectWrapper, causing itsmaterials
property (refactored from thematerial_slots
property) toreturn them.
Initially I wanted to add an extra element to each tuple value in
data_meshes
that would specify the override materials to use, but another part of the code that finds all the materials to include in the export does so by iterating through each ObjectWrapper and I didn't want to add extra conditional behaviour in this loop depending on whether the ObjectWrapper is indata_meshes
, when the ObjectWrapper is supposed to be a generic way to access data regardless of what type the Object is.This led me to replace the
material_slots
property withmaterials
because there's no easy way to create a sequence of fake material slots to be used as an override and all existing use ofmaterial_slots
was just getting the materials of the slots.LGTM, nice and elegant solution!