FBX IO: Corner vert/edge and edge verts access with attributes #104648
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#104648
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Mysteryem/blender-addons:attribute_access_corner_edge_v_e_indices_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?
Blender 3.6 moved corner (loop) vertex index and edge index, and edge
vertices to generic attributes. The old API still works for now, but is
slower and may be removed in 4.0, so this patch updates FBX IO to use
the new ".corner_vert", ".corner_edge" and ".edge_verts" attributes.
This patch makes no changes to the import or export of FBX files.
This PR depends on the base patch for adding attribute utility functions: #104645
a662ebc9b1
to769d88ffd6
769d88ffd6
to56c729f6f5
Additional changes have been made to fix the arrays being passed to Blender with the wrong dtypes when importing. I force-pushed these changes separately for easier comparison.
With
".edge_verts"
it was a mistake on my part and with".corner_vert"
it was unexpected behaviour ofnumpy.astype()
which has been worked around by modifying theastype_view_signedness()
utility function.56c729f6f5
toec702e8c19
@ -419,0 +418,4 @@
Safely views arr as new_dtype if both arr and new_dtype have the same itemsize, byteorder and signedness, but could
have a different character code, e.g. 'i' and 'l'. np.ndarray.astype with copy=False does not normally create this
view, but Blender can be picky about the character code used, so this function will create the view.
I do not understand that comment, besides the
i
vs.u
special case, this function just returns the result ofnp.ndarray.astype
. So how can it force described behavior regarding cases likei
vs.l
, ifnp.ndarray.astype
does not handle it?Before this patch, the explicit creation of a view only occurred when
arr
andnew_dtype
were both integer types, but had opposite signedness (and had the same itemsize and byteorder).This patch changes the explicit creation of a view to no longer require that both inputs have opposite signedness, just that both inputs are either signed or unsigned integers (and have the same itemsize and byteorder).
The dtype 'kind' is not the character code that describes the buffer data, it is a NumPy specific character that describes the general kind of data in the buffer. In this case, the two kinds are
'i'
signed integer (of any size) and'u'
unsigned integer (of any size). https://numpy.org/doc/stable/reference/generated/numpy.dtype.kind.htmlOn a system like mine where the C
long
andint
have the same itemsize, NumPy createslong
arrays when I use thenp.int32
type. Using thenp.intc
type instead will force the creation of anint
array which is whatforeach_get/set
are expecting. But, because these two types only differ by theiri
andl
character codes,np.ndarray.astype
appears to consider the two types equal and therefore simply returns the array itself when usingcopy=False
instead of creating a view with the character code of thenew_dtype
e.g.long_array.astype(np.intc, copy=False) is long_array
isTrue
whereas it would have beenFalse
if anp.intc
view was created.Confusingly,
np.int32 == np.intc
isFalse
, butnp.dtype(np.int32) == np.dtype(np.intc)
isTrue
, I don't know if this is intended behaviour of NumPy or a bug.Eventually I aim to do some work on Blender's buffer support in
foreach_get/set
and other areas of the Python API so that Blender stops caring about specific character codes so long as the 'kind' of data, the itemsize and byteorder are correct, but for now, the character code of the array passed toforeach_get/set
is important for whether Blender uses the array as a buffer (fast) or a sequence (slow).Edit: In this case, the
long
arrays are coming from the parsed .fbx becausedata_types.ARRAY_INT32
ends up beingl
because it finds the character code for a 32-bit integer by iterating through'ilq'
. If bothi
andl
are 32-bit, thenl
is used because it is iterated last.Thanks, I understand better now!