The problem
There is an importer/exporter for PLY already implemented in Blender, but it is implemented in Python which means it is slow for bigger files. The importer is also missing support for point cloud PLY files with vertex colors. Since PLY is often used for laser scan data (which are big files that contain a point cloud and sometimes vertex colors) it would be a shame not to address these issues.
The idea
We are a group of software engineering students from the university of applied sciences Windesheim in the Netherlands. And we would like to rewrite the current Python based importer/exporter to C++, with a focus on performance, extendibility and implementing missing functionality.
Requirements
Importer
- Vertex data
- Face data
- Edge data
- Vertex colors
- Vertex normals
- UV data
Exporter
- Vertex data
- Face data
- Edge data
- Vertex colors
- Vertex normals
- UV data
- Triangulation
Nonfunctional requirements
- The C++ based importer/exporter should be 5x faster than the current Python based implementation.
- The behavior and results of current python add-on should be matched as closely as possible. Divergences, if any, should be clearly justified and documented.
Priorities
Our main focus will be implementing a fully featured importer, since we feel that will benefit Blender users the most. But having the importer in C++, and the exporter in Python is not optimal So we will split the development team into two parts, so we can work on the importer and exporter in parallel.
Possible additions
The PLY file format supports user-defined properties; we could make use of this fact by exposing these properties to geometry nodes as attributes. This would allow us to generically support all user defined properties (which we personally think is very cool). But some research needs to be done to see if this is practical and able to be implemented.
Scope
Since this is a student project, we have a definite deadline (20th of January). And after that deadline we won’t be able to work on the importer/exporter as much, if at all. @Aras Pranckevicius (aras_p) is willing to maintain the code after the project ends (if we send him some cookies), so we will be counting on him.
Testing strategy
For this project we are planning on utilizing test driven development. Detailed unit tests will be written for a large part of the added code. We will also gather a large amount of PLY files from different sources, to keep track of which files get loaded correctly. Both fine grain and coarse grain tests will be written.
If there is functionality missing in this design, or if you have other feedback. Please let us know.