Sorry want to reword the first paragraph since it didn't make sense. I don't feel like my email was understood, because I explained how a solution like the one you've just suggested is one we should eventually add, but that regardless of that eventual feature, my current suggestion is still a worthwhile feature to add on its own which does not conflict with the future user-shader support.
On Thu, Aug 22, 2024, 7:44 PM Knee Snap <kneeste...@gmail.com> wrote: > Was hoping to get feedback on my suggestion instead, but another > suggestion doesn't work. > > The idea of a CustomMesh<TVertex> is impossible to implement until after > we have fully user-supplied shader support, which I've already addressed as > being not the scope of this change (but instead it is a separate future > change which is not impacted by this) it also feels like this point may > have been missed as well. > > On Thu, Aug 22, 2024, 6:28 PM Michael Strauß <michaelstr...@gmail.com> > wrote: > >> > Any solution which was good enough for normals is also good enough for >> vertex colors right? >> >> Not necessarily. Designing APIs is hard, and one should try to start >> from a point of asking "how would the API look like if we had >> considered all of the things we know now from the beginning". >> >> An idea that might be worth exploring is the following. Instead of >> storing positions, normals, texture coordinates, etc. in separate >> buffers as it is currently done in TriangleMesh, we could have a >> CustomMesh<TVertex>, where TVertex is a structure that stores all >> relevant components in the same place. This could be a sealed >> interface that only allows a limited set of implementations (because >> we don't have the option of user-defined vertex structures at the >> moment), but could allow for future extension with user-defined vertex >> structures. >> >
