Volumetric Smoke Shader

BigFlame1 renders pretty fast at 7 minutes on my modest 2600K/660Ti. I think you need a hardware upgrade or need to enable your GPU in Blender's settings.

 

Did you render the same frame #50 after baking the full smoke sim? Could be that other frames render faster or slower. Since my gtx 670 died I only have a gtx 660, which I doubt is that much slower than the 660ti. I'll buy a gtx 1060 soon-ish. I did check that GPU rendering is enabled, but thanks for the heads up.

 

Free'd the bakes, re-baked and rendered frame 50, which took 10:19.85. Still seems like something's off. I've got my new PC built and burning in, getting a 1080 in about a month, which should hopefully last another 5 years like this one.

 

@jack-riddell

Here is the normal issue I told you about. When you look around, the normals are facing the camera look direction. The smoke stack and the trees get different lighting even when the directional light source is static. If you are surrounded by these particles the whole world morphs like crazy.



Below is an example of how the normal mapped particles work great. If you rotate around the particles then the normals will always face the camera position, since the view direction is static in comparison to the particles.


If you can make the normals face the camera position, then these particles would be just about the most useful asset on the asset store. I understand that adding custom normals to each particle quad would have a performance penalty, but the graphical benefits would be huge.

 

Interesting, thanks for testing again. I'll give it another try and see if something was bogging down the gpu during the first render. I likely had Unity running in the background, but normally that should hurt, I do it all the time while gaming.

The 660TI doesn't happen to be one of those 2-on-1 cards, right? There were some exotic cards during the 5xx cycle I think, where basically an sli setup was put onto a single card. I'm not sure though, and I thought the 6xx series didn't have a card with that setup. I'll let you know how the second render turns out and maybe also try rendering on CPU for comparison.

 

It took 11 minutes on my GPU now 0_o. I have no explanation except maybe something else was still demanding GPU resources on the first attempt.

The CPU render I had to abort after 33 minutes where it was around ~60% finished, so I definitely didn't have it set to CPU for the 22 minute render.

 

I see the issue your having and i have an idea how to solve it. my normals are already in camera space but the light directions which i get from unity are in view direction space and that is creating the lighting changes you see there.

 

I updated my graphics card driver and downloaded the web gl plugin and everything broke. Looks like I might be delayed for a while.

 

So its defiantly the graphics driver which raises the question is the latest graphics driver for my nividia card wrong in some way and that is braking my shader or was my old driver wrong and somehow letting my shader run when it shouldn't? ether way I am wishing i did more testing earlier .

 

Good luck fixing the issues!
For what it's worth, I have v358.91 and the next time I update will be once I've bought a new card. Never change a running system ^^.

 

Its probably for the best. If a graphics card update is all it takes to tank my shader then the shader is not ready for prime time.

 

put together a solution but still needs some testing and rolling out to all the different variants of the shader. Upside is my shader will now be compatible with webgl and lower end devices. downside is it is relying on some unreleased/documented unity features so who knows what will happen in the future.

 

Added inter frame blending, makes everything look silky smooth.

 

Sounds awesome!

I remember you saying a while ago you did some scripting magic to the handling of particle systems. Is it still possible to manually emit from a particle system? The way I've set it up is to have 1 particle system per commonly used effect like fire, black smoke, dust, white smoke rocket trails etc., and then I manually reposition the particle system's transform in each frame and emit particles where they are needed. The black smoke for the fire is a sub emitter set to spawn on birth and fade in alpha over time. At the moment I'm still using stock and my own shaders for it, but performance is asking for a better solution because I need tons of particles to make it look good. It'll be interesting to see if that performs better with your solution in place, since you mentioned RTS-scale games could benefit from the lower particle count needed to make it look good.

 

The core shader is self contained and does not rely on outside components so anything that works with the stock shaders should work with this. The code I was making to handle the particle emitters is not finished. at the moment i am only using a single script to randomly cull half the particles after spawn to stop over draw.

I finished off the shader code yesterday so I should be running beta tests soon once I package it all up. in the meantime here is a HTML5 demo of it. there is one rendering bug I still need to squash but its getting close.

https://9dcfcedd2304117150d79e4cef32f3ce7f18ae2c.googledrive.com/host/0Byw8LRPFCMbMZlY0ejNtRU1aZjg/

 

Is there an option to adjust how much light affect the smoke? I want some very exaggerated effect but using light with high intensity is not an option.

 

you can make a material that has high contrast but I don't have a light multiply value in the material.

 

I have decided this thread has gotten a bit long and is spanning a few too many products so i have created a new thread over here http://forum.unity3d.com/threads/normal-mapped-smoke-and-fire.426272/ for my current normal mapped particle project which I'm calling Lit smoke and fire. I am also about to start up beta testing so head over there and post if you want to get in on the beta test.

 

With my other package waiting for unity to review it I have started porting the art assets over to ANMP.

(wip)

my other package comes with a bunch of fire assets. while I am porting across the different fire textures I can also recolor them to have different colours. So far I have just a red/yellow flame but I was also thinking of doing blue, green and maybe a pink same as what I have here.


If anyone has any other ideas for colours just add them below and I will try and implement them.

 

So the smoke and flame textures are done and all that's left is to package them up and upload the new version to unity but that so going to take 5 - 10 days to get reviewed and everything so who wants them now? post below and ill send a link to a package when they finish uploading to drop box. just a heads up there are 96 textures all up so the package might be a bit on the large side.

 

Could you please elaborate a bit on the process of recoloring? I thought the color was entirely done in the shader with the new code you made for the mobile version? Is that different for the ANMP package? Or are you talking about prefabs? I'm a bit confused.

I'd love to take a peek .

 

I have separated out the flame effects and recolored it so it can be used in a simple unity stock additive particle effect. ANMP is going to need a full rebuild to take advantage of the new stuff in the latest unity release and that is going to take some time. In the meantime I am doing a stopgap upgrade to the stock ANMP package with some new art to make it more usable to people without the time to bake out their own effects and to bring it more in line with my Lit Smoke And Fire Package.

 

would like to use the effect, would be useful to give out the recommended settings for the shaders too, I could never get it to look as good as yours.

 

Progress on porting all the assets from lit smoke and fire.

for the smoke here i am using a .6 light wrap around and a .6 light multiplier, I have the ambient light turned down and have the smoke tinted quite dark. I also have a light at the base of the particle effect and I am using a particle effect to create some fake bloom around the fire. I use bloom and occasionally colour correction to make the fire look brighter and add more contrast to the shadows.

 

I can get the smoke to look decent, what is your particle set up fro the flame?

 

In that example i am using a additive shader for the flames. I also have a particle system that has almost the same settings as the flames with a smooth glow texture applied to fake some bloom.

 

Hope you don't mind, wanted to share how I'm using your nifty smoke in my upcoming game

, smoke bombs to give cover in multiplayer demolition game, and smoke from bombs/grenades. Actually looks very good when walking inside the smoke, the sun/flares look good to me Still a work in progress..

 

Great to see how this is coming along. I'd love to give it a try!

 

To be honest this thread has disappointed me so much, it was a really good start when it had all these awesome shadows that particles were able to cast on each other and on the ground, but then you released this normal mapped particles and all these cool features just gone (accordingly to the latest demos), it's really disappointing..
I thought I finally found the solution for my project but looks like I was wrong...
I was expecting just a good shader that will give me the ability to control the particle shading (softness, shadow casting, environment lighting, light emitters amount etc.) but instead of making just a good system - you keep making useless demo scenes, it looks like you confused the process of creating of great system with the art, because people don't need the art, they need the ability to create the art using your system (which is impossible right now).
If I'm wrong because of misunderstanding of what's going on with your asset and this thread please let me know.

P.s.
I like the last sentence from your documentation:

"Finally, Advanced Normal Mapped Particles relies heavily on the art assets you use. If you use poor quality art, Advanced Normal Mapped Particles won't magically make it better"

But what if I have a good art but a poor quality particle shader?

 

My understanding is that the tech behind particles casting and receiving shadows and the tech behind particles being normal-mapped is vastly different and doesn't have that much overlap. I'd consider this 2 different products rather than a change of direction on 1 product. If shadow casting and self-shadowing particles were easy to do we would already have a solution for that from someone.

Do you also have smoke sim particle spritesheets with baked in normal map data? Because those seem to be quite the rarity outside of this project. I've seen something similar exactly once somewhere else and that wasn't remotly as high-quality. If your particle effects look nice but don't have the necessary normalmap data, then no shader can magically create that data and draw realistic lighting on your assets. I think that might be what the statement is trying to tell you.The art being tailored to the shader's required input data is mandatory, like it will be with most complex special purpose shaders. I'm an artist myself but trust me, making all those particle art assets yourself would be out of scope even for me, because you're looking at weeks to months of fulltime work to make those. It would be unrealistic to just deliver the shader and expect customers to all be able to create the appropriate art assets themselves.

 

Each project has its own visual style and unique requirements for visual effects, and very often these projects have really good artists and all that they need is a powerful tool to be able to create any effect they may want. I'm an artist, and for my project I need a smoke effect for car wheels and I do a smoke simulation for it using FumeFX in 3ds max and then I render it to a sprite sheet, so in result I have a good art, but I still don't have a good shader to make it look good...
In my opinion, you've gone in a wrong direction by separating normal mapped particles from the awesome tool that you already had, and instead of finishing your potentially great tool - you're making low-quality demo scenes of what? It could be a revolutionary system but for this moment it's not...

 

Advanced Normal Mapped Particles cannot cast shadows on the world and will not receive shadows from the world... Advanced Normal Mapped Particles do not cast shadows onto each other..

wow, that's what we get after all that we saw in your first posts...

 

Impossible that's impossible omg omg omg.
https://www.assetstore.unity3d.com/en/#!/content/58571

Martin_H
lol confused you with jack-riddell so it probably means that my previous 2 comments are not counted

 

Just to clarify because it looked like you were replying to me: I'm not the author of this asset. [Edit: seems like you realized this too now.]

...

Submitted half a year ago, no reviews and not a single update since. I wouldn't set my expectations too high. But I haven't tried it myself, so I can't really say anything about that other asset.

 

yeah, I will make a review when I buy it (when my project will be on the stage of visual improvements and if nothing will be changed in the jack-riddell's asset).
And yes it's submitted half a year ago but after all it's definitely better than the other "alternatives".

 

so here is the current state of play, volumetric particle lighting (at the start of this thread) is good for big details but can not do small details without a HUGE particle count (in the thousands). Once I realized that volumetric particle lighting on its own could not deliver the graphic fidelity I wanted I developed normal mapped particles to bridge the gap between big and small with the goal of unifying the 2 in one super particle lighting package. The last 2 packages have been to develop the graphical quality and performance of the small stuff up to a level I am happy with.

 

Particle shaders are particularly hard to develop because they are very performance sensitive. It is very easy to make an amazing looking shader that no one can run.
The advanced normal mapped particle shaders are the only ones that I know of that do true per pixel normal mapping. and while not running as fast as i would like they still outperform shaders that have a lot fewer features. Particle shadow casting and receiving is unfortunately not available from the stock unity engine and while i have built my own workarounds they are far from production ready and have not been released as a result (although if you look in the Advanced normal mapped particles code you can see the shadow casting code commented out, if you remove the comments it should work).

I

 

While i have been building a lot of demo scenes and making a lot of artwork this has been to drive the development of the package. I needed to work with the shader to see how it all came together and what needed improvement. Art is not my strong suit and if i could get away with it i would just spend all my time writing code but when working with shaders and especially when selling on the asset store you need both.

 

What this package delivers for its price is outstanding, as a novice game designer with no experience of sprite sheets and building art for explosions etc.
Having this one stop solution that receives light input from its surroundings is heaven sent.
While I may not get the most out of it using it only for smoke and fire effects, they look outstanding and really adds to my project.
Thanks Jack for bringing my particles to a new level.

 

When I just started developing graphic solutions for my game project, I've noticed (actually I noticed it a long time ago) that in every game the wheels smoke usually looks very horrible, and the reason for it is the lighting, the particles are just not affected by lighting and not affect the lighting in the scene. So I've decided that my game won't have this downside and I started searching the solution, I found this thread and I was really impressed by the job that you did, but then when you started adding new features and created mobile version - these thing I was looking for just gone, so I kept searching for the solution. What I found for this moment is the solution I've posted above, so for the first look it seems better because it has true soft shadows instead of dithered ones that you had, so pretty soon I hope I will be able to test it and write back about its performance if someone is interested. It looks like it doesn't have the ability to use a normal map, but for me, the lighting is more important.

 

if you are working on car smoke this might be of interest to you.

 

Yeah, but there's still no correct lighting on the particles, and it's fine since it's a mobile game, but I'm developing a PC game so I don't have these limitations

 

Hi, could I ask what the difference is between the Lit Smoke and Fire asset and
Advanced Normal Mapped Particles asset ? Is the one focused around being mobile friendly? Do we have tp pay for that new asset separately?

 

Sorry for newbie questions, but why? was the smoke made using your shader?

 

No that smoke was made using some shaders I wrote in the past but did not release on the store. I thought it might be of interest to him because it shows semi lit smoke being used in a car game.

 

Lit smoke and fire is written in OpenGL and will not function in direct x. It takes advantage of some features unity only enables on mobile builds. Lit smoke and fire also has better emissive particle lighting and should run faster. ANMP on the other hand has support for direct x and non mobile platforms, can use an albedo map for debris particles and has more soft particle options.

TLDR lit smoke and fire is for mobile ANMP is for everything else

 

Lol how is that possible that mobile shader has better graphics than PC?)))

 

Well, at least it speak volumn about how awesome the mobile shaders are. I am just waiting for him to convert it to be desktop compabtible.

 

I noticed that the smoke does not reflect on default unity water, is it intended?
And will you add support for the new vulcan API? It looks very promising.

 

Do other transparent particles reflect on that kind of water? Is that a planar reflection with a rendertexture or is it an SSRR effect? If the reflection technique needs zbuffer writes like SSRR does, then all transparent particles won't reflect.