Performance problem[Improved]

ok heres what i have loaded:

  1. collada model with 64000 triangles as terrain.
  2. splat texturing the model using multiple render passes.
  3. my skydome system with 16000 triangles.



    What I tried to improve the performance:
  4. lock the pass node of the model.
  5. lock the model node itself.



    the problem is my fps dropped down to only 74 or so…



    my computer: Intel Quad Core running at 3.0Ghz. G.Skill memmory 3 GB. ATI Radeon X1900XTX 512MB.



    considering my system…the frame rate is very poor right now.



    HELP!!! what can i do to improve the FPS

If your terrain model is a single model, you could try to split it in several smoller parts.



And I don't know if it is possible, but you could do de same with the skydome.



This is my idea… but maybe I am wrong.

you should try using a profiler. then you'll see what is slowing you down

What's probably slowing you down is the terrain rendering, you might want to try using some of the methods on this page: http://mfkarpg.110mb.com/wiki/?page=TLOD

Using shaders for the terrain rendering can reduce rendering time by a factor of x2-10 depending on how many passes you're using.

Ender said:

If your terrain model is a single model, you could try to split it in several smoller parts.

And I don't know if it is possible, but you could do de same with the skydome.

This is my idea... but maybe I am wrong.


how will that solve the problem since the number of triangles wont change any ways?
HamsterofDeath said:

you should try using a profiler. then you'll see what is slowing you down


yourkit jprofiler is so expensive  :'(
Momoko_Fan said:

What's probably slowing you down is the terrain rendering, you might want to try using some of the methods on this page: http://mfkarpg.110mb.com/wiki/?page=TLOD
Using shaders for the terrain rendering can reduce rendering time by a factor of x2-10 depending on how many passes you're using.


i think the problem is the lighting. coz the skydome i made has dynamic lighting which means that the lighting for the terrain is calculated each frame. but i dont want to make that tradeoff since its a big plus on the visual quality.

so i guess theres only two options for me now.
1. reduce the model's triangle count
2. using LOD and c what happens
neakor said:

HamsterofDeath said:

you should try using a profiler. then you'll see what is slowing you down


yourkit jprofiler is so expensive  :'(


use the trial. also, there are special offers (half price or even less) from time to time. even if there is nothing mentioned on their page, simply ask if you can buy a personal license. i got one :)

Profiling with the eclipse profiling framework always did the job for me.

how will that solve the problem since the number of triangles wont change any ways?

In most cases you will only view a small part of the terrain, in that case you can increase performance by only rendering what is visible on the screen.
Momoko_Fan said:
how will that solve the problem since the number of triangles wont change any ways?

In most cases you will only view a small part of the terrain, in that case you can increase performance by only rendering what is visible on the screen.


Yes. It is exactly what I wanted to say. If the terrain is splitted in different objects (square subdivisions as TerrainBlock) jME should automatically avoid rendering of the parts out of frustum.

Moreover you can add some kind of LOD (even if I do not know how it is implemented for simple Trimesh objects, not TerrainBlock). A better solution should be to load the object as a Terrain, someway. And use D-LOD algorithms to dinamically change detail (Terra from llama has one, and also the jME internal TerrainBlock).

The sky can be a big problem instead. Even if I never seen such a detiled one...

For ligts, if objects out of view are not rendered also lights over them are not rendered so you are already saving a lot of resources.

Area-LOD seems like a good option right now. and ill try to implement it tomorrow and c what happens then.



but splitting the model into several small parts wont work for my terrain since i the entire terrain should be visible under the highest graphic option. and when the user lowers the graphic option, ill just reduce the LOD distance tolerance to achieve better performance.



thx guys~ :smiley:

but splitting the model into several small parts wont work for my terrain since i the entire terrain should be visible under the highest graphic option.


even the parts behind the player?
HamsterofDeath said:

but splitting the model into several small parts wont work for my terrain since i the entire terrain should be visible under the highest graphic option.


even the parts behind the player?


they r culled anyways arent they?

only complete meshes can be culled by jME

neakor said:

HamsterofDeath said:

but splitting the model into several small parts wont work for my terrain since i the entire terrain should be visible under the highest graphic option.


even the parts behind the player?


they r culled anyways arent they?


no. the decision "cull or draw" is being made for every sceneelement, not for every triangle.
irrisor said:
only complete meshes can be culled by jME


And this is exactly the reason cause I suggested to split the Terrain mesh.
Ender said:

irrisor said:
only complete meshes can be culled by jME


And this is exactly the reason cause I suggested to split the Terrain mesh.


ok i just did that. i splitted the model into 5 meshes. and i got an increase of 10 FPS or so.... :(

is there anything else i can do?
1. collada model with 64000 triangles as terrain.

I think collada is your problem. I have played around with collada loader and got pretty bad results, including loading problems and performance problems. On some of the models the ColladaImporter crashes when optimizing geometry, so they come out really unoptimized (this should show up in your log).

Now, this is just a guess, but I think that models loaded via collada have an excessive number of states (example: if you have a node and 1000 cubes with the same textures and materials attached to it, then loaded collada model would have texture and material state one for each cube instead of putting those states at the parent node). So when rendering, jme is spending alot of time comparing the states to existing one and doing many state changes.

There is an easy way to test if collada is your problem: try saving the same piece of terrain as obj (don't even bother splitting it), load it, lock it and see if you performance gets better. From my experience I had models rendering at 70 fps to go to 250 fps or so.

What Irrisor might have meant  :stuck_out_tongue: is that the parts behind the player are culled ONLY if they are really parts (i.e. a mesh in their own), in other words, if your terrain mesh is split into pieces (TerrainBlock)… Otherwise, your huge terrain object always intersects the frustum, and thus, is always rendered as a whole… jME does NOT dynamically break your models into pieces, it would be too much of a hassle to do it.