SpriteToParticles - Emit particles from a sprite

Hi, I've published the SpriteToParticles package some time ago.
I'm making this thread to take questions, suggestions and inform about new updates and that kind of stuff.

Update! Now it works with the Unity UI Image component. No support for sliced images at the moment though.

​

Stay tuned for more info

pd: if you already bought the plugin, share a screenshot! I really want to see what you are making with it.

 

This looks really really cool, and could be absolutely perfect for what I need with the new UI support,
however I'm not confident in purchasing it currently as both your documentation and webgl preview links are broken/that entire site seems to be inaccessible?

 

Good idea, but I am wondering about the performance side of things, since the system seems like it is reading texture per frame to get the info. So if you have frame animated sprites and their size is large, isn't it going to hit cpu a lot per frame?

I think this would work much better if it can be linked with clever compute shader and somehow update the particle system from there instead cpu reading texture per frame..

 

Hi!
erm...

@SwiftIllusion That's really weird, I checked the site and it's up and running. Please try again, if you still can't log then I guess I should call the hosting service...
Also, I uploaded the main UI Demo scene, it's here
It doesn't show up in the package description because I'm fixing some strange bugs reported by users and I'll upload everything together along with a sample usage video.

@castor76 Well, actually, you get 2 main components: one static and one dynamic.
The static one will cache all the texture data only one time and save the needed info to emit the particles. This is the component used in the Forest on fire Scene. It's static in the sense that you wouldn't change the sprite source image but you can still move the game object around or scale and rotate it.

The dynamic one, yes, it will read the texture every frame you are emitting particles. This one is supposed to be used with animating sprites, this is, constantly changing the sprite in the Sprite Renderer component. Like the first two scenes in the demo.
But, you can cache thoose too. This component has a CacheSprites option that would cache all the sprites as they come along. The thing is that this would be increasing memory size with every new different sprite.
So, it's up to you if you prefer more memory consumption or cpu consumption.

I spent a lot of time making the plugin as performant as it could be. I want the tool to be as robust as possible.

All the things I'm stating here are explained in the documentation file.

I don't see how one could make this with a shader as it uses the Shuryken particle system. The tool only works on emission, after that the particle system process the particles.

I hope that aswers your question. If you have any more questions I'll be glad to answer.

 

Ok so it seems like it tries to cache the data at least. Which is good thing. In that case, the game will probably need to "warm up" all the animation before the game starts to play because we don't want the player to experience any lags during this caching period. For this purpose, it would be nice to have API that we can "supply" the sprites that is going to be changing so that we can "bake" or prewarm up the cache data before we let the game start playing. Without this API we need to force "play" all the animations in runtime in order to cache things up which gets a bit ugly.

 

Another optimization idea is that instead of storing vector3 position, you could just store vector2 and then use sprite's base transform z value instead. This will save some memory at the cost of possible vec2 to vec3 conversion but it maybe a worthwhile tradeoff. If the game is flat 2D then conversion is automatic because you can just say vector3 pos = vector2 pos.

 

Regrettably that link still doesn't work, even going to " http://numbloq.com/ " gives me "connection has timed out", have you tried visiting your site from another location/mobile etc, maybe it's because your logged into its control panel or something that allows you to visit it without issue?

Additionally just out of interest regarding the performance discussion, would the GUI be factored as static or dynamic?
If an interface image is being scaled with DotTween for example would that still be static or dynamic, or would it not function for elements like that?

 

@castor76 I'll add something like that API you are telling, maybe in the next update.

@SwiftIllusion I called the hosting, they say everything is ok. I've asked some people around the world to check if they can access and they can. Let's continue this in private.

At the moment (as specified in the documentation), the UI support only works with the dynamic component. The static will be added in the next update.
I haven't checked the DotTween yet but it should work as expected. I'll confirm you this tonight when I get my hands on it.

 

Hi, this is a really cool asset. Well done!

Just a few things:
1. I randomly get 2 errors in the console (not during play mode):
- Shader error in 'UI/Particles/Additive': 'v' : undeclared identifier; 'vertex' : illegal vector field selection; 'UnityObjectToViewPos' : cannot resolve function call unambiguously (check parameter types) 'z' : vector field selection out of range at line 76 (on gles)

And the error is immediately followed by:
- Shader error in 'UI/Particles/Additive': undeclared identifier 'v' at line 76 (on gles3)

So line 76 in UI_Particle_Add.shader

I can still run the game fine. Just thought I'd let you know. I'm running Unity 5.5.0f2

2. Is it possible to "prewarm" the particle system? I'd like the particles to begin as if they'd already been firing off beforehand on startup.

3. Is it possible to disperse the particles radially? Normally I'd do this using a sphere Shape. Seems I can only add forces in a particular direction.

 

Hi Andrew,

Glad you like the asset. About the issues:

1. Yeah, I'm fixing those things right now along with other issues that arose with Unity 5.5+
I'll upload it tomorrow to the store.

2. No, I was researching how to make that work but as the nature of the asset is to replace the particle system emission that feature turned to be quite tricky. I'll keep trying to come up with something.

3. Again, the Emission and Shape are overriden by the asset. I'll be adding some kind of effectors to deal with those situations but it will take a while before they become production ready because of performance.
This kind of effectors are high up in my todo list.

 

Thanks for the clarifications!

 

Hey there

I am just playing around with your spritetoparticle asset to create UI menu buttons and its really great so far.
However I have a small issue at the moment... the script -> "Static UI Image Emitter" doesn't seem to work - since it also doesn't have the "Emission" properties in the settings, I wonder if this is not enabled? Sure I can use the "Static Emitter Continous UI" but since its only for menu buttons which don't move, wouldn't it be more performant to just the static emitter?

BTW do you think it would be somehow possible to create some kind of "effects reuse" - what I mean is if we would copy several objects/images and always have to use a new emitter with a new renderer and a new particle effect instance - this get quite compute intense and slow on mobile devices...?

Thanks for the great asset,
Oliver

 

Hi Oliver,

That's right, the component "Static UI Image Emitter" won't emit any particles. The components inside the "Core" folder are the base ones and won't emit. This image from the documentation might clarify it a bit:



That inheritance diagram is for the Sprite based emission.

In the Image UI case that OneShot component doesn't exist but I maintained the class structure.
The OneShot on UI doesn't exist because it was ment to deal with relatively big images that emit a great amount of particles (as show in the "Static Oneshot Emission Demo", the one with the html5 logo).
This wouldn't be wise to be done with UI emission because the particle system's renderer module is overriden by the asset and has a particle limit count.

So, I maintained the class structure just in case someone really needs that particular component in the future. Unlikely but posible.


About the "effect reuse",
If you are talking about reusing the same texture, like a 20 same-texture buttons running at the same time, yeah, that would be an awesome add-on. A way to cache the same image for different emitters.
I have to think about a nice way to handle it to be easy and straightforward to use.

But bear in mind that this would only mean less memory consumption.
You'll still need an emitter, a renderer and a particle system component just like any normal particle system you would add in your scene.

Does that answer your questions?

 

Sorry for the late answer, but I was busy studying the unity courseware and forgot to check back to the forum (thought I would get an email...)

Well that answers my qustions so far.

Regarding the idea behind image effect reuse... from what I can see the performance hit a comes from "scanning the image" itself for the colors (I guess for static images this is done only once or?). But I saw that it gets very slow as soon as the image grows. So I guess that scanning all the pixels from an image is the bottleneck. But couldn't this process be done only once and then be reused? And if you had multiple objects, you could apply the same effect on other objects too, without the need to scan the image all the time. Or am I thinking totally wrong here But since I am pretty new to unity... that's just what I came up on my mind.

The idea behind is, since I want to create a trading card game (that's also why I may use UI canvas) to have different border lighting effects on them etc. - but I would need this very performant and copied over to several objects. As we know mobile devices are limited, so I wonder how I could achieve this

Thanks for your time,
Oliver

 

Oliver, @lorddevil

Ok, let's separate concepts:
1 - There's reading of the texture from unity, the call to GetPixels method on the texture (https://docs.unity3d.com/ScriptReference/Texture2D.GetPixels.html)
2 - There's the reading from the Color[] array returned by the above method.

Static emission will do 1 and 2 only once. This is done in the CacheSprite() method.
One would do that on the Loading state of the game for big textures, whether using the "CacheOnAwake" setting or calling it manually at a prefered moment as it would take some miliseconds to load (always depending on the texture/sprite size)

After the cache is available (there's an event to attach to when cache is complete) the performance will only depend on the amount of particles your are emitting. It doesn't mather if you have a 16x16 texture or a 4096x4096 texture.


Dynamic emission will do 1 only once if the "CacheSprites" setting is enabled. This is per different texture referenced in the Sprite component or Image component (this depends whether you are using the Sprite version or the UI version).

If "CacheSprites" setting is disabled it will do 1 every frame.

It will always do 2 every frame; the cost of having the ability to change texture and/or the color source emission settings on the fly.


The other concept: the ability to do 1 and 2 (using static emission) on one texture for serveral objects at the same time, aka: sharing the cached texture between different objects.
That's is not available yet but it's on my todo list.
Again, this feature would only have an effect on memory footprint.


In conclusion, for your specific case about the cards game I would go with the static emission. Remember that with static emission can still change position, scale and rotation on the fly.

Any other question I'm right here

 

Thanks alot for your detailed explanation.

Well then I guess you are right and my suggestions for sharing the "effect" would not really help performance. I thought or hoped there is a way to e.g. completely reuse an emitter to share its effect or something like that - like applying a shader on a material and then reuse this material onto several objects.

But at least it would help on the memory side of things

Have a great day,
Oliver

 

Hi, I like this asset.

But, I got a trouble.
It is infinity increase of materials.

I fixed A to B and it was okay.
Make sure there is no problem with B.

79~83 In UIParticleRenderer.cs

A.Original

Code (CSharp):

1.  
2. Shader foundShader = Shader.Find("UI/Particles/Additive");
3. Material pMaterial = new Material(foundShader);
4.  
5. if (material == null)
6.     material = pMaterial;

B.Fixed

Code (CSharp):

1.  
2. if (material == null)
3. {
4.     Shader foundShader = Shader.Find("UI/Particles/Additive");
5.     Material pMaterial = new Material(foundShader);
6.  
7.     material = pMaterial;
8. }

 

Hey @UanUes,

Thanks man, completely overlooked, luckily that code only runs on the component Initialize.

Will add the fix for the upcoming version.

Thanks again

 

Thanks for this asset, it's really very useful.
However I can't get UI particles to work on Android (including the demos). Could there be any project wide settings which I need to change to get this working?

 

Hi @TurboNuke

That's weird, it should work out of the box, can you send me an email stating:
-Unity build version,
-screenshot or info from BuildSettings (Edit->Project Settings->Player)
-screenshot or info from GraphicsSettings (Edit->Project Settings->Graphics)
-are you using the provided UI shaders in the package?

If you could also send me an .apk to test that would be sweet.

 

Hi,
I just added the shader script which I'm using to the 'always included shaders' section of GraphicsSettings, and it's working now. Thanks!

 

Hi,
I found some errors in the Demo Static Sprite Example / Static Continuous Emission Demo 01,03. like this:
IndexOutOfRangeException: Array index is out of range.
UnityStandardAssets.ImageEffects.NoiseAndGrain.BuildMesh (UnityEngine.Mesh mesh, UnityEngine.RenderTexture source, UnityEngine.Texture2D noise) (at Assets/Standard Assets/Effects/ImageEffects/Scripts/NoiseAndGrain.cs:185)
UnityStandardAssets.ImageEffects.NoiseAndGrain.DrawNoiseQuadGrid (UnityEngine.RenderTexture source, UnityEngine.RenderTexture dest, UnityEngine.Material fxMaterial, UnityEngine.Texture2D noise, UnityEngine.Mesh mesh, Int32 passNr) (at Assets/Standard Assets/Effects/ImageEffects/Scripts/NoiseAndGrain.cs:141)
UnityStandardAssets.ImageEffects.NoiseAndGrain.OnRenderImage (UnityEngine.RenderTexture source, UnityEngine.RenderTexture destination) (at Assets/Standard Assets/Effects/ImageEffects/Scripts/NoiseAndGrain.cs:126)

and this:
NullReferenceException: Object reference not set to an instance of an object
SpriteParticleEmitter.StaticSpriteEmitter.CacheSprite (Boolean relativeToParent) (at Assets/SpriteParticleEmitter/Code/Core/StaticSpriteEmitter.cs:81)
SpriteParticleEmitter.StaticEmitterContinuous.CacheSprite (Boolean relativeToParent) (at Assets/SpriteParticleEmitter/Code/StaticEmitterContinuous.cs:36)
SpriteParticleEmitter.StaticSpriteEmitter.Awake () (at Assets/SpriteParticleEmitter/Code/Core/StaticSpriteEmitter.cs:48)

 

Hi @Fengrenjie ,

That IndexOutOfRangeException must be due to an update gonne wrong. It's the Noise And Grain camera effect that comes by default with unity. It's just there to spice up that scene a little bit. You can safelly remove it or replace it with the last default. It seems unity updates those quite often.

About the NullReferenceException, that happens if you don't have a sprite set in the Sprite Component. The system expect a sprite to be there to emit from. I'll have a fix for that in the next version. If you need a hot fix please pm or email me.

(sorry for the delay in the response)

 

BTW, I am using Unity 5.6 and there are several warnings in the editor as soon as I am adding the SpriteToParticle Plugin to my project:

Any chance to get this fixed in another release?

Thanks a lot,
Oliver

 

@lorddevil, sure thing, coming in next update.

 

Are these effects supposed to only work at runtime or is there a way to get them to simulate in the editor? If not, is that on the roadmap? It's a pain to have to go into play mode to configure an effect.

 

Hey @Fuzzy_Slippers,
right now it only work at runtime but yeah, it is on the roadmap.
I'll try to add it to the next update, no promises though.

 

Hi,

I want to use particle stretched billboard mode. But seem SpriteToParticles doesn't support this mode. Can you add support for particle render mode

P/S : I found that DynamicEmitterUI has cpu usage very high, always 90%. But I can't find StaticEmittterUI. How can I use StaticEmittterUI?

 

Hi @MinhDao ,

Stretched mode for the UI render won't be added for the time being.
The reason is that the particle system renderer module is overriden by the package, as it works differently. I'll have to see how the original works in that regard and duplicate the functionality.
I'll check that out in the future but there're other priorities in the package at the moment.

As for the cpu usage, yes, UI emission is more demanding than the sprite emission. It also depends on how much particles you want to use.
Unity 5.6 had some performance upgrades in that regard, I'm checking how that can improve the performance on UI.

StaticEmitterUI can found used in the scene "UI Static Emission".

 

Hey @Zarlang,

is there a chance this will sometime in the future work on UI text, preferably TextMesh Pro?

Best regards,
Patrick

 

@Lohrion

That would be an interesting feature. I'll look into it.

 

Thanks!

 

Hi!

First of all, congratulations for your plugin, it really makes a difference when playing with sprites and particles.

Now, my question We're trying to make a trail like the one on your video, the rainbow deer. With a simple particle system without your asset, the trail looks cool, but when we apply your asset to change its color it stop looking smooth.

Here's a gif with a demo of that. The top particle system has your asset applied (a StaticEmmiterContinous) the bottom one is a simple particle system.



Any clue with that would be very nice

Thank you!

 

Hi @Elendow,

So, I'm not quite sure what you are trying to achieve.

What you mean by
"when we apply your asset to change its color it stop looking smooth."
Can you add other gifs as before and after this "change in color"?

The main difference in the gif you shared is that the one using StP emit particles from that "S" shaped thing, using the sprite pixels positions to decide exactly where to emit each particle, while a normal particle system emits at random positions.

Some references could also help me understand the effect you want to make.
Also if you want to send me a really stripped small version of your project I'll take a look.

That being said, I don't think StP is the ultimate trail system to sprites. You may want to check Sprite Trail. I have nothing to do with that asset or its publisher but seems pretty solid to me.

ps: thanks for the compliments

 

Hi again and thanks for the fast reply!

Basically, we wanted a particle system with the colors of our sprite (not shown on the gif) making the same effect as the deer of your video. We want to pic the color of the sprites for the particles system, but keep the "randomness" of a simple particle system if it's possible

I'll look at that asset too, thanks for the recomendation!

 

You may want to try playing with the "emission rate" in the StP component and the "Start lifetime" in the particle system component. That may give you the variation you are looking for.

 

Hi again,

We've been playing with all the options and we cannot reach the same effect. We love your plugin but as you said maybe this is not the moment to use it

We have a very fast movement and the "trail" of particles is not fast enough, we don't know why. Here's another gif with our trail (top) and a simple particle system (bottom). We wanted the smoothness of the bottom system with the colors of the top one.



But we're going to use StP on other things for sure!

 

@Elendow
mmmm, interesting. Actually, that may be a bug...
Thank you for poiting this out.

Let's keep talking privately and I'll post the results later here so we don't clog the forum.

 

Hi,

I'd be really interested in using your asset, but I'm using 2D Toolkit (a very popular 2D framework for Unity). 2D Toolkit uses mesh renderers for sprites, as they provide more flexibility and features than sprite renderers. If I understand correctly, SpriteToParticles works with a sprite renderer. So I was wondering if you'd be willing to make your asset compatible with 2D Toolkit. I think it might be a great selling point, and if it's technically possible, it would be amazing.

Cheers!

 

Hi @Michoko

It is technically possible. I've help a person to make it work for TK2D.

There're some reason with it's not officially up,
First, I don't own TK2D. I get a lot of request to add support for different assets from the store and, don't get me wrong, I'd love to add support for all the assets I'm being asked to but the thing is I don't have the resources to get them all.

Second, I thought nobody used it anymore but I guess TK2D still seems to have a lot of traction.

Third, It adds some complexity on the hierarchy configuration and although I believe StP is pretty simple to use, some begginers are having a little bit of trouble. I believe due to not knowing how to configure the Shuriken particle system right. Still.

I'm making a major update right now that it's taking longer than expected. I'm hoping to submit it by the end of this month (June).
After that update I'll try to find a way to add support for it seamlessly.

Have fun!

 

Hi Zarlang,

Thank you very much. Yes, I still think 2DTK is a viable solution, as it is a consistent framework with many features and optimizations. Tilemaps are very cool too, including lighting tiles. I know some features are now in Unity 2D, especially in the beta, but 2DTK centralizes all this, with a few unique selling points too IMHO.

So thank you for considering making your asset compatible with it.

 

Just wanted to drop in and say thanks @Zarlang This feels like the missing link to pixel based games Unity's Shuriken. It's really helping me revamp a lot of FX in http://playadnc.com

 

Thanks @Ash-Blue !

Best of lucks with the upcoming Kickstarter

 

I just started using SpriteToParticles for UI. I must be missing something because I'm having trouble getting it to work with a Button. Do you have a video or step-by-step instructions for that? Thanks!

Also, any way to make SpriteToParticles work with UI Text?

 

Hi @username132323232

can you please try following the step in the image?

Also remember in step 3 to add the UIParticleRenderer and Particle System components it unity doesn't add them automatically.

About text, I'm researching how to make that work. Sadly it's a completely different approach from what the asset does right now.

 

Hey there, any ETA on the new version?

It's been quite a long time and I just wished that the Unity Warnings would go away, because this is the only plugin atm which is giving me several warnings .

BTW I am using the plugin now via Screen Space - Camera and interestingly I always have to deactivate "Match Image Renderer Position and Scale data" (also in overlay mode) ? Is this a known bug or what is this setting for?

Thanks alot,
Oliver

 

Hey @lorddevil

The new version is ready. It will be submitted after I rewrite the documentation, which will be tomorrow or the day after tops (the package has evolved a lot). After the submission it depend on the Asset Store's reviewing process, usually one or two weeks.

About the Match Image Renderer Position and Scale, what are the problems that arise if you enable them?

The way those work are, given that the UI version needs to be in a different GameObject, when enabled those options will make the GameObject containing the particles mimic the Image Renderer's transform position and scale settings, in case the Image is moved or scaled.

 

That sounds great

The problem I am having is that if e.g. I have a top element under a Canvas:

Canvas
+GameObject (with Image component)
++StaticContinousEmitter (Render Image reference set to the parent game object)

Now if I have those 2 options enabled the position of the particles are wrong. If I disable the options then the particles are spreading from the correct positions of the gameobjects image. I did use a backround image on the gameobject covering the whole screen. So I guess I am doing something wrong here?

 

Hi Zarlang. Thanks a lot for the instructions! My mistake was not enabling Read/Write for image import. You included that in the manual and there was an error message too! Should have paid more attention

Yes, I understand that Text is a completely different story. Would be very cool though

 

Hi, this is great.
I just bought it, and I was thinking if there is a way to "reverse the particles", right now, the particles are generated in the sprite and they "fly" away, I want to make the opposite, generate the particles in a random place, and then they "fly" in the sprite, to create a "appearing" effect.