Jump to content
  • Advertisement

Outliner

Member
  • Content count

    47
  • Joined

  • Last visited

Community Reputation

3 Neutral

1 Follower

About Outliner

  • Rank
    Member

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Outliner

    Height map terrain + discontinuities

    This is why I was surprised to see so many suggestions related to raster images. Rasters are nothing but pixels. They are delightfully easy to make, but they never seemed like they would be enough. Naturally we'll make any level editing tools that the game requires, so we'll have stroke points if we want stroke points. The reason I allowed myself to consider the possibility of using raster-based solutions was because rasters are so much easier to edit. A stroke is easy to create initially by a simple gesture of a pen or mouse, but it gets fiddly if you want to modify it later, like extending it or erasing and replacing part of it. Now that it's clear that the simple raster is not enough, I will need to research user interface solutions to easy stroke editing. On the other hand, the simplest user interface would be to just let the user edit a raster and find a good library to extract stroke information from the raster. I'm afraid that the library would end up misinterpreting what the user was trying to draw, and the user would end up fighting with the library. No doubt that's true, but I'd be surprised if that sort of image processing is often used in game development. It is remarkably hard to find good information about those algorithms on the web. Even so, I think I'm starting to understand. I was confused because I kept focusing on the grid of squares and trying to triangulate each square based on the segments passing through it with complicated techniques like ear clipping. Now that I ignore the squares and look at each grid cell as being fundamentally a pair of triangles, the problem becomes triangulating a triangle when a segment passes through it, and we only ever need to worry about one segment passing through a triangle, because after the first segment passes through a triangle the triangle gets broken down into smaller triangles. Any future segments will pass through those smaller triangles. When it is just one triangle and one segment, there are really only 3 very simple cases to consider: A: One endpoint of the segment is inside the triangle. The triangle becomes 4 triangles centered around the endpoint (green) with the segment (blue) running between two of the triangles. Two new vertices are added: the endpoint and a vertex in the edge of the original triangle. Perhaps this is the triangle fan you were talking about and I just didn't understand until now. B: Both endpoints of the segment are in the triangle. We triangulate around the first endpoint (green) to split the existing triangle into 3 new triangles, then we determine which new triangle contains the second endpoint (red) and split that triangle around that endpoint. We just need a new vertex for each endpoint and a total of 5 new triangles. C: The segment passes through the triangle completely. We split the two edges that the segment passes through, turning the triangle into a smaller triangle and a quad, then split the quad into two triangles. We also need to consider edge cases where segments or endpoints land exactly on existing edges or vertices, but at that point we're just mopping up the details. The above three cases represent the bulk of the problem of splitting an existing mesh along arbitrary curves, and now it seems so easy.
  2. Outliner

    Height map terrain + discontinuities

    What exactly does "an actual stroke" mean? What sort of line is not an actual stroke? Based on context, I'm going to guess that a stroke is a 1-pixel-wide series of uniformly colored pixels so that for any pixel on the stroke there is a clear next pixel and previous pixel. In contrast, a non-stroke line would be the sort of line often produced by image editors where it is more than one pixel wide and where the color varies due to antialiasing along the edges of the line. Here's an image illustrating my idea of a stroke versus a non-stroke line: The curve on the left is a stroke and the curve on the right is not a stroke. Correct? I have also marked angles onto a few of the stroke pixels to illustrate my understanding of the angle squared algorithm. I'm guessing this means that a straight line through these points is measured as 0-degrees rather than 180-degrees. That way the angle increases as the bend in the line gets sharper, rather then decreasing. What is the accumulation trying to measure? I notice that fairly straight lines can have high accumulations while sharply bent lines can have much lower accumulations. Here is an illustration: The line on the left makes 45-degree bends when we measure pixel-by-pixel, but overall it is quite straight. This portion of the line has an accumulation of 16200, and that will just keep getting bigger as the line continues on its current straight path. In contrast, the bent line on the right has one 90-degree corner and all zeroes everywhere else, so its accumulation is 8100 and it will stay that low no matter how long it is. It feels like it would make more sense if we didn't square the angles, so the positive 45s would cancel the negative 45s. Another issue is in determining which pixel is the next pixel. For example, suppose we wanted 135-degree turn in the line. When we get to the corner there are apparently two pixels which might be considered the next pixel, as illustrated here: A similar issue arises when two lines cross each other. This problem should be easy enough to solve by implementing special cases which look ahead more than one pixel and are particularly programmed to recognize intersections and 135-degree corners, but I wonder if I'm on the right track and correctly understanding what you had in mind. On the contrary, searching suggests this is quite difficult or impossible. This may not have been mentioned specifically, but unlike the illustration I gave in the first post, an actual level in a game should be expected to have more than one curve. Here is a Stack Overflow question on this very topic: fitting multiple curves to set of points. No useful answers ever appeared. The usual content we get when searching for least-squares fitting is how to fit a function to given data, but we're not really looking for a function. We're looking to fit a set of curves to data, and algorithms to achieve that are much harder to come by. Hough Transform is a fascinating technique. I suspect that if I have to resort to Hough Transform it means that I'm doing something wrong, but if it's a technique that actually gets used in game development than perhaps I should try it. I would love to find a guide on using Hough Transform or similar processes to find lines in images and then turn those images into game level meshes.
  3. Outliner

    Height map terrain + discontinuities

    That search gives many results and most of them don't seem to be relevant. I'll take your word for it that useful results are in there, but perhaps an example of the sort of thing we're looking for would make it easier to spot the good results. It's a bit confusing that we're both building triangles and finding points within "the triangle". If we're talking about a whole fan of triangles, then which triangle is "the triangle"? From the sound of it, I'm guessing that we're building the triangle fan inside another larger triangle. Perhaps a picture is worth a thousand words. Is this the kind of thing we're talking about? The curve is in blue. "The triangle" is in black. The points we found by stepping along the curve are in red. The triangle fans are in gray. I needed more than one triangle fan, which makes me worry that I've got the wrong end of the stick here. Let's try another guess. When you say triangle fan, perhaps you mean a fan of triangles that is also in the shape of a triangle. So then we'd subdivide one of the edges of "the triangle" and connect the new vertices to the opposite corner of "the triangle," like this: Is that more like the triangle fan you're talking about? It ended up creating quite a few quads, so I divided them into triangles with light gray lines. We keep talking about raster images as if that were a real option. It would be quite a dream to create game levels out of raster images. The level-editing tools would simply be raster image editing tools, both easy to make and easy to use. Unfortunately in order to render 3D terrain we ultimately need line segments, not pixels. We cannot simply step along a curve made of pixels in a raster the way we can step along a parametric curve. Wouldn't we need some sort of vectorization process to guess the curve that the pixels are supposed to represent? Vectorization seems like more of an art than a science. Here's a link to the wikipedia page on image tracing just to be clear about what we're talking about. As far as I can tell, there's no way to reliably turn pixels into line segments without making a lot of guesses about what the person drawing the curve was aiming for, and that would lead to artifacts in the rendering of the terrain. Do you have a particular technique in mind? Or do you mean something else when talk about "working from an image"? This is a very appealing idea. Instead of creating margins of some solid color, we could fill the margin pixels with vectors pointing to the closest point on the barrier. That way when we check the pixel in the center of the moving object we get both the direction of the barrier and the distance to the barrier, so we can decide if the object is getting too close to the barrier based on the size of the object, and we have a normal vector to use for sliding along the barrier. Aside from trying to convert an image into a mesh, representing levels as images is a very appealing idea.
  4. Outliner

    Height map terrain + discontinuities

    What does that mean exactly? It's nice that the tool allows that, but it would be even nicer if we had access to that tool or the algorithm that it uses. How does it allow us to cut along any arbitrary line? Are we talking about using regular triangles to approximate arbitrary lines? Does the algorithm that it uses have a name? It's nice to know how old algorithms are, but it would be more useful to know the names of the algorithms so we can look them up and get details.
  5. Outliner

    Height map terrain + discontinuities

    This seems to be recommending something quite different from ear splitting. It looks more like a quadtree based implementation. At least that's what I think of first when I see the word "subdivide" and the image you provided. For example, I've created an illustration showing a single grid cell that has been subdivided by quadtree around a curve. The curve is in blue. The black lines are the new squares that have been inserted to subdivide the cell. The gray lines represent the special triangulation that we'd do to eliminate T-junctions. I've included additional subdivisions to make sure that no square is subdivided more than one level deeper than its neighbors so we only have to deal with a few possible types of T-junction. This raises a question: How far do we subdivide? The algorithm could subdivide forever and never exactly reach the curve. Even just trying to get close to the curve would seem to cause an explosion in the number of triangles in the mesh. Using diagonals across the corners of the squares helps, but even in the image you supplied it looks like jagged curve following a grid. I was planning to store the curves as line segments, but this seems to be suggesting we use a raster image exclusively. At least I've only ever heard of kernel operations being applied to rasters. Rasters are enticing in their simplicity, but I worry that we'd have no way to determine the slope of curve, and I was hoping to use the slope of the curve to implement the player sliding along walls. Perhaps the idea is to use the capsule collision shape to enable sliding even without any slope information for the walls. But in that case, wouldn't we want to avoid expanded margins? It seems the point of margins is so we can do collisions against just the centers of moving objects instead of having to worry about collision shapes, but we'll want to detect collisions before they reach the center of the object in order to do angle calculations. Here's an illustration: The blue curve is the wall. The black curve is the capsule collision shape that is colliding with the wall. The blue arrows show the direction from the center to the detected collisions. The red arrow is the direction the player is trying to move. The black arrow is the actual movement, perpendicular to the collision direction that's closest to the player's intended movement so we avoid going through the wall while still making progress in roughly the player's intended direction. Does this sound right? That seems to cover everything, but more details are always appreciated.
  6. Outliner

    Height map terrain + discontinuities

    Does that mean you'd go ahead with implementing the full unsimplified plan, ear clipping and all? All of this is sufficiently easy that there's no reason to look for an easier way?
  7. I want to create terrain that has sharply defined features, but still has the flexibility of a height map. Though a height map must be defined by a grid, I don't want to terrain to look like a grid. All my previous approaches to this problem tend to look like grids, so now I'm aiming to allow for completely arbitrary discontinuities in the height map. It should be possible to split a cell of the grid between two or more elevations and along curved boundaries. The discontinuities should be independent of the height map grid. Here is a hand-made illustration of the kind of terrain we're aiming for: On the left is a curve of discontinuity that has been drawn onto a height map grid. On the right is a rendering of height map terrain that has been split along the same discontinuity curve. Wherever a discontinuity is found, the terrain represents a difference in elevation by a vertical wall instead of the usual slope. The idea is to get an automated system for putting this sort of terrain into a game. I have considered allowing the discontinuities to be an unrestrained set of line segments with floating-point 2D vertices. We'd have total freedom to draw any discontinuities we could imagine, such as splitting a single grid cell into a dozen pieces. This introduces many complexities, such as forcing us to use procedural triangulation to determine how each cell should be rendered. Here is a link to a pdf guide to the Ear Clipping algorithm which we might use for this triangulation: Triangulation By Ear Clipping It also makes navigating the terrain tricky. At a minimum we need to determine if one of the player's moves would cross a discontinuity. That in itself is not too hard, but we wouldn't want the player to be stopped dead just by brushing a discontinuity. We want the player to slide along these barriers when appropriate, and the math behind doing that is not at all obvious. We also need a way for computer-controlled enemies to navigate this world, perhaps by automatically generating a navigation mesh. Perhaps the problem should be simplified by restricting the discontinuities in ways that have no significant impact on the resulting terrain. We don't particularly want a cell to be split into a dozen pieces, so maybe there should be a limit to how many discontinuities can pass through a single cell. We might be limited to certain vertices within each cell, such as a vertex on each corner, a vertex somewhere on each edge, and a 9th vertex floating somewhere in the interior of the cell. With that sort of restriction, triangulation should be greatly simplified. What sort of algorithms and approaches would you use to create this effect? Are there any other ways to simplify the problem?
  8. In the never ending quest to find something slightly better than a height map for terrain modelling, there is one obvious improvement: soften some of the jagged edges by splitting pixels along diagonals to cut off the 90-degree corners. A well-behaved height map has no need of such things because it is all smooth elevation changes that turn into beautiful meshes, but the moment your game design becomes more ambitious you start running into problems. For example, suppose you want a road on your landscape and so you give certain pixels a color to indicate they should be rendered with a road texture. That creates a sharp line between the road and the ground, and whenever the road curves you will get jagged pixelated edges. One alternative is to make the edges fuzzy so the two textures blur together, but that may not be a look you want. Sharp edges can also occur when there are breaks in the terrain, such as vertical cliffs. The edges of those cliffs are bound to pixelate even with a very fine resolution height map, but allowing the pixels to be split diagonally can remove the 90-degree corners that makes the pixelation so obvious. Unfortunately it is much easier to manipulate conventional raster images than it is to edit images with diagonally split pixels, since no existing image editing application supports that format. We need a special tool to draw the lines that will become the edges of cliffs in the height map, and a tool for marking the regions that will become things like roads. Drawing the lines is relatively simple, since we can just start from a mouse click and follow the mouse as it is dragged, marking each edge as we go. We have 8 directions to choose from and we can simply choose whichever direction is closest to the angle from the current point to the mouse cursor. Painting regions is far more complex, because it requires specialized rasterization algorithms that need to be custom designed and cannot be found directly on the internet. Even so, we can get inspiration from freely available rasterization algorithms such as: Midpoint Circle Algorithm on Wikipedia. That algorithm shows how to draw a circle without diagonal pixels, but we can simply create a diagonal pixel each time we take an x step. Unfortunately, drawing a circle isn't really our goal. What we need at minimum is to allow the mouse to drag a circle across the image and rasterize the resulting smear. Each movement of the mouse becomes a line segment and we need to fill the Minkowski sum of each line segment with the brush circle. It is difficult to find any references for solving this problem in normal rasterization, and still that would leave the problem of converting it into a diagonal pixel algorithm. My current line of thinking is that we should combine the circle-drawing algorithm with the line drawing algorithm and draw the smear to a pair of one-dimensional arrays, one representing the left side and containing the minimum x values, and one representing the right side and containing the maximum x values, with the arrays being indexed by y values. The concept is similar to what is being done in this algorithm from Stack Overflow: how to rasterize rotated rectangle (in 2d by setpixel) Assuming the line segment goes from A to B, we find the angle between A and B and imagine a line cut through the circle perpendicular to AB. One side of the circle will be drawn centered around A, and the other side of the circle will be drawn centered around B; we run the circle algorithm as normal and choose to center for each pixel just before the pixel is drawn based on its angle. Then we draw lines from ends of A's semicircle to the ends of B's semicircle. Once we have finished drawing to the left and right arrays, we can fill in the space between the two arrays by drawing horizontal lines from the left side to the right side. Is this over-complicating the problem? Has anyone seen anything like this before? Is there a better way to do any of these things?
  9. Lately I've been working on building up a game's terrain from grid-aligned pieces. We might call these pieces metatiles because each piece is made of a collection of grid tiles that work together to create a unified feature in the game world. The beauty of this approach is that it fits neatly within the grid of a height mapped terrain. The difficulty is determining how to maximize the flexibility of the system using very few metatiles. Not only does a metatile require time and effort to design and model, but having a vast library of metatiles to choose from would complicate the world editing process. In my experience, most complicated metatiles boil down to arrangements of a few fundamental types of pieces. My idea is to simplify the whole process by restricting the game to features built up out of these six metatiles, plus flips and rotations: The red lines represent the feature that is drawn through the grid cells, and the gray lines represent how the cell is triangulated around the feature. For example, the red line might represent a vertical cliff or the boundary between one area and another, like the edge of a road or the shore of some body of water. These pieces, plus the flexibility of a height map, should be enough to create a wide variety of game terrains. The question is how does one build build an easy-to-use editor around assembling such small metatiles? For example, you can build up a curve out of these pieces by starting at a point and dragging the mouse in the desired direction. The editor would automatically choose the piece that most closely matches the direction from the current point to the mouse cursor. We can preview the next piece and perhaps wait for a mouse click to accept it, then continue with yet another piece until the curve catches up with the mouse. If the next piece would overlap with an existing piece, we display the preview in an error color and refuse to place the piece. Has anyone ever seen a system like that? While the above seems technically sufficient, there are a few details that would make editing awkward without additional automation. For example, a road would usually tend to have two parallel edges, and manually creating two parallel edges along a curved road in a system like this would be tedious and tricky. There is also a question of UV-mapping and how the user would specify the UV-coordinates of things like cliff walls and road surfaces. Ideally UV-coordinates would be handled entirely automatically.
  10. Outliner

    Octagon-Square tiling for world map

    Good point. I'm not seriously concerned about the landscape having a realistic shape at the moment, but if we do end up using height maps then it might be nice to have erosion algorithms and so on to carve believable mountains. Right now I'd be happy to have vertical cliffs and blatantly unrealistic mountains, but my standards may rise in the future. I've been doing some work with graph paper to see how my metatiles may go, and my cliffs effectively end up being facade objects, except I'm planning to delete the terrain faces beneath the facade. I'm using a 7x7 subtile grid because the diagonal across 5 tiles is very close to exactly 7 which makes it easy to model roads and rivers the same width whether they are diagonal or axis aligned. The plan is to manually construct a text file that contains a list cliff metatile descriptions. Each description would contain the 7x7 collision array for each tile, and a list of 2D points and triangles relative to the subtile grid. The listed points will define the curve of the cliff through the subtile grid. Integer points will be translated to the corresponding subtile vertices, and fractional points will be bilinearly interpolated. The listed triangles will specify how to re-triangulate the terrain mesh around the specified curve, with triangles on the left side of the curve being listed separately from triangles on the right side of the curve, since one side or the other will need to be raised to the top of the cliff. We can cut a hole in the terrain mesh based on the collision arrays and then construct a mesh from the text file to neatly fill in the hole with a cliff. Other types of metatiles would be handled similarly, and the various metatiles would share many curves. For example, a curve used to define a cliff can also be used to define one side of a road metatile. This saves modelling effort and also allows a road to perfectly hug the edge of a cliff. I don't expect to be able to use a terrain object supplied by Unity. Considering how seriously I intend to carve up the terrain, it's surely easier to start from scratch. I don't have much of a plan for dealing with LOD, but we can at least use simplified meshes for the empty tiles in the distance, rather than rendering the entire 7x7 grid on every tile. It's not clear how we might simplify tiles that are in use by metatiles except by eliminating the metatiles. Unfortunately roads, rivers, and cliffs are exactly the sorts of details that we'd want to preserve when viewed from a distance. I would love to avoid doing terrain modelling in Blender. Imagine what would happen if I wanted to adjust the height map. I'd need to bring the modified height map into Blender again and start from scratch with push/pulling the vertices and creating the caves and so on. Making a large scale terrain by moving individual vertices in Blender feels like washing a car with a toothbrush. I have heard of this technique in several places. I have always dismissed it as impractical because you would need a special editor to manipulate such 3-way displacements. This approach doesn't seem to make modelling easier; it is just an alternative way to store the mesh you're trying to create without helping you to create it.
  11. Outliner

    Octagon-Square tiling for world map

    It is a RPG in the style of classic Final Fantasy where the player wanders around the world having menu-based encounters. To that end, there needs to be a world to explore, but there also needs to be barriers to block the player from going straight from A to B. Rivers and forests can play this role, but from the very first version of the design document I've been imagining cliffs. When I say cliffs I mean sharp changes in elevation that create vertical walls. This requires the terrain at the top of the cliff to have a much higher elevation than terrain at the bottom. Cliffs also serve as a location for cave entrances which would send the player to a dungeon/maze. Aside from facilitating cliffs, elevation serves no direct purpose in the game. Even so, there is a more nebulous goal that elevation might contribute to. It's important that the player be able to recognize the various locations in the game by sight. If everywhere looks the same then exploration would feel tedious and the game would fail to be fun. Variations in elevation may be an excellent tool to add distinctiveness to locations. I don't particularly want to displace ground to make rivers. That is just a technical trick to allow me to render rivers. Alternative approaches are welcome. Player-controlled terrain modification is not one of the goals for this game. It would be excellent to have the terrain change in pre-programmed ways as the game's story progresses, though that seems very ambitious when we're still struggling to render any terrain at all. This is exactly the case. Tiles seem like a regrettable compromise made only for the sake of level building, so I'm constantly looking for ways to make the tiles less visible to the player. The idea of building a level by fitting together pre-constructed pieces is very appealing for its efficiency and I'd gladly sacrifice life-like graphics for the sake of efficient level editing, but I don't actually want the tile-based look, especially if the tile-based look ends up making the various parts of the game world look the same. That is a very impressive tool. The most interesting parts for my purposes are the tools that generate roads and rivers from splines, because roads and rivers are important elements in my game design. There is no use for randomly generated terrain in this story-oriented RPG. A major challenge in any big project is deciding when to abandon your goals for the sake of the project. From the beginning I've wanted vertical cliffs to act as barriers and hold cave entrances. I also want roads that look like actual roads by having textures aligned with the direction of the road. These are things that a simple height map cannot do, but modelling the game terrain as a simple height map would be so easy and relieve all the struggle. Do I abandon sharp cliffs and directional roads for the sake of the simplicity and flexibility of height map terrain? If I instead go with a grid-based tile approach I can easily get directional roads and sharp cliffs, but the result is sacrificing all the subtlety and flexibility of height map terrain. Metatiles are a powerful compromise between the two, at the cost of being technically more complicated. The options are overwhelming. My current target is Unity. That also has prefabs, but as far as I can tell there's no way to make a prefab to do what metatiles must do. A prefab can contain some geometry, but it won't automatically manipulate a height map to create a river or flatten the ground beneath a road segment. The fact that two metatiles can share a single tile forces them to have a lot of subtlety that ordinary tiles don't have. Of course if we were just using ordinary tiles then prefabs would be ideal.
  12. Outliner

    Octagon-Square tiling for world map

    What about the way that the object modifies the underlying height map? A river has a bit of geometry for the water surface, but mostly it is a depression in the ground height map. In fact, it seems that everything would be manipulating the height map. Roads, beaches, cliffs, and whatever else are all intimately tied to the height map, and the height map is a grid just like your proposed subtile grid. If two objects were trying to modify the same height map vertex, that would cause problems. For example, if a road were along the edge of a river and they were close enough that the road was trying to flatten the same vertex that the river was trying to depress, nothing good would come of it. This might happen even if their geometries have no collision, unless we expand the collision geometry to either side to avoid this issue, but that would mean the objects block more space around them than necessary. It seems that the fact that we need to use height maps for rivers is almost forcing us to use subtile grid collision detection. On the other hand, I have some concerns over what tools I would use to create these metatile objects. Was this latest advice designed to help simplify the construction of metatiles? Since these objects are more than just geometries, it seems that Blender and kin are not options. I know of no way to make Blender aware of the game's height map grid, nor any way to export the relevant depression data. I should probably ask about that on a Blender forum. The more I think about how I'd construct metatiles, the more appealing it seems to design them with pencil and paper and import them into the map editor by hand.
  13. Outliner

    Octagon-Square tiling for world map

    I was hoping for a one-size-fits-all solution, but any solution is good enough. As I understand this solution, it means dividing the simple ground tile into a height map grid an depressing the vertices beneath the river. This might be done using the collision subtile grid and depressing the subtiles that are marked as being part of the river. Alternatively, river metatiles might have a special float array that stores how far the height map should be depressed at each vertex to allow for fine control and allow us to vary the resolution of the height map independently of the resolution of the subtiles. In contrast, roads would be handled entirely differently. We would force the height map to be exactly flat beneath the road, then have the road hover above the ground by a small distance to be sure that none of the ground pokes through. Other things that we'd want would also need to be handled in their own particular ways. For example, beaches are neither quite like roads nor quite like rivers. They slope down toward a body of water, so they're not flat enough to handle like a road, but they're also not depressed like a river. How could we be sure that the ground wouldn't interfere with a beach? I think I've figured out how to do cliffs. Naturally the metatile would includes a mesh for a vertical wall along the cliff and the metatile would raise the height map on one side to match the top of the wall. Then the metatile just needs to cover the gap between the top of the wall and the ground by including hand-crafted polygons that precisely connect the top of the wall to the height map vertices. The map editor for this game is going to be more complicated than the game, but it's going to be worth it.
  14. Outliner

    Octagon-Square tiling for world map

    This is a more sophisticated technique than I am used to. Ordinarily when I think of 3D rendering I imagine a scene being built out of pieces as if they exist in a real 3D space. My concern about drawing the simple ground and then the road isn't that it would be inefficient due to unnecessary drawing; my concern is that the simple ground would conflict with the road. The road might be raised above the ground slightly to avoid conflicts, but that would never work for a river which must be below the ground level by its nature, so layering both the ground and the river would hide the river completely. It occurs to me that there might be a way to render this with multiple passes. For example, we might render the ground first, then throw away the depth buffer, then render the road/river/whatever. That way something like a river could sink below the ground without being covered by the ground. Unfortunately that approach wouldn't work quite so simply because the ground is sometimes supposed to cover the river, such as when looking at the river from ground level so that the water is hidden by the river bank. I'm having a hard time picturing how this is supposed to be done.
  15. Outliner

    Octagon-Square tiling for world map

    I have created some illustrations to show what I mean. Imagine that the blue square above is one of the game's tiles. In green we have the wireframe of two roads that each come from a metatile. Since they are multi-tile objects, they pay no attention to the tile they are crossing over, and if the tile were left in this state the space between the roads would be an open void. This is the key point. How do we do this? Let's use another illustration to see what the tile might look like once we've put some ground in between the two roads. In red we see a mesh that neatly covers the void. Imagine that it is textured as bare ground. To be clear about the question, let's look at the ground mesh alone. This is the shape that is needed to fill the space between the two roads. It doesn't need to be exactly this mesh, but it needs to cover the same space and the vertices along its edges need to precisely match up with the vertices on the edges of the roads. Is this an asset that should be prepared in advance? Should it be somehow generated as needed? If it is prepared in advance, how would we lookup the necessary mesh for each tile? If we generate it as needed, what data structures and algorithms would you recommend to do the generation? Now that the challenge is hopefully clear, the proposed solution that I mentioned earlier can also be clear. I'm thinking of doing a grid-based mesh that fills in all the unoccupied subtiles. This requires that each metatile takes care of filling in every subtile that it touches, but that's no problem since metatiles never have to share a subtile with any other object.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!