Maybe it appears on slower PCs only. For this test I was using and older laptop which isn’t that fast.
I’ll see if I can replicate it on the crappiest PC we have in our test lab.
Update: could not reproduce, even at 5 frames per second, the speed of particles is the same.
1 Like
What do you mean by “faster”? Do you mean the particles are moving faster or that they’re spawning at a higher rate?
It seems like they move faster the same way as when you up the particle’s speed. Here’s another example:
Studio:
Client:
https://i.gyazo.com/f00a3a36bee143cfc5f567e0d114eab3.gif
If you look at the bottom of the flame, you can see it pretty clearly. I know for a fact that @Partcline has the same issue.
Edit:
Here are my system specs:
Windows 10 Pro 64-bit
Intel Core i5-2500K CPU @ 3.30GHz
NVIDIA GeForce GTX 960
What you are seeing here is stroboscopic effect, an optical illusion, due to the fact, that the first image has much lower frame rate. It appears that the flame is “faster” because there are more abrupt changes in multiple particle dispositions on the first image.
Notice that on both images particles reach the same height, and the overall shape of the flame is the same.
2 Likes
I made a video which have all clips locked at 30 fps, so it should be a lot more clear what I mean. There are two examples of particles having different speeds in Studio and on the client. The clips without the character are from Studio.
Furthermore, we only recently started encountering this bug (14th of October). Up until now, particle speed in Studio and on the client have been the same.
2 Likes
I am still unconvinced. Here’s what I’d like to see: in the fire scene, set particle life to a single value (not a range), put a semi-transparent anchored part where particles disappear and try filming again, both in client and studio. We should see if particles cross the part or die short of it.
The particles die out at the exact same spot, both in client and studio:
But if you want to make a particle, having it run slower on the client would subtract from the originally planned feel for it. That’s the main issue. It’s an unreliable way to make particles, given the differences in studio and client.
1 Like
As you can see, if they die at the same spot, that means the speed is the same, so there’s no bug.
That’s the main issue. It’s an unreliable way to make particles, given the differences in studio and client.
Keep in mind that particles will look different regardless - at different quality levels, and different distance, depending on how well the game runs on the player’s hardware.
My suggestion - model your particles for the ideal case (level 10, 60 fps, which corresponds to level 21 in Studio), and let the system scale the quality/performance for every client individually.
But there is a bug, yes they die at the same spot but the speed is clearly faster in Studio than the client.
It’s not that they[quote=“maxvee, post:14, topic:29893”]
look different
[/quote]
it’s that they are clearly going faster and dying in the same spot in Studio than in the client.
–EDIT–
If you watch the last video Patrick posted, change the speed of the video to 0.25, then watch the particles in both client and studio, it makes it really obvious.
Why not make a particle that’s the same speed as the character and walk along side it to see
No, if they were 2x faster, they’d travel 2x further. Here we can see only a small discrepancy of maximum height, which is due to their lifetime being effectively quantized by the framerate.
I don’t know the programming behind it, I don’t know why it is doing what it is, but the speed of the particles are clearly different on studio and client, which apparently everyone but you can see. Be it because of framerate or whatever the reason is, it is still happening and is an annoyance to work with when you want to have particles go at a specific speed and they go slower than intended.
I think you’re confusing play speed and velocity (the Speed property). The velocity is correct, and that’s why they’re travelling the same distance. The play speed is incorrect though.
Think of it this way: I have two bricks that I’m throwing up in the air. I throw both up in the air at 10 m/s, but the second one experiences time twice as fast. They both have the same initial velocity/acceleration, so they will reach the same height, but since the second brick is experiencing 2x time, it will get to the target height in half the time of the first brick.
Ah, I know what that is. Go to Render Settings and turn off EagerBulkExecution.
And forget it ever existed. 
6 Likes
That solved it, but what does EagerBulkExecution do? And was it disabled by default up until last week? Because this has never happened to me previously.
2 Likes
It is a very specific mode of rendering only really used in the thumbnailer. It forces a few fixed-step updates in certain subsystems prior to taking a screenshot for the thumbnail. Particle systems perform a few sim steps so that you can see the particles on e.g. item thumbnails.
It’s only exposed because all the settings in the code are on the same list (part of our class reflection system), and we didn’t care enough to hide it.
You probably turned it on accidentally, thinking it might improve performance.
Don’t, it does the opposite.
2 Likes
No, neither @Partcline nor I ever messed with the rendering settings in Studio. He just messaged me after getting home one day, telling me that particles were suddenly a lot faster than what they used to be. I didn’t even know it existed.
Exit Studio, go to c:\Users\{you}\AppData\Local\Roblox and remove (temporarily move somewhere) all GlobalSettings*.xml files, then start Studio and open the settings dialog. It’ll have reset to False, which is the default value.
You can then set it to ‘on’ and repeat the above procedure to see it again correctly revert to the default.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.