Terrain performance issues

I wonder if anyone can spot what I’m doing wrong here… I’m having trouble with performance with a basic terrain…









As you can see in the screenshot, it seems to be drawing 500k triangles and frame rate drops really low (on my quite useless laptop)…

I have the following code in, but it doesn’t seem to do much:



[java]

List<Camera> cameras = new ArrayList<Camera>();

cameras.add(cam);

TerrainLodControl control = new TerrainLodControl(terrain, cameras);

terrain.addControl(control);

[/java]



Am I missing something here?



Also, possibly related, I notice on the TerrainGrid demos I get a black, untextured terrain and other weirdness. I wonder whether its something to do with the lighting shader that causes performance problems for me?

Use this constructor for the terrain lod control instead:

[java]

TerrainLodControl control = TerrainLodControl(terrain, cam);

terrain.addControl(control);

[/java]

I need to update the other one to have proper defaults.

Also, you have other objects in your scene, if you remove them does the performance improve?



As for TerrainGrid, what version of jme are you using?

I updated to use that constructor and removed the rest of the stuff in the scene… it seemed a little better moving around, with triangles going down to < 100k at times, but still it often gets really high particularly around the middle.







Here we have 542k triangles, that seems pretty high for just a flat terrain? Or is that normal?



I realise the graphics card doesn’t help here, so its never going to run like a rocket… its an Intel i5 HD integrated graphics system, but it can play games from the past few years on low settings so there must be something missing here…



I am using JME3 nightly, updated with JMP today.

The detail in a default terrain is quite high. If you leave it flat, then you have a very detailed flat quad; replace it with a regular quad. Terrain is meant to have hills and valleys, that’s why it has lots of detail. Scale it up to have it feel larger and better reflect what you are wanting to see.



You can see the triangles if you run TerrainTest.java and hit ‘T’ to switch to wireframe view. You can also see then if the LOD is working.



The Intel integrated graphics systems are abysmal.

Reduce your heightmap resolution, it doesn’t need to be this detailed for this short view distance

Also the samples on the wiki seem to miss the initialisation of the LOD calculator:



[java]control.setLodCalculator( new DistanceLodCalculator(patchSize, 2.7f) );[/java]



At least this helped a lot in my world as the LOD kicks in at a decent distance and greatly reduces the amount of triangles.

@Sploreq: You are right, I was just using default terrain settings and the detail does seem really high… I made a lower detail terrain which improved things a great deal. I had to make a small one and then scale it in code though, is there a way to do this when creating it in the editor so that object placement works? I tried scaling in the GUI but it only lets me scale submeshes and not the whole thing at once…



Also, is it possible to have rough geometry for the terrain with a low triangle count but still have high detail in the textures/splatting?



@johncl You are right too, I don’t have any setLodCalculator… that looks like the kind of thing I’m hoping for, I will try that ASAP :slight_smile:

@johncl said:
Also the samples on the wiki seem to miss the initialisation of the LOD calculator:

One is set by default in one of the constructors for TerrainLodControl, I committed a fix to the other constructor last night to also set a default distance calculator.

@monkeychops said:
I tried scaling in the GUI but it only lets me scale submeshes and not the whole thing at once...

Also, is it possible to have rough geometry for the terrain with a low triangle count but still have high detail in the textures/splatting?

You can scale the whole terrain by just clicking on it in the scene composer, and on the right Properties pane change the scale.
Yes just set a more detailed alpha map when you create the terrain in the wizard.

I tried scaling the terrain as you said and updated the latest fixes… things seem much better now and I have a decent sized terrain with acceptable performance.



I think the defaults could possibly be improved though, the terrain seems pretty smooth even stretched 10x, is there a reason why it needs to be so detailed?



One little thing I notice now is that if I scale the terrain quite large and make a mountain in the distance, the mountain starts to disappear as i move away. Is there something I can tweak so that it will simply become less detailed rather than completely disappear? Ideally I’d like distant hills to become rough geometry with just enough triangles to make the silhouette… or even just a billboard… just as long as there’s some sort of shape on the horizon.

My guess is its going out of your camera’s far frustum plane. Try extending that to see if it helps. Be warned there is usually a reason why the frustum plane is set to what it is - extending it can lead to performance losses. You’ll have to manage the LOD carefully.

@ancalagon said:
My guess is its going out of your camera's far frustum plane. Try extending that to see if it helps. Be warned there is usually a reason why the frustum plane is set to what it is - extending it can lead to performance losses. You'll have to manage the LOD carefully.


Thanks, I will look into that.

I think what I want to achieve is to avoid clipping things off completely at distance, but rather just make them very very simple. I'm probably too noob to achieve that in practice, but I'll try :)

intel HD integrated, you have almost the same spec as me. Sorry but you woun’t get any performance, no matter how much tweaking you do. Its something with intel cards and openGL i think.



If I use direct3d (like with ogre3d) i can actually display somewhat advanced stuff with descent performance and use pixel/vertex shader 3.0, but if i switch to openGL fps drops drastically and advanced cg shaders craps out. got the latest drivers btw.



Not sure if its the same thing for you, but it probably is. if you have a recent directx sdk check out the caps viewer and you can find out. its in /utilities.



EDIT: I was very curious why I could run parallax-mapped terrains with grass, trees, models, water and a dynamic sky in ogre, but get 5 fps when using just a bumpmapped terrain here. Yes, java is slower, but not that much slower heh. Obviously a graphics card issue.

Haha just found an old video capture from an ogre app i’m working on. It’s laggy, yes, but mostly because of fraps + the fact that its basically on steroids (using 1000x the regular time flow). When i ran it on a fairly normal timescale and no video capture there was basically no lag, despite using:



a lot of trees with vertex lighting.

bumpy terrain with regular and specular lighting.

rain (which is in fact a post processing filter).

real noise-based clouds (not just a scrolling texture).

a dynamic skydome with multiple layers and a bunch of functions.



So yes it is a graphics card issue. it must be. This is proof.



http://www.youtube.com/watch?v=KHexulbzh0c

@androlo: yep, I see similar performance issues as you… its a shame there’s no DirectX renderer for JME3 :frowning:

It’s quite a big problem really, since Intel integrated graphics seems to be standard on pretty much every laptop now, except for a few gaming/multimedia ones which tend to be too big to carry.



The good news though is that I have made some progress - by making a smaller terrain and then scaling it up 10x, the world is pretty big and the hills are still good enough resolution for me. After tweaking the LOD settings it manages about 45-50fps too, which is acceptable. The problem I have now though is that the physics capsule seems to fall through the terrain at times, even if its really big… not sure what to do about that :frowning:



I guess JME3 performance will improve a bit over time anyway, it’s still beta after all and there are no doubt tweaks to be made.



@ancalagon: I tried increasing the far frustum settings on the camera, and do you know what, the mountains are visible nicely into the distance and the frame rate is hardly affected (thanks to LOD tweaks others gave me I guess). Really cool. I wonder if this will cause me serious problems with non-terrain stuff though, when the scene gets full. It would be nice to have the far frustum settings only apply to the terrain in this case, but my guess is I’ll see static geometry further than i need to too…

ACtually there are a few netbooks with a ati onboard, just look at the description.



Also why not a custom logic to your scene, that detaches to far away objects, but keeps the terrain always?

@monkeychops said:
@androlo: yep, I see similar performance issues as you... its a shame there's no DirectX renderer for JME3 :(
It's quite a big problem really, since Intel integrated graphics seems to be standard on pretty much every laptop now, except for a few gaming/multimedia ones which tend to be too big to carry.


Jme will not be supporting DirectX.
It is unfortunate that intel's integrated graphics chips are so terrible, in fact I think because of them they have set back the PC gaming industry a bit, at least on laptops.
Many, many laptop video cards can actually run open GL, yours is just awful. Time to upgrade.

Hmm I think you get that capsule stuff when you use low res terrains. I want my stuff to be accessible from crappy laptops I’m always cutting corners. In simple cases I drop the terrain physics completely and do a check every update like:



tH = terrain.getHeight(capsule.x,capsule.z)

cH = whatever height you want to capsule to be at (above the terrain)

if: (capsule.y < tH + cH)

then: capsule.y = tH + cH



You wouldn’t have to use terrain physics at all then, and could still place static physics objects in the scene (like trees and stuff) and use the capsule to collide with those.



EDIT: Yes I remember actually the same problem when i had like a low res terrain. where there was a river, the terrain changed more in height, and thats where i usually fell through.



EDIT: And also, of course, you can make that check into a control or whatever and use for any objects that needs to be aligned with the terrain (if there isn’t one available already, maybe it is).

@EmpirePhoenix said:
ACtually there are a few netbooks with a ati onboard, just look at the description.

Also why not a custom logic to your scene, that detaches to far away objects, but keeps the terrain always?


@EmpirePhoenix
Yeah I know there are some nice netbooks out there.. I am tempted to buy one, although it seems a bit wasteful when I have the use of an otherwise fine Core i5 laptop already (I didn't buy it myself sadly so I didn't get the chance to buy one with a 3D card). I am trying to exercise restraint and wait until its at least a year or two old :)
My point is more from a "customer base" perspective though - a heck of a lot of laptops still tend to have these crappy Intel integrated 3D chips, so selfish reasons aside it would be nice if our games could run on them.

Your suggestion about the custom logic to detach the far away objects but keep the terrain is a good one... I will give that a go. Perhaps there's some code in the paging trees plugin that I can extend to fade out the buildings too? :)

It is a pity that even modern Intel integrated graphics is so terrible.



While I was looking to support Intel integrated graphics, I dont think I can. Games like Orcs Must Die require discrete graphics cards, so I’m hoping its not too much to ask.



I do plan to buy a netbook with an ATI graphics cards, so I can make sure that, while it requires discrete graphics, it doesnt require expensive discrete graphics.

@Sploreg said:
It is unfortunate that intel's integrated graphics chips are so terrible, in fact I think because of them they have set back the PC gaming industry a bit, at least on laptops.
Many, many laptop video cards can actually run open GL, yours is just awful. Time to upgrade.



You are right... I've been the victim of Intel's crappy integrated graphics several times... sadly I didn't get to choose this laptop, but it seems silly to just buy another one when it does everything else I need it to *except* render shaders properly. It's even OK for most games apart from that. I guess I will buy a little ATI netbook at some point but I want to wait for the other one to at least lose the smell of fresh plastic first :P

Gaming on the PC has been held back quite a bit by the low end hardware shipped as standard, that's very true. One of the things that really draws me to JME is its cross platform abilities and the fact I can target Android devices with my game. I guess these terrain performance ideas we're discussing will also apply to Android as well, although I haven't been able to get the terrain to run on my phone yet, the most I've managed is a dancing cube hehe.