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.
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
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 :)
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.
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.
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.
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.
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.
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 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.