LWJGL Forum

Please login or register.

Login with username, password and session length

Author Topic: Performance issue with high quality terrain chuncks  (Read 444 times)

ErChick3n

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Performance issue with high quality terrain chuncks
« on: August 15, 2017, 16:17:28 »

I'm making a game that needs a always loaded pretty big map with a very high heightmap resolution(at the moment 8192*8192), to improve performance i divided the map in 64 chuncks and in the game i render only the ones the camera is ooking at. The improvement in performance is huge and clear but when i try to pass over the chuncks of the 4th,5th,6th or 7th column my fps drop consistently. So I tried to understand the problem by eliminating the first 2 and the last row of the map and the "critical point moved to the 7th coloumn only". At first I thought it was due to my ram filling up and the coloumns after a certain one were going to the commited part on the hdd. But after cleaning up ram usage by other applications and running the game again the issue persisted even though my ram wasn't completely exploited. Is there something i'm missing? Why is this happening?
Logged

Cornix

  • Nerdus Imperius
  • *****
  • Offline Offline
  • Posts: 471
Re: Performance issue with high quality terrain chuncks
« Reply #1 on: August 15, 2017, 18:47:31 »

Probably because of the current constellation of mars and venus. Try after the next moon period and see if things have improved.

But seriously, there could be any number of reasons. We dont know what your code looks like and it is probably too much code for us to analyse. The only things we can tell you is very vague guesses. My personal guess would be that your culling does not work correctly.

I'd say try to strip your code down to its bare basics. Start with a very simple example and make it grow step by step. Keep profiling the performance at each step to see if something went wrong.
Logged

ErChick3n

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Re: Performance issue with high quality terrain chuncks
« Reply #2 on: August 15, 2017, 21:24:48 »

Leaving aside the fact that at first i thought u were talking about eclipse versions...
For culling u only mean rendering the front and not the back of a face? because I think there's no problem with that part of code.
Is it POSSIBLE what I said in the first post: that the problem is only a matter of reading speed, because part of the program memory is stored into the hard drive and not on the ram?
Logged

Cornix

  • Nerdus Imperius
  • *****
  • Offline Offline
  • Posts: 471
Re: Performance issue with high quality terrain chuncks
« Reply #3 on: August 16, 2017, 08:53:40 »

No, with culling I mean the way you only draw those chunks which are supposed to be visible to the camera. You are culling certain meshes on the client side before issueing draw commands to the server side. The easiest guess is to say your culling algorithm is wrong. You are not correctly calculating which chunks to draw and which chunks to omitt.
Logged

ErChick3n

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Re: Performance issue with high quality terrain chuncks
« Reply #4 on: August 16, 2017, 09:43:00 »

Ok, I modified the game so now when it renders the scene it prints the coords of all the rendered chuncks and it seems to be allright; only the chuncks that are visible to the camera are rendered as desired. So culling cannot be the problem.
So again, my question is: IS IT POSSIBLE that some chunck data is not stored in the ram but on the hdd?
Logged

CoDi

  • Newbie
  • *
  • Offline Offline
  • Posts: 40
Re: Performance issue with high quality terrain chuncks
« Reply #5 on: August 16, 2017, 12:25:57 »

Assuming that you render one quad (two triangles) per sample of your height map, thats about 134 million triangles in total, and more than 2 million triangles per chunk. You are more likely running into render performance issues.
Logged

ErChick3n

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Re: Performance issue with high quality terrain chuncks
« Reply #6 on: August 16, 2017, 19:01:11 »

That's true but if there was only a render performance issue rendering 4 chuncks on the left of the map should be the same as rendering 4 chuncks on the right, and it is not.
Also, after a few more testing it seems that decreasing total LOADED chunck number, makes the issue disappear.
Where are vaos physically stored? Can they have different reading speed?
Logged

Kai

  • Guest
Re: Performance issue with high quality terrain chuncks
« Reply #7 on: August 16, 2017, 19:33:20 »

Vertex Array Objects (VAOs) are stored nowhere. They do not represent any memory.
Buffer Objects (used to be called VBOs) bound to Vertex Array Attributes (which themselves are state of a Vertex Array Object) do.
So, everytime you allocate memory for a given OpenGL Buffer Object by calling glBufferData (or other modern equivalent alternatives) you are asking the OpenGL driver to allocate some memory from the memory available to your graphics driver/card.
When you are about to run out of graphics driver memory, then the driver may probably swap memory between the slower main memory (RAM) and the faster video memory (VRAM).
You should monitor/count/profile the actual amount of memory you are allocating for everything (most importantly Buffer Objects and Texture Objects).
Logged

ErChick3n

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Re: Performance issue with high quality terrain chuncks
« Reply #8 on: August 18, 2017, 10:11:36 »

So, now I'm pretty sure the problem is that I have not enough vram(i run some tests using gpu-z while running the game and the issue shows up only when video card memory is full). So I thought about loading and unloading chuncks of map with a margin of 1, so, if i'm looking at chunck 3,3 i will load from chunck 2,2 to chunck 4,4 and i update this every time camera moves. This actually solves the issue but loading and unloading from hdd seems to be a bit too slow. So i thought about two possible solutions, using multithreading, so the main thread runs the game and another one makes the unloading loading stuff, but i'd really prefer the second one that is loading and unloading stuff from video card memory to RAM and vice versa.
Is it possible to do? And if yes, do u know some tutorials or at least some good documentation about this?
Logged

Kai

  • Guest
Re: Performance issue with high quality terrain chuncks
« Reply #9 on: August 18, 2017, 10:30:46 »

Everything you upload to OpenGL via glBufferData will be pretty certainly committed to video memory.
When you don't want something to be stored on the graphics card, decommit the memory of the buffer object via:
Code: [Select]
glBindBuffer(GL_ARRAY_BUFFER, bufferId);
glBufferData(GL_ARRAY_BUFFER, 0, GL_STATIC_DRAW);
and possibly delete the buffer object's name via glDeleteBuffers(). But you don't need to do that, because you could recommit memory to it later on.

Then later, when some chunk is about to become visible, you recommit the data again to the buffer object via another call to glBufferData(), but now with the actual data.

However, an even better way would be to ask yourself why you need this rediculuous precision everywhere in the terrain, and whether you can employ some LOD mechanism to reduce the number of vertices. For example: if your terrain has medium/large areas of constant first order derivatives (i.e. its slope does not change), you can make a single triangle/quad out of that area.
Another example would be view-dependent LOD, in which you constantly adapt the tessellation of the terrain based on the distance to the viewer. One practical example of this is "Chunked Lod".
This will in the end save you the most memory and will massively improve rendering performance.

Have a look at this: http://vterrain.org/LOD/Papers/
Logged

ErChick3n

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Re: Performance issue with high quality terrain chuncks
« Reply #10 on: August 18, 2017, 10:55:04 »

Thank u very very much!
It seems now i have a lot of things to read and learn; I'll try to apply all your advices.
I'll post my, hopefully better, situation when I reach a significant improvement.
Logged