[Open Source] TC Particles: millions of GPU particles

If you updated AMD Catalyst to v. 13.12 - you really shouldn't. This version is VERY buggy. They're implemented their "cutting-edge TressFX"... and broke all the rest. _EVERY_ CG software I have installed was glitching with 13.12.
Try to uninstall this version and re-install Catalyst 13.9.

 

Thanks for the advice but it wasn't working with the previous driver version either.

 

I'm having the exact same issue, even just tried the moon dust scene since you mentioned it and it was the only one that worked!,web demo plays perfectly never drops below 60fps.

Unity Free
Win 7 x64
AMD HD7850
tried 14.1beta driver with no luck, think i was on 13.11 before that.

 

I reported this same problem a while ago:
http://forum.unity3d.com/threads/17...pecial-again?p=1309908&viewfull=1#post1309908

A few months ago I upgraded my entire system *except* for the XFX 7870 graphics card and I am still getting the driver hanging issue..
The upgraded was my motherboard, RAM, CPU, hard drive and a clean install of Windows 8, later upgraded to 8.1

 

@krautsourced: Great
@LeoSalles: Very odd The force must be not linked up somehow, the scene looks fine here. If you select the force, and you look at the preview, does it seem ok?

@CaptainChristian: I do want to expose as much as possible ( I hate how locked down shuriken is), but I might be missing out on some things. Can you name the parameters you're missing? Or shoot me a mail at tinycubestudio@gmail.com

@XMachinaX: If there is no DX11, you can specify a shuriken system that will be used as fallback

@tomato_comet: In the demo some of the projectiles have lights attached to them to fake it. There's no way to emit particles from each particle individually though. What might be intresting is to simulate lights as particles. That's currently already possible, just a bunch of scripting work

@Lex-DRL: Intresting proposition to do this as well, but seems like it'd reck the CPU, especially for the GPU<->CPU transfer

@PatHightree: Not directly, but you can use forces to manipulate the direction the particles move in.

@overthere, Lord Simpson, Bryan Pope: Oh my, this sounds really bad. I didn't know the issue wasn't fixed for you yet Bryan Pope, I am sorry to hear abut these troubles. I should've kept my old ATI card around. I will try to get my hands on one to debug this properly. It sounds like it wasn't always the case, since the webplayer works, so at least that narrows it down. Also, when you _create_ a webplayer (or PC build), does that run successfully?

-Arthur

 

OK tried both webplayer and pc exports. Both worked for TerrainCollision (moon one) but not for fx1 or fireflies (didn't try all of failing scenes).
This is with an AMD7950 graphics card.
Let me know if you need any logs etc.

Also happy to give you a chance to fix but if after a reasonable amount of time its not working I'd like a refund.
Cheers

 

Other test I've done is just to drag in prefabs from samples folder.
Top three Grenade, GrenadeSplode and GUItext run OK
Plasmashot and Walker get same hard driver crash and reset.

All the tests I've run have been with new project with 3D presets, no other assets imported

Cheers

 

The force looks fine, I've tried to mess around with the parameters but the only thing I've managed to accomplish was for it not to affect the torch and so it would only go up, instead of going on a tangent.

 

Hi,

Thanks for making this asset, it's amazing the effects I can manage with it, though I admit I'm a colossal rookie when it comes to the more complex stuff. Hopefully I'll be able to get my head around it with some help from you guys.

I've got a box shaped system that's filling the viewable area from the camera. In separate game objects (but inside the system's area) I have several orbs, each with a negative radial force attached to them. These orbs will also have a collision on them but I've yet to get that far.

The idea is, the particles emitted from the system represent a sentient entity that wants to consume everything and therefore are rushing towards the orbs, but once the collision bits are added it'll be held back by the "aura" of the orbs.

The problem I'm having is that of my four orbs currently in the system, only one of them seems to be pulling the particles towards it. Even stranger is that as I switch off the orbs, the next one at the top of my scene's hierarchy list then starts pulling the particles in.

Is there any way to have all four forces affecting the system?

Thanks!

Ben

 

Also, is it possible to change a particle's size based on the speed it's moving?

Thanks again!

 

To affect the particles by more forces you need to set this up in the emitter's properties in the inspector. Under Forces section you can type in how many forces may act on the system at the time. By default it's set to 1 so probably that's why you're having problems with your scene.

The same thing applies to colliders, there is a separate section for that.

As far as I know there isn't any way to make particle size to be based on the speed (at least not from the inspector), maybe you can script this per particle but I haven't been experimenting with the system as much yet.

 

Excellent, that fixed it! Thanks very much!

I'll have to take a look at the script but I don't imagine I'll be able to enlighten anybody with what I find.

Thanks again!

 

I've sent you a pm a while ago.

 

This has got to be one of the best particle systems I have ever seen in recent memory, and the sword demos from alloy prove this as well... I have a question in regards to particles in game... could I use this to simulate blood shooting out of someone's neck and spilling onto the ground, or would I be forced to use a liquid simulator? The demos are crazy... keep it up man.

 

Hi again,

I've placed a particle system behind a bunch of meshes to replace an old Unity particle system, but for some reason the new effect isn't being occluded by the meshes in front of it. I'm hoping this is an easy fix and I'm just being a noob again.

Thanks!

 

I may have found where the graphics driver hard crash is happening.. I went though and recreated the Forces demo scene property by property, then saving and running after each property change. When I got to Force Texture under Force type and put something in there with Generate Noise (or by selecting NoiseForceSphere), the demo would always cause the hard driver crash. After rebooting my computer and then changing that property to "None (Texture 3D)" the demo would run without crashing.
I then went through all of the other samples, changed all instances of Force Texture to None and they all ran without crashing.

Hopefully this helps in tracking down the problem!

Cheers,

Bryan

 

@ Espion I was witnessing the same thing a couple days ago. After I switched the rendering platform and reloaded Unity, it seemed to have fixed the issue. Worth a try

 

@overthere: Hope you can take a look at the PM I send you

@LeoSalles: I still haven't found anything. I hope this doesn't influence your normal TC Particles usage. I will make sure that the next update works at least on my machine.

@Espion: Awesome to see that Klakwa helped you out Gotta love the unity community

@Klakwa: Thanks, couldn't have said it better.

@Neptune_imaging: Thanks for the compliments Blood is trick as it requires some proper shading work for it's specular, SSS, etc. I think TC particles would be a good starting point though, for the behaviour, and maybe with some shader scripting you'd get awesome effects. At least you could get absurd quantities of blood

@Espion, Zedalis: Odd! I hope the fix from zedalis worked for you.

@Bryan Pope: Thank you very much for this information. I'm sure that that'll help already. I also sent you a PM. Here's hoping that this is fixed soon

 

This is still a problem in 4.3.4 with the latest indie version of TC. Trying to implement the old hotfix breaks things, and trying to make those changes manually doesn't work either.

The only way to get the inspector working seems to be to Import the latest version. Make a particle game object. Exit. Implement the hot fix. Startup unity, open the particle inspector, delete the old version of TCP, then reimport the latest version. I don't understand how that even works.

 

Thanks a bunch Any updates on this?

 

Has anyone run into the error "Maximum number (64) of shader keywords exceeded" when using TC particles? I recently added tc particles to my project (really awesome asset btw!) and it seems that whenever I use a certain combination of assets with tc particles, this error happens and the scene becomes unplayable.

Using tc particles, sunshine! and skyshop in the same scene will trigger this every time, I'm not really sure what the culprit is (does tc particles use a TON of shader keywords?) but I never ran into this until I added tc particles, and I was running a LOT of shader packages (I tried getting rid of everything but what I mentioned above, but to no avail).

Any help/workarounds on this would be appreciated

 

I'm trying to implement a shader for TC Particles, which will fake directional light (to get at least some lighting since TC Particles themselves don't react to any actual lights).
But I'm stuck. Looks like the polygon normal isn't even provided to the shader (in the Mesh render mode).

Is there at least some tricky way to get the mesh normal in the shader for TC particles?

 

Hello,
very excited to use this plugin but upon importing I get a couple errors.

Assets/Plugins/TCParticles/Samples/Standard Assets/Image Effects (Pro Only)/EdgeDetectEffect.cs(7,33): error CS0246: The type or namespace name `ImageEffectBase' could not be found. Are you missing a using directive or an assembly reference?

Assets/Plugins/TCParticles/Samples/Standard Assets/Image Effects (Pro Only)/TiltShift.js(8,25): BCE0018: The name 'PostEffectsBase' does not denote a valid type ('not found').

Any ideas?

 

@Tee_Pee: Im rethinking the Space's system, next update that launches mid april should have it in there. Sorry for the delay.

@venain: Hm, that's very unfortunate I didn't know unity had suchs a limit. TC Particles uses about ~10 shader keywords I say, so with enough packages you will run out at some point. I am not sure why unity would enforce this arbitrary limit. The bad news is that I don't know how to work fix this for you now. The good news is that I do know how to work around it for the next patch - but I can imagine that it's annoying!

@Lex-DRL: Ah cool, would love to see that Normals right now are not sent to the shader, only the vertices of a mesh. There is no inherent reason why though (except performance), so what I think I will do is to make it an option for the shader to request the normals. You could already do it by reading the normals, and sending them as a buffer to the material, but it's of course nice if TC Particles would just handle it.

@pajamajama: Thanks! I hope you will like it. The errors seem to be coming from the image effects - make sure you don't have standard assets imported in your project. Alternatively, feel free to delete those files - TC Particles doesn't need them.



@everyone: I have some preeetty exciting news to share you, relating to nvidia, tablets and unity 5 A full release on that later. Then there's the first AAA indie game using TC Particles, more on that soon too, and there's the patch coming mid-april ish:

-Fully simulate TC Particles in editor, with a window to control playback options etc.
-Finally fixes the crash on some AMD cards
-Option to not simulate the particles, useful when doing point cloud visualizations and such
-Option to send normals to the GPU to use in a shader.
-Redesigned system to handle spaces, hopefully allowing for some more cool effects.
-Exposed more properties in the API
-All variables can now be adjusted at runtime without TC Particles freaking out
-Performance improvments, both on the CPU and GPU.

 

That would be awesome! Especially if there also will be shader constant, like TC_NORMALS_DEFINED, so I can multi_compile it

Also, one more suggestion for the future patch from me...
When updating to the newer version of TC Particles, all the already existing prefabs with TC Particles become broken. So it's a serious problem to manually recreate each TC prefab by cope-pasting each parameter for each particle system.
I'd appreciate if this bug will be fixed.

 

I am considering purchasing TCParticles for a project, but I had a question first that I could not discern from the web example. I would like to have large particle system that is affected by 8 radial attractors (inwards I believe). Can I use that many attractors with and can I control their falloff?

The goal is to have different game objects in the scene and as they move into or near the particles they rip away, consume particles that they are nearest too. Kind of like a galaxy that gets ripped apart based on the gravity of approaching objects.

 

@lex: Thanks for the suggestions The prefab bug sounds bad, I will investigate that for the patch. Hadn't seen it before

@voronoi: Definitely! It's actually where TC Particles is ideal for. In Museum of the Microstar we had 4 forces with a complex falloff pulling on a 400.000 particle star, and 3 turbulence forces working on it... and a ginormous scene around it with many particle FX 8 attractors, even on a lot of particles, is no problem at all

 

One more feature request from me
For now, particle rotation in the "mesh" mode is not so useable. There are only 2 parameters affecting rotation:


This way, I can only set random start rotation and constant rotation speed. I.e., there's no way to mimic natural particle rotation: the faster it moves, the faster it should rotate. While rotation speed should be random between particles, too.
And, of course, 3D object should rotate around all 3 axes. Not only around Y, as it is now.

I can rotate particle randomly in the shader, but I cannot make it dependent on the particle movement. Because to do this, shader needs to know total length of a path travelled by particle. Which is impossible, because shader has access to the instant values only.

So, to be more specific...
Could you:
Just provide one more data value for the shader: particle's total path length? (with it, I can do all the rest in the shader by myself).

OR

1. replace "Start Rotation" parameter with 3 "Start Rotation X/Y/Z" parameters?
2. add "Rotation over speed X/Y/Z" parameters?
3. replace constant "Angular Velosity" parameter with the same widget that lets you choose constant, random between 2 constants, etc.? Also independent parameter for each axis.

 

So, if I could plug a material such as the ones from Alloy, I could get the effect I want... consider this an instant purchase.

 

Hi, any news with TC particles convex mesh collider compatibility ?

 

I have an issue with rendering order where the particles appear on top of the opaque but with a specific setup...

If the camera have deferred rendering, and ambient obscurance script or SSAOEffect at the same time, it will render on top of everything.
As soon I used something that will take use of the ImageEffectOpaque
which will render the post process before the transparent. It break the gpu particle but shuriken seems fine.

Any idea how to fix it ?

Step to reproduce:
-Change camera to deferred rendering
-Add AmbientObscurance component to the camera.
-Create a plane and rotate it to make it look like a wall.
-Drag a prefab of TCParticle like the Fusion orange blast behind the wall.
-Place the camera to look at the wall and observe that you see the blast on top of the plane where it should be hidden by it.

 

Just picked up this really cool tool, having no trouble except this one little thing: stretched particles.

Is there any way to get stretched particles that do not billboard?

 

I've scanned through the thread trying to spot this but can particles be emitted from the surface of a skinned mesh?

 

Seems cool, but the demo isn't working for me, I checked, and I do have a DirectX 11 graphics card, but no particles will show in the demo at any point.

Also, how does this thing compare with Unreal and their fancy particles of eye candy?.

 

Just got ahold of the latest build - thanks so much for making it!!

One thing that would be nice, which might be part of the build you're currently working on, is if we could tweak all of the variables that we can adjust in the inspector at runtime, in a script, including animation curves, particle lifetime, etc.

 

below

 

I love the package but I believe 4.5 broke TC Particles.

Opening the demo scenes, nothing emits, even in the "destruction" samples. I made a new project and imported from the asset store just to make sure it wasn't the project itself.

If anyone found any temporary solutions it would be a great help or I will have to move back to 4.3. Thanks in advance.

 

Hi,
Is this being worked on? I would like to update unity but need to wait for this to work.
Thanks!

 

Hi

So the new Unity 4.5 shader compiler, though being super exciting, broke TC Particles it seems. Luckily it's an easy fix, import this package

http://g2f.nl/0wm5gzy

And you should be good to go again. Some warnings will still be printed due to other changes in 4.5, but they are harmless, the patch will fix that.


Sorry for the late reply here. My day job + university load has only increased over time. Luckily I'll finally able to show it at E3 I hope to meet as many TC Particles people there as I can!

@Lex-DRL: Adding 3 rotation floats to each particle would significantly increase mem usage. I have had a version here with full 3D rotation, and though it was nice, I don't think it's something I want to have for all the systems. Making it an option would be intresting, but hard to do / maintain.

@Neptune-imaging: An alloy shader is somewhat complex, though yes I'd love to do that

@unity_sg: More on that soon, I hope to have depth buffer collisions soon First tests are promising

@BobBobson108: Next patch will definitely help there


I hope to finally squeeze out the time to properly the next patch and upload it (it's not like there's a whole lot left to do on it!). I will post release notes here when it is submitted. Thanks everybody for the continued support and enthusiasm - despite me not being here nearly enough!

 

Thanks for the fix! fixed many errors, but this one still pops up, any ideas?

Assets/Plugins/TCParticles/Samples/Standard Assets/Character Controllers/Sources/Scripts/PlatformInputController.js(5,21): BCE0018: The name 'CharacterMotor' does not denote a valid type ('not found'). Did you mean 'UnityEngine.CharacterJoint'?

Update:
deleted samples folder, now getting this:
Assets/Plugins/Editor/TCParticles/TCOffscreenRendererEditor.cs(5,14): error CS0101: The namespace `global::' already contains a definition for `TCOffscreenRendererEditor'

Thanks

 

Check out what I did with your plugin dude! It's super prototypey, so please excuse that - the particle settings and forces still need a lot of tweaking.

 

Hey,

The link for the Unity 4.5 package is broken. Could you please re-upload it somewhere?

Thanks!

 

Did you ever manage to figure out the faked directional lighting on the particles? I'm pretty interested in something like this (while still maintaining decent performance). Also, in the quickstart tutorial listed on the Dev's website, he mentions mesh particles can be a bit of a performance killer, to what degree are we talking here? I'm working on a scene inside a blood vein with mesh particle platelets colliding with the walls, which tops out at around 4000 particles at a time, how problematic is this going to be? I am really wanting to get some GPU processing going on here but am still trying to figure out if TCparticles is going to be what I need.

 

Will TCParticles be coming to consoles soon? I'm especially interested in the WiiU as it has a powerful GPGPU.


Though the writer of this article may be exaggerating a bit, using the GPGPU should help the WiiU accomplish things that it's weak CPU cannot by itself.
http://www.cinemablend.com/games/Wii-U-Memory-Bandwidth-GPU-More-Powerful-Than-We-Thought-62437.html

 

Hi All Time for an update, but first, questions:

@HeadTrip: Seems your import is broken. Try deleting your TC Particles folder and reimporting the package

@BobBoson: That is so cool! Thanks for sharing that Is the view on the left a superimposed AR view? or was that done in post editing? Really cool, thanks for sharing in any case

@jesta: The new patch is out now, that fixes 4.5

@CofaResearh: Thanks for the interest! The latest patch has the ability to send the normals to the shader for mesh mode. From there you could write a simple one-directional-light shader for meshes. I will include one in the next patch, it's a bit of a bandaid where as particle lighting really needs some proper integration, but I guess it's a start

About the mesh particles: I perhaps should rephrase that, they are much more expensive than normal particles to draw, but still nothing compared to CPU particles. 4000 particles is absolutely nothing It's more that you can drive a million "normal" TC Particles, and with mesh particles I'd start worrying when you're using 200.000, but 4000 is nothing to worry about at all. I hope that helps, if you have any more questions be sure to let me know

@raahilsha: The latest patch makes TC Particles work on PS4 and Xbox One, so consoles are in sight The WII U however does not have a DirectX API, and while it does do GPGPU, it does not do compute shaders What we really need is for unity to start translating the shaders to OpenGL 4 based implementations. I can't disclose too much but here's a little story:

A while back nVidia needed promotional material for their new kepler based tablets. I and a friend somehow got in contact and produced a tablet based version of this little demo:

http://www.alloy.rustltd.com/?page=featured_projects&project=elemental_sword

So yes, we had that running on android The most intresting part of that demo was the fact that it was running on openGL 4, not DirectX 11. Unity worked with us and nVidia to port TC Particles to openGL 4. Again I can't disclose too much, but openGL 4 is not completely out of sight When that happens, wii U and even mac will be supported for TC Particles. So that is the current state of the consoles right now, if I know more I will let you know!


Next post: News flash

 

News Flash

Time for an update. Firstly, TC Particles 1.3b is out:

-Fully simulate TC Particles in the editor, with a window to control playback options etc.
-Finally fixes the crash on some AMD cards
-Works on PS4 / Xbox One now
-Fixes for 4.5
-Reworked the editor layout a bit, more compact, easier to read
-Option to not simulate the particles, useful when doing point cloud visualization and such
-Option to send normals to the GPU to use in a shader. (just add a tag TC_NORMALS to your shader)
-Exposed a lot of properties in the API
-A lot more variables can now be adjusted at runtime without TC Particles freaking out
-Significant GPU Performance improvements
-Fix for stretched billboard
-Reduced CPU overhead

Upgrade guide: If you were using an extension shader, update the particle struct to reflect the on in the ExtensionTemplate.compute example. The size field was removed, use the baseSize field instead

Lastly: As an experiment the price of TC Particles indie has been lowered to 80$. If it works out it will stay that way, if not, well, grab it while it lasts!

Additionally, a lot of for the future has been done. Quick overview:

Shape emitters

TC Particles can simulate millions of particles, but the other way around, simulating millions of systems with just a few particles, would completely blow up your CPU. I feel that there is a lot of missed potential because of that. Imagine every bullet from a machine gun emitting a small particle effect. Right now the overhead of having 100's or even thousands of systems, would just be too much.

To address this I'm always optimizing this overhead, but that can only go so far (though, this patch should already be better ).

Really there only needs to be one system that instructs the look and behavior of a system, that is emitted in a lot of different places. The shape emitters are very simple components that just describe an emission shape. Then link it to a system, and you have a very lightweight particle system.

This is commented out in the code right now as it wasn't quite ready for this update, but it's starting to take shape (no pun intended).


Depth based collisions

The current collision system is nice for a square room, or maybe creating a detailed object out of a few compound colliders, but again it does not scale very well. Imagine an open world game where particles need to collide against everything. Good luck doing that with TC Colliders.

By using the depth buffer however it is possible to collide against every opaque object in the scene, yes, mesh collisions. Even better than mesh collisions though, independent of your scene you'll pay a fixed cost to have collisions for your particle system(s). It could even collide with skinned meshes!

This is in early stages for sure, but it should be coming to the next update.


So that is where TC Particles is right now. Updates have been slow, I realize that, but at least I can finally share why. About a year / year half ago I was picked up by Moon Studios to work on Ori and the blind Forest:

(As a graphics programmer, of course). It started out as a xbox 360 game originally, so no TC Particles in there yet, but we have done some tests and it looks very cool, so the xbox one version just might have them

As the last note, I want to share some projects using TC Particles soon. More on that later! Thanks all for keeping TC Particles going (and respect if you read through this all, whew)

 

Thanks a lot for getting back to me on that. I ended up picking up a copy of TCparticles and I'm pretty impressed. I'm really looking forward to getting my hands on those depth-based collisions you're talking about for the next update (any sort of timeframe for when that might be ? ), as that's what's really bogging our current CPU particles down (4000 platelets colliding with the sides of the blood vessel mesh). I guess I could try to make some kind of approximate tube of box colliders, but it would be a workaround at best. I'm also having a little trouble with getting the particles to render as meshes, I'm not sure if there is another forum somewhere for general use questions? The system seems to disable itself whenever I try to run it with a mesh applied to the renderer.

For the moment we're using TCparticles for general atmospheric particles, which is already showing massive performance increases over shuriken. I'll be following development closely!

Also, congratulations on the new (kind of) job!

 

Is there any chance that you have changed something in 1.3b related to the particle emission mesh geometry orientation or transforms? I'm getting some bizarre results such as the particle y coordinates are now reversed in the emission "plane" compared to what I was seeing before 1.3b. Also, the emission plane seems to perhaps be acting like a billboard and trying to keep facing the camera if I orbit the camera around the emission plane or something similar. This may just be the orientation of the emission plane changing but it is hard to tell if that is the case.

Actually I am using the compute shader extension to place the particles relative to the emission mesh, which is a plane in my case.

Thanks,
K.N. Chaffin

 

@CofaResearch: Awesome to hear that! Thanks for that Sorry, not much of a timeframe yet, it's quite hard to plan stuff next to Ori and the blind Forest - especially now in these stages of the production. The good news is that TC Particles does support tube colliders as a primitive, so depending on what you're trying to do it might already be achievable.

As for the mesh particles: Seem I accidently broke it in 1.3b, wooops. I have submitted a patch to fix this, should be up within 2 days. If you don't want the wait shoot me a mail at tinycubestudio@gmail.com and I will send you the package.

Great to hear it's working out otherwise

@KEN chaffin: Hmm... I didn't change anything in that area that I know of. Only difference that comes close to that area is switching some matrices around. I can't repro either, emit mesh seems to work fine for me, and doesn't rotate with the camera.

Does the gizmo rotate as well? if you comment out your extension shader code, does it still happen? Any particular space settings or other special settings that might be influencing this?

 

Oh! Just realized something else was changed: I removed a field from the particle struct to save VRAM. Make sure you update your particle struct to reflect the one in the extension template, or you will see very weird behaviour. I totally forgot to mention that in the release notes, sorry about that