Sectored/repeating terrain features?

Development
1

Hi!

Just got myself into exploring jME. I have some ideas which I'd like to do with jME, and i need some features.

  1. Large terrain

    Don't know how big terrains jME can handle, but I'd like absolutely huge terrains. Would the engine slow down with a big terrain? If clipping distance is set, the display should not suffer i think, but is there any issue against huge terrains?
  2. Sectored/repeating terrain

    Terrain made up from separate parts, with different detail level and sizes. The TerrainPage can handle this, but how is with different sizes? Can repeating terrain be made so that the height and mesh data be shared?
  3. Foliage layer

    Loaded from an image file, for each color in the image the terrain be layered upon by different foliage (grass). Detailed close to the camera, and as a color (overlay?) in distance.

    Are those features simple enough to make for a beginner? If so, how would they be implemented with jME?

    Another question: I see that a BSP level can be (soon?) loaded into jME, but as i know a BSP level is only viewable from its inside. Will there be a feature, that a BSP level be placed into scene, and be surrounded by a model. So that viewed from outside its a model, and from inside a BSP level?



    Thanks.
2

Vear,

About terrain; you can get a good feel for terrain in MW3D and have detailed control of it.  Right now terrain pages can be generated in sizes ranging from 128x128 to 2048x2048 but there is a memory limitation with anything over 256x256 being created in a reasonable time.  A fix is currently in development. 



The sectored terrain you mention, if I'm not mistaken, can either refer to the sizing control of sub-blocks(or sub-pages) or the render control of terrain (culling, LOD).  Does this note from the header of TerrainPage match what you're asking:

TerrainPage is used to build a quad tree of terrain blocks. The TerrainPage will have four children, either four pages or four blocks. The size of the page must be (2^N + 1), to allow for even splitting of the blocks. Organization of the page into a quad tree allows for very fast culling of the terrain. In some instances, using Clod will also improve rendering speeds. The total size of the heightmap is provided, as well as the desired end size for a block. Appropriate values for the end block size is completely dependant on the application. In some cases, a large size will give performance gains, in others, a small size is the best option. It is recommended that different combinations are tried.


MW3D has some great controls for vegetation and the two points you make would be a great addition to it.  Currently, vegetation can be manually placed in a 3D scene simply by LMB clicking the desired terrain location.  Or it can be randomly placed through a generation process.  We currently have height map images to control terrain so I think it is a logical step to consider similar imaging for vegetation (in fact this is one of the vegetation methods found in UnrealED).  It would be easier for you to extend the existing functionality in MW3D rather then start from scratch as I believe the basic framework is already in MW3D.

3

I had a similar problem with a big terrain and I use a class to load and unload tiles cached in binary form : http://cvs.world-of-mystery.de/cgi-bin/cvsweb.cgi/wom/src/de/worldofmystery/client/SlidingTerrainPage.java

4

Hi!

  1. Grass

    I’ve been working on a grass-factory which places different grass using a PCX image as a map:





    The grass is divided into blocks:





    I’d like to draw some blocks with impostor nodes, but have problems with them. The grass is only visible from close up, and it shows up barely visible, under the terrain. I have the following setup:



    Billboard positioned where the grassblock should be

    Impostor

    Fake scene

    grasblock mesh



    By looking into the ImposterNode source:



   public void updateCamera(Vector3f eyeLocation) {
      float vDist = eyeLocation.distance(standIn.getCenter());
      float ratio = cameraDistance / vDist;
      Vector3f newPos = (eyeLocation.subtract(standIn.getCenter()))
            .multLocal(ratio).addLocal(standIn.getCenter());
      tRenderer.getCamera().setLocation(newPos);
      tRenderer.getCamera().lookAt(standIn.getCenter(), worldUpVector);
   }


It repositions the camera in the imposted scene as it is in the main scene, with looking at the "standIn" Quad's main scene world coordinates.
If the camera in the imposted scene is looking at the imposter nodes world coodinates, a mesh being imposted shouldn't be placed in the same position as it would be in the main scene?

What i want to know, is how the mesh should be positioned in the imposted scene so it appears exactly where it would be in the main scene?

I see there is a thread about making grass and using impostors on blocks of grass. Have someone succeeded in this? Is it worth doing with impostors? Using impostors causes JVM crashes when exiting the app, and takes long time to initialize when starting the app...

2. Large terrain
Thanks for SlidingTerrainPage. What i want is pretty much the same, but not with terrain blocks cached based on their position, but block types. If a block is cached, it can be reused in some other place to show.This way by tiling a limited number of blocks, a big "sector" can be filled, and then repeated for endless terrain.

3.
Cannot compile jMonkeyWorld from CVS against the latest jME with a "package com.jme.widget does not exist" error.  :(

Thanks.