[Open Source] TC Particles: millions of GPU particles

They seem to be for me, still testing, but the particles seem to render fine in the editor and also standalone builds. I don't think I ever ended up fully testing for myself whether the DK2 with TCparticles beforehand though, once I'd read about problems I put TC particles to the side. Any particular symptoms I should be on the lookout for?

 

At one time my TC-Particles would not render if built for and attached to the Oculus Rift DK2. Everything else in my scene was working okay. I've lost the fox on this and can't remember for sure what was going on. Since I also have a CUDA plugin and a custom TC-P compute shader involved, and passing and populating data in render textures, there are a lot of places for things to go astray. Hopefully Arthur can chime in here when he has a few minutes. He was working with the Unity team to try to get the TC-P with Oculus problems resolved.

Your work sounds promising that the Oculus problems are indeed resolved.

K.N. Chaffin - Texas Tech University Informatics Media Lab

 

Sorry for the very long wait before the answer :

I tried in an new project, with the latest and greatest package from the asset store : same issue.
I also have a warning : Method TCParticleSystemEditor.RenderGizmo is marked with the DrawGizmo attribute but does not take parameters (ComponentType, GizmoType) so will be ignored.

It really is just the visualize window that seems to lose the GameObject whenever you want to visualise the effect.

 

Unfortunately there seems to be some error creep getting into the package as things change... along with Feydwin's error about the visualizer being badly broken, the sample scenes are all starting to generate MissingReferenceException errors, missing script references, and other warnings. The system still seems to work in general, but it does need some maintenance. Would really love it if you (p v loon) could find some time to clean things up in the future as there really doesn't seem to be any other awesome options out there for particles!

 

Anyone tried it with Unity 5.1 yet? It didn't work for me during the beta phase of 5.1 so I fear the worst, but I haven't had a chance to try it on the final release of 5.1 yet.

 

I just installed Unity 5.1 and I'm getting the same shader errors that you were getting with 5.1 beta.

K.N. Chaffin - Texas Tech University Informatics Media Lab

 

same here: not working with unity 5.1

 

I am depressed by the lack of response to the 5.1 issue, especially as I gave advanced warning of it a few weeks ago.

I'll spend a bit of time today seeing if I can fix it myself. Failing that, it looks like I'll end up writing my own particle system to go with the fluid simulation. If that happens, I'll start a new thread in the work in progress forum since it would be inappropriate to continue posting in this one.

 

Luck & much trial and error has enabled me to trace the cause of the compute shader compiler crash.

It's in the BoidsFlockUpdate function. There is something the compiler doesnt like about the groupshared float3's called sumAveragePos and sumAverageVelocity. For example, if I stop avgPos and avgVelocity from making use of those variables, the compiler doesnt crash anymore.

However, I dont have the correct fix for this problem, and even if I botch round it I still cant see any particles in Unity 5.1 with any of the demo scenes. With no error messages or other clues, I am stuck.

 

or elbows : https://www.assetstore.unity3d.com/en/#!/content/24455
I have it, it is working, but a bit complicated.. requires C++ coding...

In any events, i guess p v loon went working on something else and will come back in 6 month , like he did when unity jumped to v 5 ...

 

p v loon has a lot of irons in the fire, including college, but, I hope he finds some time to work on this soon. TC-Particles is still the particle engine of choice for my research. I'm keeping one of my development computers on Unity 5.0xx for the time being.

Another group of developers using a product I developed and then went on to do other things, said that they all said my name five times and sure enough I appeared to answer their questions. We could try that

K.N. Chaffin

 

I sure hope it gets fixed! I also noticed it broke when i upgraded to 5.1

 

yeah, running into the same issue as of 5.1 (and 5.1.0p1 doesn't fix it)

 

Hey all not exactly 6 months, but still too long. As Ken Chaffin mentioned too much going on, but that's a bad excuse. Not sure what to say, just sorry about that happening, it should be better in the future.

Anyway, regarding 5.1:

Yeah elbows is right, the shared memory is really screwing with unity I'm not sure why they didn't test TC Particles or some other more complex compute shaders for their unified GL system.

In any case, the good news is that I could work around it. And when I did.... No particles! So more digging.... until I found that they basically broke DrawProcedural, vertex textures don't work anymore.... I tried my best hacking around that, but it's really essential for colour over lifetime and size over lifetime.

I've made bug reports and sent them to aras on twitter

https://twitter.com/aras_p/status/610063310092955649


so yeah, hope that's resolved soon....


If they're taking too long I could bring out a version that eliminates all vertex textures, but there's a lot of performance implications there... not sure how that pans out. It's a last resort however if unity ignores this issue. (and as mentioned, while 5.1.0p1 fixes some graphics issues, it doesn't fix this one).

Thanks all for the patience

 

Small update: Unity says they've tracked down the vertex texture bug, and that it should be fixed in the next patch release

 

Some good but mostly bad news:

Good news: Unity has fixed the issue in the latest 5.2 alpha.

Bad news: Unity didn't port the fix yet to the patch release released today as they promised I'm really not sure why, but I'm hoping they do so next week

 

I hope they release a patch! Tcparticles is my main weapon (literally the players flare)... hopefully sooner than september http://unity3d.com/unity/roadmap

 

Latest 5.1.1p2 patch mentions TC particles by name, so fingers crossed! (it will be 2 hours before I get a chance to try it)

 

Nice!

 

Yay it works, though I dont use every part of the system so cant be sure there are no issues at all in 5.1 any longer.

Thanks to all involved in fixing it.

By the way, is there something wrong when trying to use meshes as shape emitters? I can get a mesh to work if I use it with the main emitter that is built into the system, but have never had any luck getting it working with separate emitter objects.

 

I can confirm that my two major projects that use TC-Particles are both working under Unity 5.1.1.p2 . Both of these use DirectCompute extension shaders and use RenderTexuture's as compute data buffers. One of these uses a CUDA plugin that also populates the RenderTexture's.

One of these projects encountered the shader compiler crash while rebuilding the assets, but I cannot determine which shader was involved. It must be a shader that I am not using in my scene.

K.N. Chaffin - Texas Tech University Informatics Media Lab

 

Hey all, back from Rock Werchter

Seems unity fixed it indeed! Including the crash when importing the compute shader. Whew... Here's hoping mainline patch lands soon too, but at least people are unblocked for now Thanks all for the patience

 

Yes it works but only draws in one eye in VR.
unity 5.1 changes things for VR, its no longer handled by Oculus, but now by Unity. The integration is much easier, using any available single camera and automatically making it VR (if you enable VR in settings). Any ideas? Im on Unity 5.1p2, deferred, linear color, dx11., nvidia970
Thanks

 

Hi, can anyone confirm for me that TC particles works with the Oculus Rift DK2?

From what I read in this thread it doesn't?

If it does I'll be buying it...

 

Yes and no. I've got it working fine with a DK2 on the oculus 0.6.0.1 runtime in unity 4.5.5f1 using the now legacy unity integration.

As for 5.1, it seems like a mixed bag.

 

Hi,
i made a test with the latest version(1.4.1) with Unity 5.1.2 and had a couple of issues:

1. There is an anoying warning :

Method TCParticleSystemEditor.RenderGizmo is marked with the DrawGizmo attribute but does not take parameters (ComponentType, GizmoType) so will be ignored.
UnityEditor.AttributeHelper:ExtractGizmos(Assembly)

I suppressed it with changing the RenderGizmo method to:

Code (CSharp):

1. private static void RenderGizmo(TCParticleSystem syst, GizmoType gizmoType)

(added the GizmoType parameter)

2. In the Unity 5 version the TCParticleSystem has the [ExecuteInEditMode] commented out, the Unity 4 version not. So the TC Particles vizualizer editor doesn't work under Unity 5.
If you enable the [ExecuteInEditMode] you get an exception when you start the scene:

MissingReferenceException: The object of type 'TCParticleSystem' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.

I made some tests and there is some problem in the TCParticleSystem with adding the current instance to the static All property

Code (CSharp):

1. All.Add(this);

Sometimes 'this' is null so i made some additional checks in the Init() method and prevent multiple adding of the same instance:

Code (CSharp):

1. private void Init() {
2.         if (this == null) return;
3.         if (m_hasAwoken) {
4.             return;
5.         }
6.         if(!All.Contains(this))
7.         All.Add(this);
8. .....
9. }

and

Code (CSharp):

1. private void OnEnable() {
2.         if (!All.Contains(this))
3.         All.Add(this);
4. ......
5. }

3. There is a strange bug when you use the Rendermode 'Point' for the particles. If you hit play no particle is displayed. When i select a shader for the material of the particles (even if it is the same as before) suddently the particles a visible.

All in all I'm a bit disappointed that this mega cool asset didn't get more attention from the developer.

 

Does anyone have an example or method they use to change starting size of the TC particle system by scripting? I know this is possible on other particle systems and it's usually fairly straight forward. The API documentation lists TCParticleEmitter.Size as only a get attribute. Is there any particular reason why we can't set this? There was also some mention quite a few posts back that we would need to run the following cmd: syst.Emitter.UpdateSizeOverLifetime(); in order to get size changes over time.

Can someone provide a quick example of how to use this in conjunction with setting initial particle size or something along those lines.

Thanks for the help/ideas for getting this to work.

 

Still no sign of any Tutorials

 

Does anyone know how to get the "turbulence" force to be limited spatially? Or to make it only work on a particular System? As far as I can tell you can't have different turbulence values for different systems in the same scene, since if you give it a shape it just doesn't work, only works if you set it to "Constant".

 

Answering my own question, apparently if you give it falloff you have to drastically increase the strength, or it doesn't appear to be working.

 

Turbulence vector fields are listed as one of the features of TC particles but I don't really have any knowledge of how they work. Perhaps different systems can reference different vector fields? Again, I'm totally spitballing as its a neat feature I've never used!

 

@elbows Any update on the Fluid Sim/TC Particles project? If you've made any progress I'd like to see a video if you have one, especially since the first one you posted was incredible. Also, is there a reason you decided to start with the Scrawk implementation instead of Fluidity?

 

Thanks for the kind words and the interest. I don't have anything new to show quite yet, and when I do I doubt it will be using TC Particles due to it being hard to avoid the sense that this asset has been somewhat abandoned by its author. Somewhat similar story with Fluidity, although the author of that asset does at least provide occasional compatibility fixes for newer unity versions.

Right now the most likely outcome is that I'll give away a sample project that uses open source fluid simulation (a version of Scrawls that I've converted to use 3D textures rather than buffers) and open source GPU particle simulation (probably one of the Kvant offerings from Unity Japan team). Not sure when, but I expect I'll at least start a thread in the WIP forum by spring.

 

@elbows Using Keijiro and Scrawk projects as building blocks has some crazy possibilities! I've recently come back to this project and have finally started trying to learn about compute shaders, and for my sanity's sake, I can't wait to see what you come up with. Trying to do this myself might not have been the best idea.

I think you mentioned in a past post about feeding the velocity textures of Fluidity into TC. Did you convert the velocity texture from Fluidity into a Texture3D and then update the TCForce.forceTexture with the Texture3D? I finally managed to get this to work with, ummm, mixed results. But from what I've seen, and how the particles act, I think this is a dead end.

After working on this for an entire weekend, I've got a better idea of how everything works and I'm starting to think it might be better to use the built in TC extension template to access and sample the Fluidity velocity texture?

 

It's been ages since I looked at my TC particles version, but what I usually do is feed the fluid simulation velocity textures directly into the relevant part of the particle system shaders. This doesn't involve any conversion or copying of the velocity texture, I change a couple of lines to use the existing velocity texture directly rather than whatever texture the particle system was using before. Depending on the system I have to slightly change a line of TC shader code so that the right part of the velocity texture is used and the right values (e.g. I might need to multiply the sampled value or the UV coordinates by 0.5 with TC particles, off the top of my head).

 

I haven't worked on this since last weekend but it looks like you were right. I originally tried my extension method but was getting some weird results. I moved the code into the TC shader and that seemed to have worked. A new computer is on the docket, so until then I have to keep all of the settings low and the volumes small, but everything seems to be working properly.

 

Has anyone written custom shaders for TC? I've been trying to add lit particles that will react to light to TC but haven't had any success. Every example or demo I find uses a vertex/fragment shader with the v2f and appdata structs. Is this possible to do with TC? I've been trying to use the TCHook files to write a new shader but that doesn't seem to be the way to proceed.

 

@smnerat
Yes, I have.
And, actually, I'm the one who added that hooks system to override (add to) default functionality.

But, unfortunately, i did it a way back in 4th version of Unity, when I was working in another studio. Sadly, the studio I'm currently working in doesn't owe a TC Particles license, so I can't help you with the exact recipe how to make your custom shaders.

If I remember it right, you have a strict order that you need to define/include those "hooks" files (it's not actualy hooks, because they completely override default functions/structures, but it's the best I can get with shader-code only).
That's the one thing. Secondly, you need to declare a shader macro that tells the default basic code to use your overrides where it's needed (instead of the default ones).
And, finally, you don't define a function. Instead, you add a cginc file called exactly with the name as the default one. And there you just write a snippet of code which will be literally inserted inside the main vertex/fragment function.

I know this is a messy solution, but I was young back then. Today I maybe did it differently.

The best how I can help you is by sending the shader I made for that old project. I repeat, that was a looong time ago, even in 4th version of Unity. So this shader may not work (and most likely it won't) in the current version of Unity with the current version of TC Particles plugin.

UPD: I could try to update all that hook-override system and make it easier to use if a plugin author ( @p v loon ) would be kind enough to provide me a licence for TC Particles. I'm currently working in mobile games development so I can't use this plugin for work anyway, and I can play with the code just for fun, nothing more.

 

@Lex-DRL

My biggest problem was the "strict order" you mentioned. I ended up getting part of the way there, I was using the hook files to use custom vert and color functions, but I couldn't define and include the struct files in the right order, which lead to nothing working at all.

At that point, I ended up just modifying the struct files to get what I needed with a moderate amount of success. I haven't worked on anything since last weekend, but I think with your input I shouldn't have many more problems.

The more I use the hook system, the more I like it. It's just that its pretty confusing to start out, especially if you aren't very familiar with writing shaders.

 

@smnerat
Cool. I'm glad you've handled (or will handle) this issue.

 

Is this package dead? The last update on the store was almost a year ago.

 

It does seem that the package has been abandoned by its creator. A real shame.

It would open up a lot of nice possibilities, if there was a fully fledged and well maintained GPU-driven particle system in Unity.

 

Hey all,

Has been a real long time! I can't deny TC Particles has been a bit dead but that saddens me too, so I've finally given it some spit polish to resurrect it. This update has been submitted to the asset store today:

Integrated rendering better into the unity engine
-fixes VR rendering problems
-Opaque/cutout particles now correctly sort with alpha blended stuff


Moved the Editor folder now that it can be under the TC Particles root to make package managment easier


Improved force priority sorting to sort by actual force not just distance
Improved performance of priority sorting when a system is linked to more forces/colliders than max forces/colliders
Reduced garbage generated in a bunch of scenarios
Increased performance for multi pass materials


Fixed tail UV globally being set to the tail UV of the very first TC Particle system created
NOTE: The value has been globally reset to the default 0.5 since it wasn't doing anything
Fixed all compile warnings
Fixed missing gizmos and wireframes
Fixed some inconsitencies between constant / non constant forces
Fixed velocity over lifetime not affecting velocity effects like stretch or color over velocity
Fixed some issues with in editor visualisation
Fixed some nullrefs on starting / stopping
Fixed Vortex inward force framerate dependance issue
Fixed playback speed + "sticky" particle issues
Fixed issue where sometimes colliders/forces were picked up only after ~a second

I still see lots of potential in GPU particles too, and overall TC Particles is still doing well, check out this beautiful new game using lots of TC Particles:

http://www.desolus.com/

So I at least definitely want to keep the current system alive though. I'll take up bug reports again and update the code to better match modern unity. Longer term future I don't know if I can find the time though and if I do, whether that means adding to TC Particles or starting on a revamped system.

Thanks all for sticking around for so long

Cheers,
Arthur

 

Any hope of some tutorial videos, bought this over 2 years ago and it's been sitting since.
Really struggling to figure out how to do any of the fancy stuff let alone the basics.
Would be great if you could do some basic walk true videos showing real world examples like building a fire/smoke particle system to making a sword with animated blade overlay and trail swipes.

 

I was wondering if someone knows what the limiting factor of the number of particles in a system is? Suppose I have a scene with nothing in it besides a particle system, and I slowly increase the number of particles. Eventually, once I hit a certain number of particles, the frame rate will drop pretty significantly.

In a general sense, what defines that point? I have a few guesses, but I'm not really sure. I'm leaning towards it being the memory limit that's shared between threads? If so, if I decreased the size of the particle structure that's defined by taking out several things that I don't need, would it be possible to increase the total number of particles while avoiding a drop in frame rate?

 

Update 1.5 is up on the asset store wooh!

@John G: I'll discuss, I understand the frustration but it's a little hard to justify atm as TC Particles is pretty stale. Throwing together some casual quick guides might work though. If you have any questions atm also feel free to ask them on the forums

@smnerat: It's almost certainly memory bandwidth yeah. From what I remember decreasing the particle struct in size would definitely help. It's already pretty compressed but I'm really sad that I have to use floats for everything, using halfs would save a ton. That used to glitch on older GFX cards though. Maybe with modern drivers and I now that I might actually know why that is, maybe time to revisit...

 

I for one am looking forward to trying out the new TC Particles changes. Even though a challenge, I've succeeded in the past in doing some very complex DirectCompute (ComputeShader) HLSL scripts to make the particles do pretty much whatever I want them to. I haven't done much in the past couple of years though after TC-P stopped working with my Oculus Rift DK2. I now have the CV1, but don't have a computer that can support the CV1, which I hope to rectify soon. I really want to see TC-P in the Rift! By the way, I combine TC-P ComputeShader with Unity native texture pointer passing to NVIDIA CUDA for even more complex GPU parallel computing in C. I use RGBfloat textures for 4 floating point component data passing between Unity, DirectCompute and CUDA.

Thank you for spending some time updating TC-P. Be careful it you compress to halfs as that might put me out of scientific computing business

Ken Chaffin - Director of the Informatics Media Lab (research) at Texas Tech University

 

What is the problem with using halfs? I taught myself how to code, so I may know a lot about a subject that I spent time on and absolutely nothing about an adjacent subject. Compression and conversion is something I haven't ever really worked on.

Is it strictly a hardware problem like you mentioned? After going through the TC scripts, I can't see the loss in precision between a float and a half causing many problems.

 

Great to hear you're still at it Ken! Wouldn't worry too much about your job given the insane stuff you've pulled off with CUDA <-> Unity and other DirectCompute interop

@smnerat: Back in the days on fermi cards (nvidia 5xx) we had a lot of random memory corruption issues (many random behaviours at even more random times), switching to floats fixed most of these. Theoritcally though it should indeed be totally fine.

I think what might have happened is that I didn't set up the struct to correctly be a multiple of 4 bytes wide. On modern drivers this would probably be automatically be padded with no issues but old cards tripped on it.

I think setting up a struct that's properly 4 byte worded (probably also only using half4's and half2's) + modern drivers should probably fix this I feel, and it would make TC particles so much faster...

I'll experiment with it soon

 

@p v loon I see, did Unity implement a change to prevent that? I get a very vague error when trying to change the length of the particle structure to anything other than a multiple of 4 and I wasn't sure what it meant (actually the error is thrown when I change the ParticleStructStride in the TCComponent script).

I'm not sure its completely correct, but I changed the particle structure so that it's 24 bytes long rather than 44 and I can use nearly 2.5 times the particles without any change in frame rate.

The only problem so far is that this seems to effect the vertex functions in the shader Cg files, but that might be on me.