Release: Refactor Load Types #2241
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 3, 2024
Updated use of weights in procrustes analysis (update to #1647)
Fix nearest.ipynb Typo
Updates the GLTF/GLB reader to include point cloud colors if available.
Hello, While using `trimesh==4.5.0` to compute the minimum volume oriented bounding box of a mesh, I noticed the following bug. Running the below code seems to take an extremely long time: ``` torus_mesh = g.trimesh.creation.torus(major_radius=5, minor_radius=1, major_sections=512, minor_sections=256) trimesh.bounds.oriented_bounds(torus_mesh.vertices) ``` But running this similar piece of code completed in ~7 seconds: ``` torus_mesh = g.trimesh.creation.torus(major_radius=5, minor_radius=1, major_sections=512, minor_sections=256) trimesh.bounds.oriented_bounds(trimesh.Trimesh(vertices=torus_mesh.vertices)) ``` My best guess is that, in the first case, the computed convex hull's face adjacencies seem to be wrong although I'm not sure how exactly. Line 253 in `bounds.py` computes 139156 edges that need to be checked, which doesn't seem right. In the second case, only 516 edges are checked. I noticed that, in the first case, the convex hull is being computed by `trimesh.convex.convex_hull(..., repair=False)` and, in the second case, the convex hull is effectively being computed with `trimesh.convex.convex_hull(..., repair=True)`. This PR makes both cases use `repair = True`. Hopefully the solution is indeed that simple. Thanks for the great library!
While all the other key/values for the MTL material are provided directly on top of Trimesh's interpretation for SimpleMaterial, then accessible through material.kwargs which is useful for custom handling of the materials, map_Kd isn't. I've had a need for getting the map_Kd file path directly instead of the already loaded PIL.Image.
Merged
mikedh
added a commit
that referenced
this pull request
Jan 29, 2025
With the pull-request #2241, `load_mesh` does not respect the parameter `process` anymore. With this pull-request, the `kwargs` are being forwarded in `load_stl`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A very common source of annoyance and confusion is that
trimesh.loadcan return lots of different types depending on what type of file was passed (i.e. #2239). This refactor changes the return types for the loading functions to:trimesh.load_scene -> SceneScene, the most general container which can hold any loadable type. Most people should probably use this to load geometry.trimesh.load_mesh -> TrimeshTrimeshobject. This potentially has to drop information and irreversibly concatenate multiple meshes.Scene.to_meshrather than load.trimesh.load_path -> PathPath2DorPath3Dwhich both inherit fromPathtrimesh.load -> Geometryload_scenethat attempts to match the behavior of the previous loader for backwards compatibility. In my testing against the currentmainbranch it was returning the same types 99.8% of the time although there may be other subtle differences.trimesh.load(..., force='mesh')will emit a deprecation warning in favor ofload_meshtrimesh.load(..., force='scene')will emit a deprecation warning in favor ofload_sceneAdditional changes:
Geometry.metadata['file_path']in favor ofGeometry.source.file_path. Everything that inherits fromGeometryshould now have a.sourceattribute which is a typed dataclass. This was something of a struggle asfile_pathwas populated into metadata on load, but we also try to make suremetadatais preserved through round-trips if at all possible. And so theloadinserted different keys into the metadata. Making it first-class information rather than a loose key seems like an improvement, but users will have to replacemesh.metadata["file_name"]withmesh.source.file_name.WebResolverso it can be more easily gated byallow_remote.trimesh.resources.getin favor of the typed alternatives (get_json,get_bytes, etc).Scene.deduplicatedin favor of a very short list comprehension onScene.duplicate_nodestrimesh.graph.smoothedin favor oftrimesh.graph.smooth_shaded.Path3D.to_planar->Path3D.to_2Dto be consistent withPath2D.to_3D.