I understand that you propose to add a special-purpose mesh (GouraudShadedTriangleMesh) instead of adding yet another buffer to the existing TriangleMesh. That might be a valid idea if the goal is to not overload the TriangleMesh class with special-purpose stuff.
However, I still feel that the solution space in terms of API isn't explored in enough detail here. It might be the case that CustomMesh<TVertex> is not implementable (and it might also be the case that CustomMesh<TVertex> isn't a good idea to begin with). But at this point, none of this is obvious to me. Usually, when you propose a new feature, you should explain the motivation, goals and non-goals, alternatives, and so on (you can use a JEP template for that if you like). You adequately addressed the motivation for your proposed enhancement, but I feel that the discussion of different approaches should be expanded upon. I'm not convinced that CustomMesh<TVertex> is impossible to implement: if TVertex can only ever be PositionTexCoord, PositionNormalTexCoord, PositionColorTexCoord, and PositionNormalColorTexCoord (and this is enforced, for example using sealed interfaces), then why wouldn't we be able to connect this to our existing shaders? Again, I'm not saying that this is a good idea; it might not work for any number of reasons. But I think these alternative approaches should at least be explored a little bit before dismissing them. Maybe it will be GouraudShadedTriangleMesh in the end. On Fri, Aug 23, 2024 at 4:45 AM 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.
