Event that fires when rendering finishes

Feature Requests Engine Features
#1

I’m running a simulation in studio. I’m changing colors of hundreds of parts very quickly. They stop updating. I want to wait until it renders before I continue making more changes. New changes get rendered before old changes, so most of it just never updates at all. I want an event that fires when rendering has finished, as in, everything has updated, and everything appears as it exists. There is currently no way to tell.

example: gridfractal.rbxl (11.9 KB)
press run and set the value of the IntValue Rate inside the script to some big number like 100,000. You will see that most of it stops rendering.

3 Likes
CharacterAppearanceLoaded not Waiting for the Player Model to Render
#2

http://wiki.roblox.com/index.php?title=API:Class/RunService/RenderStepped

This event fires when ALL of the rendering finishes.

#3

The example uses RenderStepped:Wait()

#4

You probably don’t quite understand what “rendering” is, but regardless, the answer is “no”, because rolling out such an API would introduce a dependency of your game code on certain implementation details of the 3D engine (geometry generator, clustering, etc.). If we decide to e.g. change the latter, it would break your game.

2 Likes
#5

So how can I make sure that what I see is correct before I make another change? If I make another change before what I see is correct then the newer change is prioritized, and if I keep making changes, the oldest changes never appear at all.

#6

Reduce the frequency of changes depending on the distance from the camera. Try to keep it under 1000 total individual changes a minute.

#7

Maybe this should just be in bug reports. It’s not updating colors and I’m changing colors, and there’s no lag. It just isn’t updating what to show.

#8

Could you do this with a surfacegui instead?

1 Like
#9

It’s not a bug, you are simply submitting more work than the clustering system is able to process. The “there’s no lag” part is because the clustering system is working as intended on a tight time budget. Realtime is real.

Moving and resizing small parts causes geometry to lag
#10

It’s sort of a bug in that we don’t prioritize updates correctly right now so you can permanently starve portions of the map by doing per-frame updates to other portions.

New clustering system would change everything sufficiently that I don’t think we’ll be focusing on fixing this though.

1 Like
#11

Instead of setting part.BrickColor, try pooling the parts and CFrame them so they switch places when needed. This should result in less expensive part updates

1 Like
#12

I replaced the part system with just a gui with a ton of frames. I’m noticing creating new frames is super slow and just changing their color is fast.

#13

You’re still doing a geometry update when you CFrame something. CFraming anchored parts may even be more expensive.

#14

Setting .CFrame doesn’t get throttled like BrickColor, Transparency, Size, and other properties do

2 Likes
#15

It does still get throttled though.

#16

New parts being created also don’t show up, it isn’t just changing color that lags behind.

#17

CFraming different size parts extremely fast instead of setting mesh.Scale proved to be much more efficient for my game’s rain system:

https://devforum.roblox.com/uploads/default/original/3X/1/e/1e0cdebad1bfe5eb144a19bc5ce95d01a8d2f39d.gif
I’m pretty sure properties like BrickColor, Material, Transparency, Size, mesh.Scale, mesh.Offset have problems updating, while CFrame is the fastest

4 Likes
#18

Ah yes, changing the CFrame causes the clustering system to use dynamic clusters for moving parts, which have far less capacity… So if you try to force updates by wiggling the parts, that will also proportionally increase the number of draw calls, and no, it won’t solve the geometry generator throughput problem.

Moving and resizing small parts causes geometry to lag
#19

That’s correct - CFrame currently is the only “fast” property in that you can change it every frame without really heavy code kicking in. Everything else is expensive.

We’re working on a new system that would make most properties cheap to update. But for now you’ll have to live with the limitations of the existing system.

20 Likes
Moving and resizing small parts causes geometry to lag
PartCache, for all your quick part-creation needs
List of Part Property Costs, by Frame Time
PartCache, for all your quick part-creation needs
My game decides to implode with bugs if I use a fps unlocker
List of Part Property Costs, by Frame Time
In-Depth Information about Roblox's RemoteEvents, Instance Replication, and Physics Replication (w/ sources!)
CFrame VS .Positon
#20

Sorry for bumping this old thread, but is this still the case?

I’m making a chunk terrain system using triangles. I will be using PartCache so that I can reuse triangles from an old chunk, but I will still need to resize the parts. How costly to the performance is resizing a lot of parts at once?

10 Likes