<div dir="auto"><div>Was hoping to get feedback on my suggestion instead, but another suggestion doesn't work.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2024, 6:28 PM Michael Strauß <<a href="mailto:michaelstrau2@gmail.com">michaelstrau2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Any solution which was good enough for normals is also good enough for vertex colors right?<br>
<br>
Not necessarily. Designing APIs is hard, and one should try to start<br>
from a point of asking "how would the API look like if we had<br>
considered all of the things we know now from the beginning".<br>
<br>
An idea that might be worth exploring is the following. Instead of<br>
storing positions, normals, texture coordinates, etc. in separate<br>
buffers as it is currently done in TriangleMesh, we could have a<br>
CustomMesh<TVertex>, where TVertex is a structure that stores all<br>
relevant components in the same place. This could be a sealed<br>
interface that only allows a limited set of implementations (because<br>
we don't have the option of user-defined vertex structures at the<br>
moment), but could allow for future extension with user-defined vertex<br>
structures.<br>
</blockquote></div></div></div>