Recently, I’ve been trying to find an alternative to Roblox’s Trail instance. For only one reason is it that I’m seeking an alternative, and it’s for the extremely short maximum LifeTime of a trail, at only 20 seconds.
Just today, I came across this post:
I’ve been able to craft something awfully similar. However, there is a problem. Whenever I press Run, (as opposed to play), the server perceives smooth and stable performance. However, when transitioning to the client it is incredibly laggy. While there may not be a solution to this, I’d surely like an explanation as to why this is the case.
I know. I knew right from when replicating what you made, that it was not made with performance in mind lol. And before you do suggest, I’ve tried doing it on the client independently, it’s real no different.
Well… I must make it clear, I am using these ‘custom’ made trails to cover extremely high distances, of 1,000 to 2,000 studs, however, at most at a time, I only have about 3,000 parts actively in the workspace.
And the code is basically the same, just instead of a Character being referenced, I’m referencing a Part.
Have you tried profiling the code to see what the issue is? It may be due to there being many beams, or many parts being created. Also are these parts following linear or preset trajectories because then there are other optimizations that can be made.
The parts travel in a very specific, consistent and elliptical orbit around a center object. There is a lot of math that is gone into the formations of their orbits, sense this is a Solar System model I’m working on, with it’s own adjustable scale for time, distance and size (just a bit more context). But that shouldn’t matter a whole lot. I could see what happens if I create the parts without the beams, that would eliminate parts being created as a problem if it solves the issue. but again, do remember, it’s lag that is only experienced on the client, but not the server? What’s the remote difference??
There are many reasons lag could be on the server/client, without knowing the your implementation its impossible to pinpoint why. Is the server calculating everything and then just sending the client positions for the markers?
The distance can get absurdly far, replicating 50,000 Miles in a single stud. 20 seconds isn’t long enough to be able to acknowledge the entire trail of an object that COULD also be moving in real time at a scale this big.
I suggest you use the micro profiler to find out what exactly is causing the lag, and then go from there. With the limited information I have I cant help much. Its probably due to the scale of everything or an issue in your implementation but I have no way of actually knowing.
Considering everything is practically the same as you left it, other than what part is referenced, I’d imagine it could be the scale of things and what not. I will use the micro profiler, and see what I discover, and leave updates here maybe.
I’m open to new comments, suggestions, ideas and solutions to this issue still though.
I think using EditableMeshes as beams could be an option. I have not used them myself so I am unsure of their performance but they are dynamic and probably more performant than my previous implementation.
Sorry for the delay, you can use them instead of the parts and the beam. It allows you to use one instance for the entire trail. In addition to that, algorithms that simplify and optimize mesh geometry are super easy to find and very performant.