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.
You can see it affecting BrickColor and Material changes in the first gif also.
1 Like
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?
He mentioned in the discord that he animates it locally
1 Like
The guns I made for Innovation Inc that also suffered this were 100% local too. I can confirm it is not a networking issue.
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.
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.
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?
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.
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.
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
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?
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.
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.
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.
There are no property changes of the sort being run on RenderStepped, only at most a couple CFrame operations.
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
Oh, so that’s why 4Tress had crazy lag impulses
Good to know
My vehicle lights must be to blame for this, as it tends to get worse when you have a lot of people crammed together in a chaotic manner. Glad to hear this system is getting redone though.