You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just got https://github.com/trimesh/cascadio packaged for Fedora, and the test is failing on s390x (the sole big-endian architecture). This is clearly a case of an endianness mixup; I’m filing the issue rather than on https://github.com/trimesh/cascadio because trimesh is involved, and it’s not clear exactly where the problem is.
=================================== FAILURES ===================================
_________________________________ test_convert _________________________________
def test_convert():
infile = os.path.join(cwd, "models", "featuretype.STEP")
with tempfile.TemporaryDirectory() as D:
outfile = os.path.join(D, "outfile.glb")
# do the conversion
cascadio.step_to_glb(infile, outfile, 0.1, 0.5)
> scene = trimesh.load(outfile, merge_primitives=True)
tests/test_load.py:16:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3.13/site-packages/trimesh/exchange/load.py:126: in load
loaded = load_mesh(file_obj, file_type=file_type, resolver=resolver, **kwargs)
/usr/lib/python3.13/site-packages/trimesh/exchange/load.py:202: in load_mesh
results = loader(file_obj, file_type=file_type, resolver=resolver, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
file_obj = <_io.BufferedReader name='/tmp/tmpjim9fbdf/outfile.glb'>
resolver = <trimesh.resolvers.FilePathResolver object at 0x3ff2df8c6e0>
ignore_broken = False, merge_primitives = True, skip_materials = False
mesh_kwargs = {'file_type': 'glb'}
head_data = b'glTF\x00\x00\x00\x02\x00\x01?\xb8\x00\x00\x04$NOSJ'
head = array([1179937895, 33554432, 3091136768, 604241920, 1246973774],
dtype='<u4')
def load_glb(
file_obj: Stream,
resolver: Optional[ResolverLike] = None,
ignore_broken: bool = False,
merge_primitives: bool = False,
skip_materials: bool = False,
**mesh_kwargs,
):
"""
Load a GLTF file in the binary GLB format into a trimesh.Scene.
Implemented from specification:
https://github.com/KhronosGroup/glTF/tree/master/specification/2.0
Parameters
------------
file_obj : file- like object
Containing GLB data
resolver : trimesh.visual.Resolver
Object which can be used to load other files by name
ignore_broken : bool
If there is a mesh we can't load and this
is True don't raise an exception but return
a partial result
merge_primitives : bool
If True, each GLTF 'mesh' will correspond to a
single Trimesh object.
skip_materials : bool
If true, will not load materials (if present).
Returns
------------
kwargs : dict
Kwargs to instantiate a trimesh.Scene
"""
# read the first 20 bytes which contain section lengths
head_data = file_obj.read(20)
head = np.frombuffer(head_data, dtype="<u4")
# check to make sure first index is gltf magic header
if head[0] != _magic["gltf"]:
raise ValueError("incorrect header on GLB file")
# and second value is version: should be 2 for GLTF 2.0
if head[1] != 2:
> raise NotImplementedError(f"only GLTF 2 is supported not `{head[1]}`")
E NotImplementedError: only GLTF 2 is supported not `33554432`
/usr/lib/python3.13/site-packages/trimesh/exchange/gltf.py:388: NotImplementedError
=========================== short test summary info ============================
FAILED tests/test_load.py::test_convert - NotImplementedError: only GLTF 2 is...
============================== 1 failed in 0.27s ===============================
I just got https://github.com/trimesh/cascadio packaged for Fedora, and the test is failing on
s390x
(the sole big-endian architecture). This is clearly a case of an endianness mixup; I’m filing the issue rather than on https://github.com/trimesh/cascadio becausetrimesh
is involved, and it’s not clear exactly where the problem is.If I do the following in an emulated
s390x
chrootthen I get an
outfile.glb
that starts as follows:and ends with
I can see that the version field is packed in big-endian order. From https://github.com/KhronosGroup/glTF/blob/082d5a98f479c37dff18767982d1431fc6c014fd/specification/2.0/Specification.adoc, it seems like that should be considered a bug – but perhaps it’s in OCCT? I’m curious to see what you think.
For now, I plan to build the new
python-cascadio
package on little-endian platforms only.I’m mentioning #1351 and #249 not because they necessarily share a root cause, but just to cross-link issues about big-endian-related test failures.
The text was updated successfully, but these errors were encountered: