weixin_39818691
2020-12-09 02:41 阅读 0

support for composed collider

I use GetComponentInParent so composed collider will work with colliders in child GameObjects.

该提问来源于开源项目:JScott/ViveGrip

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

5条回答 默认 最新

  • weixin_40002336 weixin_40002336 2020-12-09 02:41

    First, awesome and thank you. I hadn't thought of this but it seems like a great addition.

    Second, would it make sense to only check the immediate parents? This code is ultimately getting called in Update of each Grip Point and scaling up the hierarchy from every Collider it touches. That's a lot of pointless traversal for objects that have Colliders but aren't grabbable. It's probably not as bad as checking children but it's noteworthy.

    Is your use case is the same as described in the Compound Colliders section from the Rigidbody docs? After the merge I'd also like to add a small example in the demo scene.

    点赞 评论 复制链接分享
  • weixin_40002336 weixin_40002336 2020-12-09 02:41

    Thinking about performance without sacrificing parent depth, what do you think about caching the results in a Dictionary<Collider,ViveGrip_Grabbable> on the Touch Detection? That would assume that the Grabbable scripts won't shift around too much, which seems reasonable in this context, and removes the cost of doing GetComponentInParent over and over.

    点赞 评论 复制链接分享
  • weixin_39818691 weixin_39818691 2020-12-09 02:41

    My example are simple juggling clubs using 2 capsule and 1 sphere collider (for juggling with low gravity). I can add it to the examples/prefabs folder if you like. I haven't noticed a performance impact, maybe because in my scene are only a few objects and all with a Grip Point directly in the parent. So checking the immediate parents would have been sufficient in my case. For the more general solution using getComponentInParent, the caching idea sounds good whenever it becomes a performance bottleneck. This might trigger the need for cache invalidation when an object structure is changing (like spitting). I am new to unity and can't tell whether this is already over optimization.

    点赞 评论 复制链接分享
  • weixin_40002336 weixin_40002336 2020-12-09 02:41

    I think that just looking at the current object and then its parent keeps things simple and working. More than performance, I also won't have to worry about accidentally picking up unwanted Grabbables down the chain. The Unity docs suggest doing a simple direct parentage as well. Do you want to make that change or should I? (Edit: nvm, already working on it)

    You're right that worrying much about performance is probably premature optimization on my part. I just wanted to do the due diligence of exploring it a bit. Going down the path of caching makes things way more complex than what anyone needs right now.

    I'll take a look at the changes for a quick sanity test when I get a chance to sit down with my Vive. It'll probably be easier for me to add the example and documentation myself. With that one change it should be good to merge though.

    点赞 评论 复制链接分享
  • weixin_40002336 weixin_40002336 2020-12-09 02:41

    I think I would have needed to commit to your repo to add my own changes in this PR so I pulled your commits into a branch and made #16. Let me know what you think :) If it's good to go then I'll merge there and close this.

    点赞 评论 复制链接分享

相关推荐