Terrain

Because we don't have anywhere else to talk about it, we now have a thread. :) Problem solved. I'll start it off.

I'm particularly curious about whether mountainous landscapes are possible. We've seen hilly, and we've seen mostly flat - but mountainous? How mountainous can the terrain get?
«1

Comments

  • As much as you want, really

    image
  • Talvieno said:

    I'm particularly curious about whether mountainous landscapes are possible. We've seen hilly, and we've seen mostly flat - but mountainous? How mountainous can the terrain get?

    I wonder if you are scheming of utilizing Gavan's engine as a Dwarf Fortress visualizer, because now I am. :D
  • edited October 2014
    Baile_nam_Fonn!!! :D Glad to see you here! Lol

    I don't suppose you know of Japa from Bay12? You know, the guy behind a very large number of Bay12 utilities such as Stonesense... He's already got his eye on it. In fact, he's hoping to make something out of it. :) Saw a comment on a VQ YouTube video saying so.


    Gavan - that is gorgeous. I can't wait. XD And it looks like you can have caves, too? How will it handle caves, if you can walk inside? Will it know to "hide" terrain so you can see your character, or...?
  • I assume hiding terrain to see your character will work the same way hiding walls when you are inside will
  • edited October 2014
    The Japa? O.O
    Alright! Now I'm ready to bounce off the walls.

    edit: related, another Bay 12er, GavJ, is looking to raise the bar in voxelicious geology.
  • @Mystify‌ - Aye, but with buildings it might almost work better if the walls were partially transparent instead of removed completely... hard to say, though.

    Baile - You bet. :) I guess it'll depend on how easy it is to shape the terrain from an external program. If anybody can do it, though, that would be Japa.
  • edited October 2014
    Talvieno said:

    Baile_nam_Fonn!!! :D Glad to see you here! Lol

    I don't suppose you know of Japa from Bay12? You know, the guy behind a very large number of Bay12 utilities such as Stonesense... He's already got his eye on it. In fact, he's hoping to make something out of it. :) Saw a comment on a VQ YouTube video saying so.


    Gavan - that is gorgeous. I can't wait. XD And it looks like you can have caves, too? How will it handle caves, if you can walk inside? Will it know to "hide" terrain so you can see your character, or...?

    Thanks! You can have caves, in fact I have a cave genrator just does not look good now because its confusing in iso perspective (maybe first person will fix this?) It can cutaway anything down the the voxel level, so just cutaway any voxels occluding or somewhere in the area between your character and the camera (think classic cutaway view). This is fast in some modes, slow in others - need to work on combining all modes intelligently for one optimized mode. Alternately, if the chunks are small enough, you can cut at that level too, without a performance hit.
  • In caves, when you cut away, will there be some "fog of war" that avoids you seeing adjacent rooms/passages that your character wouldn't be able to see?
  • @Katorone‌ You can easily determine visibility by raycasting against the macro chunks, works independently of perspective (calculated on the CPU). This is used for stealth / hiding among other things.
  • Cool! Looks like you're on top of things. Love it. :D
  • Talvieno said:

    @Mystify‌ - Aye, but with buildings it might almost work better if the walls were partially transparent instead of removed completely... hard to say, though.

    Baile - You bet. :) I guess it'll depend on how easy it is to shape the terrain from an external program. If anybody can do it, though, that would be Japa.

    Nah, that wouldn't be the way to do it.

    What I'd do is have the VQ engine poll a DFHack plugin for terrain data, and do its own terrain gen based on that. For an example of something I made that does that, see Isoworld, which makes an isometric sattelite view of wherever you go in adventure mode.
  • Japa said:



    Nah, that wouldn't be the way to do it.

    What I'd do is have the VQ engine poll a DFHack plugin for terrain data, and do its own terrain gen based on that. For an example of something I made that does that, see Isoworld, which makes an isometric sattelite view of wherever you go in adventure mode.

    Cool, I love those DF visualizers. :)

    The map is laid out on a 3D array/grid - these are the so-called "macro chunks" that are 8x8x4 meters in size (which seems big, but you want it big enough so that you can have an entire room/hallway in one of these chunks, and have high (12 foot / 4 meter) ceilings, and have roads where a large vehicle (i.e. carriage) could pass another similar vehicle. These chunks are mainly created to isolate larger entities on the world for AI tasks like pathfinding, and can contain as much complexity within them as you want (furniture, additional walls, etc). You can abstract this map any way you want, including drawing a traditional 2D diagram of the current level, or "onion skinning" that so you can see faded versions of levels below you. And of course since you can render at any voxel density, you can just render a really rough version to create an overworld map (say, at 32 voxels per meter, as opposed to the default 128, which is a 64x speedup in that calculation (4x4x4)).

  • Yeah, that's about what I was expecting. DF uses pretty much the same system, but the size is different (2x2x3 instead of 8x8x4) so I'd end up just changing the chunks to match the tiles that DF uses.
  • Hmm. One of the knocks I've heard regarding terrain generators is that they tend to have trouble with overhangs... but from the image above, that doesn't seem to be the case here!

    Is the generator here an additive one, where you're sticking new voxels onto existing ones, or a subtractive one in which you start with a big solid and then remove bits (like sculpting)? Or some combination of those, or something else entirely?
  • Ummmmm... Hmm. Okay, let me start by explaining that most terrain generators deal not with voxels, but with polygons. These are exceedingly simple to work with because what you start with is a net of triangles:
    image
    Then, you simply raise/lower the intersecting points between them to make the terrain as hilly as you like - but they're only allowed to move on the z-axis; i.e. up and down. This is actually how the great majority of all games work. It's simple, efficient, and easily textured, but doesn't allow for overhangs unless you put an overhang "object" on the terrain - i.e. a model designed specifically to match with the surrounding area and make it look like there's an overhang.

    With voxels, it's different. Imagine a grid of cubes, with several layers of cube-grids on top of it. Or, better, as you're a programmer: imagine a three-dimensional array of booleans:

    boolean terrainExists[][][] = new boolean[100][100][100];

    That's a cube of 1,000,000 total pieces of data, and each can be either a 1 or a 0. Imagine now that each 1 or a 0 represents whether a cube of terrain exists in that spot in gamespace. Using this, and smoothing, you can easily make a map of whatever shape you want - overhangs, arches, floating islands, et cetera - and all in a way that no polygon engine could ever manage.

    It's not really "adding" or "subtracting". The points simply either exist... or they don't. Voxels are "pixels" in 3d space. VOlume + piXELS = VOXELS.

    Now, of course, you can always add more data onto each terrain piece.

    int terrainType[][][] = new int [100][100][100];
    double damageTaken[][][] = new double [100][100][100];
    ArrayList spatterData = new ArrayList();

    And now you have spatter data, terrain types, and even hitpoints for every single cube of terrain. In a polygon engine you would have to "paint" terrain types onto the triangle mesh. Damage simply couldn't exist, as you can't destroy polygons without leaving holes in the terrain, and spatters would have to exist as mere x,y point data for you to place a blood spatter decal, perhaps with an extra number to indicate the sprite meant to be used. Things like this tend to fill up memory relatively quickly, which is why most games (if not all) have timers on their decals so that they'll eventually fade and not leak memory forever.

    There are some things voxels aren't as good for, though. For one, voxels tend to be CPU and memory hogs, while terrain comprised of polygons tend to be exceedingly fast and efficient, even if they can't hold the same amount of data or do overhangs. That's part of why we're only seeing voxel games begin to really emerge in the past five years - before that, the computers simply couldn't handle them that well.

    Finally, it's part of why everyone is so impressed with Gavan's engine. Gavan isn't simply doing this with hundreds, or even thousands, of voxels - he's doing it with billions, and keeping it at a decent framerate. This is cutting edge, more or less. This kind of thing puts games like Minecraft to shame (to be fair, though, Minecraft is horribly unoptimized and poorly written).


    As to how the terrain is generated, my guess is that he does this:

    1. I'm guessing he starts by slicing the plane of the world in half horizontally. Everything below gets solid voxels. Everything above is empty. Land and sky, but flat as a sheet of paper.
    2. I would assume then he takes that and adds noise to it, building onto certain areas and subtracting from others to make hills and dips in the terrain - at this point it would look like something a polygon-generated map.
    3. Then, I would assume he adds another layer of noise - this layer build directly onto the previous layer. With this layer, we start seeing shallow caves and overhangs, and the terrain becomes more mountainous overall.

    Finally, he could repeat step 3 as many times as he wished (and in the specific places he desired) to get the terrain to look however he wanted it to look. I wouldn't say or... it would be additive and subtractive. If he wanted (and I'm assuming he hasn't done this yet), he could create "caves" underground after step 2 by "digging out" areas of terrain.



    As to what Japa plans to do, he intends to hook the VQ engine directly to DFHack to access the [][][] voxel data in Dwarf Fortress, and use that to determine the shape of the terrain.
  • edited October 2014

    Hmm. One of the knocks I've heard regarding terrain generators is that they tend to have trouble with overhangs... but from the image above, that doesn't seem to be the case here!

    Is the generator here an additive one, where you're sticking new voxels onto existing ones, or a subtractive one in which you start with a big solid and then remove bits (like sculpting)? Or some combination of those, or something else entirely?

    Quick recap, there are 3 levels of voxels:

    Microvoxels: the smallest. Each voxel is the result of supersampling 1,8,64, or 512 (cubes of 1,2,4, and 8) voxels. In otherwords, the actual voxels that define objects are often smaller than a pixel.

    Mesovoxels: these are used for destruction and addition of voxels by the user. They are about 1/4 meter to a side by default (1/64 cubic meter).

    Macrovoxels: these are 8x8x4 meters in size. Big enough for most rooms, hallways, caves, 2-way streets, etc.

    The Macrovoxels make up the general shape of the terrain, but terrain can be edited down to the microvoxel level. Macrovoxels are used to make pathfinding fast and efficient. The are computed in a 3D array, which means that there is no limit to how you can arrange them: you can have overhangs, you can have floating islands, you name it.

    Microvoxels are not stored explicitly (but you can still fetch them easily by recomputing the generation function at a given point). In order to store all the microvoxels, you would need more harddrive space than what is used to store the entire internet.

    Mesovoxels are stored, but at a higher level on disk. Say a user clicks somewhere to destroy some terrain. Wherever they click, and the radius of destruction is stored. So, the user could click 1,000,000 times and it would be at most a few megabytes of data uncompressed. In memory, mesovoxels are stored explicitly, but only where the user has created or destroyed something.

    Macrovoxels are generated by math/logic, but changes to them are stored in a similar manner to Mesovoxels.

  • I do love good information. :) Thanks for the notes, sirs!
  • If I wanted to change the size of a macrovoxel, say by making it 2x2x3m, how much of the generation would have to be manually fixed, and how much would just adjust to the new size automatically?
  • Japa said:

    If I wanted to change the size of a macrovoxel, say by making it 2x2x3m, how much of the generation would have to be manually fixed, and how much would just adjust to the new size automatically?

    Most of it would be fixed automatically but there are many problems you would need to fix. The first one is board spacing on the walls of the Tudor-style buildings, so that boards line up correctly with corners, etc. Mostly little visual things like that.

  • Yeah, that wouldn't be a problem for me, since I wouldn't be able to use the buildings for what I want to do anyway. Mostly just want to keep the terrain because it's beautiful.
  • Related to terrain: Two questions.

    As you don't use textures, Gavan, what about blood spatters? Is there support already in there to change the color of areas of voxels as if you were using decals, or...?

    Second, I've seen lakes, but not rivers. Are there rivers? Are there waterfalls (in any form - doesn't necessarily have to be pretty)?
  • I absolutely love caves behind waterfalls. Just throwing that out there.
  • Even if waterfalls aren't supported by default, I'll sure as heck figure out a way to have them. Mostly because Iove making waterfalls in Dwarf Fortress.
  • Caves behind waterfalls is a great example of explorer-friendly design/content.
  • You have to be careful with caves behind waterfalls so they don't become cheesy. One thing I liked about Skyrim is that most of the caves didn't have waterfalls behind them, while a select few did.
  • Yeah, you can overdo it. (This doesn't stop me from getting disappointed everytime I see a caveless waterfall :P)
    In a broader sense, having secret tunnels and passages to find is fun and exciting, but you also want to have some clue as to where to search. This could be environmental, or it could be literal clues you find that you can use to locate the hidden spot. Both can be tricky to procedurally generate. If its an environmental clue, you need the generation to be able to identify the proper context, or otherwise add the clues. A waterfall should be a case that is easy to identify, and hence a prime candidate for random passages. convenient torches/rock patters, noticeable patterns on the wall, bookcases, suspicious dead ends, etc can indicate areas to search, and building in such features seems feasible. As far as clues go, treasure maps would be fairly easy to generate. This could be a rendering of the location, which will give the player something to keep an eye open for/remember, or it could be a path on a rendered map. For written clues, things get trickier. It depends on if the terrain generator has any high-level understanding of what it is doing. Does it know it built a mill here? Does it know this is an oasis?If high level features can be identified, then clues can be generated from them, using relative directions from a landmark (10ft west of the ancient pine), or a sequence of landmarks ("past the deadly swamp, into the mountains, through the dire caves, and underneath the hanging boulder)
  • One of the fun things in Ultima 7 is where you see a house is bigger on the outside than you can explore within. It gives you the hint that there's a secret wall, and a hidden lever somewhere. But yes, you can overdo these things.
  • Secret rooms like that may be /too/ obvious in voxel quest. In general, I think letting players spot that there is missing space and hence search there for secrets is good, I am not sure it will work in this case. Maybe it would, I haven't actually tried the game out, of course, so I may be picturing it wrong.
  • Talvieno said:

    Related to terrain: Two questions.

    As you don't use textures, Gavan, what about blood spatters? Is there support already in there to change the color of areas of voxels as if you were using decals, or...?

    Second, I've seen lakes, but not rivers. Are there rivers? Are there waterfalls (in any form - doesn't necessarily have to be pretty)?

    You can place a blood splatter volumetrically, but most likely it would be a screen-space effect and work with the particle fx system. They could be decals, but more likely will fit in with the fluid particles which are planned to be screen-space metaballs.

    Back in the day, in 2007, I coded an advertisement widget for the movie "30 Days of Night" (starring Josh Hartnett) that had a really awesome procedural blood effect that would drip blood wherever you moved your mouse cursor; unfortunately I can no longer find it anywhere.

    As for waterfalls, definitely something I want to get in. The basic overall fluid simulation will run at the macro-chunk level, so that it is easy to compute and update efficiently. This means it is easy to do things like reroute rivers, break dams, create floods, etc. The level of detail can be refined (even if faked) down to the micro voxel level - i.e. you put a crack in something and it starts leaking out fluid particles, which gradually fill up the nearest macro chunk. It is not going to be a perfectly realistic simulation, but then again doing that would be nearly impossible on current hardware.
Sign In or Register to comment.