Hey, to anyone interested in seeing what’s coming in the next version of Unity for Particles, you may want to take a look at this document:
Everything mentioned in the doc will be available from 2017.1.0b2 onwards, and the first few items are in the first beta, which is already available here Early access - Unity
Hey! Those features sounds really great - I can’t wait to test them in my project. Latest improvements in particle systems made my life way easier and helped deliver faster.
Since you are here and you obviously would like to hear feedback from vfx artist about features/improvements, I’d like add two requests to your probably long todo list
Attractor module - Particles would be attarcted to object over time. It would be usefull if we could choose the type of object that it would be attracted to (i.e. skeletals, geometry, other systems, colliders). User could specify what could happen if the particles find the target (die, spawn, stick, bounce etc.). I know it can be done from scripting but more robust tool would be much easier to implement for developers.
Modules instatncing - often I find my systems to get pretty big and hard to manage. Unity 5.6 added a big improvement to that area allowing me to select multiple systems and change variables in a single window (praise you for that!). However this becomes hard, as the systems grows. I always have many diffenet copies of the same thing, doing slightly different operations.Selecting that many objects can be very tedious if I want to change a simple color, not to mention selection errors. Module instancing - you select a module that should be copied and other systems can select this module to instance it. If you change any of the instances, all of the instanced modules change. This behaviour is similar to the one found in UE.
We actually have both of those on our internal roadmap already, as they would be great additions, and are popular requests
We have started prototyping an upgrade to our External Forces module that would enable more complex interactions, including Attraction, Drag and Vortex behaviors. We have only prototyped spheres and cylinders though.
I’m trying to imagine whether you could use our current prototype alongside the Collision Module, to get some of the behaviors you describe. e.g:
Using collision, a spherical attractor, and zero bounce, ought to create the “stick” effect, but maybe there would be sliding…
Using collision, a spherical attractor, and the collision kill speed property, ought to kill particles when they touch the surface of the collider.
Same again, but using a sub-emitter with spawn-on-collision enabled, for spawning.
Our reason for only supporting Spheres and Cylinders (so far) is that using parametric shapes allows us to compute “how far” inside the object we are. This is useful for allowing you to specify falloff curves for the attraction strength inside the volume (etc). More complex volumes would require a more complex solution (e.g. pre-computed 3D signed distance fields).
This all sounds really great for me. I’m working with Unity every single day. This “small” things really make my life easier and I hope to get them ass soon as possible Thank you for your activity here!
Is there any way to see that roadmap you’ve mentioned? Would be really great to see what is being planned so that I wouldn’t repeat my ideas and maybe add something usefull
One more thing I’d like to request - air resistance module. Current “limit velocity” is complicated and is not providing the same type of motion.
I created a simple script that takes two parameters: Drag (object resistance coefficient) and Mass.
Then I do - particle.velocity *= 1 - (Drag * timeStep / Mass);
It is really simple to implement and is using simplified air resistance formula but I can imagine that other people without scripting knowledge would like to see this in action.
I also wanted to ask how do you allocate random value per particle? Currently I create an array which is as large as the Max Particles parameter and I fill this array with my random data. For example, I can set random Mass for each particle. Is there any other way of doing per-particle data or maybe this is the best solution out there? I am a little bit scared of creating array with like 800+ elements in it!
Neat! I’m glad you’ve included Billboard Aligned Meshes! That’ll be a massive help and really allow for some cool effects.
I do have one question though- are you going to add Trails with a locked axis? Below is a basic animation of what I mean- the first is the ideal result, while the second is the current result. The trail kinda acts as a revealing mask but the tiling texture remains in the same spot (not screen position though).
The “Tiled” option for the current version of Trail Renderer is close but its missing some features. I think it primarily the scaling option (how big it tiles globally). Ideally, it’d be nice to have a combination of “stretched” and “tiled” at the same time to really mess around with the result. I think that’d be the best solution.
Unfortunately it’s internal, as it’s not a commitment to implementing anything, but more of a collection of all our known (and good) feature requests. We do have a public roadmap here Explore Future Plans with Unity's Platform Roadmap | Unity but it doesn’t usually contain any particle content until we can commit to an exact version something will ship in. It’s hard to find the right balance between telling you what’s coming, and not telling you so far in advance that’s it’s just frustrating at how far away an actual feature is.
This one was requested once before… but hasn’t moved on from an initial prototyping phase. I will take another look at this and see if we can finish it and get it into a version soon.
This sounds like the same thing we do internally. The only bit that can maybe be considered clever is that each particle only stores a (probably) unique seed, not the final random data that will be used by the particles. Then we have a fast way to generate lots of random data for a particle (size, rotation, speed etc), all from one seed. This saves a lot of storage space, at the expense of a small amount of extra computation.
I think this one came up once before too. I will take another look, as we have recently added some new texture modes to the Line/Trail renderers. Maybe we need another new option…
I just wanted to post back here to say that this is coming in 2017.2
We decided it wasn’t big enough to require it’s own module though, so it will appear as a new option in the Limit Velocity Module.
@richardk Quick note about dithered shadows for particles: the built-in texture tends to generate artefacts when several particles with different opacity are overlapping.
I believe this is due to the dithering texture having overlapping frames that will result in full black, whereas using a texture where only one pixel is added at each frame will prevent this.
Here’s the comparison:
Built-in texture:
Custom dithering texture:
Might be worth taking a look if you haven’t already, especially with the standard particle shader coming along!
Yep, the default dither texture used curiously doesn’t ever go to a straight checkerboard either. I’ve been considering replacing the dither pattern with my own for this same reason as I occasionally get this flash of black on overlapping shadows on my own project using my custom shaders that have a similar shadow caster pass. Actually I might have already replaced it with a stochastic noise …
Hey, thanks for the feedback! I’ve never looked very closely at our dithering, until now
Would you be willing to share your custom dithering with us?
I’ve made a note to look into this soon - it definitely seems like it would be an important fix to make, before everyone starts using this shader and getting glitchy shadow fades