Jump to content
  • Advertisement

c_olin

Member
  • Content Count

    341
  • Joined

  • Last visited

Community Reputation

197 Neutral

About c_olin

  • Rank
    Member
  1. c_olin

    Texturing large terrain

    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. http://publications....attlefield3.pdf [/quote] Thanks for the reply. This is a great read and may be relevant to my project.
  2. c_olin

    Texturing large terrain

    Thanks for the replies. 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. 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 here). 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. 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. c_olin

    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: Splat mapping - Textures that are detailed at ground level (about 1m x 1m) tile very obviously. Macro texture + detail textures - 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: Per-tile procedural on GPU (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. Outerra 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. 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 I-Novae). 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. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. c_olin

    How to handle update-rate?

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

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!