Hierarchy Folders

Did you know that organizing your hierarchy under empty GameObjects can have a considerable negative impact on the frame rate of your game?

But on the other hand, not organizing your hierarchy can have a huge negative impact on your work efficiency, not to speak of just general quality of life.

What is a Unity developer to do in this no-win situation?


Well, this is where Hierarchy Folders comes in. With the help of Hierarchy Folders you can organize your hierarchy just how you like it, while still avoiding all the negative side effects you usually get when using empty GameObjects for the job.

Finally you can have your cake and eat it too!

Asset Store - Buy Hierarchy Folders
Join Mailing List - Be in the know​

Features​

☑ Improve frame rate of your game by up to 40% by using folders instead of empty GameObjects to organize your hierarchy.
☑ Folders are clearly distinguishable from other objects in the hierarchy and in the inspector.
☑ Folder transform locked to default state so that states of children are never affected in any way.
☑ On-the-fly play mode stripping ensures 100% consistency with final build when playtesting in the editor.
☑ Order of transforms remains consistent through the stripping process.
☑ Configurable folder naming rules (uppercase, prefix, suffix).
☑ Menu shortcuts enable a very fast workflow for organizing your hierarchy.
☑ Thoroughly configurable to fit the specific needs of your project.​

Bonus: Custom GameObject Drawer
The following extra features require Power Inspector, due to the higher level of customizability it enables.

☑ Add component button hidden to prevent adding components to folders that are stripped from builds.(*)
☑ GameObject icon substituted with hierarchy folder icon.
☑ Configurable info text to clearly explain what hierarchy folders are.
☑ Tag field hidden to discourage referencing hierarchy folders in code.

(*)If you add a component to a hierarchy folder using the default inspector (or code), it immediately turns into a normal GameObject.​

 

Hi, came across your asset and find it interesting but could you elaborate your point why performance suffers from Gameobject hierarchies?

 

Sure thing @BPR ! I'll try my best to explain why flattening the hierarchies in your scenes can give such a substantial boost to performance.


Unity internally groups all the transforms in your scene hierarchies into structures called TransformHierarchies.

Each root transform in the scene is placed into its own TransformHierarchy along with all the child transforms underneath it.

When a single transform changes in any way, it marks itself, all of its children and the TransformHierarchy it belongs to as being dirty.

When an internal system in Unity requests a list of changed transforms, Unity has to iterate over every transform stored inside each of the dirty TransformHierarchy structures to generate the list.

Because of this, the flatter your hierarchy is, the fewer transforms Unity needs to examine every frame when looking for changes.


Additionally Unity utilizes a multithreaded job system when it examines the TransformHierarchies for changes. This makes it possible to examine multiple TransformHierarchies in parallel.

TransformHierarchies however are the most granular level that Unity will use when splitting these checks into jobs. This means that if you have a lot of child transforms under a single root transform, Unity can still only utilize a single thread when examining the whole hierarchy for changes.

So the flatter your hierarchy is, the more effectively Unity can utilize multi-threading when it is looking for changes to your transforms.


If you are interested in learning more here are a couple of resources on the topic that I highly recommend:

• Spotlight Team Best Practices: Optimizing the Hierarchy
• Video : Unity's Evolving Best Practices

 

Update 1.0.1 is now available for Hierarchy Folders! Here are some of the notable changes:


A new custom Editor Tool was added for quick and easy creation of new hierarchy folders.



If you have more than one GameObject selected in the hierarchy, they will be automatically grouped under the newly created hierarchy folder.

Also renaming will start automatically for the created folder, so you can just immediately start typing a name for it.


Another new feature is the ability to double-click a hierarchy folder to select all children.


In addition to the children being selected, this also makes sure that the double-clicked folder is unfolded, and all the child GameObjects inside the folder are folded. This makes for a convenient way to quickly assess the full contents of a folder.

I think that this double-click behavior makes more sense for hierarchy folders than the default behaviour of displaying the target in the Scene view, given that hierarchy folders are conceptually positionless and unseeable.


New main menu items were also added under Tools > Hierarchy that can help in converting your existing empty GameObject containers into hierarchy folders.



You can either convert an entire scene automatically, or manually convert only the GameObjects that you want.

Even the full scene conversion has complete undo support, so you can try it out safely and reverse all changes if you realize you want to convert some things manually after all.

 

I saw this when it came out and I have been looking for something like this. I was hoping at least someone would have left a review by now, lol. I might just have to go for it and give it a try as my scene is becoming quite crazy to work with, trying to manage multiple Timeline "Acts" within a single scene. It would be nice to be able to organize things without messing up any of the transform positions and relationships as everything is very precisely placed.

My only reservation is I tried something fairly similar, at least at it's core, it wasn't very feature rich though, that I found on github. If I remember correctly, the flattening of the hierarchy each time I wanted to hit play felt like it was taking forever and really slowing down my iteration cycle.

 

Hi there!

Sorry about the lack of reviews. I may have failed to give Hierarchy Folders the marketing push that it has deserves, having spent most of my time on the software development side these past few months


If you could give me an idea about the size and structure of your scene hierarchies (maybe take a screenshot), I could run some benchmarks to give you an estimate about how long flattening something like it would take.


Flattening the hierarchy when entering play mode is also completely optional, so you could have the hierarchy only be flattened when making a build, but keep the hierarchy folders in use for play mode. Performance would not be optimal in play mode, but if your computer can handle it it's a great option.

 

I went ahead and bought it already yesterday and changed over a few Objects that were standard GO's over to be the new folder objects, but since most of what I am doing is simply scrubbing through and hitting play mode from time to time and not actually making any builds, it may not benefit me as much as I originally thought it might.

My current project is primarily a cinematic / Timeline oriented project. One thing I am wondering, not sure if / how it would work exactly, but I have been looking into the newly added USD (Universal Scene Description) format, recording from Timeline, and exporting out to USD.

The way the USD recorder / export works is you give the recorder a root gameobject from the hierarchy and it records everything under that hierarchy and exports it to USD format (which I am wanting to then import into Houdini to add particle effects and such that can be aware of the environment and animations of characters).

Most everything in my scene is split up. Within a single scene I have the main root of the hierarchy, then might have an Environment GO, Lighting, Cameras, and then a Master Timeline with multiple Timeline "Acts" as child objects, then parented under the Act are objects that might be specific to that act. Each of those Acts may use the root Environment geometry such as trees, rocks, structures, etc.

I want to make use of USD exporting, but since my stuff is broken up and there is no "root" object for the scene, and even if there was, there would be way more in the recording / export than I would like for there to be. So what I am wondering is, is there a way to use this asset to, say, temporarily parent multiple things that were all originally scattered in different hierarchies to a single root object for a single play session without losing any of their original placement so that after the recording and export is completed, it all goes back to how it was as if nothing changed?

For instance, I might want a specific floor structure because that is where a character is standing and it has non-flat geometry, the character, and a camera as seen selected here:



It would be great if I could parent them all to a single root object so I can add that to the USD recorder and then hit play, it can record just those objects and then put them back, without changing how anything works or where it is in worldspace, if that makes sense?

My apologies for the wall of text, the question as a lot shorter in my mind when I first thought of it, lol.

 

There's currently no functionality to do something like that using Hierarchy Folders, but this should do it:

Code (CSharp):

1. using UnityEngine;
2.  
3. #if UNITY_EDITOR
4. using UnityEditor;
5. #endif
6.  
7. public class TemporaryParenter : MonoBehaviour
8. {
9.     public Transform temporaryParent;
10.    
11.     [SerializeField, HideInInspector]
12.     private Transform originalParent;
13.  
14.     private void Reset()
15.     {
16.         originalParent = transform.parent;
17.     }
18.  
19.     #if UNITY_EDITOR
20.     [ContextMenu("Move Under Temporary Parent")]
21.     private void MoveUnderTemporaryParent()
22.     {
23.         Undo.SetTransformParent(transform, temporaryParent, "Move Under Temporary Parent");
24.     }
25.  
26.     [ContextMenu("Restore Original Parent")]
27.     private void RestoreOriginalParent()
28.     {
29.         Undo.SetTransformParent(transform, originalParent, "Restore Original Parent");
30.     }  
31.    
32.     [MenuItem("Tools/Temporary Parenter/Move All Under Temporary Parent")]
33.     private static void MoveAllUnderTemporaryParent()
34.     {
35.         var parenters = FindObjectsOfType<TemporaryParenter>();
36.  
37.         foreach(var parenter in parenters)
38.         {
39.             parenter.MoveUnderTemporaryParent();
40.         }
41.     }
42.    
43.     [MenuItem("Tools/Temporary Parenter/Restore Original Parent For All")]
44.     private static void MoveAllUnderOriginalParent()
45.     {
46.         var parenters = FindObjectsOfType<TemporaryParenter>();
47.         foreach(var parenter in parenters)
48.         {
49.             parenter.RestoreOriginalParent();
50.         }
51.     }
52.     #endif
53. }

 

Awesome, I will give that a try. Much appreciated. : D

One quick question I just thought of. If I place a folder down in the hierarchy at root, then say, place two more under that, then place an actual gameobject in those two which are parented under the first, are the transforms of the two gameobjects that I placed technically child objects using local space while editing even though the folder object shows no transform object?

 

Yes, hierarchy folders do still actually have transform components under the hood and they act as the parents of objects grouped under them in edit mode. If hierarchy flattening is not enabled for play mode in the preferences, then this is also true in play mode. Under these circumstances there is no performance benefit to using hierarchy folders over empty GameObjects, as you would have to create a build before you would see the benefit.

On the bright side you will still have all the convenience benefits of using hierarchy folders like:

• Transform hidden and locked to default state.
• Visual distinction between folders and other GameObjects.
• Double-click to select children in hierarchy view.
• Easy grouping of selected GameObjects under new folders.
• Auto-naming functionality.

There are also various extension methods for Transform and GameObject that can be used to do things like get the parent or the root, with the option to skip past hierarchy folders, in case someone runs into a situation where these would be useful.

 

I agree that the locked and hidden transform, as well as visual differentiation, are not bad to have. On a few occasions I have found that an organizational parent ended up being moved instead of the intended child object, I ended up having to go back and figure out what I goofed up and fix it, lol.

 

Hi @SisusCo

Thanks for Hierarchy Folders - I bought it yesterday.

My use case was simple. I'm basing my scene on a Synty 3D environment asset, which has a bunch (like a LOT) of assets all in the scene root. It was impossible to find anything.

Hierarchy Folders put it all right for me - was quickly able to group together like assets into folders and calm was restored in the universe.

Have a couple of feedback suggestions:

1. I wanted to quickly select assets and then group them. Found no way directly in Hierarchy Folders, so bought another asset (Nparent AutoParenting) to group assets into a parent. I then used the Hierarchy Folder menu item to convert that parent gameobject. To cut this step, a Hierarchy Folder "Group Objects" menu would be nice. I'm sure it's something I'll need a lot.

2. If you click on a folder (or gameobject) and select "Hierarchy Folder" from the context sensitive menu, it creates a sibling of the folder you selected. This is at odds with the rest of Unity. For example, if you select "3D Object"→Cube, it would create as a child of the folder. Could you change this (or make it an option) to keep it consistent with Unity?

I plan on using Hierarchy Folders in my future projects, and will certain convert my ongoing ones. It looks like a wonderful thing – I'm curious in particular to see how it reacts to mixing with RectTransforms for grouping UI elements.

Thanks again for putting it out there into the community. I'll be sure to write you a review on the asset store when I've got more experience with it!

 

Hmm – looking at my point 1 above again, it looks like you actually have this feature via the menu toolbar folder button. Totally missed that - doh!

Maybe it would be good to add this to the menu tho - either the context menu or the Tools menu so people like me that don't look hard enough find it first time?

 

Hi @Colin_MacLeod I'm glad that hierarchy folders has been useful to you!

Sorry to hear that you had a hard time figuring out how to quickly group multiple objects under a single folder parent. There are actually multiple ways to accomplish this. First you have to select multiple targets in the hierarchy and then you have to follow with one of the actions listed below:

1. Open the create menu by clicking the plus sign found on the hierarchy view toolbar and select the item Hierarchy Folder.



2. Click the Editor Tools Toolbar icon.

To see the icon in the toolbar you first need to enable it by clicking the last icon found on your toolbar and selecting the item Hierarchy Folder.

3. Select the main menu item GameObject > Hierarchy Folder or use the shortcut Ctrl + Shift + G.


In addition to these methods that can be used to create new hierarchy folders it is also possible to convert existing GameObjects into hierarchy folders.

The simplest way to do this is to use the main menu item Tools > Hierarchy > Convert Selected to Hierarchy Folders.



You can also automatically convert all GameObjects in the root of the open scene into Hierarchy Folders using the menu item Tools > Hierarchy > Convert Scene Root to Hierarchy Folders. This works well if you have a scene that is already using empty GameObjects for organizing all your scene objects.

All of these methods are also described in the documentation found at
Assets/Sisus/Hierarchy Folders/Documentation.

Do you think that adding a welcome screen that describes these methods or at least links to the documentation would be a good solution for improving their discoverability?

Thanks for the suggestion! I will make the context menu item create the hierarchy folders as a child of the clicked object. I'll also add support for multiple selected targets for the context menu item while I'm at it, since that actually isn't currently working properly either.

There is basic support for RectTransforms. They are currently just treated basically identically to normal transforms, with positions, rotations and scales kept locked at default values. Other values of RectTransforms (dimensions, anchors) are currently not locked or altered in any way, they are simply left as they were.


So if you convert a RectTransform that is at default state into a Hierarchy Folder it should work, but if it is using non-default anchor presets and such this could have an effect on the children.

If you have any suggestions on how RectTransform-based Hierarchy Folders could be improved further I'd be happy to hear them.

That would be very much appreciated, thank you

 

Cool - yes, I think that would really help impatient/unobservant people like me. I was specifically looking in in the context sensitive help for a "group into a folder" item.

 

I just submitted an update to Hierarchy Folders that contains the improvements for the context menu command discussed above, as well as introduces greatly improved support for RectTransforms.

Previously all Hierarchy Folders had a hidden Transform component and they were not aware about whether or not they had any RectTransform children or not.

Now if a new Hierarchy Folder is created under a RectTransform parent, or if a RectTransform child is moved under a Hierarchy Folder, then the Hierarchy Folder's Transform component will automatically be converted into a RectTransform. It will also modify the anchorMin and anchorMax values so that the local state of any RectTransform children will no longer be affected at all by the hierarchy folder. This is all done without any children being affected of course.

Additionally anchorMin, anchorMax, pivot, offsetMin and offsetMax values will now also be kept locked for all RectTransform-based Hierarchy Folders. I'm not really sure how useful having this behaviour is given that the RectTransform is hidden in the inspector anyways, but it should be totally fool-proof now so users can't inadvertently alter their states even through code or something

I'll let you guys know once the update has passed the asset store approval process.

 

The update is now available for download.

 

@SisusCo Just left you a 5 star review for Hierarchy Folders and I bought Power Inspector for good measure too.

Thanks for all the great stuff!

 

@Colin_MacLeod Awesome, thanks a lot! It's a great review to boot - I'm sure it will be most helpful to anyone on the fence about getting the asset.

I hope you'll find Power Inspector very useful as well!

 

How do you store the preferences? It appears to be local to each machine.
I pushed my project to version control and then when I pulled on another machine all the "---" lines appeared again. Personally, I'm not a fan of all the dashes - can these settings be made project specific?

 

@Colin_MacLeod
All the preferences are currently stored in EditorPrefs and as such are indeed user specific. It's a very good point that this doesn't actually make sense for many of the preferences, such as the auto-naming or stripping stuff.

I'll refactor to change this behavior, moving at least some of the preferences under project settings and saving them as an asset.

Thanks for the feedback!

 

I submitted a new update to the asset store for approval with this behavior changed. Preferences will be saved under Assets/Sisus/Hierarchy Folders/Project Settings once the update has been installed.

If you'd like to get your hands on the update without waiting for it to pass approval first just let me know and I can send it to you.

 

@SisusCo Very cool - thanks for being so responsive again - that's very good of you indeed

Yes, please on getting early eyes on the update. If you can ping it across to colin@bitquirky.io that would be most wonderful!

 

@Colin_MacLeod The new version should now be in your inbox.

 

Yes, ideedy. THANK YOU!

 

Just purchased this and can't wait to give it a shot. Hopefully it would help with the near infinite scrolling in the hierarchy.

 

@pbritton You have come to the right place, sounds like just the thing that hierarchy folders can help you with

All feedback is most welcome by the way, I'm always interested in learning how the hierarchy workflow/integration feels or if anything could be improved further.

Cheers!

 

Hi @SisusCo
Will Remove From Build work with Unity Cloud build? If not what are the steps I need to do to configure it?

Thanks!

 

Hi there @mostlyapt - thanks for the great question!

I have not tested Hierarchy Folders with Unity Cloud Build, but I don't see any reason why build stripping wouldn't function perfectly fine with it. The stripping occurs during the internal PostProcessScene callback that is part of the normal build pipeline, so I am confident that it would also work with Unity Cloud Build without any special configuration necessary.

 

Thank you!

 

Hi,

For every scene load in editor I am getting error as shown in the attached screen shot. Can you let me know what might be the cause?

Thanks!

 

Hi, I'm very sorry to hear you've encountered issues!

It looks like Awake is called for a hierarchy folder but the scene containing it is not actually yet loaded, which seems to result in an exception when Scene.GetRootGameObjects is called. I'm guessing that you're using async scene loading (possibly combined with allowSceneActivation=false) which I didn't think to test.

I'll start working on a fix immediately.

 

I was not able to reproduce the issue yet using async scene loading in the Unity version I'm using.

I found an entry in the unity issue tracker that seems to claim this issue was fixed back in Unity 2017.2.0f3. What version of Unity are you using?

UPDATE: So I wasn't able to replicate the issue in any Unity version I tested, not sure what could be causing the disparity. I still went ahead and slightly tweaked how play mode stripping works to hopefully get rid of the issue. I sent you a PM with the new altered version. Hope it helps!

 

After applying update, configured folder hierarchy in the scene is getting flattened out completely, i.e. whenever I close and open the scene. I am using 2019.3.10f1 version of Unity Editor.

 

I'm glad to hear that the update got rid of the exception!

So this sounds like everything is now working as intended if I understand you correctly? Play mode stripping behavior can be configured in the preferences. By default hierarchy folders are entirely removed in play mode as they are in builds.

 

Actually, all the folders are removed and replaced by empty object versions that you get during playmode in the editor itself. I haven't entered the playmode yet and if I close and open a scene again, all the folder hierarchy is gone and it gets all jumbled up.

 

Ugh, now I see what you're talking about. A reused list wasn't being properly cleared after use in one place, resulting in the rather major side effect you mentioned when using certain preferences. Sorry about that! I'll submit a hotfix to the asset store and send it to you in a PM.

 

Hi there, great asset, but I'm having a problem. It seems like Build Stripping is removing my entire static-marked level residing within the folder. The game works in the editor, but not in build. When I move my static-marked level outside of the folder into root, the game works in build. I tried disabling Build Stripping but it never seems to remember that setting, it keeps rechecking itself to true. I've decided to move the static level out of the folder for now so I can build the game.

 

Hi there @IgnisIncendio !

Would it be possible for you to send me a project that can be used to reproduce the build stripping issue?

I was able to replicate the issue with the Apply Changes button in preferences. Changes actually did get saved to disk, but the preferences window would still use a reference to the old asset when checking for unapplied changes. I'll push out an update with this fixed.

 

Hi team,
It seems that the folders reverse back to GameObject when within a prefab. Is it correct, or am I doing something wrong?
I am using 2019.3.15f1
Please let me know what you think.
thx!

 

Hi @ecoSamJoly !

Hierarchy folders can indeed only exist in scene hierarchies and will automatically be converted into normal GameObjects if you try to add any in prefabs.

Supporting hierarchy folders inside prefabs can't be done as elegantly as it can be with scenes where it is possible to completely strip them during the post processing phase in the build pipeline. I can think of two ways that prefab support could theoretically be implemented:

1. Apply the stripping at runtime when the prefab is instantiated. The downside of this method is that it could introduce some performance spikes when instantiating prefabs with hierarchy folders, because Transform.SetParent can be a relatively expensive operation when dealing with complex transform hierarchies.
2. During the building process check all prefabs in the project for ones containing hierarchy folders, create complete backups of all of them, and then strip all hierarchy folders from them (a destructive process). Once the build has finished, revert all the prefabs to their original state by replacing them with the backups. The downside of this is that it could considerably increase build times for larger projects, as it would probably require all the affected prefabs to be reimported twice - which I'm not even sure is possible without it interrupting the build process.

Neither option seems very optimal to me, so I've just decided to steer clear from supporting prefabs so far. Would you still prefer to have prefab support even if it has a cost during instantiation? What would your use cases look like?

 

Thanks SisusCo for your quick, and detailed response.
Agree that neither option 1 or 2 seems very optimal.

I've got addicted to the Folder and keep my hierarchy the cleanest as possible. So, it's logic that I tried to use it in my Prefabs.

- Maybe an option to have the Folder without stripping when in prefab? It would miss the performance aspect, and still benefit from the organizational aspect. The down-side is that it could confused some users, that the folder would have different behavior depending if in Prefab or not - Maybe an option to toggle in the config, that would force the user to take this choice, and be aware at the same time of the limitation of the folder in Prefab?

I think that it would be a good option to have, but sometime you have to pick your battle.
Thanks again!

 

Yes, I can see how that could be useful even just for the workflow benefits.

I am a little worried about the communication aspect, as I wouldn't want any users to be blindsided by the fact that performance can actually be impacted by hierarchy folders in prefabs. But I think this problem is solvable, so I will see about implementing prefab support in one form or another in a future update. Runtime stripping and no stripping should be easy enough to add, so I'm thinking I could start with those.

Thanks for the feedback!

 

Unity. Fail.

 

Hey there, I just wanted to share that I attempted to disable a few Hierarchy folders that I had in scene and then went to hit play (assuming that it would just disable all of the child objects when playing as a normal parent gameobject would) but before the game could get to a running state, Unity crashed and closed.

Not sure if disabling the Hierarchy folder objects is actually supported, but if not perhaps a warning could be added if a Hierarchy folder is disabled and should not be in order to try and avoid a complete crash.

Spoiler: Crash details from Editor.log

Code (CSharp):

1. Mono: successfully reloaded assembly
2. - Completed reload, in 20.263 seconds
3. Platform modules already initialized, skipping
4. Assertion failed on expression: 'm_InstanceID != InstanceID_None'
5. UnityEngine.Transform:SetParent(Transform, Boolean)
6. Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren(Transform, StrippingType) (at Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolderUtility.cs:91)
7. Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren(Transform, StrippingType) (at Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolderUtility.cs:146)
8. Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren(Transform, StrippingType) (at Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolderUtility.cs:97)
9. Sisus.HierarchyFolders.PlayModeStripper:HandleOnSceneObjectAwake(GameObject) (at Assets\Standard Assets\Sisus\Hierarchy Folders\Code\PlayModeStripper.cs:115)
10. Sisus.HierarchyFolders.PlayModeStripper:OnSceneObjectAwake(GameObject) (at Assets\Standard Assets\Sisus\Hierarchy Folders\Code\PlayModeStripper.cs:74)
11. Sisus.HierarchyFolders.HierarchyFolder:Awake() (at Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolder.cs:89)
12.  
13. [C:\buildslave\unity\build\Runtime\BaseClasses\BaseObject.h line 377]
14. (Filename: Assets/Standard Assets/Sisus/Hierarchy Folders/Code/HierarchyFolderUtility.cs Line: 91)
15.  
16. Crash!!!
17. SymInit: Symbol-SearchPath: 'C:/Program Files/Unity/Hub/Editor/2020.1.3f1/Editor/Data/Mono;.;E:\_unity\_projects\Busy_Richard_URP;C:\Program Files\Unity\Hub\Editor\2020.1.3f1\Editor;C:\WINDOWS;C:\WINDOWS\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 534, UserName: 'mosthated'
18. OS-Version: 10.0.0
19. C:\Program Files\Unity\Hub\Editor\2020.1.3f1\Editor\Unity.exe:Unity.exe (00007FF7B2FF0000), size: 144797696 (result: 0), SymType: '-deferred-', PDB: '', fileVersion: 2020.1.3.23623
20. C:\WINDOWS\SYSTEM32\ntdll.dll:ntdll.dll (00007FF8B6630000), size: 2048000 (result: 0), SymType: '-deferred-', PDB: '', fileVersion: 10.0.19041.207
21. C:\WINDOWS\System32\KERNEL32.DLL:KERNEL32.DLL (00007FF8B5620000), size: 774144 (result: 0), SymType: '-deferred-', PDB: '', fileVersion: 10.0.19041.207
22. C:\WINDOWS\System32\KERNELBASE.dll:KERNELBASE.dll (00007FF8B4270000), size: 2912256 (result: 0), SymType: '-deferred-', PDB: '', fileVersion: 10.0.19041.207
23. C:\WINDOWS\System32\CRYPT32.dll:CRYPT32.dll (00007FF8B3D80000), size: 1429504 (result: 0), SymType: '-deferred-', PDB: '', fileVersion: 10.0.19041.21
24. ... etc etc
25.  
26. ========== OUTPUTTING STACK TRACE ==================
27.  
28. 0x00007FF7B3BCD984 (Unity) GameObject::SendMessageAny
29. 0x00007FF7B451E0C5 (Unity) Transform::BroadcastMessageAny
30. 0x00007FF7B45305A8 (Unity) Transform::SetParent
31. 0x00007FF7B4B6F828 (Unity) Transform_CUSTOM_SetParent
32. 0x000002A49679008C (Mono JIT Code) (wrapper managed-to-native) UnityEngine.Transform:SetParent (UnityEngine.Transform,UnityEngine.Transform,bool)
33. 0x000002A49678F90B (Mono JIT Code) [E:\_unity\_projects\Busy_Richard_URP\Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolderUtility.cs:91] Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren (UnityEngine.Transform,Sisus.HierarchyFolders.StrippingType)
34. 0x000002A49678FC5B (Mono JIT Code) [E:\_unity\_projects\Busy_Richard_URP\Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolderUtility.cs:144] Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren (UnityEngine.Transform,Sisus.HierarchyFolders.StrippingType)
35. 0x000002A49678F96B (Mono JIT Code) [E:\_unity\_projects\Busy_Richard_URP\Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolderUtility.cs:95] Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren (UnityEngine.Transform,Sisus.HierarchyFolders.StrippingType)
36. 0x000002A49678E5DB (Mono JIT Code) [E:\_unity\_projects\Busy_Richard_URP\Assets\Standard Assets\Sisus\Hierarchy Folders\Code\PlayModeStripper.cs:116] Sisus.HierarchyFolders.PlayModeStripper:HandleOnSceneObjectAwake (UnityEngine.GameObject)
37. 0x000002A49678D563 (Mono JIT Code) [E:\_unity\_projects\Busy_Richard_URP\Assets\Standard Assets\Sisus\Hierarchy Folders\Code\PlayModeStripper.cs:75] Sisus.HierarchyFolders.PlayModeStripper:OnSceneObjectAwake (UnityEngine.GameObject)
38. 0x000002A49678D4EB (Mono JIT Code) [E:\_unity\_projects\Busy_Richard_URP\Assets\Standard Assets\Sisus\Hierarchy Folders\Code\HierarchyFolder.cs:90] Sisus.HierarchyFolders.HierarchyFolder:Awake ()
39. 0x000002A7F1EFB050 (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
40. 0x00007FF82F60D8A0 (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\mini\mini-runtime.c:2809] mono_jit_runtime_invoke
41. 0x00007FF82F592912 (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\object.c:2921] do_runtime_invoke
42. 0x00007FF82F59B96F (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\object.c:2968] mono_runtime_invoke
43. 0x00007FF7B491A8F4 (Unity) scripting_method_invoke
44. 0x00007FF7B491442B (Unity) ScriptingInvocation::Invoke
45. 0x00007FF7B49146EE (Unity) ScriptingInvocation::InvokeChecked
46. 0x00007FF7B4983C13 (Unity) SerializableManagedRef::CallMethod
47. 0x00007FF7B48DD50D (Unity) MonoBehaviour::CallAwake
48. 0x00007FF7B48DC0DE (Unity) MonoBehaviour::AddToManager
49. 0x00007FF7B48DC806 (Unity) MonoBehaviour::AwakeFromLoad
50. 0x00007FF7B4A0E757 (Unity) AwakeFromLoadQueue::InvokePersistentManagerAwake
51. 0x00007FF7B4A0F2AE (Unity) AwakeFromLoadQueue::PersistentManagerAwakeFromLoad
52. 0x00007FF7B4A0F33A (Unity) AwakeFromLoadQueue::PersistentManagerAwakeFromLoad
53. 0x00007FF7B42D30EC (Unity) LoadSceneOperation::CompleteAwakeSequence
54. 0x00007FF7B42D33B3 (Unity) LoadSceneOperation::CompletePreloadManagerLoadSceneEditor
55. 0x00007FF7B42D42B9 (Unity) LoadSceneOperation::IntegrateMainThread
56. 0x00007FF7B42D7C9C (Unity) PreloadManager::UpdatePreloadingSingleStep
57. 0x00007FF7B42D858F (Unity) PreloadManager::WaitForAllAsyncOperationsToComplete
58. 0x00007FF7B5A57455 (Unity) EditorSceneManager::RestoreSceneBackups
59. 0x00007FF7B54FEC75 (Unity) PlayerLoopController::EnterPlayMode
60. 0x00007FF7B5511799 (Unity) PlayerLoopController::SetIsPlaying
61. 0x00007FF7B5514CDE (Unity) Application::TickTimer
62. 0x00007FF7B5D0FF23 (Unity) MainMessageLoop
63. 0x00007FF7B5D1928E (Unity) WinMain
64. 0x00007FF7B7984FA6 (Unity) __scrt_common_main_seh
65. 0x00007FF8B5636FD4 (KERNEL32) BaseThreadInitThunk
66. 0x00007FF8B667CEC1 (ntdll) RtlUserThreadStart
67.  
68. ========== END OF STACKTRACE ===========
69.  
70. A crash has been intercepted by the crash handler. For call stack and other details, see the latest crash report generated in:
71. * C:/Users/MOSTHA~1/AppData/Local/Temp/Unity/Editor/Crashes
72.  

 

Hey @MostHated , thanks for the feedback!

Setting hierarchy folders inactive is currently not restricted, but it has no practical effect in builds. Hierarchy folders are still stripped even if they are inactive, and when this occurs all children - except for ones that have been individually set inactive - will become active.

In play mode the on-the-fly stripping of inactive hierarchy folders currently does have one subtle side effect: Awake is called for any active GameObjects nested inside inactive hierarchy folders immediately after SetParent, which happens in the middle of the stripping process before the hierarchy folders have been fully removed. I'm guessing that this side effect somehow resulted in a crash in your case due to something that is happening in the Awake/OnEnable/Start methods of your components.

I think I will be able get rid of this side effect by manually keeping children of inactive hierarchy folders inactive until stripping has been completed and it is safe to trigger those Awake methods. I'll start working on a patch that does just this.


I could also just completely remove the ability to set hierarchy folders inactive to avoid any confusion about what it actually does. The main reason I haven't done it so far is that this can be useful for quickly visually hiding things in the scene in Unity versions older than 2019.1 where scene visibility controls didn't exist yet.

Hmmm... perhaps the best solution here would actually be to override the behaviour of the active button for hierarchy folders, making it actually set the active state of all *child* GameObjects instead of affecting the hierarchy folder directly. This way the actual effects of using that control should become very apparent, and the control would become more useful than it currently is.

 

Thanks for the detailed reply. This definitely makes sense and it also doesn't help that my project makes fairly extensive use of DOTS (ECS/Jobs/Burst as well as URP, HybridRenderer, etc) and it often feels as though if I were to sneeze while trying to enter playmode that the editor might explode already. Anything else going on is just removing another block from the Jenga tower that is my project, lol.

Luckily, though, I have not noticed any other issues or conflicts with what Hierarchy Folders does during its stripping process otherwise, and any of the solutions you have proposed sound like they should help with the unexpected "oops... I guess I wasn't supposed to do that" moment that I had, lol.

Thanks,
-MH

 

Version 1.1.1 is now out.

It improves the handling of inactive hierarchy folders in play mode
and introduces the option to prevent inactive hierarchy folders altogether, redirecting the active control to affect their children instead.

I hope this update takes care of your crashing problem @MostHated , let me know if it doesn't and I'll give it another look.

 

@SisusCo Sounds good, I will be sure to give it a go and report back if I run into anything. Much appreciated.

 

Selecting a folder allows you to transform all children together, which is nice, but it doesn't seem to be registering an undo for the transformation, is that intentional? Because it's quite annoying.

Using Unity 2020.2.0a21 btw.