Instance feature metadata #1537
Conversation
I thought this was the source of a bug. Not sure about this now, but it seems good to be explicit about what we mean for the move.
This is needed because UCesiumFeatureIdSetBlueprintLibrary::GetAsFeatureIDAttribute() returns an error for instance attributes. I guess that's reasonable behavior.
There was a problem hiding this comment.
@timoore I tried this out with the instanced version of everybody's favorite model, and it works well. In fact, the existing Metadata level in the Samples can now query instanced models without any changes, which is nice!
However, I also found that that commonality with non-instanced metadata pretty much ends there. As soon as you want to use any of the lower-level, more powerful metadata access Blueprint APIs, we're stick with completely different paths for instanced and non-instanced models.
Now there are certainly details here that I don't understand, but I'm reasonably sure that this doesn't need to be so. For example, Get Feature ID From Hit looks to me like a concept that works (and is identical) across all types of models. So why do we now have two functions to do this? (confusingly, they have the same name, too)
Well, the immediate reason is that one needs "Primitive Features" and the other needs "Instance Features". But why are those separate? Both are just containers for sets of feature IDs that are resolved in different ways:
- By face -> vertex -> feature ID attribute lookup
- By texture coordinate -> feature ID texture lookup
- And now! By instance ID -> feature ID lookup
In fact, it seems reasonable that a single "hit" could return feature IDs from all three. There could be metadata attached to the instance, the vertex, and the texture.
What do you think, is that achievable?
So that's my main feedback on this PR. I also have some additional small comments below, based on only a partial review of the code so far.
|
|
||
| LoadPrimitiveResult() {} | ||
|
|
||
| LoadPrimitiveResult(LoadPrimitiveResult&& other) |
There was a problem hiding this comment.
Can't this just be LoadPrimitiveResult(LoadPrimitiveResult&& other) = default; ?
There was a problem hiding this comment.
I did this myself when I merged in main, because I was too lazy to manually update the move constructor for the incoming modifications. But let me know if there's some reason this was a bad idea.
| * default (because of the TUniquePtr usage). Of course we really want to use | ||
| * move constructors with all these unique pointers. So, we explicitly write the | ||
| * move constructors and delete the copy constructor, in part to document what | ||
| * should happen. |
There was a problem hiding this comment.
I don't think you need to recount the history here. A comment saying "This type is move-only" (above the deleted copy constructor/assignment and defaulted move constructor/assignment) is sufficient.
| const TSharedPtr<FCesiumInstanceFeatures> pInstanceFeatures = | ||
| pInstancedComponent->pInstanceFeatures; | ||
| if (!pInstanceFeatures) { | ||
| return TMap<FString, FCesiumMetadataValue>(); | ||
| } |
There was a problem hiding this comment.
This check looks unnecessary. And also redundant because GetInstanceFeatures does the same thing.
|
I haven't looked deeply at this PR, but with the way that I also don't see something that disallows I feel like it makes more sense if we use "Instance ID" for |
|
Hm now that I think about it, "Instance ID" is not an accurate descriptor / is confusing for cases where you're assigning multiple instances the same feature ID. So maybe we have to use terminology like "Instance Feature ID" vs. "Mesh Feature ID" ? |
Support for accessing metadata in GPU instances in picking hit results.