A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Separate names with a comma.
Discussion in 'World Building' started by wyattt_, Nov 11, 2020.
Try another name, anything thats listed in AssemblyInfo should work.
There is only that 1 name in AssemblyInfo.cs:
Ah sorry, i guess thats not possible then. Your only bet is reflection
I guess I'll just continue to copy/paste code over into my own editor scripts for now..
Would you mind taking a look at https://issuetracker.unity3d.com/is...-when-creating-terrain-using-import-heightmap again?
How does one close a reproducible ticket as not reproducible? This must be a mistake.
Didn't got my questions answered
And can we get performance improvements aswell... the demo wasn't performing that great
It was the only page that appeared in google when i pasted error msg.
I created new project (3D core) and it was 1st package I imported --> Two errors.
Version: Unity 2020.3.28f1 <DX11>
Can you please assist?
Hi TerrainTools Team
For the erosion tools can we get a simulate toggle button to erode the terrain locally or globally, so we don't have to manually paint them when trying to erode the entire terrain?
I'm sorry for making you wait for this extremely late response. "Weeks" ended up being months.
There is CPU culling that is done for each detail patch on the Terrain. You can control this somewhat by specifying detail resolution and detail resolution for each patch in the Terrain's settings.
Compute is used because of limitations from the instancing buffer that is used. When compute is not available, it will work, but more work is done on the CPU.
The performance gains you do get are from the patch culling and GPU instancing of the detail meshes.
@wyattt_ can u share the plans of what we should expect from the terrain tools this year?? Are all the pain points and important tools like performance, placement tools, workflow improvements which many people complained and requested over years, considered??? And should we expect them to land this year???And why don't we have a dedicated 4.0 thread for the terrain tools??? to be honest the development of terrain tools seems very slow to me, is it because u guys are waiting for DOTS 1.0 to create a complete new and powerful systems???
To be honest, I am frusrated a lot because I was expecting to see somethings on GDC. I see now we should wait more to see a real open world environments...
Saw the GDC roadmap video, here is the world building roadmap https://youtube.com/clip/Ugkx9vj7_dtJ-D9kl_XRBAFzZORJokHdCa8c
Hi @EagleG and all,
If you have any more questions on the World Building roadmap from GDC, please let us know. The presentation was only a high level overview but, for example, scattering improvements focus on multi-prototype scattering using a single brush with controls to manage distribution for each of the details.
To help answer the question on why development for Terrain Tools seems slow, Terrain Tools v.0 is the first official release to be included in the Editor (as of 2021.2) an optional package; with that came additional quality control and standards that need to be met for us to finally remove the 'preview' (aka Experimental) package tag.
So does this mean that we will be getting multiple prefab painting and something like brush mask filters/rule based spawning for placement??? sounds great then, i expect the same for mass place function!!! is there anything planned for slope alignment... its a very important feature, without this we cannot paint grass clusters and wider grass species, rocks, trees directly over the slopes of terrain, otherwise it looks terrible to see the painted object floating mid air or intersecting inside the slope( in nature grass, trees, and rocks do align to the slope)
It felt slow mainly because the patch notes showed that the last few updates didn't received any major content... and also the GPU tree renderer, terrain shadergraph, terrain SRP rendering improvements on productboard didn't show much progress for more than a year.....
BTW can i know the progress of the both i mentioned above, does the tree renderer help in improving performance on all platforms like consoles and PC??? Anything about DOTS terrain or Concurrent binary trees terrain (which u guys showcased last year at SIGGRAPH)??
Finally some answers on this forum Better than nothing...
I forgot to mention about the non destructive terrain workflow which was showcased at 2020 GDC, but it has been 2 years and we haven't heard about it anything, i know u guys paused the development of it with the spline system to add overlays and cleanup the terrain source code, but now that the splines are coming should we expect this to return???
So I guess my question here is... if this is the case, why does the current package currently suffer from some many errors when performing basic operations? Right now there's multiple threads about how the package is just constantly throwing errors on install, errors when attempting to use brushes, errors that keep the editor UI panel from rendering...
Why does the quality control let that through but not fixes?
@DanielTG what happened??? Nothing from your end??? Can u atleast reflect the roadmap on the product board with some details.... For now it seems like nothing is happening with terrain tools
You may want to take a look at this thread:
In short: The code and functionality is excellent from what I can see. The UI however makes the Terrain Tools an upleasant experience that one likes to avoid and rather switches to 3rd party. With experimental it was tolerable, but now that this is release, it needs an extreme overhaul.
Terrain tools in 2021.3.1 have some consistent issues and errors.
Whenever I change my terrain mode, let's say to "paint texture" from something else, this happens(only after installing terrain tools):
and console errors:
- This isn't a show stopper, the errors don't block me from running the game but it's a bit frustrating.
I can fix the terrain inspector UI by switching to a different game object and then back to the terrain object.
You're aware of these simple include errors since more than about a year (and half now) and these are always not fixed today... What's wrong ? It's possible to have a fix quickly ?
I was wondering if there is some guide or more documentation on how to make this specific custom terrain tool. I've read through the documentation, and what i'd like to do is paint to another custom texture, instead of one of the builtin ones.
The existing API is very context-sensitive, e.g. you BeginPaintHeightmap, but you cant BeginPaintCustomTextureWithDimensions.
I cant really copy over the builtin tools because CommonUI is private, despite a whole bunch of utilities accepting it (for example Utility.GenerateAndSetFilterRT). The examples in the documentation also dont work, the namespaces and classes are outdated.
Hi. With which version of the package are you still seeing the visualization shader errors?
Could you tell me the use for the custom texture you're wanting to modify? I might be able to help a little better with that info.
I only looked quickly, but it does seem like the only part you'll need to implement is a class that inherits from BaseBrushUIGroup. The Utility class (at least based on the API you linked) should also be publicly accessible but I will check in a new project.
Try the following code (4.0.3 terrain tools):
public class BrushUI : BaseBrushUIGroup
public BrushUI(string name, Func<TerrainToolsAnalytics.IBrushParameter> analyticsCall = null) : base(name, analyticsCall)
public class PaintTool : TerrainPaintTool<PaintTool>
private Material m_Material = new Material(Shader.Find("My/Paint/Material")); // change this to your Material name
private BrushUI m_BrushUI = new BrushUI("Paint Tool");
public override string GetName() => "Paint Tool";
public override string GetDescription() => "Description";
public override bool OnPaint(Terrain terrain, IOnPaint editContext)
// I'm only setting things up so I can call the Utility.GenerateAndSetFilterRT using the BrushUI : BaseBrushUIGroup implementation.
// You could probably copy directly from the "DefaultBrushUIGroup" class that is in TerrainTools.
// Should get you the same functionality as the rest of our tools
var bounds = TerrainPaintUtility.CalculateBrushTransform(terrain, editContext.uv, m_BrushUI.brushSize, m_BrushUI.brushRotation);
var paintContext = TerrainPaintUtility.BeginPaintHeightmap(terrain, bounds.GetBrushXYBounds(), 0);
Utility.GenerateAndSetFilterRT(m_BrushUI, paintContext.sourceRenderTexture, paintContext.destinationRenderTexture, m_Material);
// do your paint stuff here
This is in a script I have in my Project's Assets/Editor folder
Hi! Thanks for taking the time to post details about these errors. We've got a bug filed for this one and it is being tracked here.
Sorry, but i want to ask again...
What is the progress of improvements to the placement tools and those stuck on the roadmap under "in progress" and "planned" for more than a year?? This product board page https://unity.com/roadmap/unity-platform/3d-world-building isn't helping at all!! It hasn't even reflected the 2022 roadmap and hasn't been updated for a long time!! There is literally no information of what's happening with terrain tools and what is it's progress!!
There's not really anything new that's official. All I've seen is that now there'll finally an api to place terrain details. I doubt you'll get anything of those on the roadmap in 2022 and rather have to wait for 2023. But that's just guesswork, just like the roadmap on which you can't rely on. I've waited long for the splines. Too long. Now it's there and I can't use it because I need to stay backwards compatible and there's no backport of the splines.
I really hate how the shader graph support for terrain, which is the most important and anticipated feature is just stuck under "in progress" for almost 1.5 years.... Don't know why but the world building tools are always ignored and don't recieve much love, and whatever they receive, is at very slow rate and get abandoned like polybrush and probuilder... This has been the same from the start of unity so nothing because of layoffs or acquisition.. unity never focused on wold building, right from beginning and depended upon third party like Gaia!! Non-destructive workflow is really a important thing for today's terrain system and unity was working on it in 2020 and showed it in their GDC, but it was stopped because they first wanted to bring overlays which is good, but it's 2+ years now and we haven't heard anything about both of them and aren't present in any roadmaps...
Finally seeing some improvements to the placement tools, thanks a lot!! I still don't understand why such changes aren't reflected anywhere so that wide range of people can know what's happening!! HDRP team properly maintains and updates their roadmap with time, and gives insights on upcoming features and plans on forums too....don't know why it isn't happening with world building tools!!
It's all beta. But at least there's progress. eg they've only just started making their detail api public:
Terrain: Changed: All built-in Terrain Tools can now be overridden and Detail API is publicized.
What you see in the twitter post of yours is in the terrain tools 5.0.0-pre3.
I would like to request official support for pen pressure in painting operations in the terrain.
That would be very awesome. Let's tag @wyattt_ for feedback
https://portal.productboard.com/dzc...als?utm_medium=social&utm_source=portal_share any news on this??? My team is currently using mesh because terrain doesn't support shader graph, but workflow is very bad and tedious as we need to switch back and forth to make changes, between mesh and terrain... We did try using shadergraph on terrain with hacks, but it lead to increase in batch count as draw instanced had to be disabled to use it, which was unacceptable for our project... Is there any other easy and better way to do this without increasing batch count, and how long would it take for official solution?? BTW we are using HDRP for now....
Hey!! I was playing around with UE5's grass painting system and found that it performs much better than unity's !! It can handle very high poly grass meshes (each of around 15k tris) easily at a very long distances of more than 5000 units!! It all happens because these detail (foliage) meshes support a simple tool called LOD system and nothing fancy like nanite was used, just 2-3 simple LODs and a billboard makes all this possible!! On the other hand unity paint details doesn't support LOD and things start lagging when distance is set beyond 1000m with grass meshes having just approximately 1000tris!! I feel that LOD support for grass meshes is mandatory because GPU instancing alone does not give the performance and optimizations required for efficient rendering of grass!! I can use the paint trees option, but it doesn't align to slope and i won't get additional performance because of the lack of GPU instancing!! I really hope that the worldbuilding team is reading this and considers it important.......
Damn, this means the new vegetation system is still isn't usable in production.
Companies often just buy the vegetation engine and nature renderer. I suppose that's all you can do for now.
A simple Prefab painter can work too!! My UE5 grass test wasn't using anything fancy to perform great, just some LOD's and a billboard with staticinstanced ticked which must be equivalent to unity 's SRP batcher/Material GPU instancing/Static batching... Nature renderer might provide additional performance boost because of GPU instancing
You could try doing the same with PolyBrush, which is a tool that has prefab painting.
And using something like GPUInstancer, would probably yield some very good results (GPUInstancer actually has a built in LOD system, due to how important LOD is for performance)
Height visualization doesn't work in 2022.2 (incompatible shader).
2022.2 and using which version of terrain tools package? Could you create a bug report with the details? Thanks!
MissingReferenceException: The object of type 'UnityEngine.Material' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
UnityEngine.Object+MarshalledUnityObject.TryThrowEditorNullExceptionObject (UnityEngine.Object unityObj, System.String parameterName) (at <3c0b8c6f50144d64ae13321152b1e5fb>:0)
UnityEngine.Bindings.ThrowHelper.ThrowNullReferenceException (System.Object obj) (at <3c0b8c6f50144d64ae13321152b1e5fb>:0)
UnityEngine.Material.DisableKeyword (System.String keyword) (at <3c0b8c6f50144d64ae13321152b1e5fb>:0)
UnityEditor.TerrainTools.TerrainToolboxUtilities.RevertPreviewMaterial () (at ./Library/PackageCachefirstname.lastname@example.org/Editor/TerrainToolbox/TerrainToolboxUtilities.cs:2061)
UnityEditor.TerrainTools.TerrainToolboxUtilities.SaveSettings () (at ./Library/PackageCacheemail@example.com/Editor/TerrainToolbox/TerrainToolboxUtilities.cs:2224)
UnityEditor.TerrainTools.TerrainToolboxWindow.OnDisable () (at ./Library/PackageCachefirstname.lastname@example.org/Editor/TerrainToolbox/TerrainToolboxWindow.cs:82)
This is a UI bug in terrain tools where if the window is docked when you exit play mode, it removes the default terrain material reference (or one set) on the create menu.
it's behind a drop-down menu.
Nothing that actually affects you working.
I get the following message just for installing 5.0.4 package
None of the erosion types work, they just smooth the terrain which is the only feature someone would ever need this one.