I’ve tried searching but I can’t find an answer to this problem. Maybe I’m using the wrong words.
Anyway when I’m trying to edit my terrain, whether it be lowering/raising or painting, the brush is very laggy, stuttering, choppy, very annoying.
Is there anyway to fix this? The terrain I’m working on is only 500x500 so I would think it would run just great, since that is 1/4th the size of the default.
Any help would be much appreciated because this is very frustrating.
The terrain editor isn’t especially responsive at the best of times, but the most important factor is not the size of the terrain but the resolution. If you’ve kept the resolution the same but reduced the size to 500x500, then you’ve actually increased the density of it, which means there’s more triangles per “square unit” than at the default scale, so it’ll take more processing time to manipulate it.
That is unfortunate.
Can anyone recommend a height map editing tool that would let me edit the height map visually in 3d? I used L3DT to generate my terrain but it is rather large and Sapphire won’t run very well to edit it. I split it up on export hence the smaller size in Unity.
I’m not sure what I will do about painting textures since Unity is so slow working with the terrain.
Unity should be fine for editing terrain once you solve your resolution problems. Note that this is a problem, as you have a really high resolution terrain with the setup you’re describing, almost certainly not what you want. Start with a default terrain and see how that edits. If you only need a small terrain, then you need to reduce the resolution along with the scale, not just the scale.
You’ll probably want to reduce the strength of the brush (opacity) to get smoother results while editing the height or textures. I agree it’s not great, but it’s a lot better than some other game engines I’ve seen. It does still need some lovin’, though, that’s for sure.
You could also try Fractscape, which looks quite nice. You could also try out the Terrain Toolkit, which adds things like noise, erosion, and procedural texturing based on terrain height and slope to Unity’s default terrain editor. I think that Fracscape might be making use of this as well as it seems to share similar features.
edit: if you’re generating a huge terrain in L3DT or a similar tool, with each tile being just 500x500, you really do need to be careful with resolution otherwise you’re going to run into serious performance problems. There is no point splitting it into tiles unless you’re planning on implementing a streaming/paging system to load and unload these dynamically.
Check out http://www.unifycommunity.com/wiki/index.php?title=Terrain_tutorial for a guide to the various resolution options you have for the Unity terrain. This is a really well-written page, IMO, and a must-read for anybody who plans to use terrain.
Well I plan on streaming with asset loading, etc. I want a world that is around 30 sq. km but I don’t want load screens. I figured for performance reasons I would want to split up the terrain into tiles. Maybe I don’t, I have no idea. The terrain is what I’ve been struggling with for a couple weeks now. I’ve got 80% of my art assets completed and want to start putting everything together. The terrain thing has just got me stumped.
This is going to be a 3rd person RPG and only run standalone. I won’t be publishing it to the web. I figured I would need a 1m scale and 500x500 or 1000x1000 tiled terrains. I have been exporting my height maps at 1025x1025, maybe I should lower that to 513 then use 1000x1000 terrains?
I use the Terrain Toolkit for things like smoothing but I find it hard to make 2 terrains that match close enough to stitch them well. I don’t want one big terrain because I want to be able to use different textures for different regions in my game.
Honestly, if you’re planning on having a world that size you really need to know exactly how it’s going to work and how it’ll be loaded dynamically before you even think of art assets or sculpting/texturing this terrain. You need to measure and understand the performance implications of what you’re attempting, otherwise you’re going to find yourself having to redo everything should you want to change your resolution or tiling method. This is something you want to measure twice and cut once.
A 1m → 1 pixel scale is going to be very taxing on performance and memory, and lead to the editing problems you mention no matter what you’re using to sculpt it. You probably don’t need this level of detail, and I would advise you to use meshes to handle things such as complex mountains, canyons, paths, etc. You can’t rely on the heightmap to support all of your terrain and world detail, despite how tempting it might be due to how easy it is to generate and manipulate terrain. I would not even think of going above a 512x512 resolution, personally, and aim for something like 2m → 1 pixel instead. Some commercial games do use a 1024 map, but they also have very complex and intelligent streaming that I wouldn’t know how to implement in Unity.
This is, of course, not even considering the absolutely colossal task of decorating 30 square km of terrain. That’s about the same size as Oblivion, and unless you want a vast, empty, landscape of Perlin noise for your player to trudge over, I would suggest scaling this down a lot and being realistic about how much you can achieve with a small team or even solo.
i have the same problem (stutter and delayed interaction) with Untiy3 (Free) on Windows XP with 2.8 DualCore and good graphicscard.
In Unity 2.6 on a macbook with Mac Os X and small integrated graphicscard it was just very smooth and no problems with the terraineditor.
doublepost
Well I do understand the task of something that large. However I don’t plan on selling this game, and I plan on working on it over time. So finish 1 zone then start on another. This is just a personal goal for me, as I just want to see if I can do it.
I’ll try reducing the scale and maybe I’ll just use loading screens and make each zone its own scene. Sorta kills the immersion but probably less headaches on my part.
With the current settings my terrain shows around 60 draw cells. Which doesn’t seem to be that bad.
There’s no reason not to have it streaming, and it’s relatively easy to get that working. What I mean is, be sure you’ve properly designed the terrain and know exactly how it works first, otherwise it’ll be heartbreaking to have to delete them all and start over when you run into an unexpected problem. I would create the game and streaming system first, as that’s the hard part, and only then begin work on the terrain. Sculpting and decorating the terrain can be done last, but should definitely not be done first.
Try exporting a 30km^2 terrain from a landscape generator at the type of resolution you’re talking about here and take a look at the file size of it on disk. You’re talking about a 30x30 grid of 1024x1024 heightmaps, right? That’s going to be something like 2gb of heightmaps on disk, even before you texture these things.
30km^2 would be 6000m x 5000m for example. I was exporting 6x5 tiles at 1024 each. Also some of those tiles will be water only, thus not needed. I would say my actual land size is probably close to 20km^2, if not a little less.
Now I’ve reduced the map size in L3DT to 3000 x 2500 and exporting 6x5 tiles at 512. Then applying those heightmaps to a grid of 6x5 terrains that are 1000m x 1000m, thus I have 6000m x 5000m. Well actually less than that because I excluded the water only tiles.
I read it as 30km x 30km, for some reason, so hopefully that explains my slight incredulity at what I thought you were trying to do here. Blame the demon drink.
If you just want a terrain of 5000m x 5000m then things become a lot simpler, as that’s not what I’d consider huge compared to some of the craziness I’ve seen people attempt. I’m not even sure I’d bother splitting up the terrain in this case, and yes - a 1024x1024 heightmap for a single terrain of that size would make a lot more sense and should not cause any serious performance problems. You could still split them up if you wanted different materials on them or something, to avoid doubling your draw calls from going over 4 textures per terrain segment, but you wouldn’t gain much in terms of performance unless you had a really low far clipping plane on your camera.
I just created a terrain of that size here and it edits relatively smoothly in Unity. About the same as the terrain editors in Torque (vomit!), UDK, etc.
From what Achim says, the performance you’re seeing in the editor might be a Unity 3 specific issue?
Apologies if I confused things.
edit: and just to make matters worse (for me) it seems you’re right about terrain editing performance now that I’ve experimented with it some more in Unity 3. It’s absolutely horrible, if not completely unusable. I don’t know what’s happened to it. The closer you zoom in, the worse it gets.
Yeah it is pretty bad. I’m thinking I’ll try it on my mac tomorrow and see if it is any better.
I’ll see what kind of performance decrease I get by using multiple splatmaps and maybe I’ll just go that way if it isn’t too bad. I’ll also look at using meshes for some of the mountain areas instead of trying to manipulate the terrain. This would also free up some textures on the terrain.
Also I’m looking forward to the next patch to fix the terrain editor. 
Well as a workaround for the stutter I’ve decided to import my heightmap into the Sandbox 2 editor that comes with Crysis. Then I’ll edit to my liking and export it back to be put into Unity.
It is sad that I have to do this but I just can’t deal with the stuttering.
Has there been a solution yet to this stuttering from the sculpting brushes?
I could avoid the stuttering when reducing the Heightmap resolution to 257. It works fluid then. Every resolution above stutters, no exception, reproducable anytime. Now if I want to import a heightmap RAW with 1024x1024 automatically a Resolution of 1025 is applied => as a consequence I can re-edit the heightmap only accompanied by heavy stuttering. A reduction of the heightmap resolution to the above mentioned 257 will result in a completely flat terrain, therefore not usable.
Is this stuttering solved in Unity 3.1 ? I really like to know that before I download a huge 500mb package…
I’m using a Q6600 with 8GB of Ram and a 9800GT video card, plenty of HDD space, clean and optimized system.
I reported this as a bug, and received a reply that they could not “reproduce the problem” on a similar system and were thus closing the bug report.
I run multiple other programs that do basically the same thing (displace geometry) and have NO slowdown problems. Blender, 3DCoat, Leadwerks editor, all run just fine using a similar terrain size as the default for Unity.
Not sure what to say.
I’ve just decided to import a height map, but it’s a poor reflection on Unity IMHO for new users.
Yeah, this is an ongoing problem for us as well. One would hope it gets handled soon.
Ok, I’m working on a Ati 4650 and Core2Duo 2 Ghz. Is this too slow maybe? Because it works on the mentioned lower resolution… Yet I think it should work flawlessly, since it’s only setting some vertices. Even when using a fixed vertex height + brush with hard edges + small radius it stutters…
if it would be setting vertices …
but you paint the height map which on the fly updates mesh, normals etc.
But how can it be that a resolution of 513 stutters like hell with these settings:
Brush Size: 1 (hard brush)
Opacity: 100
Height: 10
I repeat: a Brush Size of 1
And a resolution of 257 rocks like a hurricane very fluidly with these settings:
Brush Size: 1-100, no matter which value or brush I take
Opacity: 1-100, no matter which value I take
Height: 1-100, no matter which value I take