Part property changes not always rendering

Bug Reports Engine Bugs
#1

When servers in my game get busy, I’ve found that the clients stop updating certain property changes for seemingly no reason. Observe below:

https://i.gyazo.com/e67328b11d2e860ba822b4bb32c495c1.gif

When I walk through the door, the server detects the touched event and uses FireAllClients on a RemoteEvent, passing along data specifying which door needs to be changed, and how it needs to be changed. The server sets the CanCollide property of the door itself. The clients then proceed to alter the color and material of the panel you see to the right of the door, toggle which PointLights in the panel are enabled, and set the transparency of the door. However, as you can see from the gif, the client fails to set the transparency of the door and change the color / material of the panel.

1145×516 41.1 KB

As evidenced above, all three actions are being successfully called by the client as I can always see the PointLights changing, and this only occurs when there’s a flurry of activity nearby. Sometimes it works perfectly and changes the appearances instantly, sometimes it takes several seconds for the rendering changes to go through, and sometimes it just doesn’t render the changes at all.

Originally, I had it set up so the server did everything on its own. It detected the Touched events, then set the appearance of the door and panel. I figured that having the server doing all this was the issue and made the client do it instead, but it ended up making no difference.

I’m at a loss for what to do now, as it seems I can’t reliably change the appearance of these doors. This has been occurring for as long as I can remember, I’m only just reporting it now because I’ve exhausted the only solution to this issue I thought possible.

In the game I linked, this issue is very prevalent on the doors on all the homes. (The gif above was recorded in a prototype jail and isn’t in the linked game yet.)

EDIT: For reference, here’s what the doors above SHOULD be doing.
https://i.gyazo.com/c009537fbc00f5c84fbb567aaffc2a4d.gif

1 Like
#2

I had the same issues with the guns in both the Innovation Inc labs and the Innovation Inc Uranium Refinery. I think this bug is only for Transparency changes, which may be a rendering bug.

#3

You can see it affecting BrickColor and Material changes in the first gif also.

1 Like
#4

What do you usually see for NetworkReceive and Render (found under Ctrl+Shift+F4 panel) in your game? Can you post a screenshot of that panel?

#5

He mentioned in the discord that he animates it locally

1 Like
#6

Normal:

467×551 171 KB

Occurs irregularly:

449×547 272 KB

#7

The guns I made for Innovation Inc that also suffered this were 100% local too. I can confirm it is not a networking issue.

#8

Can you post a screenshot of the Ctrl+Shift+F2 panel? It has something at the bottom called clusters and IIRC that’s what ROBLOX uses to update visuals of parts/etc. Seeing as your network/GPU aren’t being bottlenecked, it may have something to do with the clusters.

#9

562×672 621 KB

I’m also noticing that this issues seems to plague the bullet trail effects that I just put together, as well as stock local transparency tweening of your character as you zoom in really tight.

#10

I took a look at a bunch of other games on the front page and noticed their numbers for clusters were nowhere as high as yours. I don’t understand clusters enough to make any definite claims (maybe @zeuxcg can chime in here), but your values are 10-100 times higher than other games, so I imagine that isn’t a good thing. Do you:

  • Instantiate parts, immediately set their parent, and then set their default properties right after?
  • Change properties (excluding CFrame) of a large number of parts, continually, on Heartbeat/RenderStepped?
  • Animate welds instead of Motor6Ds?
#11

I only render fire hoses on RenderStepped, and there’s usually never more than 2 of those going at a time.

I use welds to attach all the parts of the vehicles together if this is what you mean. Other than that, nothing’s being animated.

#12

I’m not sure what the issue could be then. You’ll probably need an engineer to check out your level, unless someone else has overcome an experience like this and has other ideas for what the problem could be.

#13

I’ll be mostly saying what’s already been said, but I’m posting it on the off-chance that it’ll help you. Issues like these are frustrating and very time consuming, so any hint as to the cause can be a great help.

Are you sure you are not using welds for any animation? Despite however sure you might be, you might want to check using game.ItemChanged (or use one I wrote here).

I once debugged an issue like this where one single Weld updating on every render step limited cluster updates and caused parts to not disappear or reappear as often as they should. One thing to note is that this seems to happen more easily with Unions. I have no idea if that extends to MeshParts, Parts with meshes in them, or why it affected Unions more. The performance of cluster updates was not the same among multiple computers: some updated slowly for one reason, some updated slowly for a separate reason.

Here are some posts about cluster updates you can read through. Maybe they’ll help. Here is a post where I talked about my experience with this previously.

Also good to know: Shift + F6 turns on the profiler, which might help you find out the cause of the problem.

1 Like
#14

The only thing I’m using welds for is keeping the vehicles in one or two pieces, depending on if it has a trailer. The trailers just use a regular hinge surface. I ran your ItemChanged code and the list topper ended up just being light toggling in the traffic signals stationed throughout the map, and removing them didn’t seem to make a difference. Could it really be the welds holding the cars together, even if none of the properties of the welds are changing?

#15

I doubt it would cause that if the welds are not being updated at all. If you have no other options then you might as well change them to Motor6Ds just to see if there’s any effect. But again, I highly doubt it. These are really hard bugs to fix since we get little-to-no information on what’s going on internally.

#16

It seemed to make vehicle rendering a bit smoother, but didn’t have an effect on the cluster rendering latency. Thanks for the help though, you’ve given me an idea for a workaround.

#17

See if your changing a part’s Transparency on render step. I ran into all kinds of rendering bugs when I was doing that. As soon as I unbound the function, though, everything rendered just fine.

Check all the places you’re editing a property of a part on render step.

#18

There are no property changes of the sort being run on RenderStepped, only at most a couple CFrame operations.

#19

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.

You can tell if this is happening by looking at the “queue” number in “Geometry Gen” row of Ctrl+Shift+F2 panel. If, when the problem occurs, the number is constantly non-zero and stays this way, your game is subject to this issue.

We are currently reworking this system pretty much entirely so these kinds of issues will go away in the future.

If you know which parts you’re updating very frequently - basically this “heavy update” triggers whenever there’s a part or decal property change that is not Part.CFrame (this also happens if you reconfigure joints every frame by changing C0/C1 or removing/readding joints, but does not happen for Motor C0/C1 changes IIRC) - you can try to avoid doing this update as a short-term fix. I’d be curious as to whether there’s something unexpected that does this - last time this happened this was due to Motor CFrames unnecessarily triggering the update in Phantom Forces, which was fixed, so maybe there’s a reasonably simple fix here as well…

6 Likes
Filtering enabled objects on the client "stalls" rendering, but not due to fps
#20

Oh, so that’s why 4Tress had crazy lag impulses

Good to know