Not logged inOpenClonk Forum
Up Topic Development / Art Workshop / [Particles] Fire
1 2 3 Previous Next
- - By Armin [de] Date 2015-01-02 18:54 Edited 2015-01-04 18:37
Played around with the new particle system. Plus, this doesn't show the Fire.png from the Graphics.ocg (which is the same sprite that was used in Rage).

Edit: Picture: FireParticles_4.ocs

I hereby license the following files under the CC-BY license
Attachment: FireParticles_4.ocs (58k)
Attachment: FireParticles_6.ocs (176k)
Attachment: FireParticles_8.ocs (278k)
Attachment: FireParticles_12.ocs (229k)
Attachment: FireParticles_16.ocs (215k)
Parent - - By Maikel Date 2015-01-02 19:42
Definitely an improvement over the old fire, but it should also work for other objects. Maybe you can make a test scenario with some more objects burning to judge whether this is an improvement.

Also not related to this improvement is the fact that trees stay green while burning, this just looks horrible no matter what fire effect is used.
Parent - By Armin [de] Date 2015-01-02 20:51 Edited 2015-01-17 17:20
There was indeed a error when I placed a few buildings and small objects in it. Fixed that and uploaded second version. My biggest problem right now is that if 2 or even 3 trees are burning at nearly the same position the particles look too bright. Also the idol is a bit strange.
Parent - By Zapper [de] Date 2015-01-02 21:50 Edited 2015-01-02 21:54

>Also not related to this improvement is the fact that trees stay green while burning, this just looks horrible no matter what fire effect is used.


The trees burn into black skeletons rather quickly. That obviously happens a lot slower when the trees are only slightly on fire (10% or so). See my other post that I will do in a second or so below..
Parent - - By Zapper [de] Date 2015-01-02 21:52
Fire has different strengths! An object can burn very intensly (OnFire() returns 100) or only very lightly.

The fire effect should reflect that! The best case would even be a visual difference between fire stronger than 50% and weaker than 50%, because that is the threshold below which fire slowly extinguishes itself.
Fire below 25% or so could even only be a few sparks or so

PS: for full-strength fire your effect looks nice! Guess, I'll have to see that in motion, too
Parent - - By Armin [de] Date 2015-01-03 14:56 Edited 2015-01-03 15:09
I copied Pyrit's sparks (thx) into the script. See the updated image in the first post.
Parent - By Zapper [de] Date 2015-01-03 15:21
That really looks interesting now, I'll check the scenario :)
Parent - - By Zapper [de] Date 2015-01-03 15:41
Looks nice already, some minor things:

> for (var i = 0; i < 2; i++) CreateParticle("Magic", RandomX(-width, width), RandomX(-height, height), 0, -20, height, sparks);


If you want to create multiple particles in one call, you can use the amount parameter like so:
CreateParticle("Magic", PV_Random(-width, width), PV_Random(-height, height), 0, -20, height, sparks, strength/2);
Also, I would suggest scaling the amount of sparks with the fire strength, like in the line above :)

Another general thing:
If you want to do an performance improvement, you could create all the necessary proplists (like sparks, yellowflash, redflash etc.) only once in Fx*Start and then use them in Fx*Timer instead of recreating them every frame.
Example:

func FxFireStart(target, effect, temp)
{
    if (temp) return;
    effect.yellowflash =
    {
        ...
    };
}

func FxFireTimer(target, effect, time)
{
    ...
    CreateParticle(..., effect.yellowflash,...);
    ...
}
Parent - - By Armin [de] Date 2015-01-04 16:38

>CreateParticle("Magic", PV_Random(-width, width), PV_Random(-height, height), 0, -20, height, sparks, strength/2);


Ah thanks I wasn't able to see the difference between PV_Random() and RandomX().

>If you want to do an performance improvement, you could create all the necessary proplists (like sparks, yellowflash, redflash etc.) only once in Fx*Start and then use them in Fx*Timer instead of recreating them every frame.


Most of the particles have to change their size depending on the current value of GetCon(). On the other hand Fx*Start gets triggered quite often as well when I remember correctly. So I guess it makes sense to do that when the particles look good enough.
Parent - - By Zapper [de] Date 2015-01-04 17:20

>Ah thanks I wasn't able to see the difference between PV_Random() and RandomX().


Random() draws a random number when you call it. PV_Random tells the particle system to draw random numbers (for every single particle) later, when the particles are created.
For example:
var random = RandomX(-10, 10);
for (var i = 0; i < 100; ++i)
    CreateParticle(..., random, ...);

This would create 100 particles with the same random number (for example the same speed). With var random = PV_Random(-10, 10); every particle would have a new random speed.

>Most of the particles have to change their size depending on the current value of GetCon()


True. If it only affects the size, you could set only the size in every timer call again (effect.yellowspark.Size = ...). But you are right: that only makes sense when the fire is finished :)

>On the other hand Fx*Start gets triggered quite often as well when I remember correctly


Fx*Start with temp = false is called exactly once when the effect starts. When effects with priorities are added and removed later, more Fx*Start calls can happen. They will always have temp = true, though.

That's why I wrote if (temp) return; in my example above!
Parent - - By Zapper [de] Date 2015-01-04 17:22
PS: the other cool thing about PV_Random is, that it can also draw floating point values.
That means that PV_Random(0, 1) can also yield 0.5. But that only works because particles are not synchronization-relevant!
Parent - - By Maikel Date 2015-01-04 18:07
Document that please if it is not already in there.
Parent - By Zapper [de] Date 2015-01-04 18:08
Parent - - By Pyrit Date 2015-01-02 22:32
I have once made some sort of fire sparks. Maybe they'd look good with that? The graphics for them would be "Magic". Kind of like...

global func Particles_Glimmer()
{
  return
  {
      Size = PV_Linear(1, 0),
      ForceY = RandomX(-50, -60),
      ForceX = PV_Random(-1, 1, 10),
      DampingY = PV_Linear(600, 0),
      Stretch = PV_Speed(1000, 500),
      Rotation = PV_Direction(),
      CollisionVertex = 500,
      OnCollision = PC_Stop(),
      R = 255,
      G = PV_Linear(128,32),
      B = PV_Random(0, 128, 2),
      Alpha = PV_Random(255,0,3),
      BlitMode = GFX_BLIT_Additive,
  };
}


So something like

CreateParticle("Magic", int x, int y, int speed_x, int speed_y, int lifetime, Particles_Glimmer(), int amount);
Parent - By Zapper [de] Date 2015-01-02 22:56
Note that the name Particles_Glimmer is already in use (and so is Particles_fire)
Parent - By Newton [de] Date 2015-01-04 00:44 Edited 2015-01-04 00:47
Looks nice so far. There is much to improve, though.

I would like to see some more structure in the fire, currently it is very blurry. How about if you took some actual images of fire, cut them into little snippets and use those as graphics for the particles? I mean, for example if you took this one, you'd preferredly cut out those pieces that have these slightly curvy lines.

Back when I created the fire effect for Clonk Rage, I used (at least) two different particle types if I remember correctly:
1. sharper additive yellow-red particles and
2. more blurred darker reddish/smoky particles that are not additive. Those should be in the background so the fire can keep some of its contrasty-ness even on the light blue sky background
I spawned the lighter particles more in the center and the darker/reddish particles further around so that the center of the fire is lighter and the fire gets a little bit of dimension.

Additionally, you might enrich the fire with red-gleaming sections (so not single gleaming pixels spread over the graphic but groups of those).

The current fire smoke is a bit sparse, it looks like someone took the "spray" tool from Gimp. I think in OpenClonk, we generally need more dense cloudy-3d-ish smoke. See e.g. this picture. If we have this, the additive fire also looks better in front of the light blue background of the sky.
Parent - By Zapper [de] Date 2015-01-04 11:20
Your effort here is great and it would be really cool to have an impressing fire effect in OC :)

So before this falls asleep or if you need any help with the particle system, please say so!
Parent - - By Armin [de] Date 2015-01-04 16:46 Edited 2015-01-04 18:37
I quickly tried to use Newton's feedback. Sadly, the result of my SharpFlame particle looks weird. I attach a picture of the used assortment: Dense particles (red ones are created on the sides, normal ones later everywhere) + these huge FlameBorders + yellow SharpFlames = fire
No more flash particles are used.

However, in the scenario, there are now way more objects burning and the fire is infinite so you don't have to use flints to get to see the fire for a short moment. That makes it easier to create alternative versions of the fire.

Edit: Picture: FireParticles_6.ocs
Parent - By Marky [de] Date 2015-01-04 17:43
I think that looks cool
Parent - - By Zapper [de] Date 2015-01-04 18:01
One point of aesthetic feedback:

The particles seem to pop out of nowhere, when they are first created. That is especially visible with the smoke when the fire is below 25%.
I'd suggest fading the particles in either with the Size or with their Alpha.
For example Alpha = PV_Linear(strength, 0), could become Alpha = PV_KeyFrames(0, 0, 0, 100, strength, 1000, 0), then it would start at 0 alpha, go up to strength after 10% of the particle's life and then fade back to 0 again. The same would work for size:
Size = PV_Linear(width*2, width/2), could become Size = PV_KeyFrames(0, 0, 0, 100, width*2, 1000, width/2),
Parent - By Armin [de] Date 2015-01-04 18:46
Right, tried the alpha method and it looks way better.
Parent - - By Armin [de] Date 2015-01-04 18:44 Edited 2015-01-04 19:24
FireParticles_8.ocs different SharpFlame and smooth (in)fading.
Parent - By Sven2 [de] Date 2015-01-04 20:20
It's hard to judge without seeing any movement of the fire. I think a lot of the fire-like appearance comes from proper movement of the flames.
Parent - - By Newton [de] Date 2015-01-04 21:59
Had a look at the scenario. Impressive, very promising. But is any of the fire particles actually additive? Might be an engine bug? As long as this isn't working, it's hard to find the optimal solution. Perhaps for now you could make the sky in the test scenario black so to better see how it would look like additive.

First some namings so that we understand each other. You have:
* Fire circles - those flame particles that are mainly composed of one squiggly line (see the log on your screenshot)
* Flame sprites - sprites of flame graphics moving up
* Old flame particles - those ballish round yellow and red particles
* Gleam particles - little red/yellowish particles that fly up into the wind

Here are some suggestions after my observations:
* Use the ThickSmoke particle for the smoke and make sure to spawn them close enough together / big enough that it is not visible that they are actually "balls".
* Those flame sprites move up very slow at constant speed. Slow enough that you can see and distinguish the single sprites from the rest of the fire. One thing I would suggest is to make them accelerate up, perhaps add some stretch when they are gaining speed (Stretch=PV_Speed()). Also, you could try adding some random rotation speed or initial speed.
* The red old flame particles that pop up left and right of the fire (mostly) don't look so good here because you can see that they are just "balls" (like the smoke).
* The fire (particles) should also contain hot whitish parts and not only red and yellow. So a fire that is drawn additively out of many particles doesn't stop at "yellow" as the brightest color. Also, currently the fire is a bit too transparent on the object IMO. Of course, it is difficult to say now that currently the fire is not additive at all.
* I'd like to see some yellow sparks that fly up chaotically into the wind and whirr around the fire. You can use the Stretch property here. I mean those particles that fly out of the fire in this video.
Parent - - By Armin [de] Date 2015-01-06 20:49

>But is any of the fire particles actually additive? Might be an engine bug? As long as this isn't working, it's hard to find the optimal solution. Perhaps for now you could make the sky in the test scenario black so to better see how it would look like additive.


Nothing was additive but now the Flame sprite in ~9.ocs uses GFX_BLIT_Additive. The sky is black as well.

>* Use the ThickSmoke particle for the smoke and make sure to spawn them close enough together / big enough that it is not visible that they are actually "balls".


Not sure which smoke you mean. However, I replaced the Old flame particles & Gleam particles (both used the tiny FireDense.png) to SmokeThick particles and it looks better than before I guess. Or are you are talking about the smoke that flies far away and is being created somewhere else in the script(s)?

>* Those flame sprites move up very slow at constant speed. Slow enough that you can see and distinguish the single sprites from the rest of the fire. One thing I would suggest is to make them accelerate up, perhaps add some stretch when they are gaining speed (Stretch=PV_Speed()). Also, you could try adding some random rotation speed or initial speed.


Yeah I tried slower speed because it looked bad on tiny objects. I changed that. Nearly all particles of a fire have a speed depending on the height of the object including a minimum value. There is still more balancing needed regarding sizes/spawn fields.

>* The fire (particles) should also contain hot whitish parts and not only red and yellow. So a fire that is drawn additively out of many particles doesn't stop at "yellow" as the brightest color. Also, currently the fire is a bit too transparent on the object IMO. Of course, it is difficult to say now that currently the fire is not additive at all.


I made the Flame sprites loosing G and B colors while moving up. Both values start with 255-0 depending on how near they are to the central axis of the burning object. Fire circles are white in the center of the graphics because they have the same width as the whole object.

>* I'd like to see some yellow sparks that fly up chaotically into the wind and whirr around the fire. You can use the Stretch property here. I mean those particles that fly out of the fire in this video.


Added a new spark doing that.
Parent - By Newton [de] Date 2015-01-06 23:04 Edited 2015-01-06 23:21

>>* Use the ThickSmoke particle for the smoke and make sure to spawn them close enough together / big enough that it is not visible that they are actually "balls".
>Or are you are talking about the smoke that flies far away and is being created somewhere else in the script(s)?


Not sure what you mean now. I meant to replace the Smoke particles here Objects.ocd\Effects.ocd\Particles.ocd\Smoke.ocd with ThickSmoke here Objects.ocd\Effects.ocd\Particles.ocd\SmokeThick.ocd. The picture you posted looks nice, this is the kind of smoke I imagine. If you use a current snapshot, you can see this smoke being used by the smoke trails of the explosions (or type GetCursor()->CreateSmokeTrail(RandomX(50,100),RandomX(-60,60),nil,nil,true))

>I made the Flame sprites loosing G and B colors while moving up. Both values start with 255-0 depending on how near they are to the central axis of the burning object. Fire circles are white in the center of the graphics because they have the same width as the whole object.


Sounds good, nice trick.
Parent - By Newton [de] Date 2015-01-06 23:15 Edited 2015-01-06 23:31
Wow, I like what you did there. Here are some more comments:

* the yellow sparks that fly up chaotically look great! I have nothing to add there.
* When you (the object that is on fire) is moving, the fire lags behind. Solution could/would be to make the particles use the Attach property of particles.
* The fire is currently very transparent. I guess this becomes even more the case when additive blitting has been fixed. But I guess the solution is just a matter of how many particles one spawns and can easily be adjusted later.
* the "popping up" effect of the particles when they reach the top of the fire is a very cool idea.
* now I get it, you used the SmokeThick particle in place of the FireDense particle. Mhhh, not sure about that, thick smoke has kind of a shadow. Perhaps try SmokeDirty or yet another one?
* not sure about this one, just an idea though: I see the size of the fire is dynamically adapted to the size*con of the object. But then it stays constantly the same size. How about you played around with variating the (height/size) of the flame to simulate this "auflodern" more. Or, as an alternative, variate the lifetime of the fire particles.
Parent - - By Maikel Date 2015-01-07 00:12
Also some feedback to version 9:

Great work, first of all. The fire still looks strange on very wide objects like the cabin, or on objects which are narrow and wide at different y, like the palm tree. Somehow the shape of an object needs to be taken into account better.

Then you test at night now. Maybe a good idea is also test underground, where the lights are at work more.
Parent - - By Armin [de] Date 2015-01-29 22:52 Edited 2015-01-29 23:18
All objects in version 12 with width > height look good/better now. While fixing this I noted that there are 2 objects with questionable DefCore.txt height:
1. The chest's height is the height of an open chest. I guess that's a matter of opinion. Should a firestone, which hits earth above the chest, damage the (most likely) closed chest?
2. The mushroom has a height of 20. That's the same height as the Clonk height which is obviously really 20px high. The mushroom is like max. 16px high. I don't know if there is a reason for this.

Both are on this picture. It does not bother me but if anyone wonders why the mushroom fire is as big as a burning Clonk..
Parent - - By Sven2 [de] Date 2015-01-29 23:54
Some shapes seem to be off. I noticed that trees and mushrooms start burning if there's just one pixel of lava at the bottom. That may be realistic, but it sucks for gameplay in volcano scenarios.

The chest having the shape of the open chest has the advantage that you can only construct it in places where there's enough height to open it. It also means there's a larger range in which the clonk can interact and open it.

I think there used to be a DefCore property "FireTop", which could be used to control fire positioning independent of shape.
Parent - By Armin [de] Date 2015-01-30 00:13
oh right the chest better remains as it is.
Parent - By Nachtfalter Date 2015-01-10 11:34
Needs still a good amount of contrast!
Reply
Parent - - By Zapper [de] Date 2015-01-17 11:19
I (finally) fixed additive particles again.

Are you still working on the fire effect? :)
Parent - By Armin [de] Date 2015-01-17 11:58
Yes I will make a post about version 11 today.
Parent - - By Armin [de] Date 2015-01-17 16:50 Edited 2015-01-17 17:06
Here is a webm of version 11.

- New is that the fire height 20-99 depends on the fire strenght. If you delete line 330 in Fire.c appendto the fire will rise from the bottom to the top like in the video. I changed that in the current upload so that the fire starts in the middle and goes up and down at the same time. That's because even in Clonk Rage very height burning objects can look weird because of the rotation. Imagine the same tree as in the video with SetR(90) or lying on the floor -> the fire would be in the earth. So that's why the scenario doesn't exacly look like in the video. Maybe it is better to replace that with a rising alpha channel, idk.
- There is some white smoke when an object extinguishes in water ( this wouldn't affect a extinguish spell e.g. ). It is not as height as in the video anymore.
- The 2 (?) big particles are attached to the object so you can move and it doesnt lagg behind as Newton mentioned.
- I noticed a small particle creation gap when the tree is replaced with the black coniferous graphic.
Edit:
And all particles are in Fx*Start. Makes it more readable.
Parent - - By Pyrit Date 2015-01-17 17:42
Now it looks awesome.
...
I just don't like it that weak fires are indicated by sparks coming up. Thats somehow unrealistic imho. A weak fire should be indicated by a small flame somewhere on the object imo. So it look like only a small part of the object is burning.
Oh and the smoke should get slower in Y direction as it travels upwards. So it forms this shape rather than a straight line upwards.
Parent - By Armin [de] Date 2015-01-29 23:03
I removed the strength 1-40 sparks (not the chaotic sparks) and made the flame gaining height AND width from 1-100. Looks different but good, I think.

Smoke: I'm still spamming smoke particles. It might be better to have less of them with higher alpha and even more movement. But I tried to make it look like in the picture. The color is of course grey. The rest is fun because the dramatic orange smoke reminds of a certain burning village in Warcraft 3.
Parent - - By Newton [de] Date 2015-01-19 01:48
Wow, very cool.

Did you try this?

> * not sure about this one, just an idea though: I see the size of the fire is dynamically adapted to the size*con of the object. But then it stays constantly the same size. How about you played around with variating the (height/size) of the flame to simulate this "auflodern" more. Or, as an alternative, variate the lifetime of the fire particles.


This could solve the problem below - for very large fires you would add more fires on the objects, for weak fires you'd only have a smaller fire somewhere on the object (that does not cover the whole object)

The smoke also looks great. One small suggestion regarding the smoke: Make it grow bigger as it looses visibility so that it looks as if the smoke is dispersing (and because of that vanishing). I think it must fade out faster.

Regarding the weak fires Pyrit has a point here. I suggest having less of those flying sparks for weak fires and instead add a different effect for a very weak fire:
1. Have a little (low alpha) fire from the start
2. have "Glut" particles that glow red-yellowish clustered in groups around the object. They'd not move and glow out quickly going from yellow over red to black, while flickering up a bit randomly during that. Not sure though how that'd look, just an idea.
Parent - - By Armin [de] Date 2015-01-29 23:55

>> * not sure about this one, just an idea though: I see the size of the fire is dynamically adapted to the size*con of the object. But then it stays constantly the same size. How about you played around with variating the (height/size) of the flame to simulate this "auflodern" more. Or, as an alternative, variate the lifetime of the fire particles.


The given height in the script leads to the particle speeds. The lifetime of them is always the same. So what I tried was that 100% fire rolls its random height between 80% and 100%. The result looked weird. Most likely because it was too abrupt. So you would have to make a new variable x in the effect for this. It could count up and down between 80 and 100%. Sounds too long-winded for me. Also, the fire damage is still disabled in the scenario. Normally, you would see a 100% fire for a short time or you wouln't see it at all because some things may die before that point iirc. When I think about it... If actual 50-100% fire is too rare in Clonk it might be better to have the 50% height as 100% but with even weaker alpha. Or a fire with minimum size plus such glut particles yeah...
Parent - - By Newton [de] Date 2015-01-30 22:16 Edited 2015-01-30 22:20
That makes sense.

As I understand the fire system, it ist not really a difference if a fire burns with 70% or 100% as in both cases it will burn up. Essentially, only 2 (or 3?) different states need to and should be differenciated.
Parent - - By Zapper [de] Date 2015-01-30 23:10
A fire at 51% still does less damage than a fire at 100%. Even if it will eventually go up to 100%, too
Parent - - By Newton [de] Date 2015-01-31 17:19
Thats what I meant. It only really makes a difference if the fire is above 50% and that must be communicated to the player.
Parent - - By Zapper [de] Date 2015-01-31 18:56
Yeah, true. Back when I created a fire effect, I used the smoke colour for that: grey smoke below 50 and thick black smoke above.
That made it quite obvious when the threshold was met
Parent - - By Maikel Date 2015-01-31 19:27
I have never noticed that!
Parent - By Zapper [de] Date 2015-01-31 19:50
That was in the original fire effect that was not put in the game due to lag. I am not sure how the current version behaves

Additional info: back when I put the fire stuff from the engine into the script, I also created a fire effect to go with it. But when a whole forest was on fire, the frame rate dropped a lot, so I never pushed it
Parent - - By Newton [de] Date 2015-01-30 22:18
Are you still experimenting with it or do you see version 12 as the final version which can be integrated into OC?
Parent - - By Armin [de] Date 2015-01-31 00:05 Edited 2015-01-31 12:19
I think version 13 (no big changes compared to 12) is final enough from my part for now. (Edit: Nah, wait for version 14 with hopefully better performance.) But if someone integrates it he has to search the code where Fire.png is being created and delete it. That's not in Fire.c.

In version 13, I uncommented the fire damage and placed a lorry with flints and fire bombs from Clonk Rage. Fire bombs are in there to make it easier to see a burning environment. Many buildings don't burn when they were destroyed by flints. Also, I fixed steam being too deep under water and I made white particles weaker if the flame is as small as a flame from a fire bomb.
Parent - - By Zapper [de] Date 2015-01-31 07:52
Did you test if the fire lags when you f.e. burn down a forest? Lag was the reason why I didn't put in my fire effect in the first place
Parent - - By Armin [de] Date 2015-01-31 12:17
It is already fast because I can burn down 50 trees at once with more than 30+FPS here but it is not optimized, no. A few lines can be combined and I could add something like "Don't spam more smoke if there are other burning objects right text to you.". And a few particles can maybe lowered without changing the appearance of the fire. Give me a few days, then I test it on my old low-end Intel mobile laptop which was even too bad to start OpenClonk with high-resolution. ;)
Parent - - By Maikel Date 2015-01-31 12:34
Here it lags, so you should try to reduce it a bit, also the fire did not look to good anymore. As a reference I think Gold Rush with twice the amount of trees should look good and not lag for sure.

Also ashes were created with background sky, making a hole in the tunnel material. Should be fixed as well.

Otherwise: great work!
Up Topic Development / Art Workshop / [Particles] Fire
1 2 3 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill