   Heightmap Generation + Seamless World
  Hello all.I'm looking to just spit out some ideas here, and get some constructive feedback on how to remedy any ailings with the solution you find.I'm looking to generate a rather 'large' world, perhaps even infitely so you could say.Take for example, Delta Force.  The main play area for a particular mission was obviously generated in a map editor of some sort.  However, you could walk well beyond the mission zone and continue for quite some time (I don't think you would ever be stopped).I'm jumping to the conclusion that this is through random terrain generation, outside of the play area.  Random terrain generation isn't a problem, I've already got that solved in my very weak heightmap engine now.Basically, the solution that I've got mapped out in my mind is this:-> Load a 'world file' that contains the zone for the current mission / level.  This file can vary in size, but it obviously not endless.-> Keep the world file parameters (ie, the world is 32 patches by 32 patches of playzone, before you hit 'random terrain') in memory.-> Have a 3x3 grid of patches connected.  These patches could be 64x64 quads big.  When entering a new patch in the grid, unload the furthest ones and load in the closest ones from the world file.  (ie, if you walk north and hit the patch at the top, you remove the patch at the bottom).-> If a patch can't be loaded from the world file, randomly generate the terrain.  This would keep the world going seamlessly if the player really feels like going on forever and ever.Heres a couple of hardships / flaws that I've already thought of, and would love to here solutions and such.1.  Texturing.  How would you texture randomly generated terrain?  Perhaps my knowledge of texturing heightmaps in general just isn't good enough.  I've read up on 'splatting', but that seems more to make your terrain sexier not neccessarily do it for you.  Any suggestions here are much appreciated.2. Load times.  If the loading hiccups the frame-rate, its not going to be as fun.  The way to get around this would be the lessen the load time by making the patches shorter.  This would however create more loads (which could potentially just be worse).  The advantage I see here, is being able to brute force the LOD by simply culling out patches not seen in the frustrum.3. Random generation.  Loading is going to be one thing, but randomly generating and randomly generating a texture for the heightmap patch is going to be even slower than loading it from a world file.  Any ideas on this one?Well thats my basic idea.  Anyone have any suggestions on how to improve upon it or what they'd do differently?  I'd really like as large play areas as possible, ontop of the random patches to allow for seamless, endless worlds.[edited by - GroZZleR on February 11, 2004 7:43:05 PM][edited by - GroZZleR on February 11, 2004 11:27:52 PM]
  Randomly generated 3D terrain...? That''s a pretty neat idea. Have you concidered having pre-textured pre-randomed blocks which just switch in randomly instead of being generated randomly. You''d loose a lot of randomness, but If you have enough to choose from it mightnot be that bad, and you could still randomize your objects on the terrain.I mean like, Have a pool of 30-30 area quads to pick from to be the next one to load up but they are pre-setup. Kinda like how some muds do thick forests.Don''t know how to help with your questions, just think it''s a neat idea and throwing some others out there. - Newb Programmer: Geek++;  Not a bad idea, but probably not best suited idea.  If I had terrain for snow, sand and grass, that''d be a lot of extra terrain stored on disk to form 30+ patches for each area.  Although I''ll have to play around and see.Anyone have any ideas on the random texturing generation and how that process could be done? ;  I''ve done the same thing in one of my test engines a few years back.Things I noticed (this is not in response to your questions, but things to look out for)1) Load time.  Each time you go over a patch, it will get a hiccup.  You will have to thread this, and trigger the thread to load the patches as you move over it.  Each patch will need a flag "Am I Done Loading?" When its not done loading, you skip the rendering of that patch.  Otherwise you do render it.  Sometimes if the loading takes a long time, you will see some patches load in before others, and they will just pop up.  If you ever played Microsoft Flight Simulator, this is exactly how they do it, and you might have noticed the effect.  In order to thread, you need to slow down the main loop, like put a "Sleep(5)" in there to give the other thread some breathing room to load.  In essense, you will need to slow down your engine purposely in order to avoid hiccups.  Its ok to do that, and its necessary. 2) Going too far away causes floating point inaccuracies.  This is probably the most major problem I ran into.  If you walk for miles in one direction the floating point number becomes too large, and the camera starts to stutter.  In order to fix this, I had have it so the patches would shift under the camera instead of having the camera scroll above the patches.  That way the camera stayed over the immediate patch (in a -1000 by 1000 area.)Just a few things to look out for. ;quote:-> If a patch can''t be loaded from the world file, randomly generate the terrain.  This would keep the world going seamlessly if the player really feels like going on forever and ever.Do you save the randomly generated terrain afterwards?  Remember, once you randomly generate terrain it has to be persistent so that if a user walks away and returns it is the same... ;quote:Original post by rypyr  quote:-> If a patch can''t be loaded from the world file, randomly generate the terrain.  This would keep the world going seamlessly if the player really feels like going on forever and ever.Do you save the randomly generated terrain afterwards?  Remember, once you randomly generate terrain it has to be persistent so that if a user walks away and returns it is the same...   You know, I didn''t even think of that.  *chuckles*  I''ll have to find a way to save the random seed used to generate that specific patch of the world.JoeyBlow2:  I''ve never played Microsoft Flight Simulator before, but that sounds like an interesting problem.  I suppose for my example, where the terrain is larger in size (ie, you''re right against the ground not miles above), it shouldn''t be as big as an issue with patches popping in.---Anyone have any ideas on texturing randomly generated terrain?  Perhaps I''m just not versed enough in texturing terrain at all.  I suppose I could use a seamless texture of some sorts, but that might not look quite as good as I expect.  Merely because its the same texture.  Any ideas? ;  It doesn''t have to be the same. Nobody will care if it''s different. The idea he has with 9 random patches at most is perfectly fine.   --------------------------------------I am the master of stories.....If only I could just write them down... ;Perhaps a simple question, I just wondering how you would go about insuring there was a smooth transition between the pieces.  IE if your middle patch of the 3x3 grid was one that was not randomly generated (instead designed outside beforehand) what would be a clean way to make everything around it fit cleanly?  (The height values at the edges would have to match up or be close, etc);Nathaniel, I would disagree with that, if I was to notice something like that it would definitely break the suspension of disbelief.  Besides it would be fairly trivial to save this kind of information seeing as how it would just be the seed and possibly some coordinates.;  For terrain texture generation, here''s a good place to start:http://www.flipcode.com/tutorials/tut_proctext.shtmlIt describes a system similar to what I usually use, and it can give some very nice results.For getting reproducable random terrain so it looks the same when you return via the same path, I would suggest looking into Perlin noise.  It not only gives you the ability to generate the same terrain again by using the same seeds, it produces seemless terrain in any size you want.  It''s a bit slower than, for example, a diamond-square fractal, but fractals are much tougher to work with when you want more control over the results, and Perlin noise is still very very fast;  plenty fast enough to allow runtime generation of the upcoming terrain, assuming you''re smart about it and distribute the work over a number of frames.For stitching the random terrain to the pre-defined terrain, or to other random terrain, you have a number of options.  Using fractals I believe you can fill in the edge heights yourself so that the terrains will match up so long as they are of the same resolution (same number of triangles per world unit).  To match up meshes of differing resolutions you have to do a bit more work;  one good solution is to insert a small buffer area around each terrain tile, and in that buffer create any necessary triangles to stitch the tiles together.  It''s not as tricky as it seems, really Hope it helps,dradon 