<div dir="ltr">I would first try to figure out if the code in the snippet I gave is actually correct. If it is, then the vertex format has a functional use. If it's not, then we can think about what to do with it. I didn't look into it, but on the face of it, it doesn't look like the unused normals should be validated.<div><br></div><div>The last sentence in my previous mail suggested a different solution: keep the vertex format as it is (for now) to dictate how points and normals are read, but add color without interaction with the vertex format. The color will be used if it's not empty/null.</div><div>This keeps everything as it is, avoids multiplications of formats, and doesn't hinder possible future additions that will also not use the vertex format. On the slightly confusing side, it means that vertex format doesn't define the format for *all* the data of the vertex, just for its positional components that are mandatory (at the very least, points should be supplied).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2024 at 3:12 AM 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="auto"><div dir="auto">These are some great points!</div><div dir="auto"><br></div><div dir="auto">Nir mentioned a builder-style pattern for TriangleMesh, but I struggle to think of how this could work well, as one critical feature of the current API is to be able to dynamically update mesh data, which is very important for any kind of animated mesh. I'd love to see any designs that get prototyped though (regardless of if they are builder-like).</div><div dir="auto"><br></div><div dir="auto">Let's discuss the big question though, VertexFormat's design.</div><div dir="auto"><br></div><div dir="auto">To be honest, light maps and shadow maps seem unrealistic right now. They are way too intensive to generate in JavaFX (we'd need a LOT of work to do this efficiently, only for the user to not like the algorithm we selected). And even if the user gets this far, they'll be faced with a significant performance penalty. Light maps usually contain data for many 3D objects, but due to JavaFX rendering order being based on the scene graph order, which is going to cause a significant amount of large texture swaps. I'd be open to changing that and do hope to fix the performance issues as much as we can, but overall it strikes me as a very far-fetched feature.</div><div dir="auto"><br></div><div dir="auto">Regarding bones/skeletal rigs, that's a really good idea actually. I'm kind of shocked I didn't think of that sooner.</div><div dir="auto"><br></div><div dir="auto">I've got a few ideas for how we can tackle these problems, but none particularly jump out as the perfect option to me, so I'm hoping for feedback on what you guys think.</div><div dir="auto"><br></div><div dir="auto"><b>1) Why not let users define their own VertexFormats? If our concern is the explosion of definitions we'd be keeping statically, we could just define a handful of built-in formats but let users define formats as they see fit. Similar to the Cesium Project Nir linked.</b></div><div dir="auto"><br></div><div dir="auto"><u>Pros:</u></div><div dir="auto"> - This would avoid the explosion of built-in formats, since we wouldn't need to explicitly define/support every single format, but instead let the user define the format themselves.</div><div dir="auto"><br></div><div dir="auto"><u>Cons:</u></div><div dir="auto"> - Doesn't address the concern of TriangleMesh properties not serving any purpose depending on what VertexFormat it has.</div><div dir="auto"><br></div><div dir="auto"><b>2) Have TriangleMesh automatically determine format based on which buffers contain/do not contain data.</b></div><div dir="auto">This is extremely similar to #1, except it</div><div dir="auto"><br></div><div dir="auto">We could keep VertexFormat around, but make it read-only, so it only serves as a reflection of the data in TriangleMesh, instead of something the user can apply. We'd deprecate the constructor TriangleMesh(VertexFormat) and TriangleMesh.setFormat(VertexFormat) but keep them around (they would do nothing) thus keeping code compatibility (and maybe also binary compatibility?).</div><div dir="auto"><br></div><div dir="auto"><u>Pros:</u></div><div dir="auto"> - Avoid bloat.</div><div dir="auto"> - Extensible without ever leaving any functionality both unusable and accessible. (IDEA: What if it's not fully removed, but instead is a read-only property obtainable inside TriangleMesh, and the constructor which accepts a VertexFormat deprecated instead? It still feels appropriate to get vertex format data from VertexFormat instead of the mesh itself)</div><div dir="auto"><br></div><div dir="auto"><u>Cons:</u></div><div dir="auto"> - Breaking API change. (If we deprecate/remove VertexFormat)</div><div dir="auto"> - The user is still responsible for supplying the faces array in the correct format, and making the VertexFormat calculated implicitly behind the scenes (something the user must respond to or the mesh will either not render or display corrupted if we can't tell), would be hidden from the user. Currently the user has to explicitly say they're changing the format, but this automatic behavior is less clear to the user. Not a huge deal but worth considering.</div><div dir="auto"><br></div><div dir="auto">The overall outcome of this seems pretty similar to #1, but it loses the benefit of explicitness in exchange for not ever having buffers which are unusable but still accessible. I'm personally torn on if this trade-off is worth it.</div><div dir="auto"><br></div><div dir="auto"><b>3) Add Vertex Colors to VertexFormat, but future features use either #1 or #2.</b></div><div dir="auto">Bump map tangents/light map uvs/skeleton seem significantly less ubiquitous than vertex colors even if they're still important. Picking this option would expand the already questionable normals design, but considering these future features may never be added, perhaps it makes sense to keep the existing design until we're sure we're even going to add the others. And at that point we'd be in exactly the same position as now with exactly the same options for implementing it. In other words, it buys us time while still letting us scrap VertexFormat if the time ever comes.</div><div dir="auto"><br></div><div dir="auto"><u>Pros:</u></div><div dir="auto"> - Keeps all existing features consistent with existing public API design.</div><div dir="auto"> - Avoids bloat</div><div dir="auto"> - Avoids breaking consistency with the existing public API up until the moment we start adding less common data fields.</div><div dir="auto"><br></div><div dir="auto"><u>Cons:</u></div><div dir="auto"> - If Option #1 is picked for future features, the same cons from #1 are present.</div><div dir="auto"> - If Option #2 is picked for future features, the same cons from #2 are present.</div><div dir="auto"> - If we're going to deprecate VertexFormat, it might be a valid point that that we don't actually want to delay that, and would rather do it earlier rather than later.</div><div dir="auto"><br></div><div dir="auto">I'm torn between all of the options  I've listed here. What do you guys think?</div><div dir="auto"><br></div><div dir="auto">We should also discuss how other primitive topologies (POINT, LINE, TRIANGLE, TRIANGLE_STRIP) could work and how this might factor into our VertexFormat discussions. (Should LINE really even be represented by TriangleMesh and not a new LineMesh? Would it make sense to still use VertexFormat?)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 23, 2024, 9:23 AM Nir Lisker <<a href="mailto:nlisker@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">nlisker@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">Having gone through some sources, I found the additional properties that can be added as per-vertex data:<div>* Additional texture coordinates (mentioned by Michael). These can be used for detailed textures.</div><div>* Bone indices and weights. These are for GPU skinning. Interestingly, the D3D vertex shader constants file has some preparation for skinning and bones [1].</div><div>* Tangents. Used similarly to normals in some lighting-related calculations.</div><div><br></div><div>While it's not clear that we'll need these, the proliferation of vertex formats will be unmanageable with even one of these added (in addition to color).</div><div><br></div><div>Looking at the use of VertexFormat in TriangleMesh with regards to normals:</div><div><br></div>private boolean validateNormals() {<br>    // Only validate normals if vertex format has normal component<br>    if (getVertexFormat() != VertexFormat.POINT_NORMAL_TEXCOORD) return true;<br>    <div>    if (normals.size() == 0) { // Valid but meaningless for picking or rendering.<br>    return false;<br>    ...<br>}<div><br></div><div>I'm confused by this. If the normals should be validated only when the vertex format defines that normals are used, why does the method return true when normals aren't used?</div><div>I would think, along with what Michael said, that either if the vertex format doesn't declare normals, or the user doesn't declare normal (size ==0), then the normals wouldn't be validated. That would also mean that the vertex format is redundant since it's implied by the existence/length of the array.</div><div><br></div><div>Perhaps it's worth looking at the color implementation this way. Additional vertex formats should not be added, and the use of vertex colors should be dictated by looking at the array.</div><div><br></div><div>[1] <a href="https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 21, 2024 at 5:17 AM Michael Strauß <<a href="mailto:michaelstrau2@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" 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">> I'm not yet convinced that new vertex formats are the way to go.<br>
<br>
To be fair, I'm not sure why VertexFormat even exists. It serves no<br>
purpose when creating a TriangleMesh, as the vertex format could<br>
easily be inferred by the presence (or absence) of vertex data. Having<br>
users specify the VertexFormat explicitly is probably not a good API,<br>
as it now makes the other data components be dependent on the choice<br>
of the vertex format.<br>
<br>
Of course, not all combinations of vertex data are valid, but this<br>
could be specified in documentation and be validated by the<br>
implementation. I think it might be best to deprecate VertexFormat for<br>
removal. This would also prevent a potential explosion of vertex<br>
formats in the public API.<br>
<br>
I have no objection to the choice to add vertex colors as an<br>
additional data component to TriangleMesh. It adds to the API, but<br>
this is not a slippery slope as there's only a very finite set of<br>
features we might be tempted to add next:<br>
<br>
The most obvious thing that JavaFX 3D really can't do is shadows.<br>
These come in static form (light mapping) and dynamic form (shadow<br>
mapping). Light mapping requires a second set of texcoords, while<br>
shadow mapping does not.<br>
<br>
Adding light mapping would make JavaFX 3D competitive with late-90's<br>
graphics, and adding shadow mapping would make it competitive with<br>
early-2000's graphics.<br>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div>