Hi, I'm new to this, went through the tutorials, and just got jME set up and running, so far so so good.
I was wondering what the expected system requirements of a jME game are? I created a bitmap TerrainBlock with physics and a stickfigure (made of three cuboids) that move on it. This simple setup has no game logic yet and already maxes out a 1GHz machine, this can't be…?
What is the optimal way to create a terrain from a bitmap, e.g. is there an optimal size, and optimal bit depth for the textures and the terrain bitmap? Is it better to make a small bitmap and then resize it? The texture is mapped so blurrily that I may as well replace it by a plain color, is that possible, would it save cycles at all?
Actually I don't need a smooth curvy landscape for my game, it would also work with flat planes and slopes instead of curvy hills. Can I switch off the curviness and render the terrain as flat polygons, would that speed it up? Or do I have to create my own non-curvy terrain out of triangles?
And has anyone ever tried to put 9 terrains in a 3x3 tile arrangement with the player always on the tile in the middle, to create an infinite, wrapping map? Or would that totally max out the engine (because all 9 tiles would need physics in case an enemy ran over to one of the other tiles)?
Also how do you create characters which, unlike cars, are higher than wide, which are supposed to be walking on the terrain? Even if I set the center of gravity below their feet so they can never fall over, they totter and stagger and spin like crazy.
Thanks for any hints.
hi zathras
Regarding the 3x3 tile approach there was an successful demo app somewhere on the forums.
You have to search the forums for "TerrainContinuous" to get to the source.
edit: You may have to fix it up somewhat for current cvs tough.
winkman said:
You have to search the forums for "TerrainContinuous" to get to the source.
Cool, thanks! :)
winkman said:
edit: You may have to fix it up somewhat for current cvs tough.
Speaking of which, I am trying to fix my project which is broken since the last CVS update, and of course I don't know whether it was the update or one of the other 10 things I did, but even starting from scratch doesn't fix it. Can you confirm that the current CVS version really works? E.g. inside the lwjgl.jar there is "devil", "fmod3" and "lwjgl", but they are empty -- should they be empty?
E.g. inside the lwjgl.jar there is "devil", "fmod3" and "lwjgl", but they are empty -- should they be empty?
Shouldn't matter, as they have their own jar's.
No idea what these directories are for.
Try running the official jmetests, if they run fine, chances are the fault is in Your code ;)
winkman said:
Try running the official jmetests, if they run fine, chances are the fault is in Your code
"package jmetest does not exist"
Sounds like this jar (and maybe others) is missing in Your classpath
(and don't forget to add a -Djava.library.path= ... statement with the path to the native .dll / .so 's to Your vm arguments)
and failed to build jme-physics
could be caused by the same fact as jmephysics contains some jar's that are not in the libs dir.
Please refer to the wiki for general setup hints (even if You are not using an ide)
hth
I started over and got it working again, I must have misslinked the libraries.
In case somebody's searching the forum for answers, I'll answer one of my own question.
Replying to my own post for others who may be interested… I tried different things and I found some estimates:
- Using a smaller terrain bitmap speeds up frames per second quite a lot (of course the terrain looks less smooth at the same time). For example:
- Scaling the terrain by supplying a bigger/smaller size vector during creation of the terrain did not increase/decrease speed
- Using 8bit grayscale compaired to so-and-so many million color bitmaps (i.e. smaller size in kilobyte) did not increase speed noticably either
256x256 pixel bitmap = 250 fps = slower, but smooth texture
32 x 32 pixel bitmap = 500 fps = faster, but blurriness and visible rectangles on terrain texture
Using TerrainBlock creates a single terrain mesh, i.e. a very brute force way of doing things. Usage of TerrainPage will create multiple TerrainBlocks that are organized in a Quadtree. This should certainly help frame rate, but does not provide any LOD on the terrain. As Winkman mentioned there are other options that provide an LOD approach that could greatly increase framerate depending on that view.
mojomonk said:
Using TerrainBlock creates a single terrain mesh, i.e. a very brute force way of doing things. Usage of TerrainPage will create multiple TerrainBlocks that are organized in a Quadtree. This should certainly help frame rate,
Thanks for the reminder, TerrainPage is litterally the last thing mentioned in the tutorial.
zathras said:
...
I am not completely clear what LOD is, (I only know it stands for level of detail) -- is LOD something that I would want to have, or something I should avoid because it wastes cycles? I am not doing anything naturalistic, I certainly do not need a high level of detail and smoothness.
PS: Oh wait -- when I look at it now, the TerrainPage looks like a quarter of the whole thing, and the distorted corner may actually be a quarter of the hill in the middle. But then the height-sensitive textures would be completely wrong. And also, how do I make the rest appear?
LOD is one of the most useful thing you can have when using large scale terrains. LOD generally means that the triangle count of terrain that is far away is reduced, as you can't see those details anyways. i.e. a mountain far away could be reduced to a few triangles, but when you get near it, the triangle count increases.
when you say that TerrainPage looks strange do you mean the one in TestTerrainPage?
sfera said:
when you say that TerrainPage looks