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
you may want to consider handling the mz3 format, the page includes Python, Blender, JavaScript code as well as a full specification and examples datasets. It attempts to live at the Pareto frontier of file size and speed. It is both faster and smaller than GIfTI. The layout design maps directly onto modern GPU architectures (and hence WebGL, Metal and Vulkan APIs). I developed this primarily for the sample files distributed with Surfice, to reduce download times, disk usage and the time to run the demos / regression testing. It is intentionally simple, and does not have the flexibility of other formats. It does not attempt to do everything, but it can fill a niche.
The text was updated successfully, but these errors were encountered:
I forgot to mention Matlab code is provided. @gllmflndn contributed to the code and specification, and thanks to him it is supported by spm12 and PALM.
Relative size and speed for several mesh formats is here.
@effigies I would suggest we close this issue. While mz3 is supported by Surfice, SPM and PALM, it was really designed to be an internal format so that the Surfice distribution size would be small and the demos would run very quickly. It did not have community input in development.
You can find Python (as well as Matlab and JavaScript) implementations and benchmarks for mz3, GIfTI, obj, STL, jmsh, bmsh. In brief, the mz3 and bmsh formats are virtually identical in terms of file size and speed. Both are on the Pareto frontier on these measures. While I created mz3, I would advocate that bmsh is better suited for the community as it is extensible and actively maintained by @fangq.
Via @neurolabusc:
The text was updated successfully, but these errors were encountered: