We made particlefx and add the particle to the object (railways in our example)
Then we spawn 3 objects close to each other.
And all emitters synchronous spawn new particles.
Looks like they have the same random seed in randomizer.
(external link to the video: Screen capture - 403c31fb307b6d5957b22f946f5b2a6e - Gyazo )
How to fix that? Maybe we did something wrong?
I tested this and couldn’t figure out a good way to not make the sparkles appear in every instance with the built in particlefx settings… you could maybe stop/start them with some random intervals, but there is a bug when doing that with multiple effects on the same go.
As an alternative, you could use game objects for these kinds of effects? If you put them on the same material and render predicate you’ll probably get same performance because of the batching, but making a new material is probably also overkill unless you have a ton of go based particles.
Would be nice to have more scripting possible with particlefx in general.
Yes, it possible. But it is will be probleme for game-designer. He like to play with parameters and find a excelent variant. On video just one of first variants for clear understanding what the problem is.
But if I starts to do this, have sense to implement some external particle format or something like this.
Unfortunately I have no time for it now.
Main priority is finishing current game.
On init call the timer module britzl made to do the first play of the particle with a random number as the period to wait on the timer. Then there should be a good enough offset even if they still happen on similar period.
Yes, it can help. I forgot about this workaround.
I already did the same with spine (when was no possibility to use parameters)
Thanks.
The particles are completely deterministic by design, so that you get the exact same appearance whenever you play it. But we obviously lack a checkbox to turn that off (i.e. let the seed vary between instances).
Yea, would be great to have the checkbox.
And one more question about particlefx and spawn rate.
For now second value of spawn rate field have no influence to spawn rate.
Doesn’t matter what value is set: it can be 1 or 10000, particle will spawn all time like in first field.
You can see it on video. For now we set inteval 1-100 but all time it is 1 second and oly one particle.
Looks like a bug. What do you think?
UPD: It’s hard to see when you have more than one particle and different life time, but it is.
UPD2:
As I see it works like:
@britzl maybe you can help, is it an engine bug?
Remember we need ability to pre-warm looping particlefx systems too!
Yes, maybe. I had a very brief look at the code and it doesn’t look like the spread value is applied to the spawn rate. Is this correct @Ragnar_Svensson, @sven and @Mathias_Westerdahl?
Hi, nobody answer me (
@Ragnar_Svensson, @sven and @Mathias_Westerdahl Is it possible to fix the spread value ?
Sorry, I didn’t hound Ragnar, Sven and Mathias for an answer. I’ll check this on Tuesday when I’m back at the office (Monday is a bank holiday in Sweden).
Yes, it looks like a bug. A fix looks trivial, but it requires some tests to verify correctness.
So, as you’ve already seen, the spread value of Spawn Rate is ignored. This is a bug and it should be fixed somehow, either by removing the spread or using the value in a reasonable way. But what is a reasonable way? If you consider the spread value of Spawn Rate and compare it to the spread value of the other properties then all the rest of them operate on the particles themselves while the Spawn Rate would instead apply to the emitter.
Every update of an emitter we currently increment a ParticlesToSpawn counter with Spawn Rate * dt. Every frame (uint)ParticlesToSpawn particles are spawned and the ParticlesToSpawn is decremented by this amount.
How does the spread value of Spawn Rate fit into this system? We could every frame instead increment ParticlesToSpawn with (SpawnRate + rand[-1,1] * spread) * dt and get some randomness going based on the spread value (or perhaps rand[0,1] * spread). This would solve what you want to achieve in your example @AGulev and avoid that all particles spawn in total sync from multiple emitters with the same properties. But is it obvious to the user what the spread value actually does?
The spread value of Initial Size makes immediate sense and the outcome is obvious and predictable. Initial Size 32 and spread 16 means that particles will have an initial size ranging from 16 to 48.
What does a Spawn Rate of 10 and spread of 5 mean? What would the user expect?
Finally, there’s the issue of a negative Spawn Rate, which is currently not handled either. You can curve Spawn Rate and let it be negative and receive some pretty weird results. This also needs to be take into consideration. Probably by treating a negative Spawn Rate as 0.
Shouldn’t spawn rate spread of an emitter be range from spawn rate? So if spread is set then it goes particles to spawn this frame = rand[rate,spread] ? That’s what I used to think it would do.
You could add another property instead too for defining a random range because messing with spawn rate as is would probably break many projects. So if other property fields were set for random range the current rate could be ignored?
Right now rate though isn’t super clear because if you have max particles at 25 and rate at 25 it doesn’t shoot them all at once you have to set rate to 10000 or something to get that to happen.
Spawn rate is particles/second. Like this, based on my description above:
FRAME ParticlesToSpawn PARTICLES SPAWNED
1 25 * 0.016 = 0.4 0
2 0.4 + 0.4 = 0.8 0
3 0.8 + 0.4 = 1.2 1
4 1.2 - 1 + 0.4 = 0.6 0
5 0.6 + 0.4 = 1.0 1
6 1.0 - 1 + 0.4 = 0.4 0
7 0.4 + 0.4 = 0.8 0
8 0.8 + 0.4 = 1.2 1
9 1.2 - 1 + 0.4 = 0.6 0
10 0.6 + 0.4 = 1.0 1
...
60 0.6 + 0.4 = 1.0 1
-------------------------------
Total # of particles spawned = 25
Getting all of them to fire the first frame would require a spawn rate of 25/0.016 = ~1562.
@britzl
it is two different issue.
First about sync particles.
It can be solved by timer on start or, maybe in futer, as @Ragnar_Svensson told by adding checkbox [quote=“Ragnar_Svensson, post:6, topic:7311, full:true”]
The particles are completely deterministic by design, so that you get the exact same appearance whenever you play it. But we obviously lack a checkbox to turn that off (i.e. let the seed vary between instances).
[/quote]
Second issue is about spread.
I just read documentation: Particle effects in Defold
@Pkeod no, by doc it something about particles to spawn this frame = rand[rate, rate + spread]
And by docs, spread should change count of particles per second.
If I have rate = 1 and spread = 1 it should spawn
sometimes 1 particle per second
and
sometimes 2 particle per second
I think this variant should be right (if we believe the docomentation)
But isn’t the second issue a means to achieve the first issue? If you could adjust the spawn rate by applying some kind of spread then the particles spawned by two different emitters will no longer be in sync.
Yes, you right! And this is great! Two issue by one shot. I meant the same thing in my first post! (I reasoned the same way when found unworked spread field)
User who want to use sync particles just leave spread field with 0.
I should have drunk a coffee before answer in topic ^__^
