Rendering performance has degraded in v5

[NicEastvillage]

Noticed by both me and Scumclass (Discord help thread).

In v4, Beast and Noob Block were performing fine with rendering enabled (100% of packets answered). In v5, Beast is at 3% of packets answered with rendering enabled even though it is the same number of rendering calls (Note: It is also slow then rendering is disabled for the match). Since it worked in v4, the issue is not simply "Python slow".

We have not converted any medium+ sized bots in other languages to v5, so we cannot exclude that the problem may be in core.

Beast in v4: https://github.com/NicEastvillage/RLBot-Beast/tree/RLBotV4
Beast in v5: https://github.com/NicEastvillage/RLBot-Beast/tree/RLBotV5Convert

[VirxEC]

I'm unable to replicate this issue. I think it's been solved in recent patches, after the help thread was made.

[VirxEC]

Hopefully this issue has been at least slightly improved on low-performance systems by 0f282de

[VirxEC]

I have a feeling that this issue was related to the ball path problem a while ago. Since beast renders the ball path, this might explain it. This would also mean that the issue has been solved. Results from cProfile show draw_ball_path still taking up some time, but optimizing around items like vec.py would be better as it takes up significantly more time. draw_ball_path is also quite inefficiently written, something like this is more efficient to generate the list locations:

max_slice = int(math.ceil(duration * 120))
locations = [s.physics.location for s in pred.slices[0:max_slice:step_size]]

[NicEastvillage]

Can confirm that 0f282de fixed the issue. My Vec3 is inheriting the Vector3 from https://github.com/VirxEC/rlbot_flatbuffers_py. Maybe we can investigate optimization for Vector3 such that they benefit everyone.