<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" 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" 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>