Unity 5 - Any plans for Shuriken ?

Are there any plans for Shuriken in Unity 5 ?

It hasn't received any attention in quite a while so I guess there must be something coming in 5 at least ?

I am hoping for these changes and fixes :

- It should be more open to scripting.

- They should include a way to disable automatic culling other than activating a module that doesn't support it because its simply a stupid workaround...

- Fix the culling bug where your particles vanish completely when the emitter is out of frustrum.(filed bug over two years ago, acknowledged and reproduced on UT's end, but still open today (unresolved).

-More control when emitting meshes (for instance being able to rotate on a certain axis x,y,z instead of being stuck with one axis which is designed for billboards not 3D meshes)

These would already be great…I'm sure other people can come up with more. I'm hoping that they will fix/add these before trying to add any new fancy features to it.

 

A logical step would also be enable the usage of sprites within Shuriken.

 

what is Shuriken?

 

haha, I like your sarcasm if that is what you were trying to express.

 

http://lmgtfy.com/?q=Unity+Shuriken

 

if it is documented then it should be available

 

He asking if they are going to update it..... not if its going to be available.

 

Hey Lane, I think now its obvious that this guy is just trolling.

If you want more proof, he also just PM me this:

So for the others that will post here please keep to topic and just ignore him. Thanks !

 

I have to say I continue using the particle legacy system because I find Shuriken is a mess, unintuitive and as Alf203 says not very open to scripting.

 

Just to give you a better idea, compared to the scripting side, it is a pleasure to use the editor of Shuriken.

 

I must agree with Dantus here. The shuriken editor is presented in a more structured and comprehensive way. The fact that it is separated by modules makes it easy to use just what controls you need without dealing with the clutter. For people already used to legacy I think it is unintuitive because they are used to the legacy system and the same options are not in the same place or have the same name in Shuriken.

I just wished they would upgrade Shuriken so it becomes less of a black box.

As a side note, it seems to me that most new systems in Unity are always very closed to scripting upon release and take a long time to catch up to the former system already in place. A good example is mecanim and legacy animation - mecanim is catching up now but is not there yet and it took a long time.

 

I can't comment on the scripting openness but the editor itself is lighyears ahead of the legacy system and once you've read through the reference manual you pretty much know how to use it. It's also so much more flexible.

On topic I agree that Shuriken would be even better if it had dedicated 2D capabilities. What would be even more usefuill, though would be scaleability. So far a particle system can only be scaled up or down with a considerable amount of manual reworking. I think that is a real shortcoming of shuriken so far.

Aside from that I'd still rather see navmesh being updated for 2D Top-Down games, though. Yes - I am not getting tired of saying this everywhere I can.

 

There are tools for that, and most of them work well for the majority of cases, but a built-in way of scaling would really be useful.

 

I was hoping more people would reply. Then, no wonder they don't update Shuriken; I guess a lot of people are happy with how it is and only about four of us on the forum would like fixes and improvements

One more thing that would be nice is if the UV scrolling would work when emitting meshes and not only billboard.

 

It's weak for 2D - for instance, I find it difficult to constrain the placement and movement of particles within a 2D plane. And I'd like the ability to specify various parameters (min/max) on a per axis basis. And the ability to stretch particles into non-square shapes (ex tall/skinny particles). And, I would like access to the systems in code - ability to manipulate hte forces, emission, size, frame by frame, to create procedural particle systems.

Gigi

 

Exposing the startColor of particles as a "Gradient" would make it so that we could programatically control it. Now it is not possible. You have to copy the particle system and make a new prefab for every randomized start color setting. This is ugly...

I am talking about a randomized start color so the particles have a random color when emitted (no two particles should be exactly the same). Not the single color that you can set through the API.

 

Would be cool if it became natively DX11 powered, like just a checkbox on the particle system "use DX11" or automatically do if unity runs in DX11 mode.
I know there are things on the asset store, yet quite expensive, like TC Particles.
But as unity supports DX11 and comes with a particle system. Why not keep particle systems built in the engine up to date with what is supported?

 

Huh?
https://docs.unity3d.com/Documentation/ScriptReference/ParticleSystem-startColor.html

 

That is all doable now.

 

Maybe not "happy", but it's not a problem, at least compared to other things I would see in Unity. There are a few things I would like to see updated, but nothing critical. Shuriken as an editor component works pretty well out the box, it isn't meant to be the be all end all solution for particle, but for creating prefabs, canned fx, things of that nature it does the job nicely. If you need more control, you can do some basic scripting into. If you need more you can dive even farther, for complex systems, you can go nuts and control every detail on every particle.

Is it the best system ever created? Probably not. But it isn't severely limited in its current state. It'll do what you want provided you have the knowledge to do so, or the desire to learn.

 

Have to second this. At times you have to resort to hacks(wrapping the entire system per particle) but you can accomplish most everything with the Shuriken system.

 

Did I miss a massive update? Do tell!
Gigi

 

Agreed, but I don't know if I would call it a hack, since it is the documented API. But yea, the only real limitation is creativity.

 

As far as I know it has always been part of Shuriken, at least ever since I have looked into it.
https://docs.unity3d.com/Documentation/ScriptReference/ParticleSystem.html

 

Would like a proper API to be able to set sprites of my choice, or cells without resorting to time hacks.

 

Just write one, it is pretty straight forward, I made one to allow random cells at random intervals (lightning effect). If you want to get real fancy, you can also add it as a editor extension to ParticleSystem so it is available on all particlesystems in your project. Extending an API or implementing your own isn't a really a hack, its just development.

 

It is a hack, because you either have to use reflection or you have to access the fields through SerializedObject/SerializedProperty. If Shuriken had a usable API, that would not be needed.

 

How so? I just access the elements directly through the component.

 

In the (Legacy) particle system, I am using ParticleRenderer.uvAnimationXTile and ParticleRenderer.uvAnimationYTile, or ParticleRenderer.uvTiles. Pretty straight forward and intuitive, even if there is a bug for certain cases.
Could you show me how to achieve that in Shuriken without using ugly hacks?

 

How long ago? My current work with the system doesn't require accessing components, but I'm positive that going back a few projects there was stuff I couldn't do because the relevant bits weren't exposed.

 

Well.., with that one, yes and no (directly no). You can easily do the same directly to the renderer, however that applies to all the particles at once. That is what I do for my lightning fx, but in my case the nature of it means that isn't an issue. Script access to that module isn't currently available, though Shuriken does have more advanced options in its sheet animation, and many of the things that affect the render.

However goals and methods are different beasts. With anything there usually many methods to the same goal. What is the end result you are trying to achieve? What would be the use case for changing the animation tiles at runtime via code? I can think of a couple of ways to do it, both with all or some of the particles. But by the same token, I can think of a practical need that couldn't be achieved in a much simpler way. (not that there isn't a practical need, just that I can't think of one). Let me know what your are trying to do, and I might be able to provide a practical solution.

 

As far I as I am aware, since it was released. I don't think there have any major updates to it. But I don't know for sure, but I have projects dating back to 2012 where I was monkeying with individual particles and changing elements dynamically.

 

I've not had any trouble messing with the particles themselves. I recall my issues being with accessing some parts of the modules on a system, though I can't remember what specifically.

 

I know how to work around the limitations. In my Cloud System, I support three ways to visualize the clouds. There is a custom mesh based implementation, one for Unity's legacy particle system and Shuriken. Developing anything that is supposed to be generic with Shuriken is just a nightmare! In my opinion Shuriken is not yet finished. Why do they create some pretty amazing functionality in the modules, but don't expose the API?

 

The frustrum culling bug is incredibly irritating, and the lack of an ability to scale a shuriken system is also really annoying. I consider these issues bugs which should be fixed ASAP.

Also, it could definitely have a few more features: forcefields would be useful, and also an ability to define forces/velocities as polar coordinates to allow systems that rotate, or spiral, for example.

 

You may vote for the culling bug:
http://issuetracker.unity3d.com/issues/shuriken-is-culling-particles-when-were-using-setparticles

 

as mentioned, some proper scaling of particles would be nice
also sorting layer and order should be exposed in inspector (instead of setting it manually in Start()), so it's more usable in 2D

 

Billboards should be lit...

 

In my case I was using Shuriken as a cyclic particle pool, with each particle or object being it's own image on the sprite sheet. This required hacks because it was the fastest way to work with unity to have that many sprites.

 

That's specifically what I was thinking off when I said, "it may require hacks".

 

just another example of the many other things in unity that requires hacks.. seriously unity3d needs to make some games and experience the pains.

 

Can you explain this in more detail? I don't follow what you are trying to do.

 

I was using Shuriken as a sprite system, controlling it manually, as it batched huge numbers and was threaded.

 

Please read carefully next time (posts and the documentation).

Color type is not Gradient type. If you want a random start color based on a Gradient you cannot have that in code. It's only accessible in the editor.

You have to copy the particle system and make a new prefab for every randomized start color setting.

Otherwise you have to run an update and check the life of every particle of the particle system in order to keep track of when they're emitted and change their start color. Good luck having good performance with that strategy.



Also another thing with the renderer of a particle system. You cannot animate its material properties via renderer.SetPropertyBlock (see https://docs.unity3d.com/Documentation/ScriptReference/Renderer.SetPropertyBlock.html).

This is in case you wanted to spawn a particle system from a prefab, with a material that has a color property that is different from the prefab for example. Setting property blocks makes it so that the original material is not copied. You cannot do that with shuriken. The SetPropertyBlock does nothing when called on a particle system renderer.

 

It seems to me you don't use it much, or you don't do anything more than really basic FX with it. Shuriken as an editor is nice but the scripting side sucks, I don't know how you can argue with that...

Sure I can roll my own particle system but then shuriken becomes useless…In that case what is the point of it? If its there why don't they upgrade it or fix the bugs… It is limited in the scripting side. How hard can it be to provide more freedom for us and not have to go through hacks and stupid workarounds…

 

Ah. Well sure, but in that case you aren't talking about a shortcoming of a particle system, you are leveraging a particle system for another task. A particle system's speed derives from lack of need for control over individual particles, (like baking values into shader instead of exposing them). Particles are stateless to a degree. Even when you address them individually, you have limited control and can't track them. The addition of detailed level of controls would reduce the performance, even if those controls aren't actually used since it still has to poll them. (like a shader).

 

I agree, although it was Unity staff that suggested I use it for this purpose due to the fact point sprites are buggy. They didn't need to animate, but they did need to have a different image applied (think bullets, debris).

 

I misunderstood what you were saying as you said controlling the start color. But what you describe can be done programmatically without having to touch the particles. The gradient setting is just a linear progression across a range based on duration. Random between two is the same, just the resulting color is a random color lerp between those to points.

You can do the same, and really, even more complex, by adding a method to the update change the start color. Either to replicate what what exists, or to something more complex. The only difference is bursts, bursts will be the same color.

But yes, having those initial settings exposed would be nice to have.

 

I use it quite extensively every day. FX are primarily what I do on our current game. I know the system intimately. Sure the api it may be limited, but then again, you don't need any (or much) to do complex FX, only if working outside he intended use of what a particle system is valuable for. Sure changing the emission rate or count or speed is valuable, direct access to all the particle display and individual factors that affect it aren't. And change it from a particle system to a loop that spits out game objects.

Here is the critical part people may be missing, Shuriken is not FX tool in and of itself, it is a particle system. I have FX events that may have a dozen particle systems each with many sub-emitters. And I have large FX events that have no particle systems at all. The point being that if you are trying to radically alter a single system over run-time, or function beyond the scope of simple particles you may missing the point of the role of a particle system in the first place. Even radically altering the start up parameters isn't needed in most cases, as particle prefabs are very light weight in the first place. Our game has many hundreds of them, it is much faster to dupe and tweak and existing prefab (and more extensible), rather have a system to alter start parameters. And easier as you can visual tweak the results than rather than plug numbers in somewhere else and check the results.

I am not saying that Shuriken is the best ever, or that it is perfect. But often, and especially with people new to development, and using tools like Unity, people can have the perception that because something doesn't function the way they imagine it should, it is broken or incomplete. (Look in the support fourms for all the people who have found "Bugs in Unity" that are typos, or lack of understanding of what they are doing.) If you have hit what you feel is critical limitation in Shuriken (and it isn't a genuine bug), consider what you are trying to do, and look for a higher level approach, rather than trying to bend Shuriken out of its scope. (though that can be done too).

----

Anything you build or try to do has many approaches, that is the fun and frustration of game development, solving the problem. That always bugs me a bit around here. People always complain about what Unity (or some plugin or system or other engine) can't do, or they are not happy about the way they have to do it.

As a professional, and more as a perfectionist, I have never had the luxury or ability to wait for something or to exclude something because it "can't" be done. Most of my tasks are to figure out how to make things work regardless of limitations. Sure, that means that often I have to do the 'weird' stuff, or beat my head against my screen for months on something that may seem minor (ugh... holograms). But my approach is always to assume something can be done, and find the solution to do it, given the current tool set. And within reason, I am happy to share these solutions with the forum community. I find it is more valuable to share knowledge and approaches rather than have a group bitch session. (though, this it the internet, so I shouldn’t have hight hopes).

So I apologize if it comes off that I am saying Unity is perfect (I am not), or that it appears that don't encounter or understand the challenges people face. I encounter and understand them extremely well, but they don't really frustrate me or get me upset because I just see it as part of the game development. Finding solutions is more important to me than wishing the challenges didn't exist.

I have to work under the assumption that a feature like Shuriken is feature complete. For all intents and purposes, it is. (at least for the length of whatever current project I am working on). Anything that isn’t available right now is irrelevant and if it affects a particular goal, I need to find another solution. Sure, it would be nice to modify certain start up values, but since I can’t, I can create multiple prefabs. Which is about equal in time investment. If I was to complain about everything little thing that could be changed to better suit my needs, I would have no time for development. Instead, I focus on solutions, and when it is direct bug or something critically flawed in design, I provide feedback to Unity.

 

Heh... well remember, they don't make games.