Jump to content
Site Stability Read more... ×
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About MasterReDWinD

  • Rank

Personal Information

  • Role
    Amateur / Hobbyist
  • Interests

Recent Profile Visitors

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

  1. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    Thanks, I'll be sure to investigate this.
  2. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    I don't think I've seen anything on Surface Nets but it came up a lot regarding Dual Contouring. In examples I've seen the non-manifold sections usually look like hourglass shapes where two parts of a surface converge at the same vertex. This link (https://www.boristhebrave.com/2018/04/15/dual-contouring-tutorial/) describes it a little under the 'Manifolds' section. There is also a paper for Manifold DC (https://web.archive.org/web/20161020191119/http://faculty.cs.tamu.edu/schaefer/research/dualsimp_tvcg.pdf). As Surface Nets and DC only really differ in how they position the vertex inside the cell it might be possible to use the same solution.
  3. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    Thanks for the extra detail, it's helping me to foresee future issues. I'd like to pursue the clipmap idea if it can be made to work for 3D terrain rather than just heightmaps. I believe Miguel on the Procworld blog managed to achieve this somehow. Generating 'spheres' of chunks of terrain around the player that halve in sampling resolution with each sphere but double in size to take advantage of the perspective projection. I think I'll need to move to an octree structure to progress. I did explore this route before (on the CPU) but I found that I needed to generate the octree from the bottom up, with leaf nodes representing a single voxel. Collapsing the leaf nodes into single parent nodes one level up proved tricky, along with the (Dual Contouring at the time) triangulation. Ideally I'd like to do all the LOD on the GPU where my noise and meshes are generated. That's a great point, thanks. I had planned to look into procedural animation later on.
  4. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    You had it right, that's the situation I'm after LOD wise. I hadn't thought far ahead enough to realise that it would cause problems like that with the physics. It sounds like fixing that would require keeping the physics mesh at a constant downsampling rate across all chunks? I might come back to you on that pathfinding algorithm when I get a bit further along. Ah, yes, I've looked into the Transvoxel algorithm and some 'stitching'/'skirt' techniques. So you generate and store the geometry around the player in a separate octree and use that for player physics?
  5. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    So your approach is to have one global octree for your whole world and then chunks are octrees inside that? Are the LOD issues at the chunk borders similar to the issues Joe is describing below? So far I only have Unity physics, which depend on me creating the Unity collision mesh. It does sound like I would run into the issues you're talking about on chunk boundaries, as I plan to have terrain which has lots of verticality. I'm not quite following you on this sentence 'Having chunks of constant detail and downloading those nearby dynamic objects sounds more robust and practical.' Do you mind expanding on it a bit? If I could get the pathfinding running on the GPU and cut out sending back the mesh for physics that would give me a massive performance boost (in theory). The downside would be the complexity of having to deal with all the physics responses. I've looked into this a bit and I gather it would begin with me implementing my own GPU ray casting system. I'll definitely look into the Diffusion approach you mentioned. I found this post from @spacerat . I'll look at it along with the link you posted earlier. The multiple choice method is essentially quadric mesh simplification but with only a small number of edge checks per round, rather than evaluating them all. Perhaps you're right though, if I can avoid using the half-edge format it would really simplify the simplification ;).
  6. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    Thanks for jumping in on this. I saw a discussion about doubling the size of the chunk at the same time as halving the sampling resolution of the density grid (downsampling). Is that what you're describing here? The benefit of this is supposed to be that the total number of meshes rendered is reduced? My chunks are all the same size at the moment. I have a chunk pool and then use a dictionary to store/load them based on distance from the player. Are you using something like the clipmap approach with increasingly sized rings around the player? Are you running any simplification on your meshes? I had planned to have a thread pool for chunk generation but unfortunately in Unity only the main thread can run Unity rendering related code, which includes Compute shaders. There is a way to run Compute shader dispatches asynchronously which I'm part way through implementing. It's not ideal though. I've read about having a small collision mesh only around the player (and other moving objects). It sounds like a very promising idea, rather than my current setup of the collision mesh being the surface mesh. So your player mesh is just a small subset of the surface mesh recreated from an octree as a separate step? Are there any caveats with this that I should know about?
  7. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    Thanks for that clarification. The illustration and the numbers really help, there isn't much up to date performance data around. If I did opt for the simplification route I was hoping to run it on the GPU, in either the same or another Compute Shader, so as to have less data to read back to the CPU. As you say I think reading back the mesh from the GPU and then running simplification on the CPU wouldn't be good for my performance. I've come across that link but haven't had a good read of it yet, I do know it avoids sorting and use of a priority queue, both performance killers from the reading I've done. I'll investigate that one more. I'm aware that quadric error metrics are essentially the gold standard in determining the suitability of a particular edge collapse. I also found this algorithm that I really like the sound of http://citeseerx.ist.psu.edu/viewdoc/download?doi= That's what lead me to the question of how to get the initial required half-edge mesh. When you say precalculate the simplification you're referring to storing different LOD versions of the meshes and loading them on demand? Downscaling is what I had in mind as a starting point for the Geometry Clipmap route. If I understand the downscaling idea correctly the simplest approach would be to sample my density grid at every 2nd point (on each axis) rather than every point, so in my case I would reduce the size of the mesh by a factor of 8 on the first past? Then on the second pass I would sample every fourth density value.
  8. MasterReDWinD

    DX11 3D smooth voxel terrain LOD on GPU

    Thanks for the reply and for the link, it looks like it touches on some new things that I hadn't seen before. Were you generating the mesh from scratch or converting one that you already had? You mentioned full mesh editing. That is something I am also targetting. It probably makes much more sense to get the mesh out of Surface Nets in half-edge format to begin with, then I had just make the edits following the half-edge rules. I think that is what you are doing? How did you find the performance in your case? Thanks for your reply. The collision data will be used for pathfinding and probably for some movable objects/projectiles. What was your idea involving sdf's? The meshes are generated at runtime and will need to be recreated if the user edits them.
  9. Hi, I currently have Naive Surface Nets working in a Compute Shader and I'm using a Dictionary to load chunks around the player. Retrieving meshes from the Compute Shader back to the CPU and creating Unity collision meshes is causing a lot of stalling. I've decided to tackle this by implementing a LOD system. I've found the 0fps articles on simplifying isosurfaces to be a weath of information. After studying those and looking at the papers I've identified what I think are the two main directions for approaching LOD: Mesh Simplification and Geometry Clipmaps. I am aiming to get one or both of these working in a Compute Shader. This brings me to my questions: 1) I've seen a lot of feedback that Mesh Simplification is going to be too slow for realtime terrain editing, is there a consensus on this? Most algorithms appear to use the half-edge format but I can't find any information on efficiently converting an indexed mesh into half-edge mesh format. Can anyone provide an example? 2) Can the Geometry Clipmap approach work with 3D terrain as opposed to heightmaps? Would I need to store my chunks in Octrees to make it work? Are there any GPU implementation examples that don't work on heightmaps? Any advice to help me further focus my research would be much appreciated. Thanks.
  • Advertisement

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!