Fixed clip planes lagging behind when parented to a bone on a model part

[TW1STaL1CKY]

Resolves last reported problem on issue #1341

[thegrb93]

I really hope this doesn't invoke setupBones for every clip

[CapsAdmin]

Just a heads up, I've tried this approach before, and while it seemed to work at first it wasn't exactly a drop in replacement for GetBonePosition. I'm not saying your solution doesn't work. Maybe this solution works now given how things have changed.

[TW1STaL1CKY]

I really hope this doesn't invoke setupBones for every clip

If you mean for the scenario where there's multiple clip parts on one model, you're right and I've now prevented that from happening, since it only needs to be called once.

If you mean for every clip part in general, yes (except for the above scenario now) unfortunately, however the way I see it from briefly benchmarking it, it's faster to just call pac.SetupBones, rather than checking whether the problem is occurring first (requires pac.GetModelBones) then calling pac.SetupBones.

[thegrb93]

I still don't like calling SetupBones from a part. It should be done via whatever hook is drawing the parts. Quick hacks like this are what made pac3 so unmaintainable in the first place. If that's not feasible and this does solve the issue then I'd be ok with merging, but bleh.

[thegrb93]

I guess the problem is bone parts manipulate the bone and then the clip doesn't have the updated info from the manipulation, which would make my suggestion not feasible. In that case, I'd guess manipulations need to be ordered first in the render stages, then SetupBones, then rendering, but with how pac3 was designed that probably isn't possible. Anyway, you can merge probably.

[thegrb93]

That said- the bug will still occur if a clip is rendered, and then another bone is manipulated and another clip is rendered.