2018.3 New Terrain comparison

So I wanted to see about the “orders of magnitude” performance increases the new terrain system offers. I’m building a VR experience and Terrain is KILLING me, so naturally I’m very excited by a statement like that.

However, doing a very simple comparison on the new beta, I basically see zero performance increase. In fact, 2018.3 seems a bit slower (but that could be something random).

It’s a 1000x600x1000 terrain, 5 pixel error, no textures, and just an arbitrary hieghtmap (res 513) was used for a bit of shape.Unity wanted to bake some lighting, which is why everything is super over exposed. I let that finish before taking my captures.

Am I doing something wrong? The only significant improvement is the number of drawcalls (Yes, I have Instanced enabled on 2018.3), but that didn’t seem to matter in terms of FPS. The CPU time is almost identical as well, which is strange because I thought most of the terrain was moved to the GPU for calcs.

I hope I did something wrong, because if the terrain is just as performant as before then I’m going to have to just accept my VR program will get max 45fps, and never dream of the coveted 90fps target.

I would take a close look at the profiler to see if the terrain rendering is indeed slower. It might just be typical editor overhead you’re seeing rather than differences in the terrain rendering.

Draw Instanced is absolutely enabled of course. Just making 100% sure since Instancing means different things to different people.

If you’re using the stats display then you haven’t got any clue what performance it’s running at. Stats is not accurate, will never be accurate and most of the time is showing the wrong number for FPS because the editor updates stuff at different times. It’s a nonsense number and frankly I’m not sure why Unity includes it there given how unreliable it is. Use profiler, and use the profiler in a standalone build.

100% sure it’s not the terrain that’s the problem. And I’m frankly stunned you’re trying to even develop with VR without using the profiler.

wags finger and mutters etc

1 Like

Lol, don’t get me wrong I do use the profiler. I just figured the simplest possible test was just in the editor stats window. Yes, I know there’s vast amounts of overhead in the editor, and the absolute purest way to benchmark would be to do two builds with the profiler enabled.

But I figured that performance increases would be seen at least at the editor level as well if they’re vast enough.

Like, if I was getting 50fps in a game build, but 20fps in editor, and some new terrain were to increase performance by 10fps, then I would be getting 60fps in a game build and 30fps in editor. Theoretically…?!?

PS. Yes, I meant “Draw Instanced” is enabled. That’s why the batches are drastically reduced

Don’t forget the difference in your screenshot is around 0.05 milliseconds. Which is about the cost of… I dunno a moth farting in the rainforest. It’s not science but religious zeal at play here :smile:

FPS do not scale like millisecs do. You don’t need to add much to dramatically drop the FPS from 700 to 300 for example.

I used to be into FPS before being totally thrashed and beaten by the brutal @superpig

Reference: news

1 Like

:smile:
You can call it like that, I myself will use the ‘margin of error’ or ‘completely normal fluctuation’ expressions instead.

1 Like

I’m hoping beyond hope that the performance gained with the new terrain is more significant that a moth faring in a rainforest

I honestly feel like the test is just too simple.
The new terrain probably simply scales (in terms of performance) much better now.
Which is not what’s being tested here. I mean you want 90fps, you already got 700+.

Make a terrain that’s a bit more complex, has more high-frequency noise, less pixel error, is bigger in general (and not just scaled bigger, but also uses higher-res base and detail maps in the settings). Definitely use a higher res than just 512 and less pixel error.
Also make it a 4x4 field of tiles.

Leave the material as is because shader/material changes have little to do with this.
Then report back how well (or bad?) the old version does with the same exact terrain (I’d just export it from the old version as a package)

Yeah, it all depends on your platform and terrain setup.
Weaker CPUs will be affected more – the optimization reduces CPU usage, so it’s only effective to the extent that CPU is the bottleneck. So having more terrain, or higher detail increases the effectiveness of the optimization.

If you really want to give it a stress test, also set your pixel error to 1.
This setup will absolutely destroy my laptop with instancing disabled, but it runs fine with instancing enabled. :slight_smile:

2 Likes

Oh now you tempt me toward pixel error 1. I still feared it, from the old dark days.

Interesting. Well, I guess my initial idea for this test is that I don’t need to spend 2 hours setting up two parallel scenes full of detail, the performance should be noticeable immediately with the most basic set up.

Yeah 700fps is great but of course once I load it up with textures and trees and waterfalls, kaboom.

But then again maybe it gets optimized in the complex operations, and the simple set up would perform the exact same because nothing taxing is being called?

Maybe I should actually try it fully loaded…

@hippocoder but a moth farting in a forest in Africa will cause a tornado in North America Butterfly Effect :stuck_out_tongue:

3 Likes

It might very well be in a real player, on device. When you’re running at hundreds of FPS in the editor it’s all just noise. That’s the main point here.

More terrain objects or just more “terrain”? In other words, are we likely to see a better increase in 16k by 16k single object or 16k by 16k made up of 64 2k by 2k terrains, etc.?

Yes I know the editor has massive overhead. I consider this to be beside the point though. The overhead would be the same in both tests, so the delta should be visible.

That’s false. First of all, a beta editor usually have much higher overhead, especially if they made a lot of substantial changes as they did.
Second: the editor overhead is not reliable. You can have different amount from run to run let alone between different versions running.

They are not joking when they tell you that you should profile on the device itself and not in the editor and on production build. That will give you usually a close answer how your application will perform in real life.
And even then you have a lot of variables (depending what else is running on such device, whether or not the device performs other tasks or not - updating tasks for example).

I’m here just to see what happened to the farting moth.

1 Like

He drowned. Or was eaten. Probably both. It was a rainforest. In Africa. And everything is bigger in Africa. Except for the moth. He was probably a normal-sized moth.

I heard he survived, he moved to San Francisco and he formed a heavy metal band called Mothallica. Later he got a leading role in an action movie, straight from LA. Fart & Furious 13: The Revenge of the Moth.

No way! – It was that moth?? – I guess Ebola wasn’t the only terrifying thing to come from Africa that didn’t live up to the hype.