• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Str3jda

Voxel terrain move

7 posts in this topic

Hi,

 

I know there's already plenty of tutorials how to implement voxel terrain, but afaik none of them properly explains how to update lods during camera movement. If anything, they only tell about octree and thats it. But how? If I were to have each lod as depth level in this octree, how do I avoid having low-res lod rendered at camera position? Or am I missing something? I wonder if there's some simple solution.

 

I'm already able to render terrain quite nicely, but before I get into "transition cells", I'd like to tackle with this first and I can't seem to find any usable resource on this topic:(

 

Thanks

1

Share this post


Link to post
Share on other sites
I'll be watching this post. I want to know the same thing. I have some ideas, but emplementing them just to find out they are wrong would be a waste of my time. *here's me hoping someone will respond*
0

Share this post


Link to post
Share on other sites

Let's think about this.

 

Let's say you've got millions of voxels in your terrain environment. You realize that there's a performance issue with rendering them at a high level of detail, so you want to render the nearby voxels at a lower level of detail if they're far away from the camera. This is the gist of what we're trying to do. But we don't want to spend a huge amount of CPU time trying to figure out which level of detail we want to use for a voxel either! In the most brute force method for the algorithm, we'd calculate the distance from the camera position to the voxel position. If that distance exceeds a set threshold, you drop the LOD by one. However, if we used the brute force method, we'd be calculating the distance between the camera and all million voxels (which comes with an expensive square root) and any performance gains in switching to another LOD would be much lower. So, we want to keep the same idea for calculating distances with voxels, but try to use fewer distance computations.

Here's where Octrees come in handy, and that's why you are reading about them. You can divide your terrain into chunks of blocks, say, 16x16x16 (use powers of 2 if you can). Each chunk can be inserted into your octree. When you're going to calculate the camera distance, you could instead calculate the camera distance to the octree bounding regions and set the LOD of all contained objects to a preset value. This would help you reduce the number of distance checks, and would also scale very well with any number of game world objects (I assume you're going to have more than just terrain).

I don't know if its relevant to you or not, but there was a white paper a while back on rendering terrain using geomipmaps. The author had an interesting technique for deciding when to switch to a different LOD which was not based on camera distance, but rather on how much the terrain would pop if you transitioned it to a lower LOD (2.3.1). He basically measures the vertical change in "pop" between one LOD and another in screen space according to the camera viewing angle, and then switches the terrain LOD if the pop is below some acceptable threshold (ie, 2 pixels). I implemented a variation of this myself and I like the results.

 

Here is my code for that:

/// <summary>
/// This calculates the maximum amount of vertical error when switching from one level of detail to another.
/// </summary>
private void CalcError()
{
	for (int LoD = 0; LoD < 4; LoD++)
	{
		int stepSize = (int)Math.Pow(2, LoD + 1);
		float d_max = 0;

		//traverse horizontally
		for (int z = 0; z < m_settings.TileCount; z++)
		{
			for (int x = 0; x < m_settings.TileCount; x += stepSize)
			{
				Vector3 p0 = m_verts[x + (z * (m_settings.TileCount + 1))].Position;
				Vector3 p1 = m_verts[(x + (stepSize / 2)) + (z * (m_settings.TileCount + 1))].Position;
				Vector3 p2 = m_verts[x + stepSize + (z * (m_settings.TileCount + 1))].Position;

				Vector3 P = (p0 + p2) / 2.0f;        //the phantom position of p1 is just the average of P0 and P2
				float d = (p1 - P).Length();         //find the error difference between p1 and the phantom point
				if (d > d_max)
					d_max = d;
			}
		}
		m_max_dy[LoD + 1] = d_max;            //this is the most error we'd get if we switched from LODX -> LODX+1
	}
}

On screen and in the game, what ends up happening is that we try to use the lowest possible LOD we can get away with without getting unwanted popping artifacts. So, if you're pointing your camera straight down and you're viewing the terrain from above, the very bottom terrain chunk will be at a very low LOD, but you can't really tell since the vertical portions are not really coming into play based on your viewing angle.

2

Share this post


Link to post
Share on other sites

Ok, seems reasonable, but I'm not sure if it's applicable to my problem. I'd like my terrain to be infinite (to some reasonable extent), therefore I have to work only with camera position a viewing distance when building octree (which I presume have to rebuild every time I move enough). This wouldn't work that well with your approach I think:( 

 

I understand with static octree, deeper we get in the tree when rendering, smaller real world sized chunks are rendered as higher-res lod (I presume blocks 16x16x16 are local size, which scales up with lower-res lod right?)

 

Btw. geomipmaps seem interesting, I will definitely read the article and see If I can use it somehow;)

 

My initial idea was to somehow enhance geometry clipmaps, but making this algorithm work with voxels made my head hurt :( Maybe it's not possible, I don't know, it just seemed like exactly what I'd like to have.

0

Share this post


Link to post
Share on other sites

So, you're procedurally creating your terrain... I think you could still get away with using an octree. The benefits of being able to use a O(LogN) search algorithm are too high to discount it too readily. If the camera moves and you have to update the octree, you don't necessarily have to rebuild the whole entire tree. You just have to add in the new section of terrain which was created and remove the section of terrain which is no longer visible. This may be a bit unconventional, but it could be worked out. The idea is that the octree gets populated with the new chunks which are procedurally generated and it dumps the chunks which are no longer needed. You *could* even do this by reusing existing memory by recycling allocated tree branches (like memory pools), but that may add a bit too much complexity without enough of a performance pay off to be worth the effort.

 

The other big pay off with Octrees is that view frustum culling becomes very fast and easy.

 

I like that article you linked. I hadn't thought of storing LOD in various levels of the octree -- I'll have to think about that a bit more. I was storing LOD in the chunk itself and letting the chunk decide what LOD it should set itself to based on vertical error. Specifically, I'm using the "Tiled Blocks" technique they're referencing and the code I posted above does the calculation for the screen-space geometric error they're talking about.

 

Anyways, these articles are talking about terrain being rendered with tesselated triangle meshes. Making it work with voxels shouldn't be too much of an extra step (I've even been considering this for my own terrain system). I think the approach I'd take is making cubic "chunks" of 16x16x16 (or some other number) and figuring out how to render the visible faces on that chunk of voxels. The general principle remains the same. I suspect that it could be done very fast with some sort of ray casting technique in HLSL, but I'd have to do a lot of R&D on that.

0

Share this post


Link to post
Share on other sites


(I presume blocks 16x16x16 are local size, which scales up with lower-res lod right?)

The idea behind octtree/quadtree is to have a varied size (scale) not vary the number of vertices. For instance, up close the 16x16x16 could represent a block that is 16meterX16metersX16meters in size and a lower level of detail the same 16x16x16 would represent a larger area like 32metersX32metersX32meters-- this is double the size in each direction. For a map (terrain) the expansion of the vertical axis wouldn't be needed as much as the horizontal axis' unless you have a volumetric approach to your terrain where even the empty areas of the sky are represented.....

 

The "geometry clipmaps" is not voxel, or do you mean to modify it into something "voxel"?

2

Share this post


Link to post
Share on other sites

What I still don't understand is how do you handle differently sized lod chunks when camera moves. If only higher-res chunk moves, then this chunks overlaps with lower-res chunk. At least, I don't expect you regenerate all the lods each move. Octree is nice to have to determine in what lod each block can be, but i still don't understand in what way it helps when moving. When there are 16x16x16 chunks for hi-res and 32x32x32 for lower-res chunks, how and when you move them? I presume regenerating chunks takes some time, it doesn't happen in on frame, so what exactly is happening during this transition, when chunks are somehow regerating and updating terrain. I don't want to see reapperaing large blocks of terrain all over the place:(

 

I understand how you build all lods on given position, but that's what I consider as "loading time specific", not what I want to do every camera move.

0

Share this post


Link to post
Share on other sites
http://www.brandonpelfrey.com/blog/coding-a-simple-octree/

Hopefully this will give you an idea of how it works.
You don't need two different resolutions (number of verts), you only need one. The idea is that the farther away the "cube" is from the camera, the larger in scale the mesh is-- with the same number of verts as all the other cubes.
Doing this on the GPU is still magic to me, so I'm still waiting for someone to illustrate "how" to do it.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0