Having gone through some sources, I found the additional properties that
can be added as per-vertex data:
* Additional texture coordinates (mentioned by Michael). These can be used
for detailed textures.
* Bone indices and weights. These are for GPU skinning. Interestingly, the
D3D vertex shader constants file has some preparation for skinning and
bones [1].
* Tangents. Used similarly to normals in some lighting-related calculations.
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).
Looking at the use of VertexFormat in TriangleMesh with regards to normals:
private boolean validateNormals() {
// Only validate normals if vertex format has normal component
if (getVertexFormat() != VertexFormat.POINT_NORMAL_TEXCOORD) return
true;
if (normals.size() == 0) { // Valid but meaningless for picking or
rendering.
return false;
...
}
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?
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.
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.
[1]
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h
On Sat, Sep 21, 2024 at 5:17 AM Michael Strauß <michaelstr...@gmail.com>
wrote:
> > I'm not yet convinced that new vertex formats are the way to go.
>
> To be fair, I'm not sure why VertexFormat even exists. It serves no
> purpose when creating a TriangleMesh, as the vertex format could
> easily be inferred by the presence (or absence) of vertex data. Having
> users specify the VertexFormat explicitly is probably not a good API,
> as it now makes the other data components be dependent on the choice
> of the vertex format.
>
> Of course, not all combinations of vertex data are valid, but this
> could be specified in documentation and be validated by the
> implementation. I think it might be best to deprecate VertexFormat for
> removal. This would also prevent a potential explosion of vertex
> formats in the public API.
>
> I have no objection to the choice to add vertex colors as an
> additional data component to TriangleMesh. It adds to the API, but
> this is not a slippery slope as there's only a very finite set of
> features we might be tempted to add next:
>
> The most obvious thing that JavaFX 3D really can't do is shadows.
> These come in static form (light mapping) and dynamic form (shadow
> mapping). Light mapping requires a second set of texcoords, while
> shadow mapping does not.
>
> Adding light mapping would make JavaFX 3D competitive with late-90's
> graphics, and adding shadow mapping would make it competitive with
> early-2000's graphics.
>
