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.

First of all: it's OK. If nothing else, in either 2017 (first copyright date) or 2020 (first CPAN), PDL::IO::STL didn't exist.

Also, that doesn't (yet) support normals in any useful way; it drops them on input, and writes out 0s on output. Does anything actually rely on them being correct in the file?

Finally, it seems to me that CAD, and 3D stuff in general, is really the killer app for PDL. The array-programming stuff makes things quick because fast C code, and also very easy to write. But especially because all the 3D maths stuff (including cross product) are just there already, together with any linear algebra stuff you might need to do. You can write lots of object-y Perl, with methods, or write 3 lines of PDL code. Truly, more than one way to do it ;-)

So, this is exactly what I said I was looking for, but what I actually was thinking was some format what would be efficient for C code to operate on. Having to reach into individual scalars for the 3D coordinates isn't going to be very fast.

I thought it over a bit, and I think what I'm actually wanting is:

• Mesh object:
• 'vertices' attribute, which contains a buffer of packed floats or doubles
• 'polygons' attribute, which contains a buffer of packed integers referencing the vertex numbers of the 3 corners of the polygon
• 'normals' attribute, which contains one vector per vertex, so can be indexed by the polygon integers
• 'textures' attribute, which is an arrayref of hashrefs describing a texture
• 'polygon_texture' attribute, which is a packed integer for each polygon referencing one of the textures and the (S,T) coordinates for each of the 3 referenced vertices, maybe 16-bit ints for the texture coordiantes adding up to 16 bytes per polygon
• A Polygon object that is just a reference to the mesh + an offset, and it loads its attributes on demand.

Maybe the specification for an object like this could be that each of these attributes may be a packed scalar, or a PDL ndarray?

The end-goal I'm trying to achieve is to pass all the buffers to OpenGL and make a shader that can render the whole mesh.

And, I don't know. Maybe this isn't the "perl way" to approach it. Maybe I should start with the inefficient expanded object and have code that packs it however required for the rendering. That adds startup cost though.

I think trying to be ultra-fast from day 1 might be premature optimisation? Making something that works correctly (with automated tests) can then be made quick.

Though getting things "right" using separate ndarrays for each thing named above, and maybe sellotaping them together into objects later would probably also be processable quite quickly. Yes, I think I'm suggesting prototyping with PDL. It already has code to do OpenGL, including animation, and responding to user inputs (e.g. rotating the view around, while the molecule demo runs). It doesn't yet have textures, but that shouldn't be too agonising to add.

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 ;-).

Well, I don't have first-hand experience with these things, I just know that people somehow design models that can flex :-) You know, like having a character run up steps and needing to have the foot meet the step in a realistic way, while all the vertices that make up the knee have been averaged somewhere inbetween a standing animation frame and a crouched animation frame. I kind of assumed you could make them with Blender, but have never actually done so. I would guess there would need to be some sort of equation encoded in the model, like "N * this vector + M * that vector" and someone clever would have found a way to build that into a big matrix so that you just take the "joint angles" of the model and do some matrix multiplication and get the current vertex array for the model.

Maybe every game engine defines their own format? I'd be interested to know if any open-source tools standardized on something.

Mainly, I hate it when I spend a bunch of effort making a re-usable piece, and then the very second problem I try to apply it to requires me to re-design it from scratch.

Having to do things more than once is no fun! I had a very quick look, and it seems Unity is both usable freely (at least for low-revenue situations, which will definitely include experimentation), and well-regarded for game development. Whatever they do is likely to be within reach of a perfect solution to the design issues you're talking about. https://docs.unity3d.com/Manual/index.html looks like a good starting point.