Hi all,
We would like to discuss the direction of our particle system with you. Rather than pre-seed this discussion with what’s on the roadmap, I want to be sure we don’t miss anything, so I want to start this discussion with a relatively blank roadmap.
To really help us though, like we have done in other threads, it REALLY helps for us to understand who you are and what your use-cases are to put you comments in context.
Who are you?
What kind of game are you trying to build or would like to build?
How does particles fit into that? What use-cases do you have?
What are the GOOD things about the particle system now you like?
What are the BAD things about the particle system now you dislike?
How can we make it BETTER?
Again, it’s super important we understand you and your use-case more than “add feature X now, do it!” without context.
Jack of all trade hobby developer who is running a free game graphics resource page since several years.
This is not bound to a specific genre. In the past i made from puzzle games up to rpg nearly everything. Former project was a 3d jump n run with puzzle elements. Next may be a Bejeweled clone in 2D. Or a strategy game. Most likely a little tool first.
Like my previous poster, almost everything around water effects and explosions, splash stuff. Additionally stuff like fog, wind effects like a whirlwind, or status effects for the player, like pain stars jumping out of him.
I double the need to scale the whole particle system as one. It’s a pain to adjust a particle system when you have it in a specific size already, and need it in another size. Makes it hard to transfer.
I also request a direct way to destroy the particle system by code. The current workarounds across is alive or to put it into a hierarchy and destroy the whole hierarchy is not as good as a direct destroy command.
I’m making a 2D side-view neon-style football (soccer) game.
I use particles mostly for “juicing my game up” when collisions occur. It gives a really cool visual feedback of what is happening during a fast paced game.
It’s pretty straight forward to get the desired effect. But please note that I’m not really an advanced user of particles, so my use cases may be really simple
Some properties are not exposed. For example it’s not possible to assign the Collision planes after instantiating a particle system, which is a pain
Expose every attribute of the particle system! Something as simple as changing both “Start Color”'s when set as “Random Between two colors” or setting the collision plane as I mentioned before are not possible right now.
Hobby dev, third person open world game.
Water, smoke, rain, indicators (directions, mission starts)
Explosions are looking good enough for me (with detonator prefabs ;))
I like the flexibility of the system, but:
its too slow (a circle with a “few” particles (maybe 1000?) drags my game from around 110fps to 60fps if in view), should maybe be gpu-accelerated
billboards don’t work with lighting
wrong culling, the whole system disappears if the particle start is behind the camera
should have better presets. The system looks good if you know what you do, but the examples look like coming from 3d game studio 2002…
I’d really love to have the smoke of the new “the division” gameplay videos. Your transporter demo shows that you really really improved shaders, lighting and antialiasing, but the smoke still looks like a quad texture with perlin noise moving through the room, and smoke would probably be the single most used effect in my game. Guns smoke, bullets do, cigarettes, manhole cover, cars, tires, waterfall haze…
It is possible now to make really diverse and unique magic effects for a RPG for example, or those sparkles with physics interaction, but smoke or water is missing a bit.
As an artist I really don’t have much problems with Shuriken. I’d give another vote for scaleability and maybe a profiler for how expensive a single Particle system is on the system. But other than that… I don’t really have any problems with it, yet. I fact - I like it
who i am ? hobbist, in future asset publisher, 3d game
use cases - enviroment effect - dust, falling leafs, snow, rain etc…, effects for spell/power/level up
adv of shuriken - visual editor with some randomization based on curve, contain some event system which is useful for collision and so on situation
disadv - slow, no gpu-accelerated, lack of API (e.g. cannot set runtime 2x curves if i use random value between curves) and some visual feature (path particle based on curve/spline in 2d/3d space rather than hard type vector which is counter-intuitive and require more reiteration - vector for force (over lifetime) is good when we require very precision, calculated by math path but not for “organic” effect)
How can we make it BETTER?
more API, more visual features like path/force based on curve/vector (defined visual rather than hard typing), improve performance, more complex event system ? (e.g. define event which throw after some sec or after reaching above/under defined value in selected property?)
Me:
In my spare time, I sell asset packages, mostly particles, and I’m prototyping 2d games. I worked in the games industry for ten years full-time on games such as Baldur’s Gate II, Neverwinter Nights, Need for Speed Underground/Underground 2/Most Wanted/Carbon and a bunch of other stuff. My job titles have been technical artist, effects artist, lead lighter, and environment artist. I have worked with a half dozen engines, Max, Maya, Softimage, After Effects, etc. I have created particle effects for most of the games I’ve worked on: 2D, 3D, and cutscenes.
Use cases:
I create asset packages with effects that have a theme. For example, I know that a lot of people make games with a pseudo-retro vector graphics look, so I will create a group of effects that I think they would enjoy. Other packages might contain smoke, fire or other things that enhance environments. I try to keep the effects as simple as possible. I want the noobiest noob to be able to use my stuff without asking for help.
For my prototypes so far, I get more technical because I am comfortable with scripting and shaders.
I’ll fill in the good/bad later, gotta go to work!
OK, I’m back…
Good things about Shuriken:
Shuriken has just the right amount of complexity for 99% of the particles I currently make. For most of the games I’ve worked on, Shuriken would have been a huge improvement.
Shuriken never crashes on me. I think Unity has only crashed once for me in two years.
The layout is organized well. I can find everything easily.
Bad things about Shuriken:
For me, nothing really bad stands out.
Making it better:
Althought I haven’t done much scripting with Shuriken, I have done some with UDK/Unreal 3.
I’d like to have the ability to easily pass variables/values between shaders and Shuriken a la Cascade
example: if a value crosses a certain threshold, I increase the intesity of the lighting in the shader
I’ll add more here when I’ve had time to think about it.
I’d like to see the addition of a new module to Shuriken that enables the sending of dynamic parameters per particle to the shader.
Specially the dynamic parameter would use a single shader semantic ( i.e a single float4 as TEXCOORD2) to enable up to 4 dynamically controlled floats per particle to be transferred to the shader. Its pretty much exactly what happens with particle colour now as that uses vertex colors.
This would enable particles to provide the shader information such as its current lifetime (normalised to lifespan) or other dynamic values that are controlled by a particles lifespan. Doing so would allow for more complex effects to be created with particles as demonstrated in this Fire tutorial created with UDK. Check out 31.50 minutes into the video for seeing how they link together dynamic parameters from their particle system to a shader.
Without this functionality its pretty much impossible to recreate the specific fire effect demonstrated as there is no easy way to get the current lifetime of a particle to the shader. You could re-purpose the existing vertex color data, but then you lose the ability to tint the particle over lifespan, so that’s not really a solution or even a decent workaround.
I would suggest having a look at how UDK does this, but generally you’d want a set up where for each dynamic parameter float you can;
1. Select an input source
Normalised lifetime of particle ( i.e. current time of the particle normalised to its lifespan)
Speed
Size
SystemTime
Collision - would be nice to get this in somehow, perhaps a value of 1 on a collision which then smoothly fades down to 0 over a specific time.
2. The source value should then be mapped using either
Between two constants - i.e min and max value that the source is mapped (not clamped) to.
To a Curve - i.e. source is horizontal, output is vertical from curve.
The key points are
These values are per particle, not per system.
Various source values can be selected
Various mapping processes can be applied to source value
The dynamic Paramaters are passed to the shader using a specific and documented semantic, e.g. TEXCOORD2
I am the developer of the Cloud System which is available in the asset store.
I am getting lots of emails regarding Shuriken. Many want to use it, because of its batching capabilities, but then they run into a culling issue. This bug makes Shuriken useless when the particles are modified by any script.
Within the Cloud System, it was necessary to integrate several hacks in order to setup the tiling and other basic functionality like that due to the lack of an API for almost all the modules. The hacks only work in the editor which takes a lot of flexibility away. It would be awesome to get access to all the modules (also at runtime) through an API.
Looking at what we know about Unity 5, one of the only fancy"next generation" features that is missing is GPU particle support. Is there any word on if this functionality will be implemented within Shuriken?
Keith Boshoff, Technical Dude. RetroEpic Software CC
What kind of game are you trying to build or would like to build?
We’ve made e-comics, infinite runners, point-and-click adventure, puzzle and many more games. A few more in the pipeline that I’m not at liberty to discuss.
How does particles fit into that? What use-cases do you have?
Mostly visual effects, in some cases those effects are vital to gameplay.
What are the GOOD things about the particle system now you like?
The curve driven nature and ‘particle trees’ that can be created with shuriken has been a massive boon.
What are the BAD things about the particle system now you dislike?
No scaling. A particle system can only be emitted from a single source (ie. I can’t have 1 fire particle system that emits from 20 sources without coding my own particle spawners).
There aren’t nearly enough script bindings to access everything in shuriken.
How can we make it BETTER?
Expose every single setting that’s available in the Inspector to script.
Who am I? - Hobbyist and student, although I’ve done some game dev for educational and outreach purposes.
What game are you building/would you like to? - A first-person puzzle game, and would like to work on an exploration based 3rd person shooter, but I’m building design tools for that first.
What are you using particles for? - In my puzzle game, the art style is monochromatic, with only certain important features having colour. These are often highlighted with particle effects. So I use them for emphasis, drawing a player’s attention through a level, and also for atmosphere, and helping the player understand their position in the world (eg. gravity often changes in the game, so there is a subtle dust effect to show which way is “up”). In the 3rd person shooter, the character is a magician, and all the “guns” are spells. This will require a lot of particle work, so I’ll probably be pushing the system to its limits.
What is GOOD? - The modular design of shuriken means that it is pretty easy to use, and the modules are pretty self explanatory. It’s easy to tweak in the editor. Being able to designate your own emission mesh allows you to create more interesting systems, but then you need to manually edit the normals etc…
What is needs improving? - There are both a few bugs that need fixing, and several features that could improve shuriken that I will list (in some sort of least-most important/easy order):
Frustrum culling bug: if the particle system origin is outside the view frustrum, it disappears. This is an absolute show stopper for any system with long lived particles over a large area (like smoke)
Easy particle system scaling: as mentioned
Independent time scale: If you want to make a “stop time” effect, or just want particles in your pause menu, this is currently impossible. Adding such an option would be incredibly useful. Also it should allow particle effect to play backwards, which would be cool and useful.
Negative forces/emission speeds: It’s very easy to make an explosion effect in shuriken. Now try making an implosion effect. Much more tricky.
More emission shapes: Ring shaped emission is quite a common need, for example. Maybe also defining local emission points. Also, being able to define “emission density” so that you can change the shape of emission and not have to change the particle emission count
Radial coordinate mode: Ever try to make a particle system that has rotating elements to it? Sure, you can make the entire system spin with a script, but what if you only want part of it to spin? An ability to define motion in radial coordinates would really help with this.
Better particle shaders: People have mentioned lighting, but there are several other kinds of shaders which I think would be useful: Alpha erosion (for smoke effects), refraction (for water/liquid), shaders that effect the colour of what’s behind (eg making colour negative)
Texture/UV based emission: Think an “emission map” like a specular map, that defines where on a mesh, particles are emitted from. (eg. just the bits that are on fire/burnt etc)
Emission from skinned meshes: self explanatory, and really useful for character effects etc. Perhaps combined with the emission maps I’ve just mentioned (eg. making a characters arms become wreathed in flame)
Attractors/repellors/turbulence/more interactivity: Whilst not vital, modules to do this would be incredibly cool. Imagine walking through a fog and the fog swirling more as you moved through it. Nifty.
Path following for particles: Being able to make particles follow a spline path would be super cool. Maybe too much of a specialised requirement for the main shuriken package though.
and finally…
Improved scripting access: So many parts of shuriken are not open to scripting. They really all need to be. Some of the desired features I could add myself, but without scripting access, that becomes impossible.
Thanks again for asking for this community feedback, it is a welcome relief after quite a long period of relative silence. It’s good to know you’re listening!
For a basic particle system, it works, and does what it is supposed to do.
Its pretty limited, and the interface for making a particle system could be laid out better.
Particle scaling. a particle can be used in many ways and many scales, the ability to scale the parent object and have the particle scale with it would
be very good.
In large scenes we have to use an origin reset to bypass float precision issues. When a particle emitter is reset like it it is cut, and then restarts. This is an awful effect and we can no l longer use particles for our engine trails. The ability to make the particles aware of the parent object and move accordingly would be most valuable, in many projects.
Bring the UI into a single view instead of the inspector like one we have, with the ability to focus on individual particles, right now everything as to be assembled in a scene to get an overall view of whats going on.
More - options, manipulators, settings, effects etc.
Mesh related particle uses, emit from shell for example.
More example content/assets, right now we don’t even have the basics needed to prototype a new effect.
open up everything related to particles in the API, there is no reason I can think of for this to not be available.
I should not have to get assets to round out the particle systems in Unity, as it is now we use FX Maker and Particle Playground, Look to them to see examples of what Unity particles are missing.
I am sure there is more, but this is what comes to the top of my mind.
This would have to be a Windows only feature since Unity’s OpenGL implementation doesn’t support the features needed for this and they said they don’t plan on changing that any time soon.
Depends on what features you’re talking about. Many things are possible even in ye olde GL2.x / DX9. That said, no, built-in “GPU particle systems” are not planned for 5.0.
I don’t think anyone actually said that. There are people working on “more modern GL version” support for Mac/Linux/Windows right now. That work might not be for 5.0 just yet, but there is progress being made in that area.
Why not? AFAIK all the stuff platforms Unity supports should have Compute shaders (Unless they are not in OpenGL ES 2.0) and even on all platforms except for IOS(It seems IOS does support it but Apple won’t accept apps using it) there’s support for Open CL which could be used, having a fall back to CPU would be ok, or even an option to pick.
Hmm, actually maybe not. Much conflict on this subject, I guess I’m not up to scratch on the lingo.
