Thread: Terrain editor

  1. #1
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607

    Terrain editor

    After seeing minecraft and being totally disgusted that people play it..or moreso that I didn't think of it I started working on more terrian. This terrain is fully editable and uses texture splatting to arrive at the final color. It mixes 7 separate textures and the height is computed in a shader. The only thing I cannot do yet is light the thing b/c the normals do not exist until the card grabs the height from the heightmap. I will have to use a normal map but I am running out of texture slots.

    An early screenshot of what you can produce with it:
    Last edited by VirtualAce; 03-12-2011 at 11:41 AM.

  2. #2
    Registered User
    Join Date
    Aug 2003
    Posts
    1,218
    Looks really nice! And yah minecraft has become a real hit and as you said, why didnt i think of that

  3. #3
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    I'm going to try to duplicate it but with this terrain. My main concern with this terrain is I cannot do overhangs because it is a heightfield. Traditional outdoor games make up for this by using 3D objects to create the overhangs. FarCry 2 does this very well and of course has very good plant and tree models which I obviously do not.

    However I'm trying to:
    • Keep it simple
    • Allow the user to create portions of the world
    • Put some type of gameplay in it that causes the player to want to do just one more thing.


    Graphics are not my main concern b/c we all know I could post process the scene and all sorts of other things but I'm not sure that actualy adds to the game idea at all. The next thing to tackle is integrating Bullet so I can start dropping in objects and see how they interact with the terrain.

    Minecraft can be done via an oct-tree but I'm still not sure an oct-tree can handle all those blocks. I'm still looking into this.

  4. #4
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Well after some fiddling and some tricks I was able to reproduce a minecraft type level with all the same texture. I can change the texture of any block and remove any block in any column. Here is a far away shot which is off the terrain and below it.

    This is a 128x128 render of a 1024x1024 map. The 1024x1024 brute force map crawls. I will have to use a quad-tree to get this fast enough to play with and have any hope of decent render distances.

    What I have created is a really crappy 6 DOF voxel engine with no half voxels. All voxels are a multiple of the desired cube size. This was done on purpose of course to imitate the minecraft look.

    Check out how many cubes it 'appears' that I am rendering. I'm actually not rendering as many as it might seem. The second screenshot is looking up the side towards the top of the terrain.
    The last screenshot shows a different side texture and top texture for each 'cube' or voxel.
    Last edited by VirtualAce; 03-12-2011 at 11:41 AM.

  5. #5
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    That first image looks pretty nice, but that last one looks "OMG Nausea" bad.

    Of course, if you are trying to hit the crappy look of "Minecraft" the last is probably the best.

    Soma

  6. #6
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    That's awesome!

    As for minecraft, I think it was because the initially didn't have a choice. Java3D anyone? ;-)

    Are they the same clouds you showed us a while ago? They look pretty snazzy.

  7. #7
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    Okay, I confess, I'm still confused about the "octree not handing all those blocks". Are you talking about storing the style of a block to be drawn or using a tree to cull volumes that can't be seen?

    I know a sparse octree can handle either, but I'm not sure what you are talking about and it is still bugging me.

    Soma

  8. #8
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    The octree can handle the data but I don't think I could render from the tree fast enough to maintain good frame rates.

  9. #9
    Registered User
    Join Date
    Mar 2010
    Posts
    68
    Ideas for speedups . . .

    decrease the texture layers to two. Also, if you want additional speedup, don't let the gpu read the height map in the vertex shader. Let the cpu build a static mesh and update that when the viewer moves enough. Just break the mesh up into manageable chunks.

    Those two should give you a really huge increase in rendering speed.

  10. #10
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Which renderer are we talking about here? The block terrain is using a totally different concept than the smooth terrain system is.

    In regards to the smooth terrain system:
    decrease the texture layers to two.
    Actually I'm increasing the total number of textures to 12 * number_of_patches. Not as good as megatexture but still provides a nice array of terrain types.

    don't let the gpu read the height map in the vertex shader.
    This is extremely fast. The operation is GPU limited whereas a lookup elsewhere is CPU limited.

    Let the cpu build a static mesh
    I'm way past that point in my system. My system has only 1 mesh in memory and it is the size of a local patch. The memory footprint comes from textures alone. Static meshes do not give as much flexibility as the current system and I built a static mesh system long ago which did not produce what I wanted.

    Just break the mesh up into manageable chunks.
    It is. Yet this is strange given your statement to use static meshes. The two statements are in opposition to one another. I have 1 mesh in memory that can be changed based on the data in the height map and the texture maps. It can change dynamically and can also be used to produce waves and other effects.

    Those two should give you a really huge increase in rendering speed.
    The only thing that will speed this rendering up is to implement a quadtree. I have done this before and it worked like a charm. This system is simply brute force patches based on view distance. However it has little trouble producing extremely long distance renders. At the point it becomes slow or advantageous to actually speed the rendering up I will optimize it. Right now there is no need.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Continous LOD Terrain Source... Released!
    By Perspective in forum Game Programming
    Replies: 13
    Last Post: 04-17-2006, 11:21 PM
  2. New terrain engine
    By VirtualAce in forum Game Programming
    Replies: 16
    Last Post: 03-16-2006, 02:47 AM
  3. Terrain algos
    By VirtualAce in forum Game Programming
    Replies: 1
    Last Post: 04-10-2004, 02:50 PM
  4. Replies: 12
    Last Post: 08-05-2003, 02:16 PM
  5. OpenGL terrain demo (EDITOR)
    By Jeremy G in forum Game Programming
    Replies: 2
    Last Post: 03-30-2003, 08:11 PM