3 ms·

https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample_file https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample... It's not the dumbest engineer

https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample_file https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample... It's not the dumbest engineering data format I've seen (seen many, this is at least one you can parse). But ffs, just use HDF5 people.

Const-me 5y ago
> It's not the dumbest engineering data format I've seen It’s not, but should the models be binary, the format would be much better. > just use HDF5 Last time I checked (a few years ago), HDF5 was only possible to handle with the official C++ library. That library didn’t even support multithreading, when I tried to write 2 HDF5 files from 2 concurrent thread, the program crashed with broken data structures in some global variables deep inside the HDF5 library. My computer has 16 hardware threads, the servers I’m targeting often have more of them, and I’d like to actually use that hardware. Single-threaded libraries aren’t OK in my books; not in 2021.
- formerly_proven 5y ago
  HDF5 supports parallel I/O with MPI, which works fine for HPC applications, but I can see how this might be a reason against HDF5.
- deleted 5y ago
  [deleted]
- ggrrhh_ta 5y ago
  It's a pity, also, some other limitations (for example with strings in HDF5 files, etc.). The format itself is to me, the closest to "the ultimate format", however, yes, library/tools support is a bit disappointing and it is sad. I came here to say that 3MF can be serialized into HDF5 - keeping the advantages of both, the textual description (which is much much more futureproof when one looks 10/15/20 years in the future) while having a one-to-one fast access counterpart.
  - Const-me 5y ago
    > which is much much more futureproof when one looks 10/15/20 years in the future IMO the main reason why binary formats suffered from compatibility issues in the past was huge variations of hardware. We had little endian/big endian CPUs, 16/32/64 bit bitness, earlier in the past there were even weirder computers with non-two complement signed integers, or 12 bits in a memory word. By now we only have big endian CPUs. Vast majority of them are 64 bits. All of them are using IEEE floats, at least for FP64 and FP32 numbers; for FP16 there’re several versions, unfortunately. None of that is likely to change in 10 or 20 years. For applications where performance matters, like image and video codecs, we do have binary formats which are older than 20 years, still in wide use, with little to no compatibility issues. Examples are PNG from 1997, or Mpeg-4 from 1998.
    - adgjlsfhk1 5y ago
      *little endian
      - Const-me 5y ago
        Indeed. Thanks for the correction.
      - ggrrhh_ta 5y ago
        there are still many HPC big-endian systems running... Maybe in 20 years everything will be little-endian.
pletnes 5y ago
HDF5 is great for many things but probably not as an application file format. In my experience it’s really hard to ensure you don’t write an invalid/corrupt file during exception handling etc. It’s great for data archival and batch processing workloads though.
ta988 5y ago
Unfortunately HDF5 failed as a universal format. I really enjoy it, but the support in various languages is extremely bad so you end up having to write your own adapters or using only the available subset in your poorly maintained language libraries.

Const-me 5y ago

> It's not the dumbest engineering data format I've seen It’s not, but should the models be binary, the format would be much better. > just use HDF5 Last time I checked (a few years ago), HDF5 was only possible to handle with the official C++ library. That library didn’t even support multithreading, when I tried to write 2 HDF5 files from 2 concurrent thread, the program crashed with broken data structures in some global variables deep inside the HDF5 library. My computer has 16 hardware threads, the servers I’m targeting often have more of them, and I’d like to actually use that hardware. Single-threaded libraries aren’t OK in my books; not in 2021.

formerly_proven 5y ago
HDF5 supports parallel I/O with MPI, which works fine for HPC applications, but I can see how this might be a reason against HDF5.
deleted 5y ago
[deleted]
ggrrhh_ta 5y ago
It's a pity, also, some other limitations (for example with strings in HDF5 files, etc.). The format itself is to me, the closest to "the ultimate format", however, yes, library/tools support is a bit disappointing and it is sad. I came here to say that 3MF can be serialized into HDF5 - keeping the advantages of both, the textual description (which is much much more futureproof when one looks 10/15/20 years in the future) while having a one-to-one fast access counterpart.
- Const-me 5y ago
  > which is much much more futureproof when one looks 10/15/20 years in the future IMO the main reason why binary formats suffered from compatibility issues in the past was huge variations of hardware. We had little endian/big endian CPUs, 16/32/64 bit bitness, earlier in the past there were even weirder computers with non-two complement signed integers, or 12 bits in a memory word. By now we only have big endian CPUs. Vast majority of them are 64 bits. All of them are using IEEE floats, at least for FP64 and FP32 numbers; for FP16 there’re several versions, unfortunately. None of that is likely to change in 10 or 20 years. For applications where performance matters, like image and video codecs, we do have binary formats which are older than 20 years, still in wide use, with little to no compatibility issues. Examples are PNG from 1997, or Mpeg-4 from 1998.
  - adgjlsfhk1 5y ago
    *little endian
    - Const-me 5y ago
      Indeed. Thanks for the correction.
    - ggrrhh_ta 5y ago
      there are still many HPC big-endian systems running... Maybe in 20 years everything will be little-endian.

pletnes 5y ago

HDF5 is great for many things but probably not as an application file format. In my experience it’s really hard to ensure you don’t write an invalid/corrupt file during exception handling etc. It’s great for data archival and batch processing workloads though.

ta988 5y ago

Unfortunately HDF5 failed as a universal format. I really enjoy it, but the support in various languages is extremely bad so you end up having to write your own adapters or using only the available subset in your poorly maintained language libraries.