In blueprint format I am doing a LineTraceByChannel and casting to my custom Foliage Component then getting the Foliage Instance Index from the Hit Result. This works flawlessly until I add a large amount of foliage. The foliage components with lower instance counts work perfectly fine, but 2 components sometimes return “incorrect” or sometimes even “invalid” Instance Indexes (negative numbers). The two “broken” foliage components contain 128k and 41.4k instances respectively. Is there a hardcoded max instance count limit for when dealing with hit results?
I’m assuming I can work around this by using multiple levels on my map via the world composition tool and multiple imported landscapes which is something I plan on doing anyways. The upper limit / max instance count (if there is one) would be nice to know though.
For clarification, the foliage “visually” works fine and all 128k / 41.4k instances are visible, but the hit result’s instance index is sometimes incorrect.
Also just to make sure the culprit was not my custom foliage component, I switched the foliage component type back to the default component type and the same instances still return the same incorrect / invalid instance indexes.
This sounds like it could be a precision issue, as having that many foliage instances and running line traces to return a hit when you have a large number of what is more than likely overlapping instances.
I do not know of any hard coded instance mesh value limit for returning accurate hit results, as that doesn’t seem like something we would randomly cap. If you could provide me with a test case so I can reproduce the issue on my end, that would be appreciated. Also, what channel are you tracing from? i.e visibility, collision, etc?
I sent you PM (on the forums) with a link to my project and some more specific info to help you figure out a cause. Also here’s a Youtube link that better shows the problem as well. UE4 Invalid Foliage Instance IDs - YouTube
Just to quickly add to this, I’m wondering if somewhere along the line the “item hit” (instance index) get’s casted or assigned to a signed 16 bit integer (-32768 to +32767).
This could account for why things are acting the way they are … due to the rollover effect of assigning larger ints to smaller ints. The two foliage types that I’m having the issue with both have more than 32.7k instances. This would explain why sometimes the index returned is sometimes negative, and could explain why it’s sometimes positive even though it’s referring to the wrong instance.
Thanks for that extra bit of information. As I mentioned in my PM on the Forums your test might take some time to verify as an issue, and I would need to share your project internally if we cannot reduce the test case down further. Either way, I will return once I have completed my tests.
I have the same issue. After some debugging found the issue in engine source:
in BodyInstance.h
/** Container for a physics representation of an object */
USTRUCT()
struct ENGINE_API FBodyInstance
{
GENERATED_USTRUCT_BODY()
/**
* Index of this BodyInstance within the SkeletalMeshComponent/PhysicsAsset.
* Is INDEX_NONE if a single body component
*/
int16 InstanceBodyIndex;
Changing InstanceBodyIndex type to int32 and rebuilding engine fixed the problem and, it seems, didn’t introduce any other problems. Would be nice to be able to use foliage meshes with large amount of instances without custom built engine though.
Just noticed your comment. Thanks for confirming that my suspicion was more or less correct and for providing the fix as well. I’ll check it out tomorrow when I get a moment and do a quick run through my buggy level just to make sure
Hi Andrew, have you ever completed your tests regarding this issue? I also seem to have this issue… Does not seem logical to use int16, especially for larger maps, 32k instances is really not many.
Anyhow, I was just curious if this was ever looked at.
