Sadly, Trails don’t play very well with particles. You can try using this fix: Collideable Particles Module [Self Collisions Update V3.2] - #84 by BubasGaming
It is not the best way but it should work.
I will try to fix this in the next version, but right now you will need to do the hacky solution.
I actually did this here, unfortunately this was still the outcome
Ok i think i fixed it. Now it should work fine. To fix this you need to have this version right here:
ParticlesModuleRewriteTrailsFix.rbxm (14.7 KB)
It doesn’t fix it by itself, you need to change one property. It is the TrailFix property. There are 3 ways you can set this up.
First one is setting it as a string which will be the trail’s name. The trail must be directly a child of part you emit. So if your trail’s name is for example “Trail”, then you need to do:
Emitter.TrailFix = "Trail"
Second one is, when you have multiple trails that are children of the emitter Part. So if the Trail’s names are for example “TrailA”, “TrailB” and “TrailC” then you need to do:
Emitter.TrailFix = {"TrailA", "TrailB", "TrailC"}
Third one is, when your Trail or multiple Trails aren’t a Children of the Part but a Desceants, then you need to make a table, and inside that table, make tables that are the paths to the trails. So let’s say that the emitted objects has a child for example named “TrailsFolder”, and TrailsFolder has Trails like “TrailA” and “TrailB” then you need to do:
Emitter.TrailFix = { {"TrailsFolder", "TrailA"}, {"TrailsFolder", "TrailB"} }
If you you still have issues, reply to this message. I would also like to ping @ne3ulimity as he had the same issue. By doing like the example above, you can fix your problem without requiring any hacky way.
Thank you, works as intended with the trail fix, big thanks for fixing this… Although it sometimes displays this error:
So i haven’t made any update on this in a while. It is due to my loss of motivation. I wish i still had that kind of motivation that i had on the start of this project. I know that there are many things that could be added to this, maybe i will comeback to this project sometime in future. This doesn’t mean it’s unfinished, it should be already good and optimized enough to be used in a real games. Right now i would like to summarize all the progress that was made.
It started like every other project. It was small, unoptimized and had many bugs. Tho it looked good and it was ok to use in projects in small amounts.
I optimized it a bit and Uploaded it to DevForum.
The first reply i got was about how i can optimize it, which was great as i wanted it to outperform other particle modules. I implemented something called “Distance Throttling” so that particles far away have less FPS. It worked great, sometimes it was unnoticeable and it helped alot. Later i discovered a method of workspace called “BulkMoveTo()” which doubled the fps. I had no idea it would speed it up that much! But then i discovered a bug that could literally crash the game. So i quickly fixed it and uploaded a newer version. But then i found ANOTHER bug that also CRASHED the game, so i made another fix and uploaded it. That was kind embarassing. Anyways.
Later i added Frustum Culling so that particles outside camera don’t update their position. Tho it wasn’t the best, it was so basic that when particles were too big or too close to camera, they could disappear even tho they should be visible. Tho it helped with performance. Then i made some less important updates. I then changed the collision code which works way better than the one before. I was also doing some small optimizations while working on new features.
But then i thought about something. Something kinda crazy. Maybe not that crazy but still kinda.
What if particles could collide with eachother instead of only with the world?
I already knew how i could i make it performant, but i wasn’t sure if it wouldn’t be laggy. But i tried anyways. AND IT WORKED GREAT. It wasn’t too much performance taxing, it looked cool, it looked cool and it also LOOKED COOL. I was so satisfied with how well it run and how good it looked.
If you are curious how i made it run well, you should read about Spatial Partitioning. For the last updates, i updated the Frustum Culling code to a proper version and finally fixed problems with trails while culling is enabled.
Conclusion
The module performance is pretty good now. I mean of course you won’t be able to simulate 100k particles, but for Roblox this is the most optimized particle module out there. And it is FREE of course.
But why cannot it run more particles without degrading the performance? Hmm…
The physics calculations aren’t a bottleneck here. Nor any other physics calculations like wind or other forces. So what is the biggest bottleneck here that makes it impossible for it to run more particles?
It is…
Moving the Parts.
Yeah, and it’s a crazy bottleneck. It doesn’t make it like 20% slower. IT MAKES IT 5 TIMES SLOWER. When i run the Snow Physics Demo using the Particle Module, when simulating 17151 particles (with Distance Throttling) i get around 100FPS when not updating the particles visual positions. So you won’t be able to see those particles. But when i make the positions update, it drops to 20 FPS.
And that’s even when using “BulkMoveTo()”. That’s honestly very very bad. But tho i kinda get it why Roblox cannot just make updating Part Positions faster, but i wish there was a way to.
Let’s also don’t forget about Native Code Generation that isn’t enabled on Client Hardware yet, so the physics calculations would be even faster. So when Clients will finally be able to use it, the Difference of FPS between particles with visual updates and particles without them will be even bigger. Well atleast it works ok with 6K particles. It might not be much, but might be enough for Roblox.
I think that’s it.
Also if you guys have any ideas for updates or performance optimizations, feel free to tell me. Maybe that will make me motivated.
I hope you enjoy using this module. I am curious what other users are able to create with it.
In the next week (or maybe earlier [or maybe even later]) i am gonna finally upload the rewrite which isn’t actually a rewrite, more of a cleanup. I will document the code making it easier to edit it, make better documentation on the functions and properties, add some tutorials. And i think that will be it.
What will the next update be if i will even try to make it? Probably collisions between particles from different actors. I already have thought of some ways of doing it but i am still not sure if it will be performant enough.
Hello I am looking through your code and wondering wouldn’t raycasts be better for these simulation rather than GetPartBoundsInBox, and i noticed few unused variables in the script
I think it might be bad for performance casting many rays per frame. The point of this module is to be able to simulate thousands of particles without fps drops, that’s why i use Box Collisions. And also there is another issue. The previous versions before the release used raycasts, but it was buggy. Because if a physics object goes into a particle, the raycast cannot detect that it is inside a object, compared to Box Collision. Raycast can only detect what is infront of it, not if it is inside something. I could probably do a hybrid of these two, but that would make it just complicated.
And the unused variables are due to me forgetting about deleting them. They won’t be there anymore after i release the cleaned up version. This module is kinda a mess, but it does it’s job pretty well.
SAME. Ive been working on developing a real time fluid simulation. The physics can run so much with no lag, but its just moving the bones which tanks performance.
DAYUM it looks extremely satisfying.
Tho i heard that moving Bones is less demanding than moving Parts. I might be wrong tho. How well does it run?
Bones cause a lot of lag when moving. Thats why when Im making my LOD system, I’m not gonna do it for the sim, but for the bones only. This runs at 60 fps stable in the unoptimized example.
Guys, i think i know how to do collisions between mesh and particles now. Tho it might not be the best way to do it, it should be performant.
If you guys didn’t know yet, sadly the module cannot do collisions for meshes, so it switches to using box collisions for them. I also never planned on adding collisions for meshes as to achieve this, i would need to use some hacky ways as there was no good way of getting the mesh data. But now that i think about this, i think i have found a solution. I could just precompute the voxelized version of mesh and use that for collisions. The voxels will store the closest distance to the surface, just like SDF. Then using some math i could get the pushPosition and Normal direction.
What do you guys think about this approach?
Also don’t expect me to actually make it as i might not have the motivation to do this. Tho i might actually end up on making this as i am already working on a module all about voxelization (things like fast voxel traversal, performant scene voxelizer, voxel cone tracking).
should work and be pretty speedy.
What’s the difference between this and just spawning a ton of unanchored, collidable parts? Does it rely on the default Roblox physics engine?
Good question. When you just spawn unanchored parts, the parts affect other physics objects, but when using this module, they don’t, they only react to them. That’s because they do use their own physics code. In theory it should perform faster than spawning parts. It is also more customizable.
It has been optimized as much as it is possible to be actually used in games.
I recently joined a development team and my other teammates really liked it, so after our game releases it will be a great showcase on what this module can do. But it will probably take us years to release the game.
If you have any questions i will be happy to answer them.
Ohh nice! I didn’t see anything saying it was a custom physics engine applying only to them, so that’s really cool. Good work!
Thanks for pointing that out. I should make it more clear.
So guys, the cleanup is done. I already finished it like one or two weeks ago. But i haven’t uploaded it yet, because i started working on something new.
I am also experimenting on ways to make Collideable Particles Module faster by using Bones instead of BaseParts and i get around 5x performance boost (tho it depends on the scene). But it is also more limited in the visuals (performance > visuals).
I think i also found a better way for simulating Wind Turbulence but i haven’t started working on it yet.
Because there are many things i could be working on, i decided to make a Poll.
0 voters
And Also:
0 voters
This is absolutely incredible. I have always been looking for a model like this.
The module should be now more readable. There were some little performance improvements added and some additional things. You can see the UpdateLog in the main post. Let me know if there are any errors in the post, like something not documented or badly formatted. Also report any bugs if encountered.
EDIT: updated the demo place so you can test the new Particles. Tho there aren’t many changes in it, all that got changed is the module version.
