Volumetric Smoke Shader

While i might be able to make this look better by using a more varied sprite sheet for each explosion spike I think this approach might have too many flaws and ultimately a waste of time.




Next I am going to try and replicate this

from what i can see its just a single sprite sheet being emitted at different rates and with different life times.
to get the mad max effect into unity without excessive particle flickering I will have to some how get it all into one particle system which is going to mean some hacky code.

 

I wish they'd just fix their flickering issues so you wouldn't have to jump through all these hoops.

 

Hi! You got yourself a new follower! pls message me if you're about te release that volumetric miracle! Thx

 

And a good review too

 

So i think i worked out how to put multiple particle effects into the one sprite sheet and get unity to play them back separately as if they were two different particle effects but to do this I will need to write a fair bit of code so I'm wondering if anyone had seen a package that does this already?

 

The question is, would that still be flexible enough as a general solution for people to use? I could imagine the spritesheet repacking might cause enough headache for some to not feel like it's worth it to avoid the flickering. If you do all that work now and they actually do fix the flickering in one of the upcoming Unity releases there might no longer be a point in using such a complex technique?
Maybe @Aras knows how likely the flickering is going to be fixed in the near future?

 

I doubt that they are going to fix the flickering any time soon baring them pulling out and replacing shuriken, its a fault with the core architecture that requires a big thing to fix it across all situations and environments. the same fault is in pretty much all games. My fix will only work with particle effects that use the same shader code.

 

I'm hoping to knock out the multi effect sprite sheets in a week but that's still a week of my life i cant get back

 

I was going to knock this out in week right up until I started working with the poorly programmed S*** storm that is animation curves.
It baffles me how they could make something so simple so complex.

 

What problems were you experiencing? I haven't done much with them, but so far it was smooth sailing for me.

 

I solved all my problems, the issue is with how you edit them via code. Animation key frames are hard to edit, don't have complete constructors, require an editor only class to edit the tangents and throw errors that don't describe the problem.

I wrote a function that combines 2 animation curves into the one curve but it took me way longer than I expected.

Now I am moving on to Gradients, hopefully they are quicker / better coded.

 

Nope gradients aren't better coded. for some reason they have a limit of 8 colour nodes. why? surly the performance cost of adding more than 8 nodes isn't that big.

 

Ok, that's way more complicated than what I did with them. Doesn't sound like fun at all . Sounds like you are trying to compress different particle systems into one, right? Just a dumb question, but would it work to have different particle systems without renderers work normally to simulate the particle positions, and then use another particle system with your scripting magic to just directly draw the particles of the other systems? You'd have to keep track of which particle represents which and I'm not sure if it would be a good idea or if particle systems without active renderers even produce the particle data you'd need. Just a thought... likely won't work that easily or you'd probably already done it yourself ^^.

 

Thats a good idea but it doesn't solve a couple of things that i want to solve like splitting the sprite sheet up into separate animations and making sub emitted particles match the size and colour of their parents.

 

Hi, I am interested in your product, does it support HDR lighting and emission? And does it work with unity's SSRR?

 

HDR lighting is somewhat supported (tested without bugs but not fully tweaked for artist manipulation) but will be much better supported in the next update which should be out by the end of the month, all the fire effects in the last couple of pages are full HDR and will be included. As for SSRR as far as i know no transparent object (particles included) can be reflected. Every pixel on your screen in a game has a single depth value (how far away from the camera it is) this is used to make sure objects in the distance with a high depth value are not drawn on top of nearer objects with a low depth value. transparent objects (Like windows) don't write their depth to the depth buffer because they want objects behind them to be visible (same for smoke). Screen space reflections work by working out which direction a reflective surface is facing then walking across the pixels in the screen testing there depth to see if it gets in the way of the reflective ray. Because transparent objects (smoke included) don't write to the depth buffer so they can't be reflected correctly in screen space reflections.

grey = smoke, green = depth buffer , dark blue and red = solid objects, light blue = reflective surface , yellow dots = SSRR ray marches, purple = final pixel used in reflection.


If you need smoke to show up in a reflection you have to do it as a custom post process or use planar or cube mapped reflections.

I hope that answered your question

 

Thank you for the reply, now in your post you mentioned defer rendering particle support, does that mean it will be compatible with SSRR sometime soon or it is something else entirely?

And I am pretty sure the new Uncharted 4 has particles reflected on surfaces, what is likely their implementation and is it something you will consider in your package?

 

Short of me writing my own version of SSRR I don't think my particles or anyone's particles will be SSRR compatible for the reasons I highlighted in the post above. As for Uncharted 4 I wasn't able to find an image of smoke particles being reflected so I'm not sure how they are doing it. I had a chat to the guy who did the particles for Naughty Dog and he said he used multiple texture samples to get the particle lighting but he never mentioned particle reflection. if you can find a picture of it or even better a video I might be able to tell you.

If you need particle reflection you will be limited to planar reflections, cube map reflections and hopefully in some distant future sparse voxel octree reflections. I cant see transparent objects being reflected in SSRR without a major change to the technology. Transparent objects are not in a ray-traceable or ray-marchable format in unity at the moment and until that changes any technique that needs ray march/tracing will fail.

what is the reason you need particle reflections? if you explain it to me I might know a work around.

 

The scene I am working on have many highly smooth reflective surfaces, the hacky way I did before was using defer cutout to simulate particles with obvious drawbacks. Particle lighting was obviously one of them. I would love to hear your work around.

 

One option would be a 2 pass shader where the soft transparent edges of particles are done using a forward transparent shader while the solid center part of the particles are shaded using a differed cutout shader. this approach is the easiest and could give you smoke in your reflections but the reflection smoke would be smaller than the non reflection smoke.

alternatively you could render all the hard objects in your scene then make a copy of the render buffer, one copy you would render the particles using a differed shader then use that to get the SSRR reflections. you would apply the reflections to the non differed version and continue to render the particles normally. this approach would get you good consistent reflections where the particle reflections line up with the non particle reflections but it requires you to edit / write your own SSRR and could be costly performance wise. this approach and the previous approach would also not work well with highly transparent objects like glass or fog because it will make them ether disappear or become 100 percent solid.

another option would be to blend SSRR with a transparent object only cube map. you would need to render all the hard objects to a cube map then use the depth map from that to render the transparent objects so that transparent objects behind a wall would not be included in the reflections. then take the SSRR and blend it with the cubemap lookup using the alpha in the cubemap. again this would require you to write your own SSRR and it may also create graphical glitches where the hard object SSRR reflections don't line up with the soft object cube map reflections. This approach would deal better with highly transparent objects like fog or dust.

Of all these options the first will be the easiest, the second will get you the best results especially if you dither the low transparency particles and the final option will work very well in situations where the transparent objects don't interact much with the non transparent objects (plane flying through a cloud for example). All of them require at least a completely reprogrammed particle shader or a complete redesign of both SSRR and the unity render pipeline which is a little out of scope for my 20$ particle shader package.

anyway hope this helps, and if you do find a solution i would love to know and if you don't I would recommend buying my particle package because its the best out there and will make your game look that much better.

 

Bought, keeping an eye out for updates.

 

Just tried out the package, I have to say the sprite sheet choppiness of the smoke in the demo scene is very distracting, can you do something to lerp the sprites changes? The sprite sheet animate at around 6-12 FPS, or do I have to look for procedural generation to fix it?

 

unfortunately unity does not pass enough data for me to lerp/blend one frame with the next it only gives me the UV's (texture coordinates) for the current frame not the next one which makes it difficult to lerp. It also doesn't tell me how far through the current frame Is which makes lerping extra hard. I have thought of attempting some kind of flow mapping but that doesn't play well with texture pre fetching and causes a thing called dependent texture reads which is death to performance on a lot of platforms. The easiest solution I have found is to use a bigger texture with more sprite frames on it but that does cut into memory.

 

After much buggering around I have packed particles working and can now emit particles that use separate parts of a sprite sheet yet are all part of the same particle emitter removing any sorting issues. I should have a demo gif up shortly

 

Ok so this is a gif of 1 particle system emitting particles out of 16 sub emitters using custom code each one only displaying a pixel from this tiny texture

(what is this? a texture for ants?)


note how no square colour ends up on top of everything else


So what does this mean? by putting all may textures in a single atlas i can draw all my particles at once provided they use the same shader settings. this allows me to do things like have a sprite sequence for sparks that i can merge with a sprite sequence for fire. it also alows me to do things like have an effect that transitions from flame to light smoke without popping.

there still is a lot of work left to do and I'm not sure if the current code layout is the best, I suspect using some of Martin_H's ideas might make this easier from an artists perspective.

 

I implemented martin Martin_H's idea of tying the main particles to other particle systems, the upside is you get all the controls you get off normal particle systems like colour, collision and wind. The down side is you have to run double the number of particle systems to get the same effect which will create an additional performance cost.


there are still a few small things i need to fix like particle frames not ending correctly but I think I'm on the right path.
now all I need to do is integrate my particle emitter code and my particle early kill code and we should be good as gravy.

 

Awesome! I'm glad my idea wasn't too far out . Does the additional cost come from pure CPU calculations or additional drawcalls? If it's just CPU, could it possibly still be faster in certain usecases, because you save on total drawcalls by combining several small particlesystems into one big one that you can draw in one go?

Do you think it might also be possible to automate the spritesheet packing so that people could basically setup their emitters and sub-emitters as they are used to, and then add your script on the parent particlesystem and everything gets put into the new spritesheet automagically? That would also help a lot in converting older particle prefabs.

If there's a siginificant drawcall advantage in common enough usecases, then I could see such a thing add tremendous value to your package as a whole. IF you can get it considerably faster, that might even be more interesting to some people than the normal mapped particles I'd imagine.

 

Draw calls I'm not sure about, I will have to test but I think the particle systems don't run if they are not drawn so I'm kinda forced to draw all the systems just to get the data I need out of them. as for automating the particle packing It is a possibility but some of the key pieces of data like the TextureSheetAnimationCurve are not available to me.

 

I just did a test and It seems like it might work when the unwanted particles are put onto a hidden layer but its hard to tell with me running it in the editor

 

I have been working on particle sub emitters, unity by default has no ability that i could find to scale your child particles based on the size of your parent particles.
to create nice spiky explosions like this



I need the ability to create sub emitted particles that scale in size.
this Is what I have developed so far


additionally unity has no functionality to change the emit rate based on the size of the particle.
so ether you emit too many particles at the base where the particles are big or you emit to little at the tips where the particles are small and more are needed to keep a consistent spike.

example of tips disconnecting


with my system the particle emit rate increases the smaller the particles are keeping the spike solid without excessively over emitting.

you can see the particle emit rate go up as the particle gets smaller. keeping the particle coverage roughly the same.


there is still a lot more work to do and this is taking longer than I would like but hopefully i should have the emitter side roughly done by the end of the week. a few things left on my wish list are velocity aligned billboarded particles, once i have that I think I will have all the tools I need to make the explosions from Mad Max

 

Wow fantastic work, cant wait to see the final outcome.

 

With any fast moving object particle or otherwise the high movement between frames can cause issues. If you just emit particles at it's known location each frame it causes gaps in the trails, to get a smooth trail you need to guess the position of the object between frames and spawn the trail there as well. Unity's particle system makes this extra difficult because it doesn't store a previous location of the particle.

the red dots are the known locations of particles the white dots are estimated locations.

My approach still had some flaws. Normally when you are adding a particle trail to something you calculate the distance it has moved each frame and add it to a total distanced moved value. When the total distance moved value gets bigger than your distance between particle emit value you spawn a particle and subtract the distance between particle emit value from the total distance moved value.
Unity doesn't give you a way to track/store the total distance moved value per particle. My solution to that is to convert the distance between particle emit value to a time value using the particles velocity, then I divide the time since start up this frame by the time between particle emit then compare the resulting value to the time since statup last frame diveded by the time between particle emit. If the last frame had more particles since startup than this frame then that means you need to emit a particle.
the code for all that looks roughtly like this

float TimeBetweenParticles = DistanceBetweenParticles / Particle.Velocity;

float ParticlesSinceStartupThisFrame = Time.TimeSinceLevelLoad / TimeBetweenParticles ;
float ParticlesSinceStartupLastFrame = LastLevelLoadTime / TimeBetweenParticles ;

float Difference = ParticlesSinceStartupThisFrame - ParticlesSinceStartupLastFrame;

if(Difference > 0) EmitParticlesThisManyTimes(Difference);

this seems to work with low velocity particles quite well especially when TimeBetweenParticles is converted to a power of 2 but with high velocity particles it becomes unstable and can cause breaks in the trail.

When it works though it works perfectly. the following gif is of the overdraw of a particle sequence. notice how even it is despite the changing particle size,speed and emit rate


bit of fun with inherited velocity and random force

 

So glad I picked up this system. That last gif is perfect for an impact explosion effect for a large caliber shell.
Can already picture it when completed.

 

@jack riddell : maybe you should have a chat with @richardkettlewell . He seems to be working on the particle system since he mentioned something he has implemented for the 5.5 release. Maybe you two should talk about what's coming up next so that you don't implement stuff that going to be in one of the next updates anyway, or even better: maybe you can inspire some new features for the particle system to be implemented in the next releases, that would help your work?

 

Still working on explosions, looks ok but its not as good as I would like.
feel like its missing something but I'm nor sure what.


I think explosions and fire are not what my shaders are best at.
With fire and explosions the resulting smoke is often dark/black which doesn't give the normal mapping much to work with.

 

It's a really good start I'd say. The problems I still see, I've also seen in every other assetstore explosion effect, that isn't just a single pre-rendered spritesheet. That doesn't need to mean it can't be solved though, just that no one went that extra mile or two. ^^

Pause the GIF when the fire starts to dissolve into smoke. What you see is transparent grey over bright yellow, that creates a color that you wouldn't see in a real explosion. Look at the slowmo part of this video:

Whenever a bit of smoke gets in front of bright fire, the fire colors the smoke with it's light. The resulting color shade is more saturated and tends to be more red. That's basically the same reason why for my fire shader I made the color fade towards red first, in the soft-particle aspect of the shader. When I paint fire in Photoshop, I often just paint it in black and white, as sort of a "heatmap" and put a gradient map over there that goes black>red>orange>yellow>white. That guarantuees that every shade falls within the spectrum of believable colors for fire. It has one problem though, the alpha mask for the gradient map needs to work together with the underlying greyscale value. If I try to keep the fire separate on a single layer and put the gradient map on as a clipping mask, I must take care to guide the colors towards darker shades in the transparent areas, or else I'll again fall outside of the realistic color spectrum with the final result, e.g. transparent light yellow.
I don't know enough about what's possible with shaders to give you a solution. It would probably require to commit to making it a fire-and smoke shader, instead of the general purpose shader you are going for. It might also require different passes, which may be too much of a performance hit, I don't know. As a start you could try to bake more lighting into the smoke part of the sim, so that in the earlier stages of the explosion the smoke is lit brighter and gets its color from that (animated point light at the core maybe). You might also need to make the smoke less transparent as long as the flames are still around. Higher FPS on the whole spritesheet would help too, at the moment it still feels a bit jittery towards mid and end. Also there seems to be a difference between oil and gas explosions in the time the smoke stays around afterwards. Look at these two. It seems like for gas explosions the smoke dissolves a lot quicker than for burning oil.

And an unrelated question: have you tried the new blender version yet? I think it's supposed to offer gpu rendering of fire and smoke now, but I haven't tested it.

 

I have been using 2.77 and it has gpu rendering and is much faster than cpu.

 

I added a light to the center of the explosion and it sort of does what you are talking about. I still need to animate the lights brightness and colour to match what is going on in the explosion but i think I'm getting closer to something that i can sell

 

Order seems a bit off with those grey tentacle-like trails, they're the high velocity bits that should be happening at the very start of the explosion and the fireball rises to engulf them, not shooting out of the fireball after it's well on its way.

 

with a few more tweaks and an animated light colour / intensity.

they all start at the same time but I get your point i'll try offsetting the main explosion start

 

A lot better! Maybe just make the "trails" much faster so that they take 1/3 the time to reach their final length.
How do the explosions look in an isometric perspective? And how is performance for having many of them, like for a carpet bombing airstrike?

 

as seen from a 45 degree downward angle


due to the sprite sheet being made for side on viewing a lot of the key details are lost.

 

I have been working on a fire ball sprite sheet and thought I would render it out first using the blender lighting to bake in the light details so I can compare how close I am getting with my in game shader lighting.

this is done using 128 frames but I think ill cut it down to 64 for the next render to save time

 

pre rendered on the left, my stuff on the right. close but still needs some work getting rid of the normal mapping dead spots in the middle.

 

changed my normal map baking rig, it now has 30 lights which isn't greate for render times but the results are much better

(old version with 6 lights)


(new version with 30 lights )


there is still a few areas not getting correctly normal mapped and this new approach has added some additional false lighting on the back side of the particle facing away from the light but I think its a big improvement.

 

Another comparison, this time of emissive lighting

not a 100% match but considering the amount of corner cutting I'm doing for performance I think its pretty good.

 

Awesome progress, keep up the great work!

Looks a lot better than I feared it would from the wrong perspective. Nice!

 

I have great concern over frame transition and don't mind sacrifice some perf for more frames, well you include something like 8k 500+ frames sheet or the blender source so I make it myself?

 

I am planing on adding the source blender files with the package so you can go crazy and make 1000 frame renders or create your own smoke effects and render them out. I have written up some instructions on the process you can follow step by step.

 

still need to tweak a few things like the alpha and the normal mapping towards the end of the particles life but I think it shows promise.