我们在项目中启用了 UE5.6 的 FastGeoStreaming 插件，
但发现被转换出来的 FastGeoComponent 无法被 UWorld::LineTraceSingleByChannel 这种碰撞检测接口探测到，
调试后发现碰撞检测探测到的FastGeo相关Component与Actor的信息是存在 IPhysicsBodyInstanceOwner中的，但碰撞检测的返回结构体 FHitResult 并没有将这个信息返回。
而 FastGeoComponent 不是继承自 UPrimitiveComponent， FastGeoContainer 也并不是继承自 AActor，
无法简单的将这个碰撞结果统一到 HitResult中现有的 HitObjectHandle 与 Component返回，需要新增字段，
判断命中Component后的逻辑也得考虑上 FastGeoComponent，改动量不小。
对于启用FastGeoStreaming插件后碰撞检测的这个问题，请问官方有什么建议？
重现步骤
启用FastGeoStreaming合并场景静态物体。
使用下面代码进行碰撞检测
FHitResult HitResult;
FCollisionQueryParams CollisionParams;
bool bHit = GetWorld()->LineTraceSingleByChannel(
HitResult,
TraceStart,
TraceEnd,
ECC_Visibility,
CollisionParams
);
HitResult.GetComponent() 与 HitResult.GetActor() 都是nullptr。
[mention removed] Hello, we are facing the same problem and would like to begin implementing our own logic to ensure FastGeo functions properly. Could you please at least provide an idea of how you are going to implement this feature so our version of realization won’t be much different?
我们也有一样的问题，在转换为FastGeo以后，射线检测逻辑里面写了东西导致检测不到geo处理过的component了。对于动作游戏和射击游戏来说，几乎需要全场景都支持射线检测，射击到的物体需要有物理反馈，播放对应的粒子效果之类的，但Geo转换以后，都失效了。
接口之类的，感觉上面提的都差不多了。upri到处都在用，其他的可能就是新的mover组件如果有对应的接口也要支持下吧，虽然还没开始用新的运动组件。
And one more question. I see that inside IPhysicsBodyInstanceOwner. GetPhysicsBodyInstandeOwnerFromHitResult: we call this function UFastGeoContainer::ResolvePhysicsBodyInstanceOwner, and it makes a read lock on PhysicsObject. Does it mean that I can’t simply cache the returned IPhysicsBodyInstanceOwner pointer and have to access it using “resolver” each time I need it?
Same problem and seeking a solution.
Hi,
你好，的确有不止一家客户反馈这个问题，我已经把需求转达给开发的同学了，等他有进一步信息后，我会再这里更新。
好的，静候佳音
Hi, 关于物理query FastGeoComponent，开发的同事想了解，除了想从原来的PrimitiveComponent访问引擎的现成接口（GetPhysicalMaterial, GetCollisionResponseToChannel之类的)，是否还发现其他接口缺失？是否有明确的列表？
目前我们发现FastGeo没支持到的接口有：
主要是角色运动检测地面位置相关逻辑这块，其他就暂时没注意到了
请问前面两个MovementBase的Component，是想通过HitResult返回的Component，找到其Actor，然后再通过Actor来找吗？
I’m collecting the issues and will send all requests to our engineers. They would like to know what the APIs they need to implement.
我没get到这句话的意思，
前两个struct是UE里原生的角色运动检测相关的struct，
业务那边需要根据这个判断角色所在地面Component，
如果转成FastGeo，这个Component就是nullptr了，
至于这两struct里Component是怎么赋值的，就不清楚了，没细看过这一块
It can take a lot of time, but for now we simply can’t use this plugin, but we want to get all the benefits from 5.6 and turn on the FastGeo as early as possible. That’s why I’m asking about the way your engineers are going to do this — just to be on the same track because I want to do it on my own.
Sorry, but what do you mean by “Geo conversion”? Have you implemented some conversion sy by your ownstem?
We haven’t implemented any new system. We just mentioned that when using FastGeo, we encountered an issue where line tracing stopped working after the conversion to FastGeo.
Hi all,
The owner of FastGeo would like to know what exactly you need, so he could try to make changes to support them.
The thing is :
You could use IPhysicsBodyInstanceOwner.GetPhysicsBodyInstandeOwnerFromHitResult to get the IPhysicsBodyInstanceOwner with the HitResult, then you could get the associated physics information (GetPhysicalMaterial, GetCollisionResponseToChannel) from it.
What else do you need? The original Actor (if it didn’t get deleted)?
Please list the requirements( better with examples), and he will consider how to achieve the goals.
We could do it by ourselves easily. The reason we are stuck is related to the native engine features that are not supported . We mentioned them earlier. Perhaps the feature owner could review this thread personally?
For example this members are alsways nullptr:
struct FBasedMovementInfo: TObjectPtr<UPrimitiveComponent> MovementBase
struct FRelativeBaseInfo: TWeakObjectPtr<UPrimitiveComponent> MovementBase
Have you ever tried to use this plugin with one of your own games and make characters move along FastGeo static meshes?
Yes, he had read all the threads.
I think the MovementBase is null because it was a static mesh component and has been transformed into a FastGeo Component.
It indeed isn’t compatible with Character Movement logic, we need to think about it further.
I’m not sure why you need to cache the pointer, as it could be different for each HitResult. But it’s the same HitResult, I think the pointer should be the same.