As discussed on your 3Space repo, I think it likely that bulk processing of this geospatial stuff could be quicker/easier to write with PDL (and run quicker too), but the hard grind of getting the maths right would still be there.

I kind of want a "Perl Standard Polygon Mesh Object" so that I can have modules pass those around without being especially dependent on eachother. Though, it's hard to have that when people want so many differing things from a mesh, like surface normals per polygon, or normals per vertex, or texture coordinates, texture references etc. On top of that, the most interesting meshes are the dynamic ones made by tools like Blender, and I have no idea how those are stored or processed. So, I probably don't have the expertise to define one that fits all use cases. I briefly investigated wrapping OpenCASCADE, but it's probably the most awkward C library I've ever tried to make into a CPAN module, mostly due to size and compilation speed and dependencies; even Debian divides that collection into 7 different packages. PDL can load STL files, so that seemed like a good place to focus, in the meantime.

If I knew more about Blender models, I might try to create a standalone CPAN dist for 3D objects and then make them all PDL-compatible, and add support for them in Math::3Space and OpenGL::Sandbox and Geo::SpatialDB.

I kind of want a "Perl Standard Polygon Mesh Object"

I'd not call it a "standard", because I doubt anyone but me has used it, but <shameless plug>I wrote CAD::Mesh3D for helping me write STL files.</shameless plug> (It's based on Math::Vector::Real instead of PDL. Sorry, etj.)

like surface normals per polygon

That's the assumption mine made (because that's what STL wants).

Though mine only has triangular facets, and a helper function to define a rectangle to turn it into a triangle. No higher-node polygons have helpers.

or texture coordinates, texture references etc

Definitely not included in mine.

input/output formats:

Since my focus when writing it was STL, CAD::Mesh3D comes with a formatter to read or write STL. But I tried to make it extensible, so CAD::Mesh3D::ProvideNewFormat should allow you to define another file format, if desired.

conclusion:

Based on your description, CAD::Mesh3D isn't likely what you need or want, but this seemed a good place for a <shameless plug>...</shameless plug>, just in case you or anyone else wanted to play with it.

I did some googling and the only things I found for Blender "dynamic mesh" was the Dyntopo feature, which just does sculpting on an existing polygon mesh. That will just edit an existing mesh, adding faces, so there'd be no difference in file format. If it's actually something else, please say!

A "standard polygon mesh" object creates questions. Would you go with each vertex is specified as a 3-float coordinate? Or as an index into a separate list of such coordinates? Would you store all the faces in a single such object, or have a memory-inefficient Perl array of SVs? Would the data be packed? How would you do extensions like textures? These aren't insoluble, but they give me the sinking feeling of knowing that people will want to write huge slabs of XS code instead of just using PDL because they have objections to the idea of dependencies (although depending on Math::Vector::Real is somehow still fine ;-).