Parenting of particle sub emitter in 5.6

I have reported a case 892393 about assertion failed errors which leads to editor crash in Unity 5.6. As told by the bug report team this is triggered by NOT parenting the particle sub emitter under its "master" emitter and there are more than 1 master emitter linked to the same sub emitter. TBH I won't say I would be surprised at the reason for such change of structure (performance?), but it also means that in Unity 5.6 onward we are required to duplicate the same sub emitter per each master emitter to avoid the assertion failed errors. This can be a problem or even nightmare of organization when we have a bunch of sub emitters linked to multiple master emitters as shown in the project of my bug report.

While it may not be relevant to the designer of Shuriken, I never ever parent sub emitter (and I even intentionally break the default parenting of sub emitter) because of a limitation of Unity editor that you can't modify the grandchild or younger descendant of a prefab in project folder, you must drag the prefab to hierarchy, edit and apply it which can be cumbersome when you are playing the scene but want to modify the prefab on the fly.

 

What about when a sub emitter is linked to more than 1 master emitter (but parented to 1 of the master emitters), that sub emitter is automatically duplicated and parented to the remainder of linked master emitters within the engine to enable multithreading? (Sorry I know I oversimplify the process obviously because I am no programmer/software engineer.)

The issue of not being able to show prefab structure beyond 1st descendant in project folder has occurred to me since Unity 4. I have just filed a Feedback ticket for this issue.

 

I am curious about this as well. I often use one sub-emitter for multiple master emitters, what is the best method for this?
The errors are extremely annoying!

 

Now we need to manually duplicate the sub emitter per master emitter, parent and reassign to the sub emitter module in master emitter. This is bearable because the particle system editor now support multi-editing.

 

Yeah you are right, besides the obvious effort we have to put into this, it seems to me like a waste of GameObjects and not an increase in performance (in these cases) to be honest...

 

@richardkettlewell case 899574
I followed the requirement of parenting sub emitter in 5.6 and only pair each sub emitter to 1 master emitter, but I still get the "sub-emitters must be children of the system that spawns them" error message under a specific setup which is related to the spawning condition of "death".

 

Can we get an official statement here? Will this be changed/fixed in a future version? It's not only annoying for me, but the clients buying my particle package will have the same issues.

 

Also I want to confirm 1 thing from Ric/Karl:
The error message "sub-emitters must be children of the system that spawns them" no longer shows up in 5.6.0f3 after linking each sub emitter to only 1 master emitter correctly but without parenting. Is it no longer required to parent the sub emitter to its master emitter? Actually there is a strong reason not to parent when you do not want the transform.rotation of the master emitter object to interfere with the sub emitter object transform especially if the latter's simulation space is local and emits particles in a definite direction/angle. (I remember in the older versions, the transform.rotation of the sub emitter object is treated as (0,0,0) in engine no matter what, but possibly from 5.5 onward the rotation is finally effective.)

 

In 5.6.0f3, Duplicating the \StandardAssets\ParticleSystems\Fireworks will produce this error in all duplicates. however, if you drag out multiple prefabs instead of duplicating. no errors.

 

I am still getting this issue when my hierarchy operates like such:

- Emitter has 2 sub emitters (1)
- 1 on birth (1.a)
- 1 on death (1.b)
- Death sub-emitter has 1 sub-emitter
- its sub-emitter is on birth (1.b.a)

Master (1)

SubEmitter 1.a (on birth)
SubEmitter 1.b (on death)

SubEmitter 1.b.a (On Birth)
​

Even tho SubEmitter 1.b is a child of the master it still throws an error. The error stops when its SubEmitter is turned off

Making 1.b.a on the same level as the other SubEmitter still causes an error.

 

OK. So how will the next patch/release treat unparented sub emitter as mentioned in my previous post?

 

I also have a particle setup where there are many particles that "sub-emit" into a single particle. The "sub-emit" particle is very complex and has components that get and set particles, instantiate prefabs onto particles, and maintains a random_seed dictionary. While I _could_ duplicate this child particleSystem, it would be an extraordinary pain to maintain while I'm iterating, and the overhead is substantial. The "parent" particles, on the other hand, are lightweight, and don't even emit that many particles. To solve this issue, I plan to implement my own emitter monobehavior so that several objects can emit into a single subemitter via c# emit commands.

 

Now sub emitter works in 5.6.0p4, but I would rather you write that "a sub emitter can only be linked to a single dominant particle system". It's just misleading by mentioning "parent" in that error message while NOT parenting a sub emitter to its linked particle system does NOT necessarily trigger that message, or vice versa.

 

I got the ERROE "Sub-emitters must be children of the system that spawns them",my version is 2017.3.0f3.