You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Considering #25 and #26 to generate more vertex data, we may end up with too much (partially redundant) code if we want the generators to support various combinations like vertex + normal, vertex, vertex + tex-coords.
We might want to consider a single vertex format to be used by all generators, potentially also covering #27. The user should still be able to map the vertex to its own format and drop some of the generated data.
The main problem I see here is the complexity of shared vertex generation. For example, a cube would no longer be able to share any vertices, since each face has a different normal (unless we smooth normals over the cube, which doesn't make much sense).
The text was updated successfully, but these errors were encountered:
Another idea is to only generate fat vertices with the Iterator implementation of the generator (thus, non-shared). This is rather straightforward, and then we can use LruIndexer to make shared vertices and indexed polygons from it.
Considering #25 and #26 to generate more vertex data, we may end up with too much (partially redundant) code if we want the generators to support various combinations like vertex + normal, vertex, vertex + tex-coords.
We might want to consider a single vertex format to be used by all generators, potentially also covering #27. The user should still be able to map the vertex to its own format and drop some of the generated data.
The main problem I see here is the complexity of shared vertex generation. For example, a cube would no longer be able to share any vertices, since each face has a different normal (unless we smooth normals over the cube, which doesn't make much sense).
The text was updated successfully, but these errors were encountered: