Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bug The Terrain Tools are locked beyond reason

Discussion in 'World Building' started by Rowlan, Jun 13, 2022.

  1. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    4,200
    I just wanted to create a new terrain tool based on the existing ones.

    error CS0117: 'TerrainToolsAnalytics' does not contain a definition for 'OnShortcutKeyRelease'
    error CS0122: 'DefaultBrushUIGroup' is inaccessible due to its protection level
    error CS0103: The name 'UpdateAnalyticParameters' does not exist in the current context
    error CS0122: 'BrushRenderPreviewUIGroupUnderCursor' is inaccessible due to its protection level
    error CS0122: 'TerrainFillUtility' is inaccessible due to its protection level
    error CS0122: 'TerrainToolGUIHelper' is inaccessible due to its protection level

    That's beyond reason. It seems like Unity doesn't want their users to extend from these tools. Locking your users out is definitely the wrong decision :(
     
  2. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    4,200
    Code (CSharp):
    1. using UnityEngine;
    2. using UnityEditor;
    3. using UnityEditor.TerrainTools;
    4.  
    5. internal class CustomTerrainToolWithBrushUI : TerrainPaintTool<CustomTerrainToolWithBrushUI>
    6. {
    7.     private float m_BrushRotation;
    Even the demo for creating a new tool is set to internal o_O

    https://docs.unity3d.com/Packages/com.unity.terrain-tools@4.0/manual/create-add-brush-controls.html

    By the way, the examples in the documentation aren't compilable.

    GetDesc()
    => GetDescription()

    (int)UnityEngine.TerrainTools.TerrainPaintUtility.BuiltinPaintMaterialPasses.RaiseLowerHeight
    => (int)TerrainBuiltinPaintMaterialPasses.RaiseLowerHeight

    TerrainPaintUtilityEditor.BrushPreview
    => TerrainBrushPreviewMode
     
    Last edited: Jun 13, 2022
    Thimape and awesomedata like this.
  3. wyattt_

    wyattt_

    Unity Technologies

    Joined:
    May 9, 2018
    Posts:
    424
    Heya. Which version of Terrain Tools are you using? 4.0? I can try to make another custom tool. (I thought I had done that recently with some success. Only hold up was that you needed your own thin BrushUIGroup implementation. Can't remember where we were talking about that though)
     
  4. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    4,200
    Yes, using 4 currently. An example would be great. I mean I can make my own, but if I eg look at the Set Height Tool there's several things in it that would be really very helpful, yet I can't use it because other code in it is locked for access.

    The idea is to simply use the Set Height tool and automatically / dynamically set the height to the minimum of the bounds of the gameobjects which are inside the brush. ie simple flatten tool rather than projection and blending. Normally I'd just use the Set Height Tool as it is and add my code to it. But when I copy the code of the existing Set Height tool and just rename the tool and other minor things, then all I get is compiler errors and I'd have to copy other code in other classes as well. And that goes deeper and deeper and in the end I'll just end up copying the entire terrain tools, change the namespace and make all methods public. And that I'd like to avoid, which makes rather ask for a proper API.

    Thank you very much in advance :)
     
    Last edited: Jun 23, 2022
    wyattt_ and awesomedata like this.
  5. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    This is the problem I had with Unity's tools since the beginning. Their API design decisions SUCK.

    Code that _could_ be useful (e.g. the Grid Class in RuleTiles) is always internal, and stuff that clearly _needs_ to be modular -- isn't. :/
     
    joshcamas likes this.
  6. wyattt_

    wyattt_

    Unity Technologies

    Joined:
    May 9, 2018
    Posts:
    424
    Thanks. I'll give it go and get back to ya
     
    Rowlan likes this.
  7. wyattt_

    wyattt_

    Unity Technologies

    Joined:
    May 9, 2018
    Posts:
    424
    Alright, ya... Kind of annoying. Things I had to duplicate for replicating the SetHeightTool functionality in my own tool in my Project using Terrain Tools 4.0.3:

    - DefaultBrushUIGroup & Brush variators (This was the big one, in my opinion. Lots of lost functionality without making these public)
    - The various BrushRender* classes. These are quite confusing. Primary benefit is how they interact with the IBrushCommonUI instance that you provide to them for handling shortcuts. Otherwise they are just a wrapper class around Editor code that isn't much more verbose. Still would be better to just have them be public
    - Some UI functions in TerrainToolsGUIHelper
    - I removed any calls into analytics. That's not necessary for custom tools
    - Copied TerrainFillUtility.GetTerrainsInGroup into the tool itself
     
  8. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    4,200
    Thanks. Yeah, that's what I did until up to a point where I thought it's futile and there'll always be something I need, so I copied the whole package, changed the namespaces and made methods public where necessary, changed shader paths, etc :)

    My point is though: Why is it locked so really, really hard? I understand it's easier for Unity to not have to consider any compatibility with assets of users and refactor as the devs please, ie maintenance is secured. However it's not extensible. And this way it won't grow with the community. At least not in a way that it actually could.
     
    wyattt_ likes this.
  9. wyattt_

    wyattt_

    Unity Technologies

    Joined:
    May 9, 2018
    Posts:
    424
    Part of it originally was because we wanted a public API that we were happy with but felt we weren't at that point yet. There are rules with public API, where once it is in a public release, it's difficult to get the approval to change the API once it is public because it could introduce breaking changes to users while also increasing the amount of code that needs to be maintained.
     
    Rowlan likes this.
  10. SorraTheOrc

    SorraTheOrc

    Joined:
    Jun 11, 2016
    Posts:
    207
    Meanwhile those docs are still broken in exactly the same way as reported here. I'm all for being cautious about public APIs but, well errr.... v5 is around the corner, that's allowing for breaking APIs anyway. Meanwhile those of us trying to work in an LTS version of Unity are held back.