In Unity 5.4, we have finally begun the process of removing the Legacy Particle System from Unity.
The Legacy Particle System classes (ParticleEmitter, ParticleAnimator, ParticleRenderer, etc) have been marked as [Obsolete] in the API, and using them in the Inspector will now display a warning message. We have also begun work on reducing the number of packages in the Asset Store which are using the Legacy Particle System.
If your project is still using the Legacy Particle System, you should upgrade your effects to use the newer ParticleSystem component soon. (We’re exploring whether we can create some kind of automatic upgrader tool, but we cannot promise anything).
If you’re using the Legacy Particle System via packages that you obtained from the Asset Store, we recommend monitoring the store for new versions of your packages. We will be encouraging Asset Store authors who have Legacy particle effect packages to update their effects as soon as they can.
We don’t have a fixed date for when the Legacy Particle System will be removed; instead we’re going to monitor how widely it is still being used, and try to wait until that’s dropped to a sufficiently low level. (But we’re not going to wait forever).
A lot of effort has gone into improving the new ParticleSystem over recent Unity 5 releases - through removing limitations such as the lack of API for system properties, through new features such as the Trigger module in 5.4, and through general performance optimizations such as multithreading support. At this point we believe there is nothing you can do with the Legacy Particle System that you cannot also do with the new ParticleSystem. But, we never know about all the use cases out there. If you’re currently using the Legacy Particle System and cannot upgrade to the new ParticleSystem component because of technical limitations, please reply to this thread and explain what’s blocking you.
If Unity offered a tool to automatically convert existing legacy particle systems to Shuriken systems, then I bet most people would be pretty happy about it. I am guessing that the people still using the legacy particle systems are doing so simply because that is what they initially set some of their prefabs to use. I cannot think of any reason to actively choose legacy particle systems over Shuriken at this point.
That’s fair enough. If you can’t get an auto-converter working, would there be any pointers in how to go about converting any you have from the legacy to the new system? Sort of a “these settings in the legacy system correspond to these settings in this module and that module in the shuriken system”
I have very little experience in the particle systems, either legacy or shuriken, other than accessing them via code to switch them on/off as required.
imo at some point if you want to keep working on old stuff, you will have to live with previous versions of Unity, that’s it.
The way UT is handling obsolete part of their engine is one the best solution for their users.
But a potential disaster for anyone that needs full code control over animation playback and loading…
There’s things I’ve done with legacy anims that just weren’t possible with Mecanim. Something as simple as resetting an animation controller (e.g. for reusing prefab instances when object pooling) was impossible not so long ago. And loading an anim clip from resources and assigning it to a Mecanim state was impossible last time I tried.
I’ve also written tools that could display animations in editor mode, by setting the exact anim times and blend state, and using Animation.Sample - couldn’t see any way to do the equivalent via Mecanim at the time.
If the old animation data format is removed, that’s probably great - but I don’t think we can afford to lose that more direct control over loading and playback of animations that the Animation component gives. And while Mecanim in principle is great for main characters with lots of anims/transitions, setting up a new animation controller for every little ‘door opens’ or ‘UI bounce+spin’ animation seems kind of overkill, and additional work.
(Sorry, this was rather off-topic… losing legacy particles doesn’t affect me - but losing Beast hurt. The year of broken lightprobes. So losing legacy animation is a scary prospect, given that my Mecanim experiences so far have been fairly mixed)
You might want to check out playables api, it should mirror the functionality as far as I’ve checked. As it eventually will go (it is depreciated after all), you should be moving to it as the day will come when you don’t have the choice (same for all depreciated stuff I guess).
Regarding animation: yes, we will eventually begin to deprecate it in the same way that we’re deprecating the legacy particles (the particles are acting as a sort of ‘pilot programme’ for doing this stuff). But we’re not going to do it while there is still a significant gap in use cases covered and in usability.
That said, @hippocoder is right: a lot of the things people want to do with the legacy animation system, they can actually do with the Playables API - to the point that you can more-or-less build your own version of the Animation component on top of Playables if you want. I’d definitely recommend checking out what can be done with it.
But anyway, I’m all for deprecating the legacy particles. I recently went and switched a few particle effects we still had that used the old system and I didn’t find any trouble replicating the effects.
Hello.
Particle.color is now marked as Obsolete. But I need to change color property of the individual particle not changing other’s particles properties. What should I do to make it right now? (the same for size of particle for example)