Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Gnollrunner last won the day on May 18

Gnollrunner had the most liked content!

Community Reputation

336 Neutral


About Gnollrunner

  • Rank
    Advanced Member

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. Gnollrunner

    Fractals in games

    I think somewhat the opposite. The "clever" technology is an attempt to cut down on the huge processing and memory requirements while achieving a desired level of performance and capability. Brute force methods are rarely the best.
  2. Gnollrunner

    Fractals in games

    I'm kind of working on that now. I have my voxel planet generator but I'd like to put trees on it. I'm not going for ultra realistic trees, however I don't want blocky trees either. I'm targeting something like older game trees like you find in WoW. The problem with voxels is, to get something reasonably detailed you need a fairly high voxel density, much higher than you need for terrain. That takes a lot of memory. My solution is to build a tree in a more cylindrical shape and then apply an hour glass morph to it. where the roots fan out on the bottom and the branches on the top. There will also be a different kind of morph for pine like trees. Since I'm using prism voxels I think it's a little more suited to trees to begin with than cube voxels. The main goal is really to not have to place specific trees with a separate LOD system. I'm implementing a system that lets me use the same set of voxels as the terrain, but apply multiple sets of functions do them in addition to an optional morph. It will support the generation of up to 8 sets of meshes for the same set of voxels. Id like to be able to do a pretty dense jungle. Since the LOD is done on the voxel level it will also apply to the trees. The tree generation functions will of course have to incorporate the terrain functions in order to avoid placing trees on water and steep terrain. I'll also have to include some environment function over the planet to vary the type and density of trees. Anyway it's a work in progress...
  3. Gnollrunner

    DX11 3D smooth voxel terrain LOD on GPU

    I suppose something like a clipmap would be doable. But I don't think you would use an octree in that case. Notice the 2D mesh is fully populated as it has to be since we are dealing with height-mapped data with no holes. In 3D you do have unused spaces, however as you move you never know where the data will fall so again you have to have a fully populated set of voxels which makes using an octree pretty useless in the simple case. You could still use one and create and destroy voxels as needed but that kind of the defeats the simplicity of the whole algorithm. The other thing is, the data is not mesh vertexes but voxels corners, so ostensibly you would have to generate all new meshes every time you moved. However, since you typically aren't moving all that far, I can think of one cheat that might work where you simply move internal mesh data over by you snap value so only stuff near the edges of chunks needs to be regenerated. Regarding your comment on bottom up tree generation, I also found this to be the case. This is where the "ghost tree" thing comes in. I generate down the tree in a pre-phase using a lightweight structure, and on my way up I leave the the parts that I need (where I found geometry) and delete the rest. I later convert the new branches to the actual full tree format. The trick is to have fast allocation/deallocation. I use slab allocation with a free list so it's just a push or pop off the list and also it keeps stuff tight in memory for better caching. There are also some optimizations with this (other than the threading). For instance each node of the tree has a byte which says how far it's been down before, without finding geometry. If I need to search down the same branch to the distance or less again, I can quickly look at this byte and just eliminate the search if I've already done it and no geometry was found.
  4. Gnollrunner

    DX11 3D smooth voxel terrain LOD on GPU

    The thing is I'm targeting very large worlds with sub half meter triangle sizes. Even something like a matrix of values that are fed into a voxel algorithm would take up far too much disk space on a players system. I therefore generate everything from terrain functions at run-time as a player walks around. That all takes some CPU cycles. The FPS can't actually bog because it's in a separate thread that's using the "current" build of the world while the next build is being calculated in the background. Also ideally I should be able to do sub second world builds. However in some odd cases where the world build lags, I don't want the physics to be affected. So as I said I have a second voxel tree where leaf voxels only exist right around the player for physics. They can also be built ahead of ranged projectiles and stuff like that if necessary. The general idea is to only build terrain right ahead of any possible collisions so it's fast. For physics I don't care about voxel level transitions because it's all at one level so that simplifies things. I also don't actually need a mesh because I can access triangles in the tree directly. .....So yes physics is done in an entirely separate octree in the same thread that calculates collision. However since it uses the same functions it matches the graphics terrain at it's highest resolution. This whole system is really particular to my project. If you aren't using run-time procedural generation there are probably better ways (I'm sure there are better ways anyway :P) . For one you don't have all the terrain available for path-finding at any given time, which is a problem. However I thought of a cheating way of doing path-finding but I'll have to try it out when I get that far. I'm basically forced to do all this because I want to support several thousand large planets. That's why I was saying I'm not sure how much help I can be since my project is kind of odd.
  5. I'm not an artist, but I am a long time D&D player. I was just wondering if you had miniature rules in your game.
  6. Gnollrunner

    DX11 3D smooth voxel terrain LOD on GPU

    Almost. The root actually has 20 children, but this is simply because I'm using an extruded icosahedron to generate my top 20 prism voxels. After that it's a normal octree. If you're not doing planets there is no advantage in this. It's realy done to meet my requirements. a) I'm building voxels on a sphere. b) voxels have to be oriented the same way in relation to the surface of the sphere and c) I want voxel size to be as as consistent as possible over the sphere. These last two are so that similar terrain generated at any point on the planet will give similar mesh results. Also I'm going to try to do voxel morphing to generate reasonably realistic looking trees (i.e. not blocky) so the starting orientation is important. Well ..... with certain algorithms like marching cubes, you can't easily change voxel size (i.e. adjacent voxels can't easily have a different size). To take care of this you have to use something like the transvoxel algorithm. I'm using voxel tessellation. However you mentioned you use surface nets so I don't think that's a problem with that algorithm. The down side with that is you can end up with non-manifold geometry, which can't happen with marching cubes (or prisms in my case) For physics you can normally just use your smallest voxel size for calculation of meshes, so it's not a problem. However depending on what you are dong you may have other issues. For instance if you are using the same set of voxels for collision as you are for graphics, you can end up with some race conditions especially if a player is moving fast. In my case I'm generating everything from functions at run time and I use a completely separate set of voxels for physics to avoid that problem altogether. With the physics there is no LOD supported, and geometry is regenerated just around the player. I actually don't even build meshes for physics. Since the geometry is already generated in an octree I just use it as it is. That's one other advantage of algorithms that keep geometry confined to a single voxel.
  7. Gnollrunner

    DX11 3D smooth voxel terrain LOD on GPU

    I basically calculate the distance from a chunk to the player and base it's resolution on the square of that. I guess it's like spheres around the player. However it's a bit more involved because my entire voxel area is an octree (or 20 rather since I build around an icosahedron since I'm doing planets) so what I'm really doing is going down the octree and applying certain rules for splitting, merging, growing and shrinking chunks. The chunks themselves are just pointers to points in the octree. I had some code for simplification but it's disabled right now because I want to keep the collision meshes which are only generated at max LOD the same as the view meshes and there were some issues at chunk borders. I'll probably try to enable it later when I get those issues ironed out but it's lower priority for me, since I'm working on other stuff.
  8. Gnollrunner

    DX11 3D smooth voxel terrain LOD on GPU

    I'm not sure how much help I can be here. I think my approach is WAY different. For one I'm doing almost everything except the graphics on the CPU. I do have chunks of voxels however my chunks change size along with the voxel size, so the number of voxels in a chunk stays roughly the same. I say roughly because a chunk is actually an octree so everything depends on the data. In any case that's basically how the LOD is done. It just generates meshes on bigger voxels for chunks that are farther away from the camera. As for the mesh format, I use an edged format. Faces point to edges and edges point to vertexes. There are also back pointers from edges to faces which lets me loop around vertexes to generate normals. My general impression is most LOD with voxel generated smooth terrain is done similarly, by changing voxel sizes. I'm not 100% sure on that, but it does seem to be the easiest way to me, given that voxels can generate some fairly complex shapes. The only tricky part is that you have to do level transitions. However I think the surface nets handles that OK so it shouldn't be too bad. I'm using marching prisms so I have to do some extra work for the transitions. I'm not really targeting editing at this time however it should be just a matter of changing values at voxel corners. As for threading, in my case it's closely tied to the way I generate stuff. I don't think it's really relevant to GPU generated meshes but I'll give a brief description. I have something called a ghost tree. which is a light weight octree that represents part of a voxel trees. The ghost trees are generated in threads, are independent of each other and are used to extend leaves of chunk trees as things change. Since I'm using fractal generated voxel data, I put all my fractal routines in these threads. I played around with threading a bit and the fastest way that I've found so far is to have a thread pool where threads are blocked until needed. This gets rid of the thread creation, deletion problem and also gives you and easy way to control the maximum number of threads allowed. I have one special thread that's a dispatcher that gets commands from the main thread and sends them the threads in the pool. Once a ghost tree is finished, it's then converted to voxels in the main thread. I may try to thread this part too later but it's a little more tricky since that part would involve special threading constructs like mutexes and atomics. Also I find that most the processing is done in determining how to build your voxels and not the actual voxel building itself so I'm not sure how much I would gain by that. Finally for collision I have a separate tree that just generates mesh data right around the player that matches the graphics data. I call it a JIT (Just in time) mesh. The reason I'm doing it this way is to avoid any race conditions as a player moves around. This way it's impossible for an avatar to beat collision mesh generation. Anyway I don't know if that helps, but good luck.
  9. Gnollrunner

    Need to figure out a formula

    I can see the patterns. However may I ask if this is homework?
  10. I'm using kind of a chunk system. It's splits or merges chunks as you move around and also splits or merges all triangles in the those chunks to match. A chunk is considered some point in the overall tree and everything under it. Each node in the tree has a bounding volume and as you go down the tree it calculates at what level a chunk should be, based on the square of the distance from the bounding volume to the camera. Then there are rules...... For instance if you reach a point in the tree that should be the top of a chunk and it is in fact a chunk top, then you don't have to go further. If you reach a point where there is a chunk top but the chunk top should be further down in the tree based on the distance calculation, then you have to split the chunk into multiple chunks. Conversely if you reach a point where there should be a chunk top but you haven't encountered one yet on your way down the tree, you have to merge all chunks below that point into a new chunk that you create at that point in the tree. This way if you just move the camera just a little and nothing has changed, you only have to go down to the top of each chunk and not to each triangle within the chunk. You can see it in action in the first part of the video in my last blog entry. The system also works for voxels using an octree, but this one uses a quad-tree since it's dealing with height-mapped terrain albeit wrapped around a sphere. It's really just flat terrain here because it's a sun, but it would work for other terrain too.
  11. I don't really care about the odd comments. However I do find that some people (usually when they are anonymous) get a bit hostile if you're not using an off the shelf engine. I really don't get why. I mean what's with the "you'll fail" comments and down voting because you're doing something differently from others? I'm not really talking about gamedev.net, mostly reddit. In any case, I try to be supportive of people using Unity or UE4. IMO "roll your own" and "off the shelf" are both valid choices.
  12. Yes, I looked into that myself and decided to stick to full sized indexes. The problem is the meshes are based on 3D chunks. The chunks are constantly resized since voxels constantly subdivide and re-merge, so the voxel library tries to keep a very roughly constant number of voxels per chunk. In common usage I should be able to set the chunk size such that 16 bit indices would work. However for odd cases with a lot of vertical geometry I could easily over break 65536 indexes, which means I'd have to support more meshes per chunk. Sticking with 32 bit indexes just seemed easier. I guess what I'm asking is, are there any in-obvious yet known downsides to having large mesh sizes. I'm aware of things like frustum culling and sorting of meshes from front to back to minimize wasted calls to the shaders. However that should by taken care of by the current chunks system. But is there anything else I should worry about, when generating large meshes? Like would there be anything inherently wrong with having a 200K vertexes in a mesh?
  13. I've decided to add multiple data set capability to my planetary voxel library. This is a smooth voxel system using extended marching algorithms. It will allow for up to 8 different data sets using the same set of voxels. This is so I can support things like trees and buildings more easily using voxels+morphing+functions, instead of having to construct and load discrete assets, with their own LOD and so forth. As it stands I have chunks of voxels and each chunk typically generates a border and a center mesh so that the border can change to match neighboring chunks if they change. However now since I will support 8 data sets, It could generate a maximum of 16 meshes per voxel chunk. What I'm wondering is if there is a maximum optimal mesh size. I read years ago in some book that terrain mesh sizes should be a about 6K triangles max, but I'm sure things have changed since then. What I was thinking of doing is sill having just 2 meshes per chunk, and then adding an extra vertex parameter that tells the shaders which data set a vertex belongs to, so the right shader routine can be selected. This seems like it would generate a lot less draw calls at the expense of possibly very large meshes. Do large meshes really matter any more? I'm guessing having less calls is more important.
  14. Gnollrunner

    DX11 Vertex buffer as double3 for position

    Yeah most likely. I think it's basically the hardware that's the bottleneck. If this is just something for your personal use, it might be OK. However if you plan to release it for general consumption, it's probably sub-optimal to use 64 bit on the GPU if you can avoid it.
  15. Gnollrunner

    DX11 Vertex buffer as double3 for position

    I won't say it's impossible to use doubles on the GPU but it's generally not advised. I don't think there is a DXGI_FORMAT for it. I remember reading somewhere that you can pass them in as 2 32 bit numbers, but don't quote me on that. In any case I think your performance may be very bad even if you get it to work. On the CPU 64 bit floats are no problem, but a lot of GPUs don't really handle them well. What do you need them for? There are some tricks to handle GPU range/precision issues that don't involve 64 bit floats. Perhaps it would be better to use one of those. What I do is set up my transformations to transform the world around the camera, which is always at the origin. Then you just need a good LOD system. You can still use 64 bits on the CPU side and just convert them when passing them down. I think there are some other hacks too if you look into it.
  • 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!