Before writing about Unity, I wanted to provide clarification for my subscribers and let them know that I've moved away from XNA development and moved to Unity. While XNA isn't entirely dead (there are still plenty of XNA developers around and still using XNA for desktop and XBLIG games), it is certainly fading away.
More...
I decided to finish out the year by converting my XNA Terrain series to work with Silverlight 5 and XNA but during the process of converting I ran into an interesting issue. The Texture2D.GetData() method is oddly missing from the Silverlight 5 XNA implementation. I came across several posts around the web asking for a workaround but found no solution so I decided to develop my own. More...
Introduction
In previous sections of this series I mentioned better culling techniques. I wasn't going to touch upon any of these until after the series but it continued to eat away at me until I finally decided to do so. The result was hours and hours of trial and error and a lot of mistakes along the way. Thanks to community contribution in the AppHub forums I was able to get many of my questions answered or at least get pointed in the right direction. I ran into several issues along the way, but eventually came up with a working solution. More...
So far in the terrain series we've learned how to create a heightmap based terrain, leverage a quadtree to navigate our terrain data, and add progressive level of detail by using our quadtree to step away our active vertices as we move further from the camera. Today we're going to concentrate on view frustrum culling. We're going to avoid drawing any geometry that is not in view of the camera. If you haven't read through the first 5 parts of this tutorial you can find them on the Terrain Table of Contents page. More...
Up to this point in the series we have accomplished a few major milestones. We've created a set of data objects to hold the information needed by our terrain, we've constructed a quad tree to allow efficient traversal through different portions of our terrain, and we've implemented the logic to draw our terrain at different levels of detail. In this part of the series we're going to explore adding LOD to our terrain. The level of detail code we're going to implement will be simple and linear.
Only the deepest node containing our camera will be drawn at highest detail and it will step away the detail one unit at a time as it gets further from the camera. As you'll soon see, this leads to some decent but less desirable results. Terrain drawn in the distance will be subject to some visible "popping" as the LOD transition changes and vertices not visible to the user will still be drawn, however we will address these issues in the next parts of the series. For now, our goal is to simply implement a system that allows a transition of detail from our target point outward. More...
UPDATE: If you've been following this terrain series you have probably seen some bugs and a few things that I've overlooked. I spent the last few days following my own tutorial, updating the series text, and fixing and refactoring the code. If you don't want to start the tutorial over just to find the few changes I've made, you can download the complete solution for parts 1 through 4 here: Terrain Solution Parts 1 through 4
In the first three parts of this tutorial we examined creating the basic data structures to hold our terrain data and structuring our QuadTree. In this part of the tutorial I'm going to show you how to activate different depths of the terrain and draw it based on which vertices are active. We won't get into dynamic LOD until the next section, but when we do you'll have a good idea of how we're going to output our indices and draw our specific triangles. If you haven't already read the first three sections of this tutorial, please visit the table of contents page and check them out. More...
In Part 2 of the terrain series we looked at how to build the basic data storage containers that we'll be using to hold our vertex related data. In this segment we're going to examine the QuadTree we'll be using to manage our terrain. The QuadTree aids us in efficiently determining where we are in the terrain. We'll also be using it to determine which individual vertices to display and which groups of vertices will be active. More...
In this second part of the terrain series, we're going to build some of the data structures we'll be using for our terrain. If you haven't already done so, please read Part 1 of the terrain series.
The most imporant piece of our terrain project is the terrain data and more specifically the vertex data. Calculating all of the vertex data can be fairly CPU and time intensive and this is not something we want to do every frame. For this reason, we're going to setup some simple data objects to store our vertex data. Remember from part 1 of the series I said we're working with VertexPositionNormalTexture. This allows us to easily send vertex data to the BasicEffect class and draw a simple texture with little effort. You may decide you want to use a different vertex type and draw the data differently. This is entirely up to you, but I would recommend sticking with VertexPositionNormalTexture for the duration of this series. More...
Overview
Today I'm going to switch gears and write something a little more fun. This is the first article in a series dedicated to developing a QuadTree based terrain for XNA 4. Terrain generation is a hot topic amongst XNA developers and a question that arises often.
There are several different approaches to developing terrain. The simplest method is the “brute force” approach where all terrain data is rendered every frame. With the power of today’s hardware, this is definitely a viable solution for games with simple, low geometry terrains that target the PC, but it’s an approach that doesn’t scale well when terrain becomes more complex.
Another approach to terrain is to implement a Level of Detail (LOD) algorithm that sets out to reduce the complexity of the terrain as it gets further away from the user. This step alone can increase efficiency and produce phenomenal gains in performance while raising the complexity and detail of the terrain. There are several different approaches to LOD, and even more ways to improve performance beyond simply subdividing the terrain.
This series focuses on implementing something very similar to a ROAM algorithm. Aside from simply subdividing the terrain, it also implements further improvements by performing view frustrum culling. View frustrum culling put most simply is the process of culling away, or removing geometry that is not visible to the user. More...