Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The API for creating the geometry of a plant is currently terrible.
We first have to define reference meshes, put them in a
RefMeshes
structure, and put that structure into the root node of the mtg.Then, each node has a given geometry that points to the reference mesh, to its position in the vector of reference meshes in the
RefMeshes
structure, its transformations, tapering, and finaly the actual mesh of the node (which is lazily reconstructed).I think we can improve that by removing the
RefMeshes
structure altogether, and only giving a reference to the reference mesh to the node. This way we simplify greatly the API.The API would be something like:
And if the user wants to add more information into its reference mesh, it can still wrap it into a
RefMesh
structure as follows:Now if some reference meshes are given directly as meshes, we need to give each a default name and compute the normals of their vertex when we write them to disc in the OPF.
We also need to change how we write the OPF altogether, because currently we use the index of the reference mesh. But we could make a dictionary of keys refmesh and values index + any other needed information (material, normals...), if the mesh/refmesh is not in this dict, we add it, if it is, we just extract the information. In this case, we should write different parts of the OPF at different times. Starting with the topology, and slowly growing the meshBDD and other header information. I don't know if that's possible though.