Filtering enabled objects on the client "stalls" rendering, but not due to fps

[rater193]

Filtering enabled: yes
Place that this is happening: True RTS 0.1.2 (BETA) - Roblox
Screenshot to show whats happening: External Media

Whats happening?
When i goto have a few things being handled on the client with rendering, the scripts controling their animation still execute, however the graphics “stalls” (not due to fps, due to some other rendering bug)

Reproduce-able: yes, 100%
Steps to reproduce:
I gave a link to my place above
create a new game from the match maker lobby
use wasd Q-E to move around
spam right click until you start seeing the bug.

When did this start happening?
I just came back to roblox recently, after taking a break from it for about a year, and this has been happening ever since i came back.

[unix_system]

Try disabling FE. Does the issue persist?

[rater193]

just tried, yes it does
oh wow, it can happen to non fe games as well.
i make it a habit to use fe, so i figured i should post that i was using it, just incase it was the problem.

[unix_system]

Yeah seems like a game specific issue

Try using the microprofiler to identify the issue

[rater193]

Didnt really notice anything out of place.

[rater193]

that spike btw, was because i paused it then resumed it.

[rater193]

found 1 possible cause. The issue gets worse, the faster you update objects on the client. I changed it from using render stepped, to using while wait(1/20) and it got “better” but still had the issue. it just wasnt as bad.

[buildthomas]

There is a limit to how fast you can update geometry before the engine gives up and postpones/skips updates AFAIK.

[rater193]

ah, ouch, that sucks

[buildthomas]

Here’s a post about it from an engineer:

Part property changes not always rendering - #19 by zeuxcg

@zeuxcg

You may be running into update queueing. I think I’ve described it once before on these forums because somebody else had this issue, but basically if you have a constant stream of updates to part properties that require rebuilding rendering data, then due to how update throttling is implemented a few clusters (groups of parts) can basically hog the entire update budget, and if they change all the time this would mean other parts are permanently starved.

[rater193]

thanks

[rater193]

ill just make 1 model that gets created at the mouse position, and when u rightclick it just deletes the old model, and creates a new one, so this issue doesnt persist. Thanks again for the help.

[buildthomas]

@rater193

ill just make 1 model that gets created at the mouse position, and when u rightclick it just deletes the old model, and creates a new one, so this issue doesnt persist

That actually also sounds great for game play (you don’t want people confused by 100 indicators when only the most recent click matters), so two problems solved in one

[rater193]

yup, it fixed it, thanks again!

[Sharksie]

Roblox internally prioritizes geometry updates based on proximity to your character. With no character it doesn’t work right.

The way I solved this in tiny tanks is by making a character (two blocks) and constantly CFraming it to the focus point.

Also, make sure your focus point is set properly or lights aren’t going to work either.

[rater193]

good to know

[zeuxcg]

I believe there should never be a need to CFrame a character around - all our internal logic is driven by the Camera.Focus as far as I remember.

Also, we do have distance-based prioritization for updating geometry due to new assets coming in, but we don’t really prioritize property-based geometry updates in the same way.

[rater193]

sry for the late reply, took a bit of a break from roblox, working in unity3d now, lol. That game had no use for the roblox character, it was a generic rts proof of concept. Also, the cframe was applying to the pointer when you rightclick, that was what i was having issues with
thx for the reply