I want to play a smoke particle system continuously but at present, it was taking a pause for some time then after again started spawning particles.
This is my particle system inspector values:
I want particles to remain to continue always not take any kind of pause. What kind of changes will solve my problem?
EDIT:
Okay now I understand, exactly this kind of problem running, it does not disappear but exists in a different place.
Still, I can't able to get continuous emission of particles, it getting a pause in mid:
I have also checked by changing Emission from Time to Distance but still the same problem.
So lets take a look at some specific settings. Rate over Time = 10, Max Particles = 10, Start Lifetime = .5 and Duration = 1.00. In order - you are emitting 10 particles per second, allowing a maximum of 10 particles, which exist for .5 seconds, and then it starts over again after 1 second. So, 10 particles are immediately emitted. No more than 10 can be emitted while they are alive, so for .5 seconds no new particles are being emitted. Then, at .5 seconds they all disappear. So now we have .5 seconds per second that no new particles are being emitted. Then, after a full second the process restarts. You can solve this in two ways.
Lower Duration to .5 seconds from 1.0 seconds so that it restarts right when the particles die
Increase the start lifetime to 1.0 seconds so that the particles stay until the next batch is ready to spawn
The first solution is probably the better fit.
This issue was related to Unity Particle System. Based on other forum discussions, I got the suggestion to update Unity with the latest version because I was using Unity 2018 earlier version.
I downloaded Unity 2018.4.2 and play the game with the same settings. With my surprise, the error was gone and the problem solved.
#TheBatman for giving useful suggestion too.
Try raising the rate over time in the Emission section.
Related
I'm new to Unity and I see many times that Time.deltaTime needs to be added. In which cases should I add it? I know this is so that there will be no excess power in the event of a quick refresh of the frame's computer.
For example, in the next case, do I need to add Time.deltaTime?
playerRigidbody.AddForce(Vector3.up * 100 * Time.deltaTime, ForceMode.Impulse);
Time.deltaTime is the amount of seconds it took for the engine to process the previous frame. It's calculation is rather simple: it uses the system's internal clock to compare the system time when the engine started processing the previous frame to the system time when the engine started processing the current frame. Every motherboard has a "system clock" which is responsible to keep track of time. Operating systems have access to that system clock and provide API's to read that clock. And Unity gets the time from that API and that's how things are synchronized.
Think of a game as a movie, which is essentially a sequence of images. The difference is that a movie is rendered at a fixed rate of 24 images per second, while a game doesn't have a fixed frame rate.
In a movie, if a car travels at 1 meter per second, each image will make it move by 1/24 meter, and after 24 images (1 second) the car will have traveled exactly 1 meter. It's easy because we know that each frame takes exactly 1/24 second.
In a game, we have to do the same thing, except the frame rate varies. Some frames can take 1/60 second, some others can take 1/10 second. We can't use a fixed ratio. Instead of a fixed number we have to use Time.deltaTime. Each frame, the car will move a distance proportional to the time of the frame. After roughly 1 second, the car will have traveled roughly 1 meter
Delta is the mathematical symbol for a finite difference. Its use is very common in english when talking about something that changed over time.
deltaTime is a difference of time, so it's a Delta
Shorter Terms
You must always use Time.deltaTime when moving objects over time, either by supplying it yourself or by making use of functions like SmoothDamp that use Time.deltaTime by default (hardly any functions do that though). But you must never use Time.deltaTime for input that's already framerate-independent, such as mouse movement, since in that case using Time.deltaTime will do the opposite of what you intend.
If you're ever unsure you can always toggle vsync on and off and observe any potential speed differences. If the game's already running close to the monitor refresh rate anyway, then make use of Application.targetFrameRate instead.
In very easy words
Time.deltaTime is the time passed since last frame was rendered.
By multiplying a value with it you basically convert it from Something per frame into Something per second.
Is it needed?
Now if you need to use it totally depends on your specific use-case! In your case for AddForce: NO!.
The force influences the velocity of a physics object. The velocity itself already is an absolute per second vector.
Usually there are two use-cases for AddForce:
It is called continuously but within FixedUpdate
Because FixedUpdate is not called every frame anyway but rather on a fixed real time intervals (by default 0.02 seconds) you would not need Time.deltaTime. The Doc already provide this in the example.
It is anyway called only as a single event (e.g. by jumping)
Here there is nothing continuous, so you don't need and don't want to use Time.deltaTime either since a single event can not be frame-rate-dependent anyway.
I'm a senior software engineer, but completely new to Unity programming. I've been teaching myself Unity for a few weeks by writing some SteamVR toys for myself. I wanted to ask about Unity's standard built-in ways to improve frame rate for a program with a lot of intensive physics calculation.
In my current VR scene, I have a ball with a Rigidbody on it. When I pick it up and throw it, I let it move naturally, but I apply small forces on every Update() call to adjust the landing position and always hit a target.
I saw my framerate take a big dive, so I wrote my own function to throttle the updates, limiting them to 5 per second. The question is, is there some standard Unity behavior that I should be using instead of rolling this code myself?
In my throwing script, I maintain a bunch of top level variables and update them first to decide whether I should do calculations on the current frame.
private void updateCalculationFrame() {
isCalculationFrame = Time.time > nextCalculationTime;
while (nextCalculationTime < Time.time) {
nextCalculationTime += (1 / calculationsPerSecond);
}
}
On each frame, I run this function, then if isCalculationFrame is true, I proceed to calculate and add force vectors. I just wonder if I am overlooking some more standard way to do this with less code? I feel like this must be a very common thing to try to do.
The code you have there will freeze the Unity until the loop is finished. You shouldn't do this at all.
You could simply set a new Time.fixedDeltaTime. By default it is usually about 0.02 but you can set it to anything you want.
The interval in seconds at which physics and other fixed frame rate updates (like MonoBehaviour's FixedUpdate) are performed.
...
Note that the fixedDeltaTime interval is with respect to the in-game time affected by timeScale.
To my understanding of this diagram, Update() is called strictly once per game cycle, while FixedUpdate() is called 0 to multiple times when Unity feels like to do physics. Is it true?
What I'm not sure is, are physics steps commonly behind current time, or ahead of current time? In other words, how is Unity's decision made for doing physics or not, like while (currentTime - previousPhysicsUpdateTime >= fixedDeltaTime) or like while (currentTime > previousPhysicsUpdateTime)?
Or neither of the above?
It is a bit like to opposite. Physics is done regularly on a fixed time basis. That means that FixedUpdate is called on a fixed time basis. It is the Update, that can vary depending on the fps of the game (60 fps, Update was called 60 times per second).
Now, we usually thing from the Update point of view. Meaning that if you have a high fps, maybe you can have two Update calls before a FixedUpdate happens. In the same way, if you fps drops you have less Updates, but still the same amount of FixedUpdate, so you will have several FixedUpdated between two Updates.
So for example, let's say FixedUpdate happens 50 times per seconds (that's the default in unity). It you game runs at 60 fps, It means most of the time you will have one FixedUpdate and one Update call. Occasionnaly two Updates will follow (because Update is a bit more frequent). If you reach 100 fps, it is sure that you will always have at least two Update calls before a FixedUpdate.
I suggest you look at the FixedUpdate Doc if this is not clear enough
I am trying to extinguish the fire particle using Unity water particle. Which is working. But the water particles Splash effect is overflowing. I tried to scale it but it"s not working. So how can I reduce the splash effect?
To stop the water particles from overflowing you can do a combination of two things:
decrease emission rate of particles or the velocity of particles. You find these things under certain modules. Here is the list of modules:
To change the emmission rate, find the particle system in the inspector and go to the emmission module. If not already opened - open it. Adjust the Rate over Time variable to a lower value, you should notice a lot less particles being formed.
Then to change the velocity of the particle system, this one can be change a few ways. And, it depends on how you change it for your water to go upwards. A good place to check is in the Velocity over Lifetime module and you want to decrease the speed modifier or the linear velocity values.
You may also want to check if lowering any velocity values from Limit Velocity over Lifetime, Inherit Velocity, Force over Lifetime solves your issue.
EDIT
To stop emitting particles just set the prediscussed particle emission Rate over Time back to 0. To do this inscript:
GetComponent<ParticleSystem>().emission.rate = 0.0f; // Or a higher number if you want to restart it
Also, when I notice your particle system, you don't have to add burst like I have done so in the examples. Just change the specific variables mentioned.
I have a particle effect for a muzzle flare set up. What I'm currently using is a low numParticlesToEmit to limit the emitter to a short burst, and doing resetSimulation() on the emitter whenever I want to start a new burst of particles.
The problem I'm having is that resetSimulation() removes all particles onscreen, and I often need to create a new burst of particles before the previous particles disappear normally so they get erased early.
Is there a clean way start up the emitter again without erasing the particles already onscreen?
Normally particle systems have a feature missing from SKEmitters: a duration. This controls how long a system emits. I don't see this in SKEmitter, despite being in SCNParticleSystems
Never mind, a work around:
SKEmitters have a numParticlesToEmit property and a particleBirthRate. Combined, these determine how long the particle system emits before shutting down.
Using these as a control of the emission it's possible to create pulses of particles emitted in the way you want for something like a muzzle flash or explosion.
I'm not sure if it remvoes itself when it reaches this limit. If not, you'll have to create a removal function of some sort. Because the way to get your desired effect (multiple muzzle flashes on screen) is to copy() the SKEmitter. This is quite efficient, so don't worry about overhead.
There is a targetNode on SKEmitters that are suppose to move the particles to another node so that when you reset the emitter, the previous particles still stay. Unfortunately, this is still bugged from what I can tell, unless somebody else has figured out how to get it working and I just missed it. Keep this in mind though in case they do ever fix it.
Hi to help future readers, the code that I use to calculate the duration of the emitter is this:
let duration = Double(emitter.numParticlesToEmit) / Double(emitter.particleBirthRate) + Double(emitter.particleLifetime + emitter.particleLifetimeRange/2)
It works perfectly for me
Extension:
extension SKEmitterNode {
var emitterDuration: Double {
return Double(numParticlesToEmit) / Double(particleBirthRate) + Double(particleLifetime + particleLifetimeRange/2)
}
}