Unreal vertex index vs. glTF vertex index

[GhisBntly]

I noticed a bug in our project code yesterday that used vertex indices to get metadata using UCesiumFeatureIdSetBlueprintLibrary::GetFeatureIDForVertex: we were using vertex indices from the Unreal mesh, but those don't always match the original glTF model vertex indices, because in some cases there is vertex duplication in CesiumGltfComponent.cpp's loadPrimitive:

cesium-unreal/Source/CesiumRuntime/Private/CesiumGltfComponent.cpp

Line 1547 in 3e17502

bool duplicateVertices = needToGenerateFlatNormals || needToGenerateTangents;

(Note: visiting Unreal mesh vertices was a bad idea as the buffers have no reason to remain in main memory once the render thread has copied them to graphics memory)

Me and @Julot94 checked that possible index mistmatch was not a problem for cesium-unreal blueprint library's functions doing picking, as those are based on Unreal mesh face indices, which match glTF's, and obtain glTF vertex indices directly from there.

But all variants of GetFeatureIDForVertex as well as UCesiumFeatureIdAttributeBlueprintLibrary::GetFeatureID are blueprint-accessible, and it made us wonder whether this is really a good idea? Is there a way a user of these functions would be able to supply a glTF vertex index, and not merely an Unreal one, leading to "random" bugs?

So I see several possibilities:

• deprecate or remove these functions from blueprint accessibility, keeping only the equivalent code for their internal usage sites,
• declare that they take Unreal vertex indices as input, and support the vertex duplication case somehow
• or I may simply be wrong in assuming that these functions can take Unreal vertex indices, and there is nothing to do ^^

[j9liu]

Hi @GhisBntly! Actually, GetFeatureIDForVertex just passes the given index to an AccessorView under the hood, which is a view on the original glTF data. So the indices are relative to the original glTF model.

But I'm concerned now that it's not handling the vertex duplication case properly... so I'll make it a point to look at that and think about a proper solution 🤔 Thanks for raising this up with us!

[GhisBntly]

Thanks for the prompt reply, @j9liu !
Indeed I realized the indices are relative to the original glTF model, which is why I'm wondering how a blueprint could have any use for these methods, my assumption being that BP writers would only have access to Unreal vertices. But I may be wrong in thinking that, I have no idea what kind of use case these BP functions might cater to. Maybe there are BP getters that return glTF model vertex indices...

[j9liu]

Hi @GhisBntly,

To start from the beginning, our Blueprint API intends to help users easily enable metadata picking in their apps. Our idea is that an Unreal Hit -- the result of a raycast -- can be passed to a FCesiumPrimitiveFeatures to extract the feature ID from that Hit.

Previously, GetFeatureIDFromHit did not exist, and neither did GetPropertyTableValuesFromHit in the metadata side. Instead we had a FaceIndex parameter that would take the index of the mesh's face from the Unreal Hit.

cesium-unreal/Source/CesiumRuntime/Private/CesiumMetadataUtilityBlueprintLibrary.cpp

Lines 28 to 30 in ed38004

	UCesiumMetadataUtilityBlueprintLibrary::GetMetadataValuesForFace(
	const UPrimitiveComponent* component,
	int64 FaceIndex) {

FaceIndex was used in a way such that int index = 3 * FaceIndex; return featureIDs[index];. But I ultimately deprecated this because it was more useful to pass the entire Hit in, especially when it came to feature ID textures.

As I'm writing this... I am seeing your point that GetFeatureIDForVertex is less useful. I may have left it in there because I wanted to preserve some granular per-vertex access to feature IDs. But, we're not really using this anywhere in the code. Still, I'm hesitant to just remove the GetFeatureIDForVertex because it is unfortunately public API, even though I agree that it's not doing too much.

IMO, users shouldn't need to know the internals of the glTF mesh; they should just be able to interact with it from their perspective as Unreal developers. If the intention is to draw the feature ID information from a mesh in Unreal, then my thought is to reframe all of the "indices" as relative to the Unreal mesh. But I may feel differently after I think on it for a day! Either way, I'll look into this more deeply and see if that's the right call, especially if there's an easy way to map the Unreal vertex index back to the glTF one.