<div dir="ltr">Hi all, just sending an update on the proposal since I'm hoping to start work on a draft PR for this, but I'd like feedback on the proposed API (with & without the changes mentioned in the previous email).<div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2024 at 11:49 PM Knee Snap <<a href="mailto:kneester77@gmail.com">kneester77@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Michael,</div><div><br></div><div>Thanks for the response!</div><div><br></div><div><div dir="ltr"><b><u>> Have you thought about ways how we could allow deverlopers to define custom formats? Maybe that would also require a new kind of Mesh that can accept custom data.</u></b></div></div><div>Yep, and while I'd very much like this eventually, this cannot occur before user-supplied shaders are supported since otherwise there'd be nothing done with any user-configured data. User-supplied shaders would be a very large amount of work in many different aspects.</div><div>For example, there isn't even currently a way to tell if the 3D backend JavaFX has running is OpenGL or Direct3D, let alone manage shaders.</div><div>I don't know that I'm qualified to even implement something so large for an open-source immutable API yet. And, it would also ask more from developers who utilize JavaFX, as they now need to write shaders for each supported backend, and juggle a lot objects & concepts more when it comes to rendering.</div><div>I still see value in keeping a platform-agnostic shader-free TriangleMesh which has vertex coloring even after a hypothetical user-supplied shader system, which could co-exist separate from the "TriangleMesh" as perhaps a new "AdvancedTriangleMesh" class.</div><div>Now here's where I think you've brought up an interesting point and I'll counter with a slight change to my design.</div><div><br></div><div dir="ltr"><b><u>> However, with the introduction of programmable shaders, the structure of vertices can be freely defined by developers. It seems to me that your proposed API would pick just one (maybe useful) scenario, and eternally bake it into JavaFX APIs. What if we get custom shaders one day? Then we would need a way to customize the vertex format again.</u></b></div><div>Yes! It is just one scenario and shaders are the dream, but I still believe it's worth baking into the JavaFX API due to how useful it is, I imagine that this feature can co-exist separately from the hypothetical user-supplied shader support.</div><div>I mentioned before in a previous email that I don't think having vertex colors takes away from the ideal future where custom shaders are supported. Since there seems to be a concern here, I'll expand upon what I meant by that.</div><div><br></div><div>The current TriangleMesh.java is equivalent to a non-shader fixed rendering pipeline, as it has an explicitly defined group of buffers. Some of which (normals) are already optional.<br></div><div>The design of the future user-supplied shader system has not been made worse by supporting vertex colors, as we already have the same exact eternally baked API already inside TriangleMesh.java.</div><div><br></div><div>It's true though that TriangleMesh's existing buffers are mostly applicable to pretty much every future shader, but it's not entirely the case.</div><div>Normals are also currently optional, and also might not be desired by certain custom shaders when it's time. I'll concede that normals are somewhat more common than vertex colors, but it's the same problem in the same file.</div><div><br></div><div>Initially because of this observation about normals, my thought was that TriangleMesh wouldn't be the parent class of any future mesh with shader support. There would be two separate mesh base classes, TriangleMesh (fixed capabilities), and something like AdvancedTriangleMesh (allowing user-specified shaders).</div><div>Any solution which was good enough for normals is also good enough for vertex colors right?</div><div><br></div><div>Well, after your critique, I've come up with another option, I'm curious if you prefer this one.</div><div>Instead of modifying TriangleMesh.java and having an unrelated AdvancedTriangleMesh class in the future, this one can consider that just because normals are in TriangleMesh.java a bad thing doesn't mean vertex colors need to clog it further.</div><div>So, I'd instead create "GouraudShadedTriangleMesh" which extends TriangleMesh, and it's what would contain the vertex buffer, etc. So it can have the coloring, and also allow a future AdvancedTriangleMesh to extend the original TriangleMesh without having a hint of the vertex color buffer.</div><div><br></div><div>I believe this should adequately address why I think this is good to have in the API forever.</div><div><br></div><div><div><b><u>> Currently we have two predefined vertex formats: VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD. It doesn't seem obvious to me that the best way forward is to add more bespoke formats here.</u></b></div><div>I partially agree, and partially disagree. I agree that we should not be adding VertexFormat options left and right. But the only other scenario I can imagine as theoretically adding more VertexFormats is if it became time to support quads. Either that or a new user-supplied shader system, but that isn't really relevant. </div></div><div>Vertex colors feel to me like the final missing piece before the current non-custom shader mesh support is fully featured, so I don't think it's unreasonable to add new VertexFormat entries.</div><div>In theory it would be possible with the "GouraudShadedTriangleMesh" idea to not actually create any new VertexFormat object/functionality, and keep such functionality within the "GouraudShadedTriangleMesh" class itself. Personally I think it depends entirely on the decision of "Would a potential future user-supplied shader system extend TriangleMesh or should it be its own thing?"</div><div><br></div><div>Thanks again for the feedback!</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2024 at 10:51 PM Michael Strauß <<a href="mailto:michaelstrau2@gmail.com" target="_blank">michaelstrau2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Vertex colors usually refers to a technique where the vertex format is enriched with an additional color component, and this color component is then used in one of the shader stages to affect the computation in some way (usually by combining it with the texture color).<div><br></div><div>As you correctly say, this technique is decades-old, it existed even back in the days of fixed function pipelines.</div><div><br></div><div>However, with the introduction of programmable shaders, the structure of vertices can be freely defined by developers. It seems to me that your proposed API would pick just one (maybe useful) scenario, and eternally bake it into JavaFX APIs. What if we get custom shaders one day? Then we would need a way to customize the vertex format again.</div><div><br></div><div>Currently we have two predefined vertex formats: VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD.</div><div>It doesn't seem obvious to me that the best way forward is to add more bespoke formats here.</div><div><br></div><div>Have you thought about ways how we could allow deverlopers to define custom formats? Maybe that would also require a new kind of Mesh that can accept custom data.</div></div>
</blockquote></div></div>
</blockquote></div>