thanks for the update…
thanks for the update…
Can we inherit simulation speed across all child submitters the same way we can we size please
I think I did something like this once via vertex shader (in Unreal). The gravity didn’t come from the particle system but I was pushing the vertices downward with a particle-parameter which controlled the amount the vertex-shader pushed the vertices towards the ground. Of course it would be nice if particle systems would have support for something like this without having to use a workaround like this.
I finally had a chance to check this one out after few months and this is not what I was expecting to see
I want to set Duration of subemitter to Lifetime of parent particle. This means that I could use Curve over Duration on subemitter to change looks over parent’s particle lifetime. Practical example:
Inheriting Lifetime only means that subemitter particles will have lifetime equal to parent particle lifetime and has nothing to do with actual Duration.
I’m on 2018.2.
EDIT: I also tried creating Random Rotation for an emitter by creating parent emitter with random rotation and setting Inherit:Rotation but that only affect rotation of the particle itself, not of the while emitter. How would I go about aligning the whole subemitter shape with rotation or parent particle?
I think this makes sense to me, thanks, I’ll make a note.
To ensure I understand correctly - at the point the sub-emitter spawns a particle, you want to read a main-module property (eg start color curve), at the point along the curve as if the parent particle was performing the sample.
Do i understand?
Thanks for the feedback!
Right now we align sub-emitter shape with the velocity of the parent particle. There is no way to choose to use the rotation, though i agree it would be useful and it’s not the first time it’s been requested! I can add it to the roadmap too. My main obstacle in adding it, is i could never quite decide where in the UI it would go. (ideas welcome!)
Exactly. So in classic fireworks example, the older the rocket is (main emitter) the fewer particles you spawn and the more red they are (sub-emitter). This you would achieve by animating sub-emitter’s main module params over Duration inherited from Parent Particle Lifetime at the spawn event.
To me it makes sense to put it into Shape module, somewhere close to Rotation, Position Etc at this is logically bound to Emitter Shape (you are sort-of adding rotational offset to the Shape). So you would set it in SubEmitter rather than in Parent Emitter. This way you could have some Subemitters which are aligned to parent rotation and other which are not. Or, if that’s not possible, I guess this could be added in SubEmitters module but Inheritance Enum would have to be changed into a list of inherited props. Otherwise you will end up with a bloated enum with tons of permutations.
Also, how feasible it would be to have curve and random value controls for Rotation and Position params of Shape?
I also have some feedback on 2d workflow:
It is REALLY hard to align particles to the XY plane. It is possible but the amount of adjustments I have to make to Shape Rotation offsets is overwhelming.
I am replacing Cone Shape with Circle+Angle which is fine but Subemitters are aligned with Z axis of the Parent Emitter which means that if I want to align SubEmitter on XY plane I have to set X rotation to 90. Check it out yourself ( https://drive.google.com/open?id=1djaeqL8W7J7Jpv4T3UZ7p1U-rGST-sDj this is a .prefab of example effect without rotation in the subemitter Shape module. It is -not- aligned with XY plane).
Then If I’m using Angle of eg 50* I need to set additional Y Rotation Offset to -25* to make emission symmetrical (otherwise I am getting 50* angle of emission on one side of the emitter). And so on. This is very time consuming and not fun at all.
Other features are also semi-compatible with 2d. For example Noise works in 3D by default and I need to separate axes every single time and set 3 parameters instead of one in a project which actually has one dimensions less. Meaning that in 2D project you have more numbers to punch in than in 3D projec an it actually should be the other way around.
Unity changes few things for the user be default when the project is set to 2D but it seems that nothing like that happens in Shuriken (Collisions are set to 3D, default shape is Cone orientated so that it always spreads particles in Z axis etc etc).
Probably it’s my fault, but there is a way to avoid continuos rotation after collisions? If I have rotation by speed, even if I put damp high when the particles collide on the ground they continue most of the time to rotate… I think that collision module maybe can be tuned up, found Unreal one easier
Ok, I’ll see what I can do about “Inherit Duration”
And I added your suggestions about using rotation instead of velocity for sub-emitter shape module direction!
Not very It would mean 9 more curves, and those curves don’t come for free. Sorry, not likely that this one will happen!
No not your fault, we have an item on the roadmap to add “Rotation Loss on collision” simliar to lifetime and speed loss options, to allow you to freeze a particle’s rotation after a collision.
Admittedly the 2D workflow is something that we don’t focus on enough with Unity’s Particle System.
However, I would expect that you should simply set the Z scale of the Transform Component to 0. (And use Local or Hierarchy scaling mode in the main settings)
I agree that this wouldn’t solve everything (eg the subemitter issue you raise) but it should make the Noise Module work in 2D without any extra work.
Thank you for your answer. I tried to give much speed loss and hope that rotation by speed would stop but I found this combination quite buggy… maybe my fault I was thinking, but you confirm me that it’s not a good working stuff for that
In Unity, you can make it thinner over time by animating a custom parameter (color, alpha, etc) as Material parameter input, and use it to displace the vertex position using the vertex normal. I’m sure Unreal and others have similar approaches.
Maybe not good question, but would be possible to include also a box collider shape? I know that sphere is maybe less demanding and I would not think to a more complex convex collider, but sometimes a box would fit better than sphere, in addition of course to the stop of the rolling factor