Hierarchy Folders

@Bezoro That is not intentional, I'll start working on a patch to add undo support for it. Thanks for the feedback!

 

Hello, I just bought your asset and thought I was doing something wrong, however, it turns out it does not flatten out the hierarchy if you use the "Enter Play Mode Options (Experimental)" in the Build Settings. I have the "Reload Scene" checked, but not "Reload Domain". I also have "Play Mode Stripping Method" in Hierarchy Folders options set to "Entire Scene When Loaded", but it doesn't flatten the hierarchy on Play. It only seems to work if I set "Reload Domain" checked, but that slows testing down immensely. I still need to test periodically with the "Reload Domain" option checked, and Hierarchy Folders seems to work fine in this situation, but it would have been nice if it worked all the time. I wonder why Scene Reloading is not triggering the flatten operation? I thought I would just bring this to your attention. Unity 2020.1.4f1, Windows 10. Thanks.

 

Hey @FireMutant , thanks for bringing this to my attention!

I had to do some code rewriting, but have now managed to get everything working with all the different experimental enter play mode options.

The source of the issue was that I was relying on some state automatically resetting when switching between play and edit modes, but this wasn't taking place with domain reloading disabled, so I had to handle it manually instead.

I'll submit a new version with this fix to the asset store for approval.

 

Thanks SisusCo! Yes, I understand the difficulties caused by using the Enter Play Mode Options. It can cause major havoc with scriptable objects also. Lots of things don't get reloaded or reinitialized without reloading the domain, but dang, once you start developing without reloading the domain each time, it is hard to go back. The efficiency gain is hard to ignore.

Thanks for responding so quickly. I look forward to updating to the newest version when it is approved in the asset store.

 

+1 for Prefab support. I'm happy to not have the stripping happen if the folder exists inside a prefab - I'm using empty gameobjects anyway to help organize my prefabs internals so no performance hit. Could it be an opt-in option?

 

Version 1.2.0 of Hierarchy Folders is out now and introduces support for Hierarchy Folders inside prefabs!



The feature is off by default but you can enable it in Edit > Preferences > Hierarchy Folders by changing
the Folders In Prefabs setting to something other than Not Allowed.

Three new modes for dealing with hierarchy folders inside prefabs are now available:

1. Stripped at Runtime:
Hierarchy Folders inside prefabs will be stripped when the prefab is instantiated. This takes place before any other code on the prefabs executes (including Awake, OnEnable and Start methods on all components).

This mode can introduce a slight overhead when prefabs containing hierarchy folders are instantiated because all children of every hierarchy folder need to be reparented. If you instantiate such prefabs very often then you might want to consider alternative stripping modes or utilizing Object Pooling to avoid performing the stripping more times than necessary.

2. Stripped at Build Time:
Whenever you create a build all prefabs in your project will be searched for hierarchy folders. If a prefab containing hierarchy folders is found, a backup is created and then all hierarchy folders are stripped from it. Once the build has finished all stripped prefabs are restored to their original states.

This mode can make the build process take longer in larger projects, because all prefabs in the project need to be scanned for hierarchy folders and processed as necessary.

Additionally hierarchy folders at the root of a prefab can not be stripped at build time, because the root of a prefab can only hold a single object, so runtime stripping will still be utilized in this situation even when this mode is selected.

3. Not Stripped:
With this setting selected Hierarchy Folders are not stripped from prefabs at any point. As such, using hierarchy folders inside prefabs will offer no performance benefits over using empty GameObjects when grouping objects.

 

Great idea for an asset!
I have a lot of transforms that should behave like folders.

Here's a small bug report:


The folder icons don't fit very well if UI scale in Preferences is set to anything other than 100%.

(however, after a while, sometimes the underlay box icon disappears)

Does Hierarchy Folders avoid being converted to Entities, both by DOTS-Editor or (more likely to happen, because it is forced) by Subscenes? It doesn't quite seem like it right now, but it's not affecting me negatively because I had transforms there anyway. (but would love, love, LOVE to get rid of them)

 

Hey @Thygrrr and thanks for the feedback!

It looks like the system for injecting the new prefab icons to the preferences which I added in the 1.2.0 update worked unreliably. The asset database wasn't necessarily ready when the icons were initially being loaded, which could cause all the icons in the hierarchy view to be missing (except for the fallback icon with clipping issues). This issue should now be fixed in version 1.2.1.

There is no special logic in Hierarchy Folders related to entities / DOTS at this time.

I suspect that build stripping should still work with Subscenes, since the EntityScenes are generated based off of the scene data, and all traces of hierarchy folders are removed from all scenes during the build process. I'll need to do some testing to ensure that this is indeed the case.

Hierarchy Folders can't contain any additional components, so adding the ConvertToEntity component to them should be impossible at least (they turn into normal GameObjects the moment that extraneous components are added). I'm not sure how the DOTS editor works, but if it functions by adding this component, then that situation should also be handled. I'll do some investigating into this too.

 

It would actually be really great if they could ([ExecuteInEditMode] components only).
Really really great. A lot of my tooling is based on parent gameobjects having EditMode Components on them to do something complex or repetitive in edit mode.

I think I would need to add that functionality to

Code (CSharp):

1. OnlyComponentAttribute.DestroyComponentIfNotAttributeHolderOrTransform

correct?

I suspect they would be converted because everything in a subscene is forced to convert.



But apparently... (subscene in gameobject mode)


and ...

The entities converted in the Folders are part of the hierarchy (probably not unlike the Folders as gameobjects)

(this entity has a child buffer on it, and the child entity has a parent component on it)

I am pretty sure this happens in a build, too. Subscenes, even though backed by Unity scenes, are not part of the scenes in a build, so I don't know what Preprocessing steps can actually run on them.

No, everything in a subscene is forced to convert as if it had the behaviour. You can't deactivate this. It will get fed to a GameObjectConversionSystem.



It might require a Conversion System running in BeforeGameObjectConversionGroup to work around this. What can I call on a HierarchyFolder for it to "do its magic"? And... I fear it needs to be reversible. (I'll volunteer to sort out such a system and can share the code, it's likely just ~10 lines of actual code or so)

 

Hey @Thygrrr , sorry for not getting back to you earlier! I've had quite a busy week.

I've been thinking about this for some time too, that it might be a good idea to allow some components to be added on Hierarchy Folders for their editor-time functionality.

I've thought about adding an interface like IHierarchyFolderComponent which components could implement to let the system know they should be allowed on hierarchy folders. The downside with this approach is that it would not be a good solution for components from other third party assets, where you might not be able to make modifications to the components. Also it would introduce a dependency between the components and hierarchy folders which is not optimal.

Having a whitelist in the preferences where users can add any component types they want to be allowed on hierarchy folders is another approach which I think would work better, as it would avoid the aforementioned issues.

OnlyComponentAttribute yes, and also HierarchyFolderUtility.HasSupernumeraryComponents. I believe those are the only things that would need to be modified, but I'm not 100% sure without doing some testing.

Ah yes, that's a good point! Build post processing probably doesn't affect those scenes since they're not included in the build settings as such.

HierarchyFolderUtility.ApplyStrippingType can be used to strip an entire scene of hierarchy folders and
HierarchyFolderUtility.CheckForAndRemoveHierarchyFoldersInChildren can be used to strip all hierarchy folders recursively in children of a root transform. Neither one of them are reversible processes though I'm afraid, so these would only be usable if acting on a copy of the source scene (or creating a backup first which is restored after the process is done).

It should also be possible to create a fully reversible process which stores the child hierarchies of all hierarchy folders and then flattens them - but doesn't destroy them. I actually did some testing with a system like this when I was working on prefab support, but it ended up not being a viable solution for prefabs assets, so that code is not currently included with the asset. The HierarchyFolderUtility methods can be called with StrippingType.FlattenHierarchy though, so they could maybe be used for the flattening portion of such a system.

Thank you for offering to help with this! I can also try looking into this on my end, but I'm afraid I don't have much experience with the ECS right now, so it might take me a while to figure everything out - so your help is much appreciated

 

Why do I get these errors all of sudden? it was fine before.
I try to create a new empty scene and play it and the errors still appear!
Weird

here are the errors:

Code (CSharp):

1. Assertion failed on expression: 'gRefreshReentrancyCount > 0'
2. UnityEngine.StackTraceUtility:ExtractStackTrace ()
3. Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:RestoreBackups (bool) (at Assets/Plugins/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:282)
4. Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:.cctor () (at Assets/Plugins/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:53)
5. UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes (System.Type[])
6.  

and

Code (CSharp):

1. StopAssetEditing invoked without a call to StartAssetEditing. Please make sure that for every call to StopAssetEditing there is at least one call to StartAssetEditing
2. UnityEngine.StackTraceUtility:ExtractStackTrace ()
3. Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:RestoreBackups (bool) (at Assets/Plugins/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:282)
4. Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:.cctor () (at Assets/Plugins/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:53)
5. UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes (System.Type[])
6.  

 

Hi @ch1ky3n

It seems there was an issues with the new prefab build stripping system. After a build has been made with prefab stripping enabled it would try to perform asset database editing during initialization even if there were no more stripped prefab backups that needed to be restored. This would result in errors in newer Unity versions than what I had used in my testing.

I've created a fix and will publish an update with it soon; I'll also PM you the updated package so you don't need to wait for asset store validation.

Thank you for letting me know about the issue!

 

Done and Gone in less than 24 hours , You are awesome!

 

Stripping Folders in Prefabs that are embedded in other prefabs at Build Time does not work (at least in 2020.3.5f1).

Setting the parent of a transform which resides in a Prefab Asset is disabled to prevent data corruption

UnityEngine.StackTraceUtility:ExtractStackTrace ()

Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren (UnityEngine.Transform,Sisus.HierarchyFolders.StrippingType,bool,System.Collections.Generic.List`1<UnityEngine.GameObject>) (at Assets/Sisus/Hierarchy Folders/Code/HierarchyFolderUtility.cs:147)

Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren (UnityEngine.Transform,Sisus.HierarchyFolders.StrippingType,bool,System.Collections.Generic.List`1<UnityEngine.GameObject>) (at Assets/Sisus/Hierarchy Folders/Code/HierarchyFolderUtility.cs:154)

Sisus.HierarchyFolders.HierarchyFolderUtility:CheckForAndRemoveHierarchyFoldersInChildren (UnityEngine.Transform,Sisus.HierarchyFolders.StrippingType,bool) (at Assets/Sisus/Hierarchy Folders/Code/HierarchyFolderUtility.cs:86)

Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:StripPrefab (UnityEngine.GameObject,Sisus.HierarchyFolders.StrippingType) (at Assets/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:218)

Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:StripHierarchyFoldersFromAllPrefabs (Sisus.HierarchyFolders.StrippingType) (at Assets/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:171)

Sisus.HierarchyFolders.HierarchyFolderBuildPrefabRemover:OnPostProcessScene () (at Assets/Sisus/Hierarchy Folders/Code/Editor/HierarchyFolderBuildPrefabRemover.cs:111)

UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)

This error also destroys you prefabs in the process, so better have a commit you can go back to when trying.

 

@Tirus Oh you're right, I totally failed to consider nested prefabs for the build-time prefab stripping Thank you for bringing this to my attention and sorry for the trouble! I pushed a hotfix to make the build stripping system for now just skip over any nested prefabs. Optimally it should instead unpack them first and then flatten them, but I'll look into implementing this for the next patch.

All stripped prefabs usually get restored to their original states during the OnPostprocessBuild event if the build finishes normally. If the build process fails for some reason after it has already processed the first scene, they currently only get restored during the next assembly reload event - which isn't very good if it doesn't happen immediately after a build has failed. I'll give the backup restoring system another look and see if I could make it restore the backups more reliably immediately after build failure.

 

I pushed a second update, and with it the systems should now be able to always restore stripped prefabs right after building finishes even in the event that it should fail at any point of the process.

Build-time stripping of prefabs can now also handle nested prefabs properly by unpacking everything recursively before flattening the hierarchy and removing the hierarchy folders (this is necessary since these operations are not allowed for objects inside prefab instances).

 

I see that you identify whether objects are Hierarchy folders by TryGetComponent on every object that's a candidate (and most objects aren't hierarchy folders).

This could mean a lot of failed calls in complex unfolded hierarchies; what alternatives would you suggest - comparing tags perhaps?

 

@Thygrrr just to make sure: in what context would you like to check whether something is a hierarchy folder or not? In most cases these checks would not be necessary at all in builds - but I'll assume this is probably related to subscenes which are the rare exception.

TryGetComponent is still very fast. On my machine checking 50 000 objects using TryGetComponent took 0.0052 seconds. Using CompareTag took 0.0045 seconds. If I generated a HashSet containing all hierarchy folder GameObjects and used HashSet.Contains I could get this down to 0.0011 seconds.

So tl;dr: I don't think trying to optimize this would be worth the effort

 

Importing Hierarchy Folders is showering the console with errors:

Spoiler

HF: 1.2.4
Unity: 2020.3.12f1

Edit.: Importing it in a blank project and copying it into my existing project seems to have worked.

 

@Bezoro Glad to hear you managed to get it fixed!

It looks to me like you used to have both Power Inspector and Hierarchy Folders installed in the same project, but then later on removed the prior from the project. This resulted in the Power Inspector specific HierarchyFolderDrawer becoming active in the project but no longer compiling once the Power Inspector assets it relies on were removed.

 

This is at edit time and editor run-time.

I care absolutely zero for code executed at (build) run-time, I expect anything pertaining to Hierarchy Folders to be completely gone in builds.

But for my own in-editor tooling, to build upon the hierarchy of Hierarchy Folders, it would be great if I could identify them quickly - is object X a hierarchy folder, is object Y inside a hierarchy folder, etc. Also, I want to have monobehaviours on a hierarchy folder, it would be EXTREMELY useful to have this (like, a generator object with its own custom editor and no (build) runtime functionality, or debug inspectors etc.)

Lastly, also for rendering my own custom icons.

5 milliseconds is definitely worth optimizing, especially in more complex transform hierarchies. I think a performance ceiling of 20k to 50k objects is generous.

 

Okay well, I can spend some time investigating if I could integrate a HashSet based optimization in the editor. Generating the HashSet is very easy to pull off, but there's a risk with switching to utilizing cached results that if the caching isn't guaranteed to always be performed before any polling could occur in any external code, the results would become unreliable.

I can investigate registering hierarchy folders to the hashset in their constructor, in which case I think it should become 100% reliable. However, I'm not sure if Components' GetHashCode() method will return a correct value at that point or not, so not sure if it's a viable approach.

Another option would be to still utilize TryGetComponent for most checking, but that a faster HashSet-based solution would live alongside it as a separate method that should only be used if you are sure all hierarchy folders have had time to get registered via their OnValidate method. This way at least checking performed inside hot paths such as OnGUI could be optimized to be as fast as possible.

Yeah, this is something I've been planning to tackle for a while but haven't gotten to it yet. I can see how this could be a really useful feature for some to have, so I'll try to find the time to start working on this soon

Thanks for the feedback!

 

With the latest version of Hierarchy Folders it is now possible to add components to Hierarchy Folders. This might be a useful ability to have when it comes to components that enhance the editor experience in some way without having any effects in builds.

For example:



Allowed components can be individually whitelisted in the preferences, and it is also possible to just allow components of all types without restrictions (in case you want to live dangerously and can't be bothered to whitelist everything).



For editor tooling power users a new editor-only method HierarchyFolderUtility.IsRegisteredHierarchyFolder(GameObject) was also added.

It provides basically the same functionality as the GameObject.IsHierarchyFolder() extension method but is a bit faster (about 1/4th the execution time). However one should be aware that it is not guaranteed to give accurate results for GameObjects in scenes that have not finished loading (e.g. potentially if using RuntimeInitializeOnLoadAttribute), since it relies on Hierarchy Folders registering themselves during the Awake and OnValidate event functions. But for most editor tooling use cases it should work perfectly fine.

( @Thygrrr Apologies for the long wait )

 

Well, YOU DELIVERED.
Awesome. Thanks!

 

Hi there,

first of all, thanks for this great tool.
Unfortunately we have a problem in Unity 2021.1.27f where Canvas related GameObjects inside a hierarchy folder have their scale set to 0.9999987, 0.9999987, 0.9999987. This is immediately undone when we move the objects out of the hierarchy folder (scale goes back to 1,1,1)

Please advise!

 

P.S. The anchored position X and Y changes as well.

 

Hey @Memphizzz

I have not seen this happen before. You wouldn't be able to share a scene file where this is happening by any chance?

Internally hierarchy folders placed under canvases have their state set to such that they shouldn't affect their child elements state.


It sounds like probably a floating-point precision related thing. The floats used to represent RectTransform state are only accurate up to 6 to 9 digits, and when you nest multiple transforms into a chain this small imprecision can add up to be large enough that the numbers you see in the inspector change a tiny bit from whole numbers. I haven't seen this effect in practice even when stacking dozens of hierarchy folders yet, but it could be that it mostly only happens in specific scenarios, like when transforms have a scale other than (1,1,1) or something.

 

I had this pretty weird bug where my entire scene's hierarchy folders were flatten while not in playmode. Prefabbed hierarchy folders were also rapidly attempting to flatten its hierarchy but I guess it can't and constantly gave errors

 

@Facechecker Yikes! That doesn't look right...

It's curious that the pause button looks to be active in the video, I wonder if that is in any way related to the issue. Perhaps EditorApplication.isPlaying should be used instead of EditorApplication.isPlayingOrWillChangePlaymode when deciding when should subscribe to / unsubscribe from play mode specific events...

Could you check whether or not you have Enter Play Mode Options enabled with Reload Domain disabled in Project Settings > Editor? It would make testing a bit easier if I knew which configuration I should be focusing on.

 

I haven none of the settings you mentioned enabled in the project settings:


The error fixed itself when I reload the Unity Editor. Still, it's a pretty bizarre bug that I think you should try to look into.

 

@Facechecker Thanks for the additional details! I'll definitely look into this. Even if I can't reproduce the issue, adding some EditorApplication.isPlaying checks further down the call stack should be enough to make it impossible for this to happen.

 

@Facechecker A new update which should prevent the edit mode flattening issue from rearing its ugly head again has been submitted to the asset store for review. It'll probably be live in a day or two. If you encounter that bug again before the update is live just let me know and I can send the updated version to you beforehand.

 

I haven't encounter the bug again at all. The asset is still not updated, though.

 

@Facechecker The update is still pending review. It will likely go live on Monday since Unity doesn't review updates during the weekends.

 

I see. Thanks for the quick updates.

Any chance you'll make a compatibility patch for Hierarchy Folders to work with Hierarchy 2? I really like Hierarchy 2's design and it also comes with its own hierarchy folders. Unfortunately, this causes it to clash with Your hierarchy folders, causing errors. Yours is no doubt the better and more performant since Hierarchy 2's folders are just regular game objects with a custom icon, but it'd be nice to use Hierarchy Folder and Hierarchy 2 simultaneously.

 

@Facechecker Sure thing! Here's a small compatibility patch for Hierarchy 2. It hides Hierarchy 2's main menu and add component menu items for creating its own hierarchy folders and gets rid of the conflicting name warning.

 

Thanks. You're awesome!

You should probably include that in the main asset store page just in case anyone else wants a compatibility patch.

 

Just a quick suggestion for your icon loading logic in HierarchyFolderPreferences: I tried including hierarchy folders into a project as a .dll and didn't pack the icons, which lead to the preferences trying to load the icons every frame. As it searches the entire asset database, it's pretty slow and allocates a lot of memory, making the editor basically unusable. So I think it'd make sense to check whether loading the icons failed and then send out a log, rather than trying it again every frame.

 

@one_one That is a good idea.

I think the retry-again-later-if-loading-failed logic was put in because the icon loading could fail at first if attempted while the asset database is still being updated. But I believe I should be able to add a check to see if

EditorApplication.isUpdating

is true or not and only retry again if it is and otherwise log a warning and give up.

Thanks for the feedback!

 

I encountered this warning while trying to build:

 

@MysleyMakers Thanks for letting me know! I'll submit an update to fix it today.

 

HI,

wondering why it doesn't have the option to "Do Nothing" for builds?. it broke our app without realising because a developer had used GameObject.Find but we had it set to prepend folder name which will obviously break the name for the find

Delete seems ok though, but would still be useful to be able to just keep as is.

Also can anyone confirm if the folder gets added at 0,0,0? I tried dragging a gameobject out of it but it broke the position in a way that Unity normally doesnt (since Unity makes a relative update to the coordinates)

other than that, useful thanks!

J

 

Hi @codemonkeynorth

It should be possible to disable stripping of hierarchy folders from builds in the Project Settings by unticking Remove From Scenes and setting Folders In Prefabs to Not Stripped.



If this doesn't work in the latest version I'll look into fixing it.

(That being said, even with build stripping disabled I would personally recommend avoiding using GameObject.Find for finding references, because it is so easy for these connections to get broken accidentally during development. Using GameObject.FindWithTag for example is safer - and faster.)

Hierarchy folder transforms should stick to default local position, rotation and scale reliably; at least I've never seen this behaviour break in my testing with the latest version. Here is a test with a bunch of nested GameObjects at different positions mixed with hierarchy folders:



What version of Unity are you using? I could test that everything is working as it should in that particular version as well.

 

I want to buy this asset but, try many folder hierarchy folder plugins, it always have an issue:
- Folder have child with DontDestroyOnLoad.
- When change scene, folder destroy, object with DontDestroyOnLoad is destroy too.

Does this plugin solve this issue?

 

@Jumeuan This works if you enable stripping of hierarchy folders in Play Mode. This stripping takes place during scene loading before Awake is called for any other components in your scene.





Alternatively you can turn off Play Mode stripping if you make your DontDestroyOnLoad call target the root GameObject. In this case the entire Hierarchy Folder that contains your persistent objects will persist through scene transitions in Play Mode.

Code (CSharp):

1. void Awake()
2. {
3.     DontDestroyOnLoad(transform.root.gameObject);
4. }

 

@SisusCo apologies for the confusion. turns out i'm using an entirely different asset with similar name/functionality to yours!

 

After I exit playmode, I get a console error. It happens whenever a folder is selected in the hierarchy.

 

@sean244 Thanks for letting me know, I'll look into ways of getting rid of the error. I'm afraid that it's a bug in Unity's internal inspector code, where they don't handle hidden components properly.

 

I now have a second bug, which is that some scenes immediately become dirty as soon as I open them. This is only resolved after I remove the asset.

 

@sean244 Thanks for letting me know! I'll try to get a fix in for this in the next version as well.