Feature Request: read/write more mesh file formats

[swiss-knight]

Hello,

would it possible to also work with those very common mesh file formats with MDAL?

• .DAE
• .OBJ
• .STL
• .glTF 2.0 / GLB

Many thanks!

Warm Regards.

[runette]

@swiss-knight

Just some comments from me personally>

1 I have a feeling the most likely response will be "We welcome PRs implementing new features" :) There is no dedicated development group for MDAL so it grows by people creating what they need and publishing it.

2 That said, the main target for MDAL is meshes that embody data; particularly, for historical reasons, hydrology data and the associated formats. The formats you are talking about embody meshes but not "datafull" meshes and are primarily intended for forms of graphics. I started to blur the distinction when I implemented .PLY for MDAL - but PLY DOES have the ability to store arbitrary data on the vertices and edges.

3 That said, I personally can see a benefit to be able to import mesh geometries from common creative packages, using those formats, to be able to add data and save in datafull formats, or to be able to take a datafull mesh and create a false coloration and save for viewing in common packages. Just not enough to be able to find the time to do it, especially since I can generally do it using the .PLY driver.

[PeterPetrik]

Hi,

As Paul said, the package is mainly used in QGIS for mesh data layer formats, not 3D, which is reflected in the internal structure of the library.

Peter

On Tue, Sep 17, 2024 at 2:46 PM Paul @.***> wrote:

@swiss-knight https://github.com/swiss-knight

Just some comments from me personally>

1 I have a feeling the most likely response will be "We welcome PRs implementing new features" :) There is no dedicated development group for MDAL so it grows by people creating what they need and publishing it.

2 That said, the main target for MDAL is meshes that embody data; particularly, for historical reasons, hydrology data and the associated formats. The formats you are talking about embody meshes but not "datafull" meshes and are primarily intended for forms of graphics. I started to blur the distinction when I implemented .PLY for MDAL - but PLY DOES have the ability to store arbitrary data on the vertices and edges.

3 That said, I personally can see a benefit to be able to import mesh geometries from common creative packages, using those formats, to be able to add data and save in datafull formats, or to be able to take a datafull mesh and create a false coloration and save for viewing in common packages. Just not enough to be able to find the time to do it, especially since I can generally do it using the .PLY driver.

— Reply to this email directly, view it on GitHub https://github.com/lutraconsulting/MDAL/issues/488#issuecomment-2355658748, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGEOABNCCGVGJJD63QFKV3ZXAQEBAVCNFSM6AAAAABOHVRNVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVGY2TQNZUHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[swiss-knight]

Hi there,

Thank you both for your prompt replies 🙏!

It's precisely by coming from the world of QGIS that I've asked this question.

Initially, I simply needed to load some triangular 3D meshes (given in those formats) as layers in a QGIS project. In my opinion, there's still a small gap when it comes to handling triangular 3D meshes in GIS softwares in general. Whether they should embody data or not (to draw a parallel, you can e.g. think of LINESTRING ZM vs LINESTRING Z in PostGIS).

Like the great GDAL or PDAL libraries, I was hoping that MDAL would be able to handle the most commonly used mesh formats. Indeed, like these other libraries well known for the data they handle, the name MDAL suggests that it could cover most commonly used 3D mesh formats. I perfectly understand that it's still attached to its heritage from the world of hydraulic simulations, but I think that in the long run, it would have everything to gain from opening up more widely to the world of 3D meshes! 😉

By currently lacking the time and skills to contribute to such developments 😟, I'm curious to see how this will evolve in the future. 🙂

Warm Regards.