[Open Source] TC Particles: millions of GPU particles

Is there an emit from mesh example we can find? I ve been digging in the forums, api etc with no luck.
When I try giving a mesh to a particle system, it crashes with the attached error log.

 

@elbows:

Huh interesting. I had hoped that would work out of the box - that is unitys goal but I guess there might be some complications coming up. Im definitely interested in having a metal version that works well, finally having TC Particles on OS X will be great, could possible ven run well on iPads. I dont have either to test on though so you if you are interested in helping that would definitely be appreciated!

@Homer-Johnston: So after giving this some thought, 2 conclusions:
->Adding light in deferred mope for opaque particles should _definitely_ happen. It will be relatively easy, and should provide higher quality to integrate with deferred rendering 'natively' instead of drawing as a forward thing in deferred. The new unity hooks should allow this.


->Adding light for forward & alpha blenden particles will be very hard, currently. With how the light passes work, and generall how unity lights work, this isn't really feasible.

However! With the new clustered lighting unity is working on for their HD render pipeline this does seem doable. When that hits I will reevaulate.

->Seperate from all that, renderering TC Particles in shadowmaps is possible for some cases. At least for directional & spot lights. I don't think there's an API to do it for point lights though :/

I will look into these options, could be interesting. Let me know what light cases you were having in mind


@pixelshader: Super strange. Judging from those errors some files might be out of whack - can you try deleting your TC Particles folder & importing a fresh copy from the asset store?

 

Certainly, I am more than willing to assist, and tracking down issues is one of my favourite things. I've got access to a windows machine, a couple of macs, an iphone and a couple of ipads including the 9.7" ipad pro that can do metal. If I get time even before 5.6 reaches final release then I will start digging in deeper to the issue(s) now that I know you would like to support this stuff.

At the very minimum you will need to check the pragma target stuff in one or two of your shaders (just one I think from memory when I tried but I cannot remember which off the top of my head). The 5.6 beta manual has the updated info about what works on Metal platforms:

https://docs.unity3d.com/560/Documentation/Manual/SL-ShaderCompileTargets.html

Some relevant bits:

#pragma target 4.5 (or es3.1)

• Supported on DX11+ SM5.0, OpenGL 4.3+, OpenGL ES 3.1, Metal, Vulkan, PS4/XB1 consoles.
• Has compute shaders, random access texture writes, atomics etc. No geometry or tessellation shaders.

#pragma target 5.0

• Not supported on DX9, DX11 before SM5.0, OpenGL before 4.3 (i.e. Mac), OpenGL ES 2.0/3.0/3.1, Metal.

 

@pvloon I got it to work. Something got corrupted.

Another question, I am emitting particles from a moving mesh (an avatar) and baking mesh from SkinnedMeshRenderer to update the mesh in the particle emitter.

But the performance falls down very quickly, any ideas or tricks to keep the frame rate right?
thanks for all the feedback

 

V1.6.1 is uploaded to the asset store!

Added new textured emission sample
Changed shaders to target 4.5 in preperation of metal compilation
Added NoSimulation toggle to public API
Updated point cloud sample

Fixed error in shaders when using mesh rendering
Fixed leak of command buffers
Fixed bias in turbulence force in linear color space



@elbows: Neat, thanks for the help. I've changed the targets so curious to see whether this will already work natively or not. It's still submitted from 5.5.3 as 5.6 is a little rocky and didn't want people to force upgrade though.


@pixelshader: I think I actually found the error now, my bad. 1.6.1 fixes it.

Bake Mesh is indeed not great for performance It's currently your best bet though. I am looking into native emission from skinned mesh renderers however. Similair too: https://github.com/keijiro/Skinner but hopefully without requiring the special assets and such he needs, and more of a drop in replacement.

I might also look into particle trails, as they can give really cool effects especially for the sci-fi ish, glowy look TC Particles is best at anyway.

 

Cool - I will be able to test this in about 2 hours and will report back. Based on previous experiments I expect there will be some other metal issues but you never know, might get lucky.

 

Oops I mistook 'uploaded' for 'available' so obviously I wont be testing 1.6.1 just yet

 

OK I grabbled 1.6.2 from the store and here are the messages I get in the console now when using the editor in metal mode on a mac. The buffer binding ones are repeated about half a dozen times and the pipeline state one a couple of times.

Metal: Vertex shader missing buffer binding at index 1 (particlesRead / TCShaderAdditive)
Metal: Vertex shader missing buffer binding at index 1 (particlesRead / TCShaderAlphaCutoff)

Metal: Error creating pipeline state (TCShaderAdditiveSmooth): fragment shader color output does not have enough component for the pixel format (MTLPixelFormatBGRA8Unorm_sRGB)
(null)

 

Hiya!

Ah thanks so much for testing that. Those are some really cryptic errors though mmh. I will take a look at both soon and try to iterate on it but might get tricky. Eh, worst case it's a good excuse to get an iPad

 

Dont you also need to get a mac in order to build for ipad?

I am happy to do more testing but yeah those sorts of errors, which I believe I have seen with one or two other assets since playing with 5.6 betas and metal on macos, are too cryptic for me. Perhaps you can find someone from unity who can help since it has the potential to be bugs or compiler weaknesses in their new system which they'd probably like to fix or rule out their side being at fault?

 

I have to say I am excited to find out how it performs on modern iOS devices one day. So apologies if I ever sound impatient, I'm not really and I know the timescale for a working metal version will be unclear so long as the exact nature of the problems remains unclear.

I'm also pretty excited for the long-term future of the high-end of macOS devices. Apple had to admit they dropped the ball witht he last mac pro and lack of upgrades to it, and revealed that they are working on a new, modular/upgradeable mac pro although it doesnt sound like it is anywhere near being ready for sale. And then nvidia announced that they have made a driver to enable pascal (10 series) geforce cards to work on macOS and it will be available in beta next week. I'm presently using a 970 in an old mac pro but will give a 1070 a try once the driver is out.

 

I thought I would give it a quick try on the first beta of 2017.1 to see if there were any metal changes.

Not much difference in terms of console messages compared to 5.6. But for whatever reason the missing buffer binding error messages have changed slightly, they are now stuff like this:

Metal: Vertex shader missing buffer binding at index 2 (bufPoints / TCShaderAdditive)

Why it is now having an issue with index 2 rather than index 1 I could not say but maybe there is a clue there.

 

Huh neat! I think those errors actually might be somewhat helpful. I've sent you a .cginc with some potential fixes, let's see if that works.... And yeah, I'm excited too! Would be great to have this running on many more devices.

Also prepping the new update Mostly just cleanup & bug fixes though.

 

I'm thinking about purchasing this asset. But I would like some input on its viability for my situation.

I'm making a forest fire simulation. As such, I have a grid with each cell representing an acre of forest. I need to be able to show fire and smoke out of each cell in the grid as it catches fire. I'm trying to target VR here so there's a major performance concern. I need to be able to change the variables for each cell that catches fire to show changes in behavior of the fire of that cell. (mostly just to "fade" it in and out.) In an ideal world I would just use the default unity particle system and have it create fire and smoke representing one cell, and then instantiate instances of that particle system for every cell as it catches fire. Unfortunately that's not going to work for performance reasons.

So, will this system be able to meet my needs? And if so, what approach do you recommend taking after purchase?

 

Really? Nothing?

 

Hi CornDog,

Apologies for the late reply. I think the answer to that is a bit of a mix:

For the smoke and some parts of the fire you would really want alpha blended particles. Right now particles from TC Particles are not sorted by Z Depth and thus don't look right alpha blended, and are generally not ideal for giving a 'volumetric' feel.

However, fire particles often also have little fireflies / sparks / other small details in there. In terms of simulation cost you could do these drastically cheaper with TC Particles. Especially if you were to use the 'shape emitter' feature from TC Particles which would basically put every repetition from a cell into one big particle emitter allowing for way more efficient simulation than if all these were distincs simulations.

In other news, I'm working on an update for 5.6 and doing some new bugfixes.

 

Just dropping by to say I love what you're doing here, and look forward to OpenGLCore/Metal versions of it. Thanks for the email response suggesting I watch this thread, Arthur!

 

Hey all,

Just a quick heads up a big update is coming I'm still deciding on how big exactly. Currently these are the release notes:




The new method to draw stuff using DrawMeshInstanced is going to be super powerful and allow for all kinds of new shader effects. My aim is to include a new lit and unlit 'uber shader' for TC Particles and a version of the unity standard shader that supports TC Particles. Additionally I want to start replacing the samples with more modern examples soon.

I might release before including that to get the other mentioned goodies out earlier or do a larger update all at once. Slowly working towards V2.0!

Thanks all for keeping TC Particles alive since Unity 4.0, for 15(!) unity versions

 

This is absolutely phenomenal news!

 

So I Didn't have as much time as I had hoped but 1.7 is finally submitted!

V1.7

TC Particles now supports OpenGLCore & Vulkan!
TC Particles metal preview. Some issues remain so I'm happy with anyone testing. Shoutout to Elbows who helped a great deal with this!
New method of rendering TC Particles using DrawMeshInstanced
-New method of rendering TC Particles using DrawMeshInstanced
-Makes authoring new shaders easier
-In the future:
-Enables surface shaders
-Enables lit shaders / Deferred shaders
Reduced overhead of spawning TC Particle systems when having many colliders / forces enabled
Optimised TC Particles update overhead
Can now mult edit ShapeEmitters
Updated samples scenes to be more instructive & modern
Removed deprecated offscreen renderer as it was broken at this point anyway
Fixed serious performance degredation when disabling / enabling last active TC Particle system
Fixed Mesh ShapeEmitters using the wrong mesh
Fixed forces / colliders that had their layer changed dynamically being ignored by TC Particles
Fixed frustum culling only checking whether system was visible in last camera, not if it was visible in any camera
Fixed IL2CPP compilation


Super excited about the next updates that'll use the posibilities of the DrawMeshInstanced features

 

Hello,
Could it be possible to add a color mix to the particles ?When a blue particle touches a yellow particle, both should became green?
And liquid simulation for the particles ?

 

Ding! Purchased.

Super exciting developments for sure. Well done!

 

@Gontz: Hi there! Unfortunately, there are no particle-particle collions - meaning no color mixing or fluid simulations. It is possible to write these as extensions - and elbows has even done so for a fluid sim - but def not something out of the box.

@x4000: Awesome that's great! Definitely let me know if there's anything missing or not working right.

 

Will do! I'll be digging into it increasingly over the next couple of months.

 

Seems like your website is gone?

 

Bought the asset, seems to be leaking particle systems left and right whenever a gameobject that contains a particle system is destroyed.

 

Sounds GTEAT !! Can't Wait for the new fature ! !!!!!!!!

 

Hey!
I purchased TC particles a bit over a year a go, and I have been using the plugin quite a bit! However the Tiny Cube website seems to be dead, and I cant find the API any other places, this used to be accessible under the Documentation on the Tiny Cube webpage. Does anyone here have access to the API? Cheers!

 

Hi all,

@Kanadaj: For the website, see below For the other problem - can you describe what you mean with 'particles leaking ' everywhere? Do you see some memory leak or? I am not entirely sure what you mean by this. Thanks!

@bjerken: That's great to hear! Really hope it's doing what you need, let me know if you have feature requests Sorry about the documentation, see announcment below


After getting mails from a few people all at once it seems it definitely didn't go unnoticed the Docs went offline a while back.

The docs were very out of date, on a host I didn't any longer use or need and based on out of date tech Apologies for the rough transition, but it meant it was high time to polish that up.

I have create a new docs website which you can preview here:

https://arthurbrussee.github.io/TCParticlesDocumentation/

It is hosted on github which makes it much easier for me to keep up to date. It also uses a new doc generator backend - docfx by microsoft which seems to produce pretty good docs.

While in there I have done some other updates:

-Filled in a lot of the missing API summaries.

-A TC Particle system holds references to some internal components that hold all the settings for their particular area (say, ColliderManager, ParticleRenderer ed). In the old API you could only get access to an interface of these components, exposing part of their API. This was clunky and slow however, and meant that often API was missing when I didn't update the interfaces. For the next version I have removed this layer and have given direct acess to these internal components while cleaning up their API so they only expose what they should and are safe to use. In practice this means more API is exposed now and there is less performance overhead when usng the API

-I have namespaced all parts of TC Particles properly now. This was needed for the doc generator and generally a good idea for a cleaner API. That does mean the next version is not entirely backwards compatible however. Some scripts will need to be updates with a "using TC;" directive.

The site is still considered preview as I want to fill in some more documentation and API's on the website, and the version this doc was generated from is not on the asset store yet. Hope it helps already though!

 

V1.7.5 containing the updates to the docs & API are submitted to the asset store.


Next updates hope to work on a new uber shader, encapsulating all shaders there are now into one uber shader model. Opaque cutout will be able to cast shadows. Cutout can also receive screenspace shadows.
Also a Lit mode will be added, that works only in deferred mode, to receive light.

 

Not really quite sure what to make of this... but i just bought TCP and imported it to my project. That worked fine. But once i tried to open up an example scene my whole editor froze. I restarted unity and all my windows inside unity were white. (like the inspector, scene and game view). And the rest of unity is unresponsive. I had to manually remove the TCP plugin outside of unity to get it to work again.

I tried to start a new clean project to check out the demo scenes there instead. And all of the demo scenes are broken spitting out these errors:

Point cloud scene
DirectoryNotFoundException: Could not find a part of the path "E:\TCP Test\Assets\StreamingAssets\PointCloud\horse.ply".
DirectoryNotFoundException: Could not find a part of the path "E:\TCP Test\Assets\StreamingAssets\PointCloud\bunny.ply".
DirectoryNotFoundException: Could not find a part of the path "E:\TCP Test\Assets\StreamingAssets\PointCloud\dragon.ply".
DirectoryNotFoundException: Could not find a part of the path "E:\TCP Test\Assets\StreamingAssets\PointCloud\manuscript.ply".
DirectoryNotFoundException: Could not find a part of the path "E:\TCP Test\Assets\StreamingAssets\PointCloud\hand.ply".
System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/FileStream.cs:292)
System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share)
(wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
System.IO.File.OpenRead (System.String path) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/File.cs:363)
System.IO.File.ReadAllBytes (System.String path) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/File.cs:538)
PointCloudSpawner.SpawnPointCloud () (at Assets/Plugins/TCParticles/Samples/PointCloud/PointCloudSpawner.cs:89)
PointCloudSpawner.Awake () (at Assets/Plugins/TCParticles/Samples/PointCloud/PointCloudSpawner.cs:80)

Fusion Blast and projectiles scene
NullReferenceException: Object reference not set to an instance of an object
TC.ParticleManager.Bind () (at Assets/Plugins/TCParticles/Implementation/internal/TCParticleManager.cs:365)
TC.Internal.ParticleComponent.BindParticles () (at Assets/Plugins/TCParticles/Implementation/internal/TCParticleComponent.cs:112)
TC.ParticleManager.Dispatch (Boolean emit) (at Assets/Plugins/TCParticles/Implementation/internal/TCParticleManager.cs:320)
TC.ParticleManager.UpdateParticles (Single deltTime) (at Assets/Plugins/TCParticles/Implementation/internal/TCParticleManager.cs:311)
TC.ParticleManager.Update () (at Assets/Plugins/TCParticles/Implementation/internal/TCParticleManager.cs:283)
TC.TCParticleSystem.UpdateComponents () (at Assets/Plugins/TCParticles/Implementation/TCParticleSystem.cs:314)
TC.TCParticleSystem.TCUpdate () (at Assets/Plugins/TCParticles/Implementation/TCParticleSystem.cs:310)
TC.Internal.TCParticleGlobalManager.Update () (at Assets/Plugins/TCParticles/Implementation/TCParticleGlobalManager.cs:74)

Now i am too scared to touch this again. I am glad there still seems to be support for this though haha

If it helps explaining anything at all... I use Unity 2017.1.0f3. The project that completely froze because of this plugin is a VR project. Not sure if that's related.

 

Hi Alienpop,

Oof sounds bad!

For the point cloud - you need to double click the CloudDataUnpackMe.unitypackage and import that into your folder.

For the other errors however, seems there is something wrong in 1.7.5. I've submitted a hotfix now - hope it lands in the asset store soon. Last review only took 1.5 days. Apologies for the inconvenience though, I've PM'ed you an updated version in the meantime

 

Hotfix 1.7.5.1 is up!

 

There are some hints. When the particle count is high enough to affect the computer's performance, deleting the gameobject with the particle system component doesn't change the performance impact. Also, it seems like particles (and maybe orphanned particle systems) remain in the system even after stopping the Unity play. Once any errors surface in-game, stopping the game doesn't fix the constantly increasing list of errors without restarting Unity.

I can do some more experiments if you want, but it's a bit hard to pinpoint things without knowing the workflow of the system and had no time to read through all the code, but it feels like the particles are managed completely outside of Unity's grasp.

 

On another note, the system seems to work surprisingly well in SteamVR. I'm thinking of replacing all fire sources with TC particles, since it seems like Shuriken does take some stupid amount of resources for a few hundred candles/torches scattered on the map.

 

Hi Kanadaj,

Mmh alright that sounds bad! I'll investigate. Are you on the latest version already (1.7.5)? I did fix a leak a whle back where after disabling the last TC Particles system, and enabling it again, every rendering function would be called twice. Do it N times and render function are called N times. I don't see how anything can run after destroy though so this might be different. Either way I'll keep you updated, and thanks!

Good to hear it's working otherwise! That's definitely a good use case for it. Two things that should could make it faster:
->Setup some bounds you know the particles to be in approximately, and turn on frustum culling. Can also disable simulation when offscreen.
->When emitting many of the same particle type in different locations, try using shape emitters. This means only 1 particle buffer is used, and everything is drawn in one draw call instead of a draw call for every system.

(Note: Shape emitters are not incompatible with frustum culling though - so will have to pick one of the two)

 

Honestly, I was kinda wondering why everyone was complaining about performance in VR (my 1080Ti doesn't even mind it whatsoever) but then I added the particles for all the lighting and my CPU started to choke on it. So I was fairly happy when I found TC Particles.

And no, not yet updated to 1.7.5 (downloaded the version before the update, so I'm guessing 1.7.4). I'm still working on figuring out how I discovered the problem first time around (I've deleted those particle systems since, and saved the scene, so sadly I have to figure out what I did weeks ago). What I did find though, was that if you delete a particle emitter then undo it, the emitter emits particles but they seem invisible.

 

I'm super excited to see if you have any luck implementing lighting into your particles. Do you know yet if it might require any odd caveats? I know some other particle systems do things like, force you to globally define an important light and only that light will affect particles... or one light might affect all particles from a single emitter equally regardless of individual particle positions... etc.

Do you think it will be possible to provide GPU particles that simply work decently as basic alpha-blended smoke-style particles? Dark in a dark environment, and grey/white when a strong light is shining through them?

I notice Unity is starting to try and get things like lighting into their basic particle system ( https://forum.unity.com/threads/release-standard-particle-shader.461938/ ), but GPU particles are just so much better for 90% of what most games need, so I really hope it works out!

 

May be of some interest. Fake self shadowing effect. Used colour radial gradient with a black radial gradient underneath set to 50% opacity and offset position - shown at bottom of image.

 

All the sample scenes work and are far more stable for me on macOS with editor in metal mode now I'm not sure what improved the situation though because I am now using the latest 2017.3 beta, with the latest TC particles and I am on High Sierra with updated nvidia web drivers now.

 

@pvloon patiently and excitedly awaiting any updates or progress info you might have

 

Hey all,

Sorry didn't realise I missed so many posts here!

This has been release for quite a while but I see I never even posted the 1.7.6 release notes!

TC Particles 1.7.6
-Greatly improved performance of spawning and removing particle systems, forces, colliders and shape emitters -Lowered overhead of having many colliders & forces in the scene
-Fixed inspector errors
-Fixed mesh particles being broken in some cases
-Fixed build errors
-Fixed changing of shape emitter tag at runtime


Secondly, TC Particles 1.7.7 has been submitted to the asset store:

TC Particles 1.7.7
-Added EmissionCallback and DispatchEmitExtensionKernel to easily set custom values after emisison on particles
-Particle Prototype now uses proper default settings when prototype value is not used. Added usePosition to particle prototype API
-Added EmitTexture API to emitter. Now is a Texture rather than Texture2D to allow render textures.

-Fixed non-looping systems playing too fast after system life
-Optimised all binding code by using precomputed ShaderID's
-Optmizations for scenes with lots of colliders
-Fixed a potential memory layout error on Metal



@Kanadaj: Do you still have the problem? I think 1.7.6 or 1.7.7 should definitely fix it as a bunch of binding code has been overhauled.

@Homer-Johnston I definitely want to do something akin to the unity standard shader. Now that TC Particles had the uprade to using DrawMeshInstanced it should be possible to use Surface shaders with which it should be possible to support many features like the unity standard shader. In fact, I might look into creating an adapted TC Particles version of that shader. This is a larger project though and I haven't been able to find that much time besides my studies + job.


@DR01D: That looks really cool! Great trick. Would it be alright if I adapt that to a sample scene at some point?

@elbows Interesting! I'm sure Unity is still working out some kinks so that helps. 1.7.7 has another memory layout fix so fingers crossed the metal version gets 100% solid soon!


Another question: I got asked about making a MegaFlow integration into TC Particles. Is this something more people use? Would it be useful to use force fields authored in mega flow in TC Particles?

 

First thanks for the good works. It's really nice to have a GPU particles easy to use.
I'm also definitely interested in using TCParticles with metal devices. I know it's still in dev but while it works pretty well on my Macbook Pro, I'm stuck on my iPad Pro. Here is the error I'm having at runtime (compilation is ok) :

Code (Boo):

1. 2017-11-26 13:50:34.886948+0100 ProductName[3840:4145329] -> registered mono modules 0x101811660
2. 2017-11-26 13:50:35.421476+0100 ProductName[3840:4145329] [Accessibility] ****************** Loading GAX Client Bundle ****************
3. -> applicationDidFinishLaunching()
4. 2017-11-26 13:50:35.737597+0100 ProductName[3840:4145329] [MC] Lazy loading NSBundle MobileCoreServices.framework
5. 2017-11-26 13:50:35.738950+0100 ProductName[3840:4145329] [MC] Loaded MobileCoreServices.framework
6. 2017-11-26 13:50:35.760654+0100 ProductName[3840:4145329] [MC] System group container for systemgroup.com.apple.configurationprofiles path is /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles
7. 2017-11-26 13:50:35.794682+0100 ProductName[3840:4145329] refreshPreferences: HangTracerEnabled: 0
8. 2017-11-26 13:50:35.794748+0100 ProductName[3840:4145329] refreshPreferences: HangTracerDuration: 500
9. 2017-11-26 13:50:35.794775+0100 ProductName[3840:4145329] refreshPreferences: ActivationLoggingEnabled: 0 ActivationLoggingTaskedOffByDA:0
10. -> applicationDidBecomeActive()
11. GfxDevice: creating device client; threaded=1
12. Initializing Metal device caps: Apple A9X GPU
13. Initialize engine version: 2017.3.0b10 (d1367129888f)
14. WARNING: Shader Unsupported: 'Hidden/BlitToDepth' - Pass '' has no vertex shader
15. WARNING: Shader Unsupported: 'Hidden/BlitToDepth' - Setting to default shader.
16. WARNING: Shader Unsupported: 'Hidden/BlitToDepth_MSAA' - Pass '' has no vertex shader
17. WARNING: Shader Unsupported: 'Hidden/BlitToDepth_MSAA'

The same last error is repeated for each frame rendered but absolutely nothing is displayed.
Any ideas to fix this?

It would be really nice!!

 

Megaflow integration would be great.

 

Get it while it's hot, TC Particles is on sale: https://www.assetstore.unity3d.com/en/#!/content/7324 !

Also 1.7.7 is now up

And lastly good to hear there is more interest in mega flow - I will have a look at it to see if it can be integrated.

 

@pvloon No problems.

 

Hello,

I use Kinect v2 to get the dynamic mesh and texture data and assign them to TCParticles' EmitMesh and Texture. I'm wondering how I can make the dynamic mesh been updated. It seems like the mesh in TCParticles' system can only be the first captured one and won't be updated though the original mesh is continually updated by the kinect.
Thanks in advance.

 

Hey all,

1.7.8 has been submitted:

TC Particles V1.7.8

-Fixed big performance regression where particles were always drawn and updated at least twice, even more if the last active particle system was enabled / disabled multiple times
->NOTE: This means additive particles will now appear less bright. You might need to crank up Glow Strength after this

-Added new example scene showing how to use the extension update & emission API

-Added UpdateCacheForEmitMesh/ReleaseCacheForEmitMesh to ParticleEmitter, and a global TCParticleSystem.UpdateCacheForEmitMesh/ReleaseCacheForEmitMesh(Mesh mesh) to manage GPU mesh data. Useful when dynamically updating your emission mesh
-Added OnPreSimulationCallback, OnPostSimulationCallback to match emission callback & easier ordering of events
-Made UV Channel a slider as opposed to an unbounded int
-GPU Mesh data generation is now faster and uses less GC

-Renamed EmissionCallback to OnEmissionCallback

-Fixed particle bursts not working first loop when time was exactly 0
-Fixed EmissionCallback not working properly
-Fixed switching Mesh texture uv channel not updating the mesh data
-Fixed normalize area not working if two particle systems used the same mesh, one with and one without normalization



That first fix is a pretty important one as it could degenerate performance a lot in some cases. I hope it goes to the asset store quickly.

@DR01D: Great, thanks! Will do so in the next update.

@Future-Action: Adressed via mail For people wondering, the new UpdateCacheForEmitMesh/ReleaseCacheForEmitMesh now handles this.

 

can't wait for surface shaders ! ! ! ! ! ! ! !

 

Did your website get stolen, or expire? http://tcparticles.tinycubestudio.com/