I’ve been working on my projectile system made from scratch and this seems to be one of the most difficult problems i can’t solve but yet seems to have a simple and easy solution and idk.
in my system i set it so that the trajectory of the projectile updates every 1/30th of a second, so essentially its making 30 calculations every second. you don’t need to do more than this because its inefficient and will cause lag.
so given this information, im creating 30 dots per second that are connected by raycasts in the trajectory. heres a visualization :
Now if i try adding a trail that positions itself on the next created point in the step it would look like they are running at 30fps since the trajectory is updating every 30 seconds which looks kinda laggy for users running at 60fps or higher which is mostly everyone:
Now, how do i make smooth bullet trail that follows my trajectory made at 30hz? Like this game:
Their tracers look so good and smooth and ontop of that at the end of the trail it turns into a ball like shape after a certain distance and glows and shrinks over time. I want to do this how do i do this with my current projectile system??? im lost i just can’t do it idk how. and phantom forces does this good too. how?
And you have mentioned that it updates every 1/30 of a second, Thats what a wait()
does, Am I safe to assume that you are using wait() to update the part, If so. That would not be considered good practice, What I would do is use RunService, specifically RunService.RenderStepped.
I’m not using wait(), i use tick() and create a step every 1/30th of a second, and then renderstep checks to run the step, if it fails to do so in time, another step will have been created thus, meaning i missed 2 steps, if i can catch it in time it will iterate through 2 steps in 1 frame.
I think a misconception you have here is that running 60 calculations per frame is expensive, although the amount of calculations is important what more important is the actual computation cost of the calculation itself. Assuming you’re using cframe to move this projectile all a cframe is is just moving a point along in space, this is very cost inexpensive so running this type of calculation 60 times per frame is not a problem at all, it’s not smooth specifically because you’re using fewer frames.
If it does lag with switching to 60hz then you most likely have code that very laggy, for example creating a thread(such as coroutine,defer,spawn, or events) per projectile will be bad (I made guns before and I use 60 hz and I had over 100 projectiles running at same time without issue)
(If you are using bodymovers or any other physics object to move the projectile though then that a big problem there)
If you want to stick to 30hz though, something you can do is generate a path of points like what your doing now, and once you have a set of points you can tween the projectile, you can increase tween speed to simulate the speed of the projectile ( I don’t really recommend this but if you want to try it then go ahead.)
im not running x amount of calculations every frame, im running every second. I have to calculate the next point in trajectory with gravity and air resistance velocity etc.
Lua is a single threaded language, I loop through every bullet each time they can step. I stress tested my system and i was able to handle 1600 projectiles at once running them at step rate of 30hz while my client was running 144fps. ryzen 5600x
i was thinking about something similar to the last thing you said. what if i made the tracer update as many times as it can in a single line of the trajectory until a new line is created and then repeats that process each line. Essentially making it look like the bullet is smooth.
The reason why i don’t recommend my last solution is because you esstinally have to calculate twice
For the bullet trajectory
For the actual bullet and collision
Whereas if you just move the bullets in a 60hz you only have to move it until it hits something and you only need to do the same calculations once, and also tweening a bunch of bullets just adds another layer of computation which could potentially create more cost then just simply not doing it in the first place
I think It would be better to break the line into points for the tracer to travel. if you are running 60 fps and the line is 30hz you can update the tracer twice in each line. (1/30)/(1/60) = 2. this should be less calculations than doing 60hz, and it adjusts to people with higher framerates. like 144, it will be able to fit around 4 dots into a single line of a trajectory of 30hz.
I’ll show progress soon maybe in 24hr or more since im tired
oh yeah i forgot about this post, i eventually came up with something and it worked. another problem that i didnt realize was that i reset the step timer to tick() at the end of each step iteration and ignored the fact that theres still some remaining time, this causes me to lose time that leads into the next step causing delays. so by fixing that i made my projectiles accurate to time and makes things smooth as it shouldve been.
: