I was trying to design a weather system for a map that is pretty large. Instead of putting hundreds of blocks that emit particles all over the sky in the map, what is a better solution to have weather particles?
Right now, the only solution I’ve come up with is laying down large flat anchored invisible blocks in the sky with rain particle effects emitting from them, but I feel like there might be an easier method for the desired effect. Doing it this way may be severely laggy too.
Another thing that got me stuck was how to stop the particle effect for a player that is inside a building or a cave, such as, detecting that there’s a part or terrain directly over the player and disabling the particles for them.
you could use @buildthomas’s rain module, it has a very simple usage,
and instead of it emitting hundreds of blocks that emit particles, it only puts one over the players camera, and it uses raycasting to detect if someone is under a roof, if they are under a roof it will automatically disable itself.
You can also use multiple smaller parts to avoid the old issue of not seeing rain outside the building. Performance shouldn’t be an issue as long as the part count stays within a reasonable number.
Have you tested this? Do the particles cause lag? I can’t see a reason why particles would cause a large amount of lag, unless there are absolutely huge amounts of them. The particles emitted are essentially billboard GUIs, which are generally handled fine.
However, if they are causing lag, try decreasing the frequency of particles, and increasing their speed (so that they are destroyed quicker).
As for the problem of them going through parts, you may need to create a custom system instead of using ParticleEmitters. You could create parts designed to resemble rain and tween them downward. Before tweening the part, raycast downward. If you detected a part with the raycast, play a splash effect and destroy the part.
Part count isn’t an issue at all, games can support a large number of parts without any performance hits. Performance hits will come from the particles themselves. That makes this solution no different than placing anchored blocks over the sky, which consequently results in the same performance concern OP is worried about.
The engine has a cap of how many particles it can render on screen, so exceeding that limit can and will produce unintended results of strangely disappearing particles or ruin the aesthetic the particles are meant to introduce. As well, some machines do experience lag when you put too many particles in front of a user’s screen at once.
To top this off, it is inefficient to render things for areas you can’t see or shouldn’t. There is no point in rendering rain particles for a far-off region unless your game aesthetic calls for being able to see, for example, a cloud over a tower.
Rendering them above the player’s head in world space is efficient, useful and in cases where you need to interact with them, better. In fact, it also fits in well with what OP also wants to do with that rain, which is to disable it when in the presence of a building.
With a simple-render solution:
Raycast upwards every frame (don’t make the ray too long or you’ll incur a performance cost)
Check if there’s something between the player and the space above them
If there is nothing, disable the specific rain effect above your head, otherwise don’t
Using your complete cover solution, we change only the last step to iterate over every rain block that can possibly exist and disable it. That doesn’t sound pleasant.
So in short? Don’t do this. Your players won’t like it and it’ll become a pain for you to maintain. It’s more preferable to create a rain effect over the player than to constantly add small invisible rain blocks all over your map. This is much more of a pain if you have a greater map size and ratio of enterable buildings and head-covering structures than not.
Any distance is acceptable so long as you recognise the performance and efficiency of the approach you select, as well as how it fairs out in your game. I personally would pick the minimum height I can get without ruining player immersion or performance, then have a low cutoff for the particle’s lifetime.
The ultimate goal is to only render as much as you reasonably need.
By part count I meant emitter count. For some reason, even my workstation lags with too many emitters present (R7 2700X). The inconsistency can be easily fixed by finding the max consistent rate and setting the rate by multiplying the max rate with a number between 0 and 1.
What do you mean by creating small parts all over the map? Just create an anchored model composed of a grid of parts with a MainPart in the center and set the model’s CFrame above the character.
This doesn’t cause lag either. Emitters don’t cause lag and part count has little performance hits as well. What you’re experiencing is a large number of particles being rendered on the screen at a single time.
This was an assumption based off of a vague explanation you gave:
Whether you meant that or not, the point itself stands that the method is inefficient.
I’m sorry to tell you, but absolutely nothing of what you said made any sense to me. I even made an entire framework a long time ago. Had to fix it as it used parts with decals, but here it is:
Almost no lag, the base rate is set to 1000 and all emitters get a static rate of 1000 divided by the surface.
What part of the post do you not understand? I explained it very clearly. It doesn’t seem like a case of misunderstanding, rather a different experience with the matter.
Neither parts or emitters cause performance any major performance hits without being done en masse. The source of performance drops from an emitter come from the particles they emit. I never said that 1000 particles suddenly causes lag, there are other combinations of textures, sizes and other properties on screen that can cause varying levels of lag for different users which is something to accommodate for. 1000 particles is only around 6.25% of the render maximum and you probably aren’t using any intensive particles at all.
In addition to this, there is a limit to how many particles can be rendered on screen at a single time. Exceeding this limit results in some particles failing to render, which can butcher the quality of an object with applied particles.
And you keep trying to explain a problem about something I never said.
I never said I was going to create hundreds of parts for this to work. In fact, I pointed out that you shouldn’t go over the edge with particle emitters which are bound to a part, so making more emitters = making more parts.
Adding onto the previous, particles can cause lag, be it limited or not. Hundreds of rainbow colored emissive sparkles will obviously cause issues, but any reasonable person would avoid doing that, unless it’s a core component of the game, making any other particles less important.
There aren’t many ways to create complex particles; in fact, the only way to make them performance intensive is to make them emit light or have changing color, and I don’t remember the last time water droplets were fluorescent or purple.
Unless you have some kind of a particle based wave emitter, there aren’t that many settings where 1 or 2 non-rendered particles would be an issue. It’s only a problem when an emitter with a rate of 100 can barely squeeze out 10 particles.
EDIT: Forgot to mention that my system will stop certain emitters from emitting if they are blocked, meaning less particles.
Clearly there’s a misunderstanding between our posts. I thought I cleared this up already that I possibly could’ve misunderstood your post.
Regardless of that fact, you aren’t the only one on this discussion. There are others who might find the information valuable to hold on to, which is why I mentioned it.
So it’s not that you don’t understand, it’s that we’re not talking about the same thing.
On that note,
Not entirely true, even now with this explanatory post. You can siphon ParticleEmitters to attachments and cull your part count, so long as they’re over a specific area.
Completely useless in this situation since attachments can only emit from a point, not a surface. It will look more like a public shower than a precipitation.
In this situation specifically, yes. The point itself is what I’m commenting on. It’s not necessarily true that you need to increase your part count just to increase your particle count.