When is Zwift going to remove the 100-rider nearby rendering limit, at least for races? Participating in races with more than 100 people is becoming increasingly frustrating. Riders that attack off the front suddenly vanish on the game screen, on the rider list, on the mini map, on the companion app map, and on the companion app rider list once they are not one of the 100 riders nearest to you. The peloton is then left blind to how many riders are up the road, how big the gap is, how hard they are riding, etc. This is exactly what happened in race 4 of the L39gion crit series. The BL13 team coordinated an attack off the front and since the pack was much larger than 100 riders they vanished from everyoneâs view once they got a few seconds up the road. Combine that with the Zwift washing machine effect and no one was none the wiser to the group up the road.
Also, Iâm not sure what Zwift actually calls this. Is it a feature or a bug? If it is a bug is it against the rules to exploit it to oneâs advantage? The last time a bug was discovered, the pairing screen bug, users who exploited it were threatened with punishment.
The limit is in place to account for lower end devices that struggle to render so many assets at once. Any decent dedicated GPU should cope with higher numbers easily, but the low end is currently catered for with the same principle for everyone. It would be good to see the number of riders shown be based on the graphics profile, scaling up from 100 on Basic profile (integrated graphics, Apple TV, tablets/phones etc) to higher numbers on more capable systems. Testing would be required to determine the appropriate levels, but almost everyone has spare GPU capacity in group events because the pipeline is CPU limited anyway.
100 % agree on this needing to be adjusted. With riders disappearing as soon as they are 2 seconds off the front and not even visible on the map, the only way to find out if anyone is in a break in zp live, and with updates every 30 seconds thats not always precise
I was under the impression (from you and the zpcmr fb group) that in busy scenarios, such as large group events, performance tends to be bound by cpu rather than gpu. Also Zwift only uses a single thread so that it really doesnât take advantage of modern multi core cpus much at all.
Whilst I certainly donât disagree that a decent gpu should be able to render more riders Iâm wondering if it is the other processing that is slowing the system down and the fact that Zwift doesnât take advantage of multiple cores that even on newer systems the current code still couldnât handle the display of larger rider numbers.
In groups and busy areas the game is CPU bound, yes. The bottleneck is processing all the positions of nearby riders including those you canât see, which is on the CPU (hence why the frame rates donât drop as far with a faster/stronger CPU). The GPU becomes starved because itâs left waiting for instructions, so the frame rate drops. Since GPU utilisation is already low in this situation, rendering more âstuffâ (in this case, rider avatars) should be possible. Itâs just the same as going up in resolution. It wouldnât affect the frame rate because thatâs still limited by how fast the CPU can provide the position data - unless you got to 100% GPU load of course.
Yikes; I was going to say that I was one of these lower-end Zwifters, as I Zwift with an old boat anchor of a laptop, and even I would support doing something about this, because this is def a problem. I would just⌠make do, I guess.
But then, if Zwift is only single-threadedâŚgreat scott, yâall.