• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

197 Neutral

About c_olin

  • Rank
  1. Texturing large terrain

    [quote name='Pottuvoi' timestamp='1342553391' post='4960140'] [quote name='colinhect' timestamp='1342549792' post='4960099'] After a quick skim this seems like a similar idea as mega texturing. The problem is that I can't have a large virtual texture because it would be too large to hand-paint/generate and store on disk. This is why I'm looking more at procedural splatting methods. [/quote] Mega/virtual texturing doesn't mean that everything must be hand painted. You just create the data in whatever way you want instead of just loading it off disk. (splatting, procedural textures, baking GI data just in time.. etc.) Battlefield 3 used splatting with virtual texturing quite nicely. [url="http://publications.dice.se/attachments/GDC12_Terrain_in_Battlefield3.pdf"]http://publications....attlefield3.pdf[/url] [/quote] Thanks for the reply. This is a great read and may be relevant to my project.
  2. Texturing large terrain

    Thanks for the replies. [quote name='UltimaX' timestamp='1342546768' post='4960080'] Google: Texture Mipmap Quadtree You may find this to be a good read: [url="http://www.realityprime.com/articles/how-google-earth-really-works"]http://www.realityprime.com/articles/how-google-earth-really-works[/url] [/quote] After a quick skim this seems like a similar idea as mega texturing. The problem is that I can't have a large virtual texture because it would be too large to hand-paint/generate and store on disk. This is why I'm looking more at procedural splatting methods. [quote name='TMKCodes' timestamp='1342546778' post='4960081'] Why do you need to texture the terrain, you could just color it according to something like vertex height from sea level. You could also add some modifiers like this area is dirt and this grass. Then you place all your rocks, grass, pushes, trees on top of the terrain. Though i am not sure how it would look, because i have not implemented large terrain like that yet, but been playing with the idea quite much in my head and done quite much calculations, but realized that I can not create map of earth at 1 x 1 meter triangle resolution, even if the client would not need to load all of it at once, but the server would. [/quote] This would not be acceptable. I could have much better results by just selecting the texture in a pixel shader based on height/slope with some added noise (see [url="http://www.gamedev.net/blog/73/entry-1692117-terrain-texturing-explained/"]here[/url]). But that method isn't desirable because the textures will still tile noticeably and the sharp edges between textures doesn't look very good. Also, there is noticeable popping between terrain LOD levels. [quote name='TMKCodes' timestamp='1342546778' post='4960081'] Anyway at that scale you will run out of memory quite fast if you want to texture the whole terrain at once. [/quote] I'm not looking to have a unique pixel for every centimeter of the map. I'm looking for some sort of procedural technique of texturing the terrain in a way that tiling is not obvious and can look good from near and far.
  3. Texturing large terrain

    Thanks for the input. The main advantage of megatextures is that you can keep a small portion of a very large virtual texture on the GPU at a given time. While this would solve the tiling issues it would be nearly impossible to hand-paint 65km x 65km at a decent resolution. And if it wasn't hand-painted then it might as well be procedural per-tile on the GPU at runtime (no disk-space usage). To have 1 pixel per ~0.4 cm (decent texture resolution) would be 768 terabytes as 24bit uncompressed. So I don't think megatextures would work on this scale.
  4. I am rendering large terrain (65km x 65km) at 8m height resolution and 1m triangle resolution by sampling height with bi-cubic interpolation. I've been experimenting but having trouble finding a decent method of texturing. The texturing needs to be detailed at ground level and look good from far away as well (no view distance culling, entire terrain is visible). Methods that I've tried but look bad: [b]Splat mapping[/b] - Textures that are detailed at ground level (about 1m x 1m) tile very obviously. [b]Macro texture + detail textures[/b] - Can't really afford to have a decent resolution macro texture for the entire terrain. Looks good from far away but gets pretty bad as you get close. Methods that look nice but not technically possible for me: [b]Per-tile procedural on GPU[/b] (see Outerra) - Can't afford the render-to-texture overhead for when terrain tiles are split. Currently I'm leaning toward trying a larger scale splat map (say 1024m x 1024m textures) to avoid tiling and add detail textures on that. However, I don't really like the look of a stretched macro texture with a detail texture on it (looks very dated). Are there any techniques that I haven't considered? I don't need fine control over textures so procedural approaches are fine. But it will need to include dirt/grass/sand/rock based on slope/altitude. All ideas are welcome.
  5. [quote name='lawrencemann' timestamp='1334047266' post='4929816'] However, I was thinking that the output from tectonic generator could be used as a template for fractal generator. E.g. take a 128*128 map, scale it by 4 and fill 75% of the map with such fractals that they preserve the original 25% of the heightmap data ("corner points"). This might result in very detailed maps that have quite realistic landforms very fast. But, i haven't tried it out yet. Should'nt be too difficult to do. If there's interest, I might try to find time to do it and tell you how it turned out. [/quote] [url="http://www.outerra.com/"]Outerra[/url] renders an entire planet using real-world elevation data for low-resolution and fills in details using fractal algorithms. I believe they are interested in eventually supporting completely procedural planets as well. The low-resolution data could easily be generated using an algorithm similar to yours to provide more realistic continent-level terrain while still providing details via fractals. In fact, I'm sure this would generate some interest by the Outera devs and community if you were to post this in their forums.
  6. [quote name='lawrencemann' timestamp='1333978893' post='4929549'] It seems to me like even the most naïve model of plate tectonics is able to produce more convincing heightmaps than conventional fractal based methods. That's why I'm really wondering why it's not used in more projects? [/quote] Fractal-based methods are often used because it is fast enough to be computed on the fly for procedural terrain (see Minecraft). For extremely large scale terrain you simply can't have all of the terrain in memory (see [url="http://www.inovaestudios.com/"]I-Novae[/url]). This is the main reason why fractal-based methods will continue to be very popular. Your work looks awesome. I don't have time to read your thesis though. Do you have any rough numbers on how long it takes to simulate and what resolution height-maps it can run in reasonable time?
  7. [quote name='Ripiz' timestamp='1333606293' post='4928394'] C++ isn't that hard. You just have to remember if you wrote [i]new[/i] you have to write [i]delete[/i] somewhere. [/quote] It isn't quite that simple.
  8. [quote name='alvaro' timestamp='1332873328' post='4925764'] [quote name='colinhect' timestamp='1332868008' post='4925740'] [source lang="cpp"] typedef std::vector<std::vector<Tile>> Chunk; std::map<const Point, Chunk> [/source] [/quote] Why the `const'? What does it even mean in this context? [/quote] Perhaps I meant to make the Chunk const. There is no reason to have the key const.
  9. In general std::vector is normally the right container for the job. However, without more details about how you will be using it is difficult to tell. Assuming you break up your map into chunks and chunks are loaded/generated on the fly I would start with something like. [source lang="cpp"] typedef std::vector<std::vector<Tile>> Chunk; std::map<const Point, Chunk> [/source] Of course you will want to have the implementation details of the map abstracted away. So I wouldn't spend too much time thinking about it and implement it as simple as possible and if there are performance/memory problems then investigate if your choice of container is at fault.
  10. [quote name='Zael' timestamp='1331138723' post='4920105'] [quote name='bullfrog' timestamp='1331105853' post='4920003'] //Convert bytes to megabytes g_uiTotalClusterMemory /= 1024; g_uiTotalClusterMemory /= 1024; g_uiTotalCubeMemory /= 1024; g_uiTotalCubeMemory /= 1024; [/quote] Um... you are converting bytes to kilobytes here. To convert to megabytes you need another division by 1024. [/quote] He is dividing by 1024 twice. Just on two separate lines for each value.
  11. Based on your last post it sounds like you might be loading resources manually as different parts of your code needs them. I would recommend you look into writing a centralized resource cache to abstract away the IO details (and error handling). Here is an example of how mine works: [source lang="cpp"] ResourceCache resourceCache("Data.zip"); shared_ptr<mesh> someMesh = resourceCache.get<mesh>("Test.mesh"); shared_ptr<mesh> someMeshAgain = resourceCache.get<mesh>("Test.mesh"); // The mesh is not loaded again. A pointer to the cached mesh is returned. shared_ptr<textuer> someTexture = resourceCache.get<texture>("DoesNotExist.png"); // The texture does not exist. A pointer to the default texture is returned. [/source] Notice how no exception handling is needed when retrieving resources. And with the raw IO abstracted away the code doesn't care if the files are on the filesystem, in a zip file, over a network, etc... Since the IO is abstract you can also have resources existing in different sources. For example, you can have core resources built with the executable so that they will not fail to load unless someone messes with the executable.
  12. [quote name='Waterlimon' timestamp='1328624848' post='4910504'] For the destructor call, maybe it detects that you are not going to use the variable anymore, and thus destroys it before reaching the end of the block. [/quote] The compiler can do that? Doesn't that essentially break RAII? For example, how could std::scope_lock work if the compiler could do this?
  13. I'm not quite sure what you are asking. What do you mean by impact? In general I follow these guidelines: * Use shared_ptr when ownership is shared (don't pass shared_ptrs around unless you really are sharing ownership rather than temporary access). * Use unique_ptr when there is a single owner. * Favor const references over pointers. * Only allocate on heap when necessary.
  14. The separation of tasks that you describe doesn't sound like a good candidate for multithreading to me. In general, separating persistent things like UI logic, game logic, rendering, etc ends up not gaining much from multithreading and makes coding/debugging it much more difficult. Threads are more useful (and manageable) for things like asynchronous resource loading or short term parallel computation (updating unrelated entity components simultaneously or a parallel algorithm for frustum culling, etc). In my opinion the concept of tasks is a bit redundant since you will naturally separate things like entity logic, inventory management, and interface logic into separate modules anyway. To formalize them into tasks would not give you anything you didn't already have.
  15. How to handle update-rate?

    Use a fixed timestep. Explained here: [url="http://gafferongames.com/game-physics/fix-your-timestep/"]http://gafferongames.com/game-physics/fix-your-timestep/[/url] This will decouple rendering framerate from the logic update rate.
  • Advertisement