So well, all the particles are 3D. The 2D ones are made by changing the particle emitter’s FaceCamera property, and using a 2D mesh. The mesh then has a texture on it. So to make the particles act like if they have flipbook animation, you could add a flipbook texture and change it’s properties every frame to change the particles texture position.
For referencing particles, the only way you can change particle’s properties is by using the EveryFrame() function. Just change the function to update the particle instance properties you want. Sadly you cannot change the particles speed and position, i might add it in the next update if you want.
If you need any help you can reply anytime.
1 Like
So the next update will have new things like:
-Better Camera Culling. (Less Position updates to Particles behind Camera)
-Toggleable Collisions. (It will be now possible for Particles to not interact with the environment)
-Changing Collision Group for Particles.
-The module will be typechecked, which will make the autocomplete work on everything.
-Now Default Part Shapes will have Proper Collisions. (Still unsure on how would i do it for models)
I will be also making a Plugin for making it easier to make Particles. So it will be possible to make Particles without scripting knowledge. It will also make it possible to test the Particles in Studio without the need to run Test Mode.
4 Likes
Oclussion culling optimization LETS GO!, wait edit thats called frustrum culling, my bad.
2 Likes
i made a cool fluid sim with this module i did edit the module for the fluid sim tho its cool but laggy and buggy i will publish the fluid sim soon in like a few hours also for those wondering about my older replies i decided to use normal roblox fire even though it goes through the oven roof also that game that had the oven its abandoned also it would be cool if self collisions actualy worked with multiple threads you should also maybe try to make it auto generate actors
well i think CS2 uses raytracing for smoke but very well obtimized raytracing but this module is just regular ol rasterization cuz roblox uses rasterization you can do raytracing on roblox but its usualy laggy tho i have seen raytracing on roblox with okay fps usualy 24 fps or higher but it isnt high quality
oh also i think spheres are more performant than boxes cuz its just easier to do math with spheres
for example checking if a point is inside a sphere is as easy as checking if the distance to the center is less than the radius
but for checking if a point is inside a box thats more complicated than with spheres especialy with rotations
2 Likes
I actually thought about self collisions that also work between different threads but i had no idea how to do it efficiently. But auto generating actors seems like a good idea. I thought that making auto generated actors would be a bad idea because there wasn’t a good way for communication between threads, but now there are actor messaging functions and shared tables so maybe i will try to make it. It would probably make the module easier to use. But for now it will stay how it currently is until i find a good way for self collisions between threads.
This is amazing, very kind of you to allow anyone to edit the place as well!
I can’t wait to mess around and learn from this.
1 Like
Very cool, thanks for sharing this!
1 Like
I am using trails on my emitter parts and the trails keep looking like this when placed over a block… How do I fix this? I am already trying the fix provided with the other trails problem
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.
1 Like
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 @deathcharge415 as he had the same issue. By doing like the example above, you can fix your problem without requiring any hacky way.
1 Like
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.
3 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
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).