Feature Request: read/write more mesh file formats #488
Comments
|
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. |
|
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
<#488 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGEOABNCCGVGJJD63QFKV3ZXAQEBAVCNFSM6AAAAABOHVRNVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVGY2TQNZUHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
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. 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. |
Hello,
would it possible to also work with those very common mesh file formats with MDAL?
Many thanks!
Warm Regards.
The text was updated successfully, but these errors were encountered: