Graphic Stream : LOD

Smart Terrain Rendering with Xna using Billod algorithm

valentin — Tue, 30 Sep 2008 12:13:00 GMT

Version Française ici.

If you're a game developer you've already worked on terrain rendering. It is, in my opinion the critical point of a game. Not because conceptually speaking it is the most important visible thing on the screen but because it is the main factor playing on the performance and quality of your application. It is therefore important to use techniques designed to minimize the burden borne by your game to view the ground while preserving its quality display. This article shows a way that attempts to answer this question in XNA.

Conducting a study of game engine designed to help game developers in the Imagine Cup competition, I naturally preferred this important aspect in seeking a way to display a 3D world unlimited real size with an acceptable level of detail.

There are many techniques for displaying world explained by interesting articles. These are often based on a compromise uncomfortable wearing a choice between the size of land or quality level. In addition, they are often prohibitive algorithms.

This article does not appear as the only possible response to the display ground XNA but would just provide an effective solution running for this technology knowing that most of the examples existing on the Web are made in DirectX and OpenGL.

We will split our study in several phases:

· First we describe the problems posed by the display of land and explain the need for optimization.

· We then describe the method used to cut our land into a QuadTree.

· We will explain how we reduce the retail field at distance while keeping up its appearance nearby.

· We will describe a more technical implementation of this technique

· Finally we will see possible optimizations offered to the reader.

The problem

Let's say we wanted to model a land about 10 km by 10km with a degree of detail about 1 meter (1 kilometer = 1000 meters). So we have (without optimization) a grid of 100000 * 100000 to show. We have to specify that that each vertex of the grid has a memory size equal to approximately 40 bytes. It reaches about 4 gigabytes of data to display. The hardware of a lambda PC cannot handle such loads memory. Another problem, such a field modeled in a grid rendering static demand of 200 million triangles per frame. This is a disaster. From the moment the size of the field becomes important and where we add the ground ingredients of usual games, as 3D models, an user interface, animations, performance of a game can no longer follow. This is here, that we have to manage a smart rendering.

It is therefore important that the CPU and / or GPU taken by the display field is as low as possible to keep processing time for other needs of the game. The virtual world offered by most modern games are huge and cannot be done with a simple static grid

The need for optimization is therefore evident. I invite readers to visit http://ww.vterrain.org to discover some presentations techniques other than that presented here.

If we had a specification to comply, we would have:

· Keep the appearance of the ground up by reducing as much as possible the burden with its display.

· Make the management of land by the code clean and accessible.

· Using a technique efficient, simple and fast.

· Respecting a QuadTree to optimize performance and meet the needs of treatment games.

Keep appearance with 100 times less resources, is a beautiful goal!.

The QuadTree

The first step is to manage our future terrain through a QuadTree.

A QuadTree is a data type tree in which each node can have up to four children. The Quadtrees are most often used to split a two-dimensional (3D abscissa and depth) by recursively subdivided into four knots. Each node has 4 children and so on. The route of such a tree is simple and takes on average the same time : for each level, there is a maximum of 4 tests to be "allowed" to navigate into lower level. This is important given the task before us here: "Show ground with maximum details using minimal resources.". The goal is to minimize the course of such a tree through its hubs in making these tests smart and simple.

Principle

The QuadTree (often used for rendering the field) provides an intelligent answer to the problem of optimization. First it loads the data only when needed. Then, the burden caused by the representation of a node on the screen depends on the depth of the node in the tree. Therefore, the sooner it is estimated that a node not be displayed in the course of a tree, the greater the optimization of display is realized (we limit the same time the number of triangles to display ). We will explain it all over this article.

More on sinking into the tree, more precision displayed with refined detail.

The real question to be asked to optimize the display of our tree is "what tests should be performed to determine the appropriateness of displaying a node on the screen”. We will see this as soon as possible. For now let us concentrate on how we manage the tree in our code.

Display the tree

Initially our terrain is only rendered by a single node (see picture above). The node size will be equals to the size of the terrain. A node on the screen corresponds to a surface composed of 9 square vertices:

1. Nord North

2. Nord Est North East

3. Est East

4. Sud Est South East

5. Sud South

6. Sud Ouest South West

7. Ouest West

8. Nord Ouest North West

9. Centre Center

A node is composed of 9 vertices

The QuadTree will be based on a heightfield (a two-dimensional array containing all the heights of each vertex Y on the screen). Each vertex of each node in the QuadTree has a height whose value is drawn from the heightfield.

Initially, only the corner of a node are visible, namely: North East, South East, North West, South West. Its rendering is similar to the following picture:

The shaded vertices are visible vertices

These four vertices displayed allow us to draw two triangles form the surface of square knot. For each update of the terrain, for each node currently visible, we calculate the visibility of each of the vertices. Each update of a node is accompanied by a redrawing of triangles that make it up. he following picture explicit some possible configurations for a node:

The algorithm for this part would be:

/ / For each of the vertices North, East, South, West

If ( !Vertex.Visible && VertexTest())

Vertex.Visible = true ;

Else if (Vertex.Visible && !VertexTest())

Vertex.Visible = false;

The test of this algorithm takes into account the distance of the vertex from the camera and the growing need for detail as the camera approached it. We will see the nature of this test later.

In a second step it is necessary to calculate the visibility of children of current node. A node consists of four children as the next picture shows:

Here we have shown the North East of child root node, then the child South East of it, then the child of the South East last child finally North West of it.

The more one penetrates deep into the QuadTree over the mesh tightens and will display a more detailed terrain.

The algorithm for this part at this stage of our study would be:

// For each of the four children North West, North East, South West, South East

If ( !Child.Visible && ChildTest())

Child.Visible = true ;

Else if (Child.Visible && ! ChildTest())

Child.Visible = false;

Once again, the test of this algorithm takes into account the distance to which the child and the growing need for detail as the camera approached it. We will see the nature of this test later.

When a child is exposed, its vertices and his own children are subject to two algorithms that we have just seen. We are therefore in a principle of recursion.

We compute the triangles that’s makes a node by not taking into account the parts overshadowed by children:

We note here that the vertices North and East of the parent shared with the vertices North West and South West of the child. We will see that later.

The basic principle of the Billod algorithm is relatively simple. Vertices et enfants à afficher sont soumis à chaque mise à jour du terrain à un ensemble de tests qui déterminent leur visibilité. Vertices and children are subjected, at each updated of the terrain, to a set of tests that determine their visibility. The display of a node node is a recursive set of instructions that goes through the QuadTree along the root node to each leaf node of each branch.

Improvements

We talked previously shared vertices between a child and a parent. The previous image illustrates this point. This may cause an unpleasant graphic bug illustrated by the image below:

Or, with wireframe:

This problem is due to the non-activation of a vertex in the neighboring node. The nodes affected by this bug are:

So in reality:

The West vertex of the child red is activated but not the vertex of the yellow child. There is therefore a delta between the two sides of the two children. To resolve this bug simply validate the vertex of the child is yellow:

Finally we get a perfect continuity:

Now imagine that the southern vertex of the yellow child becomes visible. The parent node has only two children north west and north east. Activating this vertex pose the same problem as before graph:

Unfortunately, unlike the previous case, there are no children in the South West. It is therefore necessary to create a child to this position (although the "ChildTest” of our algorithm for that child returns false) and to activate its North vertex:

The addition of southern vertex of the white child led to the creation of the Child South West and the activation of southern vertex parent node. The vertex South may itself cause the modification of neighboring nodes. There are, here, some cascading effects that are not really controllable but, fortunately, limited. The following image shows the impact of activation of several children deep into the QuadTree at the bottom right of the terrain.

We note that the nodes located at the opposite are impacted.

Managing nodes in the QuadTree

Some years ago I read an excellent article by a person named Stan Melax author of an ingenious technique for calculating a dynamic aspect of a 3D model at different levels of resolution. The articles on progressive meshes are subject to the same laws as those on land: either the reduction algorithm is too complicated or it is inappropriate. Stan Melax found a clever way to solve this problem. He studies the cost the disappearance of each vertex by studying their impact on the overall shape. He is then able to gradually reduce the resolution of the 3D model by removing vertices in a logical order with the less impact. Its strength lies in the calculation of the cost of a vertex which proves to be a simple and effective. We will proceed the same way.

The curve : Element to remember

To explain simply : We measure a terrain to its forms. We measure a form to its curves. The question is then: how to define a curve ?. Answering this question would determine the locations of the terrain where we must keep an important retail level and those that can be degraded.

There are many techniques to transform a curve into a mathematical function. We return in this case to the beginning problem: Do not overload the processor too much. We have seen, it is necessary to execute the formula found at all vertices and all children nodes. A formula that generates a lot of instructions will deteriorate application performance.

The solution is simple. We have said that our land is splitted into a set of nodes belonging to a tree. Each curve of the land therefore consists of nodes that are actually surfaces square whose size varies

The terrain is a set of curves visible on the screen. Each curve is an assembly of square knots coast to coast glued.

The normal, order of magnitude of a curve

Plus la courbe est importante, plus les nœuds qui la composent forment un angle important. The greater the curve is, the greater the angles made by its nodes are important. Take for example a curve :

It shows all nodes glued side by side. At the place where the curve is really important we find nodes that form an angle. In contrast to where there is no curve, but a simple slope, nodes coast to coast appear to belong to the same plane. We noticed even more if we show each normals nodes:

We are now close to finding the formula! All the students know that the mathematical function that measures the angle between two vectors is the dot product.

The inner product of two vectors represented by non-zero vectors A and B is the actual number ABcos (θ) if the angle θ is the angle formed between the two lines whose direction are represented by the two vectors.

The maximum angle that can be found in a curve of land as we conceive it tends to 90 degrees (90 degrees value cannot be achieved because nodes can’t overlap). Cos 90 equal 0 so we can infer that when the curve formed by the vectors is important, their dot product approach 0 (A * B * Cos (90) = A * B * 0 = 0). On the contrary if the value of inner product increases, is that the curve formed by the two nodes tend toward the "right" (A * B * Cos (0) = A * B * 1 = AB). See this picture:

The inner product between the normal parent and child will return here a value far away from 0 : we are on a surface, certainly inclined, but plane. Needless to cut the node.

Consider now a pronounced curve :

The angle between the three normals is more pronounced. The original node (symbolized by the black dotted line) should be divided into sub-nodes. We can found in this process a certain logic: a flat surface is easily modeled with few polygons. A curved surface ask for much. Here to complete the wireframe curve:

Where the curve is more pronounced, our technique uses more primitives

Activation

Child Test method should compare the normal of the children to test with the normal of the parent node to which it belongs. If the angle between the two normal exceeds a threshold when the method returns true.

Disabling

Disabling a child occurs when a series of factors are met:

· The child has no longer visible vertices

· The child has more sub-children

· The test method returns false.

Enable/Disable switch node in the vertex

Interpolated to real

La gestion de la visibilité des vertices ne suit pas la même logique que celle décrite précédemment. The management of the vertices visibility does not follow the same logic as that described above. Here there is no curves but delta. Only vertices on the sides of a node are to be tested. So the North, East, South, West vertices. When a node is created, this vertices are not visible. But they are located between two vertices on node edge and so, we can deduce their height easily. Here is an example of node viewed from the side:

It shows the vertices North West and South West enabled (visible)) and West vertex disabled.

The West vertex seems to be on the right along the two summits. In real, it may not. For now we have interpolated (deducted) its position (If South West is at a height of 10 and North West at a height of 20, it is reasonable to assume that the West vertex will be at a height of 15). Yet in reality, it is may be at another height:

There is a distance between the delta position of vertex West interpolated its actual position. This difference in height measures the degree of reality of the node currently displayed with a more detailed version.

View node with only the 4 vertices summits displayed therefore does not adequately reflect the reality on the ground displayed by the node.

Way of activation

The activation method is very simple, we only need to determine the Delta value (a simple difference of heights) and determine if it exceeds a threshold too.

Test of disabling

Disabling a vertex is only when a series of factors are met:

· The vertex is used by a child node

· The test method returns false.

Progressive Details

It was one of the prerequisites for our technology, we must optimize the display according to the camera position. At this point, our two functions tests (for vertices and children nodes) do not take into account the camera position and the position of the element to test.

We have seen in the two algorithms dedicated to the vertices and nodes, that test is performed to determine if a vertex or child should be displayed or not. The land must be displayed according to the camera position for the comfort of the player. The more an area of land is close to the camera the more it have to be detailed. It also aims to preserve up to the appearance of the terrain away with a minimum of vertices and gradually detail when the camera comes.

Detail for progressive QuadTree

For the time the testing method is based on the angle made between the normal of a child with its parent. This procedure is not necessarily relevant distance.

If a few degrees angle is visible when you are close to the nodes that make up this angle is not necessarily detectable at a distance It is not necessary to activate the child.

Here is the implementation of this test method:

private bool ChildTest(Vector3 childNormal, BoundingBox boundingBox, Vector3 cameraPosition)

{

//by default, the four childs of the root node are visible.

if (this.Depth < 1)

return true;

//get the closest point to the camera and check the distance

float distanceCameraToPoint = Vector3.Distance(GetBoundingBoxClosestPointToPoint(boundingBox, cameraPosition), cameraPosition);

//compute the dot product between parent normal and child normal

float dotprod = 1 - Vector3.Dot(childNormal, this.CenterVertex.Value.Normal);

//check with the threshold

return (distanceCameraToPoint / this.ParentTree.QuadTreeDetail) < (dotprod);

}

By default nodes at the top of the tree are made visible. We then determine the distance between the camera position and the nearest point of it in the BoundingBox encompassing child. The dot product is then calculated. We test the division of this distance by an adjustable threshold is below the dot product.

Note that this method of testing may well be adapted to submit the QuadTree to another technique optimization.

Progressive detail for the vertex

Again, the testing method for vertices does not take into account the distance to the camera. We must determine if the distance between the actual position of the vertex and its position interpolated exceeds a threshold configurable.

Here is the testing method:

public bool VertexTest(Vector3 vertexPosition, Sides side, Vector3 cameraPosition)

{

//get the distance between interpolated height position and real height position

float lengthToTest = this._realToInterpolatedVertexHeight[(int)side];

//get the distance from the camera position to the vertex position

float distanceCameraToPoint = Vector3.Distance(vertexPosition, cameraPosition);

//check with the threshold

return lengthToTest * this.ParentTree.VertexDetail > distanceCameraToPoint;

}

The delta between the two vertices (interpolated and real) is stored in memory. We then determine the distance between the vertex and the camera. A test is then conducted to determine if the Delta exceeds the threshold distance to the camera. Like earlier this test method may well be adapted to submit the vertices of each node to another technique optimization.

A field at different level of detail, from left to right: 7500, 3000, 1500, 300 150 vertices

Improvements

Our algorithm at this stage works perfectly: it displays the details where they are relevant, frees up resources and uses a quadtree.

Remember that time, the relevance of viewing a node is measured using the dot product of its normal with normal direct its parent. This is rather good, but we can improve. The following pictures illustrate a graphic unpleasant bug that modifies the appearance of ground within walking distance:

In front of us: a slight bump on the ground

The hump has been truncated

Note that the bump on the first visible image is greatly reduced by the mere fact of having moved slightly camera. But our algorithm has worked here perfectly. We simply validated a threshold requiring a node to be cut. So we need to reduce the implementation of our algorithm close to the camera. We will therefore introduce a second threshold that will represent what we mean by "proximity".

The new test function is thus as follows:

private bool ChildTest(Vector3 childNormal, BoundingBox childBoundingBox, Vector3 cameraPosition)

{

//by default, the four childs of the root node are visible.

if (this.Depth < this.ParentTree.MinimalDepth)

return true;

//get the closest point to the camera and check the distance

float distanceCameraToPoint = Vector3.Distance(GetBoundingBoxClosestPointToPoint(childBoundingBox, cameraPosition), cameraPosition);

//compute the dot product between parent normal and child normal

float dotprod = 1 - Vector3.Dot(childNormal, this.CenterVertex.Value.Normal);

//check with the threshold

return ((distanceCameraToPoint - this.ParentTree.QuadTreeDetailAtFront ) / this.ParentTree.QuadTreeDetailAtFar) < (dotprod);

}

We now have two thresholds, a threshold of visibility for “near displays” to maximize the details close to the camera and a threshold of “far display” that manages the details beyond the previous threshold according to a affine function as we did until now.

The advantage is undeniable. For proof, just take a look at the picture below:

I went to the center of the terrain, I stopped the implementation of the algorithm (similar to a pause in the Update of the QuadTree) and take some the altitude. We notice that the details seem to diminish when away from the center. This is indeed the case:

At the center of the screen near the crater, the details are at maximum. If we were on the ground, we do not see any ground near bump be changed by moving the camera. On the contrary, the far away details keeps the overall look of the land.

It's not all, we are now able to generate a climate and geographical well known: a mountain line (sorry I do not know the English term for “ligne bleue”). Look at this picture:

It is the blue line Vosges clearly visible from the north of “Franche-Comte” in France. Plus on regarde. The more one looks far more mist arises in a bluish tint. By applying our algorithm and a modified fog we are able to generate a skyline purified up to cut a new notch resources taken by the displayed terrain. Return on our field, but this time by being near the ground:

We've added a blue fog to simulate this. The remote mountains are visible thanks to the difference in color the fog gives them. Now the same view but with a threshold of visibility at distance greatly reduced:

We get a display similar but with 1300 primitives less!

Code and optimization

The code given with this article is deliberately sketchy for the sake of understanding. Son but est de tester la technique Billod Its purpose is to test the Billod technique described here with no optimization.

Description of the "business" classes

Four classes are really business:

· The terrain is naturally managed by a class called Terrain. We will return later on its possible usefulness. Terrain is a container for Quadtrees. It represents the whole ground.

· The tree is represented by an instance of QuadTree class. QuadTree represents a part of Terrain. It is a container of QuadNodes.

· The nodes of the tree are created using the QuadNode class. It is a container of TerrainVertex. QuadNode represents a node.

· Finally the 9 vertices of a node are TerrainVertex.

Most treatment is within the class QuadNode. This has two important methods: Initialize and Update. The Initialize method handles load the node with all information related to its position in the QuadTree. It makes visible its four edges, it determines the neighboring nodes (for sharing vertices). It also calculates the deltas, normals, BoundingBox. It is called once every creation of a node.

The Update method performs tests on the four vertices "sides" (North, East, South, West) and four children on the potential (North West, North East, South West, South East) to each update of the tree .

This is the class QuadTree which initializes the first node and start treatment on the tree. Every x seconds (adjustable) it launches an asynchronous update on all the nodes instantiated to update the tree depending on the position of the camera.

The instantiation of a QuadTree is achieved by specifying the size of it, its depth and its location:

QuadTree tree = new QuadTree(treeDepth, rootNodeSize, location);

The structure TerrainVertex contains the vertex to display. A vertex can be shared on multiple nodes.

The code of this four major classes has been simplified in the extreme and widely commented. If there are still black spots do not hesitate to contact me.

Update Thread

A quick and easy (dirty ?) solution has been implemented to update the field. A BackgroundWorker is launched when you start the application and handle the updating of the field asynchronously.

This procedure avoids any slowdown of the game during the update. The data displays (VertexBuffer and IndexBuffer) are stored in a stack and used in the Render method. In the example provided with this article, we do an update that every 4 seconds.

Optimizations

Apart from improvements to the code, here are some ideas to increase the quality of reporting and the power of technology Billodes.

· We do two courses of the shaft each Update (one to update the tree, the other to extract the list to display triangles). There 'may be a point to improve here.

· The updated every X seconds is not necessarily the best solution. There are several other possible avenues to update, for example when the camera is moved or predicting the movement of the player and update accordingly. Finally, it should be noted that the final status of a tree is not achieved in a single Update It may be preferable in some cases to await the final version of the tree by calling the Update method as many times as necessary. You shlould prefer update the tree by little part each frame.

· Some thresholds for activation or deactivation of a child or a vertex are very low. We can consider that they will never be activated.

· When a node is cut or merged, or when a vertex changes state (visible / hidden), the transition is visible.It may be useful to cut this transition more gradual steps to soften the visual changes.

· Relying on the Terrain class. In this sample we render only a single tree. The Terrain class field can be a serious springboard to try to manage several trees that will be linked one to another.

· We load the entire Heightfield from the start by analyzing a black and white. It is an effective way to proceed to achieve an example but not to make a game. It might be wise to store the array of heights in a file and read what the QuadTree needs at each Update.

· The source code has not been optimized for readability.

The example program

This program is just one example of a rapid implementation of the land Billodes. The business classes are quickly adaptable to individual needs. The project is XNA 3.0. Il est toutefois adaptable au 2.0. However, it is adaptable to 2.0.

Commands to interact with the world are:

· Mouse: Click to turn the camera.

· Arrow keys: moving the camera in the current direction.

· Key W: Wireframe Mode On / Off.

· Page Up / Page Down: Change the Far Threshold Test.

· Key left Shift + Page Up / Page Down: Near Threshold Test.

· Left Key Shift + arrow keys: fast move.

· Left Key Alt + arrow keys: moving slow.

To test the Billod algorithm, simply move on the ground and studying the evolution of the field.

Note that it is possible to modify some parameters affecting the display using the configuration file of the application.

You can reuse the source code as you want. I just ask to refer me in your "credits".

References / Credits

The Web site of Stan Melax: http://www.melax.com . A very pragmatic man at the root of a technical Progressive Mesh very smart on which I based my algorithm. I take this article to thank him for his kindness and his exchange at the time or I was working on progressive meshes in XNA.

"Continuous LOD Terrain Meshing Using Adaptive Quadtrees" by Thatcher Ulrich. A method quite similar to mine but more research-oriented to deltas. This is one of the few methods available on the web that can be used for a game. My algorithm has a QuadTree quite similar to his "Adaptive QuadTree" but his management heightfield is much more intelligent than mine. His details management is, in my opinion less good than mine.

The page Hugues Hoppe: http://research.microsoft.com/ ~ hoppe. One of the masters of the terrain rendering. Everything is so great but illegible for novices and not necessarily adapted to the world of video gaming.

Virtual Terrain Project: http://www.vterrain.org/ . Website with a great set of publications around the management of terrain.

And on a more personal way Mathieu Laussel, a French friend 3D modeler (engineering) with whom I realize an editor of the world and who kindly wait as I write this article. And Boris Driss student that like game development and with who, talking is very interresting.

Downloads

You can downalod the C# project here.

Annexe : Progressive Mesh en Xna

valentin — Thu, 05 Apr 2007 14:00:00 GMT

Retourner au sommaire des cours

Avant toutes choses je tiens à remercier Stan Melax qui m'a gentiment aidé à passer son algorithme en DirectX et Xna et m'a laissé la possibilité d'utiliser pour ce cours quelque schémas qu'il avait réalisé.

L'utilisation de MRM est une véritable merveille pour accroître de manière significative les performances de ses applications. Le principe est simple : transformer un model 3D détaillé et formé de très nombreux polygones en une version allégée utilisant moins de faces mais aillant un aspect aussi similaire que possible.

Cette technique est la plupart du temps couplée avec la camera pour réduire proportionnellement la qualité du modèle 3D en fonction de la distance à laquelle il se trouve de la camera.

Au final, nous pouvons ainsi grappiller des FPS et libérer le GPU en lui évitant d’afficher des modèles détaillés au loin, là ou une version grandement allégée donne le même résultat à l’écran.

L'image suivante explicite cela :

On y voir l'affichage d'une voiture sous différentes résolutions (le poucentage indiqué au dessus de chaque modèle correspond au nombre de vertices utilisé par rapport à l'original). Le modèle à 10% reste tout à fait acceptable et similaire à l'original. Il est donc tout à fait imaginable de l'utiliser à grande distance à la place d'un modèle plus "complet" et plus lourd à manipuler.

Les MRM (multi resolution mesh) occupent une place prépondérante dans les moteurs 3D : Utilisés pricipalement pour libérer du traitement GPU sur l’affichage des objets lointains il est aussi employé dans l'occlusion culling (l'occlusion consiste à supprimer de l'affichage les objets qui sont cachés par d'autres objets nous y reviendrons dans un autre post). Nous allons donc dans ce cours chercher un moyen pour créer et utiliser des MRM dans nos applications. Ce moyen, c'est bien evidemment un algorithme qui va etre en mesure de calculer la réduction du nombre de vertices dans une forme 3D en sauvegardant au maximum son aspect général lors de cette transformation. L'algorithme

Une complexité qui rebute

Si on se tourne vers les moteurs de recherche sur le net (live.com, google.fr) à l'aide des mots clés "MRM algorithme" on trouve un grand nombre de travaux de chercheurs et de passionnés sur ce sujet. Pourtant la plupart des algorithmes qu'on y trouve sont inexploitables : soit ils sont trop gourmants en calculs et donc inexploitable en temps réel, soit le resultat change l'aspect de la forme 3D ou bien encore la complexité est telle qu'il est tout bonnement incompréhensible. Quelques pasionnés ont toutefois trouvé un moyen de réaliser des réductions de résolutions relativement simplement. Nous retiendrons ainsi la méthode utilisé par Stan Melax parce qu'à priori la meilleure et, cerise sur le gâteau, l'une des plus simples.

Réduction par Fusion de Meshs

Melax se base lui-même sur les travaux de H.Hoppes, un développer de MSR (Microsoft Research) dont est issue vraisemblablement l'algorithme se trouvant derrière la classe ProgressiveMesh de Direct3D. Cet algorithme vise a réduire la complexité d'un model 3D par l'intermédiaire de fusions de vertices. Le principe est trivial : à chaque réduction de résolution on fusionne deux vertices (que nous nommerons ici u et v).S'ensuit :

La suppression des triangles qui possèdent à la fois les vertices u et v.
La mise à jour des triangles qui utilisaient u sur l'un de leurs trois points afin qu'ils utilisent v à la place.
La suppression du vertex u.

Le schéma ci-dessus explicite tout cela. La figure A montre l'état du modèle avant la baisse de résolution. La figure B montre le même modèle après la fusion de deux de ces vertices. Le modèle garde son aspect mais en utilisant un vertex et deux faces en moins.

Ce processus est répété jusqu'à atteindre le nombre de vertices ou de faces voulu.

Choix de u et v

Cette méthode est relativement simple sur le papier et réduit effectivement sans grandes difficultés un model 3D. Il ne faut pourtant pas crier victoire trop vite : comme dit précédemment, il est primodial que le model "réduit" garde une apparence similaire au model complexe originel. Il convient donc de choisir avec intelligence les sommets u et v à fusionner afin de provoquer la plus fine modification visuelle à l'écran. L'image suivante illustre celà :

Le choix du sommet à supprimer est important pour garder une apparence aussi similaire que possible à l'original (image extraite de l'article de Stan Melax avec l'aimable autorisation de l'auteur).

C'est là ou le bat blesse : la plupart des algorithmes propose pour ce choix des calculs lourds et inutilisables en temps réel. Sur ce point, Stan Melax a montré son savoir faire. Il part d'un principe élémentaire : les surfaces coplanaires ne demandent pas autant de vertices pour être rendue à l'écran que les surfaces avec un relief prononcé (comme les courbes). Il est plus facile de réduire la complexité des premières, que celle des secondes. Le coût pour la disparition d'un sommet pourrait se traduire ainsi : c'est le résultat de la multiplication de la taille du sommet par l'importance dans la courbe sur laquelle il se trouve.

Pour la fusion uv, visant à déplacer u vers v nous avons l'algorithme :

Calculer la taille du sommet (distance u à v).
Déterminer l'ensemble des triangles qui possède à la fois u et v.
Pour chacun des triangles connectés à u :

Calculer le produit orthonormé de la normal du triangle courant avec chacun des triangles qui possèdent à la fois u et v. En extraire le plus petit produit.

Calculer le plus gros des plus petits produits : C'est la coùt de la fusion.

La formule mathématique pour calculer ce cout est la suivante est la suivante :

où Tu est l'ensemble des triangles qui possèdent u and Tuv l'ensemble des triangles qui contiennent à la fois u et v (image extraite de l'article de Stan Melax avec l'aimable autorisation de l'auteur).

Le principe peut se résumer ainsi : on parcourt tous les triangles connectés à u. Il est nécessaire, pour chacun de ces triangles, d'analyser le cout de la fusion avec v. On calcul celà en analysant l'impacte de la transformation des triangles afin de déterminer l'ampleur de la modification. Il y'a deux types de modifications : Soit les triangles sont connectés uniquement à u, et, dans ce cas ils sont modifiés pour être reliés à v, soit les triangles sont liés à u et v à la fois et doivent etre supprimés du modèle. La figure A et B au début de cette annexe illustre celà parfaitement.

Passons aux choses sérieuses

Pour l'heure la classe ProgressiveMesh que vous pouvez reprendre est industrialisable mais est encore améliorable :

Il reste à associer un poid à chaque vertex pour la transformation.
A réaliser un tris sur la liste de vertices pour classer par ordre de coût de transformation.
A réaliser des méthodes d'optimisation comme dans la classe Mesh de Direct3DX (fusionner les vertices qui sont assez proches pour ne faire qu'un).

Passons maintenant au code.

Celui-ci se trouve à l'intérieur d'une DLL nommée ArcaneEngine.Objects. Deux types de données nous interesse :

ProgressiveMesh<T>
Resolution

La création d'un mesh progressif et son affichage se fait en trois étapes.

Tout d'abord la création de l'objet (étape pouvant être asynchrone) en passant au constructeur la liste des vertices qui composent le mesh, la liste des indices pour relier les vertices et enfin les poids associés aux vertices (un tableau de booléens pour l'heure) :

ProgressiveMesh<VertexPositionNormalTexture> mesh = new ProgressiveMesh<VertexPositionNormalTexture>(vertices, ints, null);

Puis le chargement des buffers 3D lorsque le device a été créé

mesh.Load(this._device);

Enfin l'affichage du mesh

this.mesh.Render();

La gestion des MRM est beaucoup plus simple qu'avec la classe de Direct3DX.

Revenons sur la généricité de la classe. Le développeur doit indiquer un argument de spécificité a la classe générique ProgressiveMesh (ici VertexPositionNormalTexture). Il s'agit en fait de la classe utilisée pour le type de vertices.

A partir de cet argument, la classe pourra extraire les positions de chaque vertices et, avec les indices, calculer les différentes résolutions. Elle pourra en outre extraire le format des vertices pour l'affichage, elle pourra aussi renvoyer à l'utilisateur pour chaque resolution les buffers et array de vertices actuellement affichés.

Pour changer la résolution deux choix. Soit vous utilisez la propriété NumberOfVertices pour indiquer directement le nombre de vertices a afficher. Soit vous utilisez la property Resolution en donnant un membre de l'énumération :

    public enum Resolution
    {
        /// <summary>
        /// <para>No resolution : no mesh rendered.</para>
        /// </summary>
        None = 0,
        /// <summary>
        /// <para>No resolution : no mesh rendered.</para>
        /// </summary>
        Dynamic = -1,
        /// <summary>
        /// <para>Ten percents of the mesh's vertices used to render it.</para>
        /// </summary>
        Lowest = 10,
        /// <summary>
        /// <para>Twenty five percents of the mesh's vertices used to render it.</para>
        /// </summary>
        Low = 25,
        /// <summary>
        /// <para>Fivety percents of the mesh's vertices used to render it.</para>
        /// </summary>
        Medium = 50,
        /// <summary>
        /// <para>Seventy five percents of the mesh's vertices used to render it.</para>
        /// </summary>
        High = 75,
        /// <summary>
        /// <para>One hundred percents of the mesh's vertices used to render it.</para>
        /// <remarks>Full vertices are used.</remarks>
        /// </summary>
        Full = 100

}

Le changement de la résolutiond'un mesh demande un leger temps de calcul à priori invisible à l'écran.

Nous n'analyserons pas ici le code qui reste assez simple. A l'intérieur de la classe ProgressiveMesh se trouve la region "Multi resolution computing" qui contient les méthodes liées au calcul de la resolution. La méthode ComputeEdgeCostAtVertex détermine le cout de la fusion d'un vertex, la méthode Collapse réalise cette fusion et MinimumCostEdge permet de trouver le vertex ayant le coût le plus bas pour une fusion. A noter que la classe ProgressiveMesh possède deux types internes : Vertex et Triangle qui permettent d'opérer sur les vertices et les faces plus facilement.

Une analyse du code par vos propres moyens devrait eclaircir tous les points encore obscurs à vos yeux. N'hesitez pas a poster des commentaires pour toutes questions.

A l'intérieur de la classe Game1 se trouve le code qui montre comment utiliser notre classe ProgressiveMesh. L'application principale contient en outre un ensemble de classes statiques qui contiennent des ensembles de vertices et d'indices permettant de charger un MRM. Elles héritent toutes de l'interface IData qui permet une utilisation générique de ces dernières.

Les liens

Evidemment en première place le site de Stan Melax

http://www.melax.com/polychop/

Ensuite le site de Hugues Hoppes

http://research.microsoft.com/~hoppe/

(déprimant parcequ'on voit qu'il fait des trucs super, mais on comprend rien)

Sample

Vous pouvez télécharger les trois samples ici.

Conclusion

L'application au final se présente ainsi :

L'interface graphique est rudimentaire mais nous l'améliorerons avec l'arrivée de l'annexe portant sur l'UI. Les touches Page Haut et Page Bas permettent de passer d'une résolution à une autre. Les touches + et - permettent de modifier la resolution plus finnement en changeant le nombre de vertices affichés. La souris permet de déplacer la camera autour du mesh affiché. Enfin la touche espace permet de changer de modèle. L'application affiche 6 modèles :

Beethoven
Fourmi
Un terrain
Porsche
Vache
Lapin

A noter que le modèle terrain sert à voir l'utilité du tableau de poids passé au constructeur. Sans ce poid, la portion de terrain "s'arrondit" au fil de la réduction de résolution en perdant ainsi tout son aspect. Notez de même que le modèle fourmi montre les limites de notre système sur les formes 3D disposant de peu de vertices ...

A bientôt sur ce Blog !

Valentin Billotte

N'hesitez surtout pas à me faire part de vos incomprehensions afin de pemettre d'améliorer ce cours pour le rendre plus accessible aux autres (trèèèès important)!

Vous pouvez télécharger les trois samples ici.

Retourner au sommaire des cours

XNA Tutorial 8 : Les textures

valentin — Mon, 12 Feb 2007 08:52:00 GMT

~~< en construction / under construction>~~

Retourner au sommaire des cours

Notre premier chapitre consacré aux textures : un vaste, un très vaste sujet et au combien important dans le développement 3D. Le texturing est sans aucun doute l'élément le plus important pour donner du réalisme et de l'interet à un projet 3D. Nul doute qu'après cet apprentissage, nos petites productions n'auront plus rien à voir avec ce que nous faisions jusque là !

Nous suivrons trois phases dans cet apprentissage :

Faire connaissance avec le texturing en apprennant les notions de base.
Faire connaissance avec le blending de filtrage, de mipmapping, de blending et de multitexturing.
Opérer sur les textures.

Texture ?

Aucun rapport avec la définition du dictionnaire. La texture est une image qui est plaquée sur un triangle. Il s’agit donc d’un objet à deux dimensions. Nous pourrions la comparer à une surface collée sur un objet 3D pour lui donner un habillage réaliste. XNA comme DirectX autorise toute sorte de taille de texture. En interne il les découpera en images carrés dont le nombre de pixels est une puissance de 2 (16,32,256, …). Dans tous les cas il faut toujours se rappeler que pour la majorité des matériels installés sur les machines, les textures les plus rapides à manipuler font une taille de 256 par 256 et plus la taille de la texture est importante, plus il faudra de temps GPU pour les manipuler.

Si les données affichées à l’écran sont nommées pixels, les données d’une texture sont nommée texels (pour "texture element").

DirectX dans le chargement s’avère très polyvalent et peut lire un grand nombre de type de fichiers images, à savoir PNG, JPG, BMP et TGA.

Dans tous les cas le format d’image n’influence rien pour les performances de jeu. Chaque image étant traduite dans un format interne à Direct3D lors de son chargement. Notons enfin que les textures peuvent être générée à la volée à partir d’un accès mémoire.

Coordonnées de texture

Voilà une notion qui peut étonner au premier abord : Une coordonnée de texture permet de spécifier une position dans la texture. Dans la mesure où, dans une texture, l’espace est en 2D, seules deux valeurs sont nécessaire pour spécifier une position : U et V. U représente l’abscisse, à savoir le nombre d’unités à parcourir horizontalement et V qui représente le nombre d’unités verticales (ordonnées) à parcourir. Leurs valeurs oscillent entre 0 et 1 (des valeurs supérieure peuvent être données pour répéter une texture, nous verrons cela plus tard). Le point supérieur gauche de la texture est donc le (0,0) et le point inférieur droit (1,1) pour (U, V). Le schéma ci-dessous explicite tout cela avec la texture que nous allons employer dans notre premier exemple.

Les coordonnées de textures.

Placage de textures

Les coordonnées de textures sont donc une notion simple qui s’apparente aux bases mathématiques de la géométrie dans l’espace mathématique. Toutes les coordonnées (UV) pour le placage sur une forme 3D seront associées à chaque vertex qui la compose.

Pour plus de simplicité nous allons mettre de coté le cube qui servait à tous nos exemples depuis plusieurs cours pour revenir au carré utilisé dans le tutoriel 3. Dans ce programme un carré est formé de 4 vertices associés à une couleur et une position X, Y, Z comme ci-dessous.

Un programme simple déjà vu qui affiche un carré.

Associons maintenant un troisième type de valeur : les coordonnées de texture nommée ici tu et tv. Nous allons afficher sur ce carré notre texture en entier. Le point haut gauche aura donc la coordonnée de texture (0,0), le point haut droit (1,0) le point bas gauche (0,1) et enfin le point bas droite (1,1). Simple donc. Nous aurons :

La texture entière occupe la surface du carré.

Essayons maintenant de n’afficher que la moitié haut droite de la texture, à savoir la partie :

Nous aurons donc pour caractéristiques des 4 vertices :

Essayons pour continuer de n’afficher que la moitié basse de la texture :

Les caractéristiques seront :

Autre exemple, affichons le centre du carré à savoir :

nous aurons :

Finissons sur une tâche plus compliquée (rassurez vous seulement d’un chouïa). Nous n'allons pas prendre une portion de la texture de manière a avoir des coordonnées "ronde" (à savoir 0.5 ou 1) mais une portion complétement aléatoire. Il va donc nous falloir calculer la valeur exacte de la texture, prendre le pourcentage et reporter la valeur entre 0 et 1. Mettons au hasard le point haut gauche de la source au texel (12,16). Pour une texture de (64,64), converti en pourcentage nous avons : 18.75% en abscisse (12/64*100) et 25% en ordonnée soit donc en coordonnées de texture 0.1875 pour tu et 0.25 pour tv. Faisons de même pour les 3 autres coins. Au final nous avons :

Terminons enfin sur la répétition de textures. Jusqu’à présent les valeurs de tu et tv étaient comprises entre 0 et 1. Que ce passe t’il si ces valeurs dépassent 1 ? XNA, lors du mappage va répéter la texture suivant le pourcentage donné par les coordonnées ; Si tu vaut 1.5 la texture sera copiée entièrement avec la moitié d’une texture sur l’abscisse. Si tv vaut 3, alors sur l’ordonnée nous aurons trois textures copiées. Le dernier schéma de ce point illustre cela très bien :

Notons aussi que les valeurs négatives données à tu et tv inverseront le mappage de la texture. XNA permet d’autres interprétations dans le cas ou tu et tv dépassent la valeur 1 (nous verrons cela plus loin dans ce chapitre).

Passons maintenant aux choses concrètes.

Textures et XNA

Préparer notre projet à l'utilisation de textures...

Jusqu'à présent, la seule manière que nous avions pour ajouter des couleurs à un scène 3D étant de créer autant de vertices que de couleurs associées. Nous allons utiliser maintenant un moyen bien plus puissant et efficace en associant chaque vertices à une coordonnée de texture comme vu dans le point précédent. Nous reprendrons un projet relativement similaire à celui utilisé pour le chapitre 4 consacré aux matrices. Revenez quelques instants sur le code qu'il contient avant de continuer plus en avant. Notre but sur ce cours est d'afficher un carré à l'écran et, en utilisant un format de vertice adapté, y plaquer une texture.

La première étape consiste à définir 6 vertices pour les deux triangles formant le carré. Sachant que nous n'utilisons plus de couleur nous ne pouvons plus utiliser le type VertexPositionColor. Nous utiliserons à la place un nouveau type de vertex : VertexPositionTexture. *

Remarque : Nous avons déjà abordé les structure de format de vertices comme VertexPositionTexture ou comme VertexPositionColor. Ces formats permettent d'associer à un vertex différentes informations (comme la position, la couleur, les coordonnées de texture ...). Vous vous demandez peut être comment XNA peut il savoir quel type de données (couleur, texture, ...) est associé aux vertices qu'on lui donne ? Il utilise tout simple le contenu de la propriété que chaque structure de format doit posséder. Pour plus d'information à ce sujet et pour créer vos propres formats rendez vous ici.

Changez la déclaration du tableau de vertices ainsi :

VertexPositionTexture[] vertices;

Vient maintenant la création de chacun des vertices :

vertices = new VertexPositionTexture; //triangle 1, face devantvertices[0].Position = new Vector3(-10f, 0f, -10f);vertices[0].TextureCoordinate = new Vector2(0f, 0f);vertices[1].Position = new Vector3(-10f, 0f, 10f);vertices[1].TextureCoordinate = new Vector2(0f, 1f);vertices[2].Position = new Vector3(10f, 0f, 10f);vertices[2].TextureCoordinate = new Vector2(1f, 1f);//triangle 2, face devantvertices[3].Position = new Vector3(-10f, 0f, -10f);vertices[3].TextureCoordinate = new Vector2(0f, 0f);vertices[4].Position = new Vector3(10f, 0f, 10f);vertices[4].TextureCoordinate = new Vector2(1f, 1f);vertices[5].Position = new Vector3(10f, 0f, -10f);vertices[5].TextureCoordinate = new Vector2(1f, 0f);

On remarque ici une première différence avec nos programmes précédents : plus de couleur mais une coordonnée de texture associée à chaque vertex. Le vertex 0 se trouve en haut à gauche du carré. La coordonnée (U,V) associée est donc (0, 0). On ancrera donc la partie supérieure gauche de la texture sur ce vertex. Le second vertex se trouve en haut à droite sa coordonnée est donc (0, 0). La partie supérieure droite va être ancrée sur lui. Ainsi de suite pour les 4 autres vertices. C'est exactement ce que nous avons vu au tout début de ce chapitre.

Nous devons aussi spécifier à notre effet que nous ne manipulons plus des vertices colorés, mais texturés. Pour cela modifiez la ligne :

this.effect.CurrentTechnique = effect.Techniques["Colored"];

this.effect.CurrentTechnique = effect.Techniques["Textured"];

Il a été vu précédemment que le device où est affiché notre jeu (la carte graphique principale donc) a besoin de connaître le type de vertices utilisé (c'est à dire leur format). Il est donc nécessaire dans la méthode de dessin de modifier la ligne :

this.graphics.GraphicsDevice.VertexDeclaration = new VertexDeclaration(this.graphics.GraphicsDevice, VertexPositionColor.VertexElements);

this.graphics.GraphicsDevice.VertexDeclaration = new VertexDeclaration(this.graphics.GraphicsDevice, VertexPositionTexture.VertexElements);

A ce stade, l'application, à l'exécution affiche un magnifique carré ... noir ! Tout est normal : nous n'avons pas encore utilisé de texture et nous n'utilisons plus de couleur.

Ajout de textures au projet...

Nous utiliserons la texture prise en exemple précédemment :

Celle-ci, nommée "texture.jpg" se trouve à la racine du répertoire HuitiemeChapitre. Ajoutez là en cliquant droit sur le nom du projet et en selectionnant "ajouter un élément existant" :

Dans la fenetre qui s'ouvre, choisissez "Content Pipeline" dans la combobox de choix de type de contenu et selectionnez le fichier texture.jpg.

Après validation

Déclarez un object de type Texture2D dans la classe Game1.

Texture2D texture;

C'est cet objet qui va nous permettre de manipuler les textures dans notre application. Rendez vous maintenant dans la méthode LoadGraphicsContent : Il nous faut y charger la texture mais aussi spécifier à notre effet que nous associons cette texture à l'affichage des vertices. Nous procédons comme ceci :

protected override void LoadGraphicsContent(bool loadAllContent){ if (loadAllContent) { // TODO: Load any ResourceManagementMode.Automatic content texture = content.Load<Texture2D>("texture"); effect.Parameters["xTexture"].SetValue(texture); } // TODO: Load any ResourceManagementMode.Manual content

}

L'objet content de type ContentManager s'occupe des ressources du jeu en évitant au développeur d'avoir à se soucier de leur gestion. La méthode Load, générique est son seul membre réellement interessant. Elle renvoie un objet du type spécifié en généricité à partir du path ressource donné. Ici :

texture = content.Load<Texture2D>("texture");

Nous indiquons la spécificité sur le type Texture2D et donnons en path la string "texture". Nous ne donnons pas l'extension ".jpg" car la méthode Load prend le nom AssetName. Pour voir sa valeur, selectionnez la texture dans le projet et appuyez sur F4 (ou cliquez droit sur ce fichier et faites Propriété). Dans la fenêtre d'outil qui s'ouvre le champs AssetName contient la string "texture". Vous pouvez toujorus changer cette valeur pour donner un nom explicite, mais faites attention à bien vous y retrouver lorsque vous avez plusierus centaines de fichiers ressources !

Si vous lancez l'application vous obtenez maintenant :

Voila nous avons terminé ! Comme exercice revenez sur le premier point de ce chapitre où l'ont voit différentes manière de texturer un carré. Appliquez ces différentes possibilités à votre programme pour les tester.

Vous pouvez télécharger le sample, les deux moteurs et les exercices ici.

Ajout de textures et de couleurs au projet...

Avant de passer aux choses sérieuses, nous allons tenter d'associer trois données à chaque vertex :

La position bien évidemment
La texture
Une couleur

Nous utiliserons pour cela la structure de format de vertex VertexPositionColorTexture en lieu et place de VertexPositionTexture.

La déclaration des vertices sera modifiée de manière a spécifier le champs color comme auparavant :

vertices = new VertexPositionColorTexture; //triangle 1, face devantvertices[0].Position = new Vector3(-10f, 0f, -10f);vertices[0].TextureCoordinate = new Vector2(0f, 0f);vertices[0].Color = Color.Green;vertices[1].Position = new Vector3(-10f, 0f, 10f);vertices[1].TextureCoordinate = new Vector2(0f, 1f);vertices[1].Color = Color.Red;vertices[2].Position = new Vector3(10f, 0f, 10f);vertices[2].TextureCoordinate = new Vector2(1f, 1f);vertices[2].Color = Color.Yellow;//triangle 2, face devantvertices[3].Position = new Vector3(-10f, 0f, -10f);vertices[3].TextureCoordinate = new Vector2(0f, 0f);vertices[3].Color = Color.Green;vertices[4].Position = new Vector3(10f, 0f, 10f);vertices[4].TextureCoordinate = new Vector2(1f, 1f);vertices[4].Color = Color.Red;vertices[5].Position = new Vector3(10f, 0f, -10f);vertices[5].TextureCoordinate = new Vector2(1f, 0f);

vertices[5].Color = Color.Yellow;

Faites bien attention à remplacer partout VertexPositionTexture.

Si vous lancez cette nouvelle version du programme, vous obtenez la même sortie qu'auparavant : et pour cause, notre fichier effet ne permet pas de gérer les vertices qui possèdent à la fois une coordonnée de texture et une couleur. Deux possibilités face à ce problème : chercher un fichier effet qui permet cela, ou utiliser celui de base inclu dans le framework. C'est cette seconde option que nous utiliserons pour sa simplicité.

La classe BasicEffect est une classe qui encapsule en interne un fichier effet (.fx) pratiquement identique à celui que nous utilisions jusque là. Elle offre une interface objet simple et intuitive pour paramétrer la façon dont les vertices sont affichés à l'écran.

Remarque : Pourquoi ne pas avoir directement utilisé cette classe au tout début de notre apprentissage ? Pour des raisons de compréhension : lorsqu'on travaille à trop haut niveau les API nous cachent se qui se passe réellement dans les couches basses des fonctionnalités utilisées. On se trouve souvent ainsi confrontés à des bugs incompréhensibles faute de connaissances techniques... Ce qui a été appris jusqu'ici sera très utile lorsque nous aborderons le chapitre sur les effets.

Supprimez toutes les références vers la classe Effect et son instance effect du programme. Ajoutez la déclaration suivante dans la classe Game1 :

BasicEffect effect;

Dans la méthode Initialize ajoutez le code suivant :

effect = new BasicEffect(this.graphics.GraphicsDevice, null);
effect.VertexColorEnabled = true;
effect.TextureEnabled = true;
effect.View = viewMatrix;
effect.Projection = projectionMatrix;
effect.World = Matrix.Identity;

Nous pouvons en convenir : le code est réellement plus simple ; Ecrire :

effect.View = viewMatrix;
effect.Projection = projectionMatrix;
effect.World = Matrix.Identity;

est plus lisible que

effect.Parameters["xView"].SetValue(viewMatrix);
effect.Parameters["xProjection"].SetValue(projectionMatrix);
effect.Parameters["xWorld"].SetValue(Matrix.Identity);

Les deux premières instructions indiquent que les vertices affichés à l'écran gèrent à la fois la couleur et les textures :

effect.VertexColorEnabled = true;
effect.TextureEnabled = true;

Reste a affecter la dite texture dans la méthode LoadGraphicsContent de cette manière :

effect.Texture = texture;

Si vous lancez maintenant l'application le résultat est meilleur :

La couleur de chaque texel de la texture a été "aditionnée" à la couleur du pixel du carré issue de la couleur du vertex sous jacent.

Pour la suite de nos applications nous utiliserons la classe BasicEffect.

Vous pouvez télécharger le sample, les deux moteurs et les exercices ici.

Passons aux choses sérieuses...

Nous allons maintenant modifier la classe Cube du chapitre précédent afin de lui faire afficher une texture. Il lui sera aussi ajouté un objet de type BasicEffect afin de mettre la gestion de l'affichage des vertices au niveau du cube et non au niveau de tous les cubes. De même, pour changer un peu, une nouvelle texture (qui devrait rappeller de bon souvenirs) sera utilisée:

La classe Cube va contenir deux nouveaux champs :

private Texture2D _texture;

private BasicEffect _effect;

et deux nouvelles propriétés :

/// <summary>/// <para>Gets the cube's effect.</para>/// </summary>public BasicEffect Effect{ get { return this._effect; }} /// <summary>/// <para>Gets or sets the cube's texture.</para>/// </summary>public Texture2D Texture{ get { return this._texture; } set { this._texture = value; this._effect.Texture = value; }

}

Une méthode InitializeEffect est ajoutée pour initialiser notre effet :

private void InitializeEffect()
{
    this._effect = new BasicEffect(this._device, null);
    this._effect.VertexColorEnabled = true;
    this._effect.TextureEnabled = true;

}

La méthode Render est modifiée en conséquence :

public void Render(){ this._effect.Begin(); foreach (EffectPass pass in this._effect.CurrentTechnique.Passes) { pass.Begin(); this._device.Vertices[0].SetSource(this._vertexBuffer, 0, VertexPositionColorTexture.SizeInBytes); this._device.Indices = this._indexBuffer; this._device.VertexDeclaration = new VertexDeclaration(this._device, VertexPositionColorTexture.VertexElements); this._device.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, 24, 0, 12); pass.End(); } this._effect.End();

}

Le code de la classe est maintenant largement simplifié. Il ne nous reste plus qu'à modifier la déclarations des 8 vertices du cube pour leur donner à chacun, une coordonnée de texture. En fait il y'a ici un problème. Nous avons 8 vertices pour 6 faces et donc 12 triangles. Donc chaque vertex du cube est utilisé pour plusieurs faces. L'image suivant illustre le problème :

Le vertex rouge est utilisé par plusieurs face

Si on prend le vertex surmonté d'un point rouge, on remarque que celui-ci appartient à trois faces :

La rouge pâle
La jaune pâle
La bleue pâle

Comment donner à ce vertex une coordonnée de texture dans ces conditions ? Pour la face rouge, ce vertex se trouve en bas à droite il aurait donc la coordonnée (1,1), or pour la face jaune il est en haut à droite et possède donc l'emplacement (1,0) sans parler de la face bleue dans laquelle il a la coordonnée (0,0) soit haut gauche. En fait chaque point du cube (au total 8 points) appartiennent à 3 faces. Il est donc nécessaire de créer non pas 8 vertices pour un cube mais 24 : chaque face possèdera ses propres vertices non partagés avec les autres faces, nous avons 6 faces de 4 vertices donc 24 vertices. Il ne s'agit pas ici d'une regression ; nous ne revenons pas au cube du tutoriel 5 qui possédait 36 vertices. La méthode InitializeVertices se présente désormais ainsi :

private void InitializeVertices(){ VertexPositionColorTexture[] vertices = new VertexPositionColorTexture[24]; //face devant vertices[0].Position = new Vector3(0f, 0f, 0f); vertices[0].Color = this.Color; vertices[0].TextureCoordinate = new Vector2(0, 1); vertices[1].Position = new Vector3(0f, 0f, 1f); vertices[1].Color = this.Color; vertices[1].TextureCoordinate = new Vector2(0, 0); vertices[2].Position = new Vector3(1f, 0f, 1f); vertices[2].Color = this.Color; vertices[2].TextureCoordinate = new Vector2(1, 0); vertices[3].Position = new Vector3(1f, 0f, 0f); vertices[3].Color = this.Color; vertices[3].TextureCoordinate = new Vector2(1, 1); //face derrière vertices[4].Position = new Vector3(1f, 1f, 1f); vertices[4].Color = this.Color; vertices[4].TextureCoordinate = new Vector2(0, 0); vertices[5].Position = new Vector3(1f, 1f, 0f); vertices[5].Color = this.Color; vertices[5].TextureCoordinate = new Vector2(0, 1); vertices.Position = new Vector3(0f, 1f, 0f);// vertices.Color = this.Color; vertices.TextureCoordinate = new Vector2(1, 1); vertices[7].Position = new Vector3(0f, 1f, 1f); vertices[7].Color = this.Color; vertices[7].TextureCoordinate = new Vector2(1, 0); //face gauche vertices.Position = new Vector3(0f, 1f, 0f);// vertices.Color = this.Color; vertices.TextureCoordinate = new Vector2(0, 1); vertices[9].Position = new Vector3(0f, 1f, 1f); vertices[9].Color = this.Color; vertices[9].TextureCoordinate = new Vector2(0, 0); vertices[10].Position = new Vector3(0f, 0f, 1f); vertices[10].Color = this.Color; vertices[10].TextureCoordinate = new Vector2(1, 0); vertices[11].Position = new Vector3(0f, 0f, 0f); vertices[11].Color = this.Color; vertices[11].TextureCoordinate = new Vector2(1, 1); //face droite vertices[12].Position = new Vector3(1f, 0f, 0f); vertices[12].Color = this.Color; vertices[12].TextureCoordinate = new Vector2(0, 1); vertices[13].Position = new Vector3(1f, 0f, 1f); vertices[13].Color = this.Color; vertices[13].TextureCoordinate = new Vector2(0, 0); vertices[14].Position = new Vector3(1f, 1f, 1f);// vertices[14].Color = this.Color; vertices[14].TextureCoordinate = new Vector2(1, 0); vertices[15].Position = new Vector3(1f, 1f, 0f); vertices[15].Color = this.Color; vertices[15].TextureCoordinate = new Vector2(1, 1); //face haut vertices[16].Position = new Vector3(0f, 0f, 1f);// vertices[16].Color = this.Color; vertices[16].TextureCoordinate = new Vector2(0, 1); vertices[17].Position = new Vector3(0f, 1f, 1f); vertices[17].Color = this.Color; vertices[17].TextureCoordinate = new Vector2(0, 0); vertices[18].Position = new Vector3(1f, 1f, 1f); vertices[18].Color = this.Color; vertices[18].TextureCoordinate = new Vector2(1, 0); vertices[19].Position = new Vector3(1f, 0f, 1f); vertices[19].Color = this.Color; vertices[19].TextureCoordinate = new Vector2(1, 1); //face bas vertices[20].Position = new Vector3(1f, 0f, 0f); vertices[20].Color = this.Color; vertices[20].TextureCoordinate = new Vector2(0, 1); vertices[21].Position = new Vector3(1f, 1f, 0f); vertices[21].Color = this.Color; vertices[21].TextureCoordinate = new Vector2(0, 0); vertices[22].Position = new Vector3(0f, 1f, 0f);// vertices[22].Color = this.Color; vertices[22].TextureCoordinate = new Vector2(1, 0); vertices[23].Position = new Vector3(0f, 0f, 0f); vertices[23].Color = this.Color; vertices[23].TextureCoordinate = new Vector2(1, 1); if (this.IsObjectOriginInCubeCenter) for (int i = 0; i < 24; i++) vertices.Position += new Vector3(-0.5f, -0.5f, -0.5f); this._vertexBuffer = new VertexBuffer( this._device, typeof(VertexPositionColorTexture), 24, ResourceUsage.WriteOnly, ResourceManagementMode.Automatic); this._vertexBuffer.SetData(vertices);}

A noter la présence du bloc :

    if (this.IsObjectOriginInCubeCenter)
        for(int i = 0 ; i < 24 ; i++)
            vertices.Position += new Vector3(-0.5f, -0.5f, -0.5f);

J'ai rajouté sur demande de certains d'entre vous une propriétée nommée qui permet de préciser si le centre du cube doit coincider avec l'origine du repère de l'objet (pour plus d'information allez voir ici). L'origine se trouve par défaut sur le vertice 0, pour mettre l'origine au centre du cube il me suffit de déplacer tous les vertices de 0.5f unités car le cube a une taille de 1. Modifiez la méthode d'affichage pour indiquer que vous gérez non plus 8 vertices mais 24. Au lancement vous obtenez

(je reviendrais dans une annexe sur la manière de faire des mouvements amples et fluides pour ses objets dans une annexe prochainement).

Vous pouvez télécharger le sample, les deux moteurs et les exercices ici.

A ce stade de nos connaissances nous pouvons ...

L'information qui suit est à prendre avec des pincette mais elle donne toutefois une idée assez précise du niveau de nos connaissances à ce stade de notre apprentissage. Une partie de ceux qui lisent ces lignes ont sans doute déjà joué à l'un des épisode de la série à succès Tomb Raider (l'auteur de cours XNA a pour sa part joué aux version 1, 2, 3, 4). Nous sommes maintenant capable de réaliser des mondes tous à fait similaires à celui présenté par la capture d'écran ci-dessous :

Regardez attentivement cette image. Vous verrez qu'en fait, ce monde n'est constitué que de formes cubiques comme nous savons très bien les faire maintenant : des cubes, des cubes coupés sur leur diagonale, des cubes coupés en leur milieu etc. C'est là toute l'ingéniosité et toute la puissance du moteur de Core/Eidos : reproduire n'importe quelle architecture/géographique à l'aide de ces formes. Les mouvements de Lara sont d'ailleur soumi à une seule unité de mesure : la taille d'un cube. Ce principe assez proche des jeux de plateforme 2D permet de gérer les collisions et les déplacements très facilement et de créer des formes à l'écran simplement. Core/Eidos peut donc créer des mondes et développer un moteur beaucoup plus rapidement que des moteurs complexes comme celui de World Of Warcraft (que nous reproduirons à la fin de cet apprentissage).

Si le temps nous le permet nous essayerons de reproduire un monde à base de cubes.

Les filtres

Introduction

Tous ceux qui ont travaillé avec des programmes d’édition d’images comme paint shop pro ou photoshop sont familiers des effets de pixellisation. On obtient cet effet désagréable lorsqu’on réduit la taille d’une image selon un rapport impair. Résultat : de nombreux détails sont perdus et la qualité de l'image s'en ressent. Pour éviter cela, les bons programmes d’édition d’images proposent différentes techniques de réduction ou d'augmentation de taille d'image aussi nommées filtrage pour réduire au minimum les pertes dues au changement de taille. XNA aussi.

Pour mieux comprendre, voici un exemple concrêt : Quand XNA affiche une primitive, il plaque un modèle 3-D sur un écran 2-D. Si la primitive possède une texture, XNA doit utiliser cette dernière afin de créer une couleur pour chaque Pixel de ce modèle en utiliser une valeur de couleur de la texture. C'est ce processus qu'on appelle filtrage de texture.

Quand une opération de filtre de texture est effectuée, la texture utilisée est "magnifiée" (agrandie) ou "minifiée" (réduite). En d'autres termes, elle est plaquée sur une primitive qui est plus grande ou plus petite que sa propre taille. La magnification d'une texture peut avoir comme conséquence l'utilisation d'un seul texel (point de couleur dans une texture) pour colorer un grand nombre de Pixel à l'écran. L'image résultante peut être volumineuse et pixelisée. La Minification d'une texture au contraire signifie souvent qu'un Pixel simple se substitue à plusieurs texels. L'image résultante peut être trouble . Pour résoudre ces problèmes, se mélanger des couleurs de texel doit être effectué pour arriver à une couleur pour le Pixel.

XNA tout comme DirectX fournit plusieurs types de filtrage de texture (lineaire, anisotropic, gaussien ...) et un système de mipmapping (notion sur laquelle nous reviendrons plus loin). Si vous ne choisissez aucun filtre, XNA emploie une technique appelée nearestpoint sampling (en gros : choix du texel le plus proche).

Chaque type de filtrage de texture a des avantages et des inconvénients. Par exemple, le filtrage linéaire de texture peut produire des bords déchiquetés ou un aspect volumineux dans l'image finale. Cependant, c'est un filtre très simple et rapide à mettre en place à faible coùt de mémoire. Le filtrage anisotrope demande plus de temps processeur et beaoucp plus de mémoire.

L’exemple suivant dans le jeu Might and Magic le montre bien :

La maison vu de loin est belle ...

... mais quand on s’approche ... tout est pixellisé et ... hideux le jeu à l'époque, manquait d'un bon filtre de texture...

Might and Magic dans sa version 6 (NDA : la meilleure version) n'était pas très avancé graphiquement parlant. Le jeu manquait en autres choses d'un bon filtrage de texture. La première image montre un batiment dans la ville de Sorpigal. Vu de loin, la texture qui est plaquée sur ce batiment semble normale, mais comme le montre la seconde image, si l'on s'approche, un filtre nearest point sampling est effectué pour créer une magnification : on agrandit énormément la texture. En ressort alors un très désagréable effet de pixelisation. Dans la première image, la surface visible du batiment est d'environ 300*200. On s'approche donc de la taille de cette texture : l'affichage est donc optimal. Dans la seconde image la surface d'affichage pour la texture passe a 450*350 et ce pour n'afficher que 8% de la texture ! L'utilisation d'un bon filtrage permet d'éviter cet effet pixélisé horrible.

Et Xna dans tout ça ?

XNA offre au développeurs 5 filtrages (tous énuméré dans le type TextureFilter) :

Membre	Description
GaussianQuad	Un filtre 4-sample Gaussien pour la magnification ou la minification.
PyramidalQuad	Un filtre 4-sample pour la magnification ou la minification.
Anisotropic	Un filtre de texture anisotrope utilisé pour la magnification ou la minification. Les filtres anisotrope compensent la distorsion représentent par l'angle du polygone à mapper et la position de la caméra.
Linear	Un filtre de texture anisotrope utilisé pour la magnification ou la minification. Une moyenne pondérée de 2x2 texels autour du texel concerné est utilisé.
Point	Un filtre de texture point utilisé pour la magnification ou la minification. Le texel avec les coordonnées les plus proches du pixel voulu est utilisé.
None	Aucun filtre.

C'est la propriété SamplerStates de l'objet GraphicsDevice qui va nous permettre de spécifier le filtrage à appliquer en minification et/ou en magnification.
Si nous voulons appliquer un filtre anisotrope en mignification et lineaire en magnignification nous ferons :

this.graphics.GraphicsDevice.SamplerStates[0].MinFilter = TextureFilter.Anisotropic;
this.graphics.GraphicsDevice.SamplerStates[0].MagFilter = TextureFilter.Linear;

...pas très compliqué. Nous utilisons ici la propriété SamplerStates comme un tableau tout simplement parcequ'il est possible de plaquer plusieurs textures sur un même polygone (jusqu'à 8 textures). Nous appliquons ici nos filtres MinFilter et MagFilter sur la première texture (0). La classe SamplerState possède de nombreux membres pour la gestion de l'affichage des textures à l'écran. Nous les verrons tous dans ce chapitre.

Un exemple concrêt

Rien de mieux pour bien comprendre l'effet d'un filtre à l'écran que de développer un exemple. Nous reprendrons le dernier projet pour y effectuer quelques menues modifications. Voici ce que nous allons faire : un cube va être affiché en gros plan. Il tournera sur lui-même a vitesse très réduite de sorte de bien mettre en évidence les différents filtres que nous appliquerons. Les filtres seront selectionnés au clavier : la touche 'A' pour anisotope, 'L' pour linéaire, 'P' pour point, 'G' pour Gaussian, 'Q' pour Pyramidal, 'N' pour aucun. Si la touche Shift est appuyée en même temps, le filtre s'applique en magnification, sinon, en minification.

En fait le sample sera rapide à écrire, nous n'allons ajouter qu'une vingtaine d'instructions. Première étape, la classe Cube. Ajout de deux membres et deux propriétés associées pour sauvegarder le filtre en magnification et minification :

        private TextureFilter _minfilter;
        private TextureFilter _magfilter;

        public TextureFilter MagTextureFilter
        {
            get
            {
                return this._magfilter;
            }
            set
            {
                this._magfilter = value;
            }
        }

        public TextureFilter MinTextureFilter
        {
            get
            {
                return this._minfilter;
            }
            set
            {
                this._minfilter = value;
            }

}

Seconde étape : Application des filtres dans la méthode Render :

/// <summary>/// <para>Render the cube on the device.</para>/// </summary>public void Render(){ this._effect.Begin(); foreach (EffectPass pass in this._effect.CurrentTechnique.Passes) { pass.Begin(); this._device.SamplerStates[0].MinFilter = _minfilter; this._device.SamplerStates[0].MagFilter = _magfilter; this._device.Textures[0] = this.Texture; this._device.Vertices[0].SetSource(this._vertexBuffer, 0, VertexPositionColorTexture.SizeInBytes); this._device.Indices = this._indexBuffer; this._device.VertexDeclaration = new VertexDeclaration(this._device, VertexPositionColorTexture.VertexElements); this._device.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, 24, 0, 12); pass.End(); } this._effect.End();

}

C'est terminé ! La classe Game1 a bien entendu été modifiée pour pouvoir affecter au cube le filtre voulu suivant la touche clavier appuyée. A l'exécution, l'application se présente ainsi :

En jouant avec les touches a, A, l, L, p, P, g, G, q, Q, n ou N on peut facilement voir les différences de qualité entre tous les filtres suivant les angles de vue et la distance du cube. Les deux images suivants explicite cela. En mode point, le cube en courte distance donne l'affichage pixélisé suivant :

Le zoom sur la face du cube en mode point montre bien l'effet de pixalisation. Maintenant la même face en anisotropie :

donne un bien meilleur résultat visual.

Cet exemple n'est qu'une première approche des filtres. Il met en évidence l'importance qu'ils revettent pour le design et l'aspect de nos productions. C'est aussi un élément important à prendre en compte si l'on veut rendre son jeu accessible à tous, un filtre gourmant comme l'anisotrope doit être un choix et non une obligation.

Pour cela vous devez toujours vérifier avant toute chose que la machine sur laquelle tourne votre application supporte la technologie ou la fonctionnalité que vous voulez utiliser. D'une manière générale faites donc toujours des tests par rapport à la propriété GraphicsDeviceCapabilities de l'objet GraphicsDevice. Cette propriété de type GraphicsDeviceCapabilities contient un ensemble de booléean et d'énumération indiquant toutes les fonctionnalités et technologies supportés par le matériel en rapport avec le device courant. Pour savoir si l'anisotrop est supporté, faites un test sur :

this.graphics.GraphicsDevice.GraphicsDeviceCapabilities .TextureFilterCapabilities.SupportsMagnifyAnisotropic

this.graphics.GraphicsDevice.GraphicsDeviceCapabilities.TextureFilterCapabilities.

pour la magnification et sur :

this.graphics.GraphicsDevice.GraphicsDeviceCapabilities .TextureFilterCapabilities.SupportsMinifyAnisotropic

pour la minification.

Remarque : une annexe sera écrite prochainement et consacrée uniquement à l'importance des tests sur les capacités du matériel avant l'exécution.

De même (mais là nous voyons vraiment loin) il est préférable de proproser les fonctionnalités poussées comme ce filtre dans un menu d'option.

Le mip mapping

Mip vient du latin Multum in parvo, qui signifie « beaucoup de choses dans un petit endroit ».

Principe

Le mipmapping est une technique visant à améliorer l'affichage des textures sur les polygones en prennant en compte la distance comprise entre le dit polygone et la position de la caméra. Le niveau de détail des textures est adapté à la distance de l'objet. Ainsi, un objet proche de la caméra affichera des textures en haute résolution tandis qu'un objet situé au loin sera plaqué avec une texture de petite taille.

Chaque texture utilisée dans un processus de mip mapping est appellé "niveau de MIP map" ou LOD (pour Level Of Detail). Elles sont choisies suivant la distance à la caméra. La technique du MIP mapping consiste à envoyer au GPU des textures de résolutions décroissantes qui seront utilisées à la place de la texture originale. Le choix de la texture ayant la taille la plus adaptée s'effectue selon la distance du point de vue de l'objet texturé et le niveau de détails nécessaire. Le GPU n'a alors plus qu'à appliquer les bonnes textures sur les bons objets suivant leur éloignement, réadaptant la texture chaque fois que l'objet se rapproche. La texture utilisée lors du rendu sera alors celle dont la résolution est la plus proche de celle de l'objet sur l'image projetée. Chaque niveau doit avoir pour hauteur et largeur la moitié de la hauteur et largeur du niveau précédent. Le dernier niveau a bien évidemment au moins un coté égal à 1.

Par exemple, d'une image d'une taille de 256x256 pixels seront produits les mêmes images aux résolutions de 128x128 pixels, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2 et 1x1. Si la taille de l'objet sur l'image projetée à l'écran est de 30x30 pixels, la texture utilisée sera alors celle de résolution 32x32 pixels.

Le filtrage joue ici un rôle primodial en évitant de voir les "sauts" lors du passage d'une texture à l'autre, grâce à une transition progressive.

Quel est l'interet de du mip mapping ? Si cette technique est gourmande en mémoire vidéo (elle consomme un tiers de mémoire en plus), elle est plus rapide : La diminution du nombre de texels à traiter et des opérations de filtrages en temps réel de la texture permettent un rendu plus rapide de l'image. De plus le choix des différents niveaux de mipmap peut être laissé à l'apprecciation du développeur : Souvent laisser votre machine opérer pour voir les filtres peut donner un résultat qui s'avère desastreux et ce, même avec les meilleures techniques de filtrage. Prennez l'exemple de l'image suivante qui pourrait se trouver dans un de vos jeu :

Le message qu'elle véhicule est clair : tirer sur la cible fait perdre le joueur. Si nous laissons la machine gérer le mip mapping et la réduction de la texture nous pouvons obtenir le résultat suivant

C'est cette texture qui pourrait etre plaqué sur une forme 3D se trouvant loin du joueur. Celui-ci ne voyant pas le message tirera à coup sur. En fait l'algorythme de réduction d'image ne se préoccupe pas de l'information que l'image porte dans le mesure où il ne peut la quantifier. Il ne prend donc pas en compte l'importance de laisser le texte visible après une réduction n'est donc pas pris en compte dans le calcul du filtre. Si ce n'est pas la machine qui effectue cette tâche mais une personne, celle-ci peut réduire l'image de manière intelligente en gardant l'information visible au maximum :

Paramétrage du Mipmapping

Deux paramètres peuvent intervenir dans l'affichage d'une texture mipmappée : Le MaxAnisotropy et le MipMapLevelOfDetailBias.

MaxAnisotropy

L’anysotropie est un filtre intelligent et assez gourmant en ressource (bien qu’il soit souvent intégré au hardware des cartes graphiques). Il se base sur l’aspect graphique de l’objet sur lequel on plaque la texture. Les texels ne sont pas tirés d’une forme symétrique, mais plutôt en utilisant un motif irrégulier ajusté à la perspective (on parle de figure anisotropique). Le nombre de texels pris en compte pour ce filtrage détermine la qualité de celui-ci. Avec le filtrage anisotropique 1x, on prend 8 texels. Le niveau maximum est 16x, les plus courants sont 2x (16 texels), 4x (32 texels), 8x (64 texels) et 16x (128 texels). Plus la valeur de MaxAnisotropy est importante, et plus le niveau de filtrage est élevé, et forcement, plus le temps de calcul augmente (et ceci de manière exponentielle…).

MipMapLevelOfDetailBias

Il arrive que pour la beauté du jeu il faille garder un LOD plus longtemps que prévu en retardant le passage à un LOD inférieur lorsque la caméra s’éloigne par exemple. C’est le LOD bias qui permet de réaliser cette opération. Si une surface s’éloigne de l’utilisateur, augmenter le LOD bias revient à retarder l’utilisation du LOD inférieur. Au contraire, en diminuant sa valeur, on passe plus rapidement aux LOD inférieurs.

Après la théorie, la pratique !

Il est temps de passer aux choses sérieuses. Le sample que nous allons réaliser ici aura pour but de mettre en évidence le mipmaping et les impacts des différents filtres. Nous allons réaliser pout cela un damier de 64 cases sur 64 cases. Chaque case sera associée à une texture "mipmappée". La camera pourra se déplacer sur ce damier et nous pourrons ainsi voir, en se déplaçant l'évolution des textures sur les différentes cases. Nous aurons trois types de textures : des textures de couleur qui permettrons d'apprecier facilement le passage entre deux LOD, des textures représentant un sol pavé pour voir en réel ce que nos choix produisent, une texture damier pour apprécier la qualité des filtres.

La première étape consiste donc à créer ce qui va être notre premier terrain de jeu. A ce stade de nos connaissances il y a ici aucune difficulté : ayant déjà développé des applications affichants un carré, nous sommes largement en mesure de créer un monde constitué de 64 carrés sur 64 carrés. Ouvrez le projet nommé "TroisiemeProjetMipmap". Une nouvelle classe Region fait son apparition. Elle sera chargé de la création et de l'affichage d'un terrain. Elle possède un seul vertexbuffer et un seul indexbuffer. Le vertexbuffer contiendra les 64*64 cases du terrain, sachant que chaque case possède 4 vertices. La méthode InitializeVertices se présente comme suit :

private void InitializeVertices(){ float caseSize = 16; VertexPositionColorTexture[] vertices = new VertexPositionColorTexture[_numberOfVertices]; int index = 0; for (int j = 0; j < this._depth; j++) { for (int i = 0; i < this._width; i++) { vertices[index].Position = new Vector3(i * caseSize, j * caseSize, 0f); vertices[index].Color = this.Color; vertices[index].TextureCoordinate = new Vector2(0, 0); vertices[index +1 ].Position = new Vector3(i * caseSize + caseSize, j * caseSize, 0f); vertices[index +1 ].Color = this.Color; vertices[index +1 ].TextureCoordinate = new Vector2(1, 0); vertices[index + 2].Position = new Vector3(i * caseSize + caseSize, j * caseSize - caseSize, 0f); vertices[index + 2].Color = this.Color; vertices[index + 2].TextureCoordinate = new Vector2(1, 1); vertices[index + 3].Position = new Vector3(i * caseSize, j * caseSize - caseSize, 0f); vertices[index + 3].Color = this.Color; vertices[index + 3].TextureCoordinate = new Vector2(0, 1); index+=4; } } this._vertexBuffer = new VertexBuffer( this._device, typeof(VertexPositionColorTexture), _numberOfVertices, ResourceUsage.WriteOnly, ResourceManagementMode.Automatic); this._vertexBuffer.SetData(vertices);

}

Les membres depth et width représentent la profondeur et la largeur du monde (ils possèdent donc pour valeur 64 chacun donc). La double boucle for parcours le monde de jeu sur chaque ligne et chaque colonne en créant un carré à chaque fois. La valeur caseSize représente la taille d'un carré. Rien de compliqué ici. La méthode InitializeIndices est la suivante :

private void InitializeIndices(){ short[] indices = new short[_numberOfIndices]; short index = 0; short indexCase = 0; for (int j = 0; j < this._depth; j++) { for (int i = 0; i < this._width; i++) { indices[index] = indexCase; indices[index + 1] = (short)(indexCase + 1); indices[index + 2] = (short)(indexCase + 3); indices[index + 3] = (short)(indexCase + 1); indices[index + 4] = (short)(indexCase + 2); indices[index + 5] = (short)(indexCase + 3); index += 6; indexCase += 4; } } this._indexBuffer = new IndexBuffer( this._device, typeof(short), _numberOfIndices, ResourceUsage.WriteOnly, ResourceManagementMode.Automatic); this._indexBuffer.SetData(indices);

}

Nous spécifions 6 indices pour chaque carrés (une case équivaut à deux triangles de 3 points). Rien de vraiment compliqué là encore. Terminons sur cette classe en ajoutant qu'une propriété TextureMipMapFilter a été ajoutée afin de pouvoir spécifier un filtre mipmap depuis la classe Game1.

Chaque texture utilisée sera un mipmap composé de 6 LODs (256*256, 128, 60, 32, 16 et enfin 8). De la même façons que le premier projet de ce chapitre nous allons incorporer les LODs de chaque texture dans le projet. La texture colorée possédera les LOD suivants :

chaque couleur permettra de bien discerner les niveaux de mip map utilisé. La texture de sol utilisera les LOD suivants:

Chaque LOD a été placé dans un répertoire du projet nommé MipMapTextures de la même façon que pour le premier projet de ce chapitre. C'est la classe Game1 qui va former les trois textures composée de 6 LODs. Dans celle-ci se trouvent trois méthodes similaires nommées GenerateMipmap, GenerateMipmapTexture et GenerateMipmapCase respectivement pour la texture colorée, de sol et de damier. A noter qu'on aurait pu ici factoriser le code en une seule méthode, mais pour des raisons de compréhension, cela n'a pas été fait. Ces trois méthodes étant similaires, nous n'en verrons qu'une :

private void GenerateMipmap(){ Texture2D mainTexture = new Texture2D(this.graphics.GraphicsDevice, 256, 256, 6, ResourceUsage.Dynamic, SurfaceFormat.Color, //std 32 bits mode ResourceManagementMode.Manual); Texture2D texture256 = content.Load<Texture2D>("MipmapTextures\\256"); Texture2D texture128 = content.Load<Texture2D>("MipmapTextures\\128"); Texture2D texture064 = content.Load<Texture2D>("MipmapTextures\\64"); Texture2D texture032 = content.Load<Texture2D>("MipmapTextures\\32"); Texture2D texture016 = content.Load<Texture2D>("MipmapTextures\\16"); Texture2D texture008 = content.Load<Texture2D>("MipmapTextures\\8"); uint[] array = new uint[256 * 256]; texture256.GetData<uint>(array); mainTexture.SetData<uint>(0, null, array, 0, array.Length, SetDataOptions.None); array = new uint[128 * 128]; texture128.GetData<uint>(array); mainTexture.SetData<uint>(1, null, array, 0, array.Length, SetDataOptions.None); array = new uint[64 * 64]; texture064.GetData<uint>(array); mainTexture.SetData<uint>(2, null, array, 0, array.Length, SetDataOptions.None); array = new uint[32 * 32]; texture032.GetData<uint>(array); mainTexture.SetData<uint>(3, null, array, 0, array.Length, SetDataOptions.None); array = new uint[16 * 16]; texture016.GetData<uint>(array); mainTexture.SetData<uint>(4, null, array, 0, array.Length, SetDataOptions.None); array = new uint[8 * 8]; texture008.GetData<uint>(array); mainTexture.SetData<uint>(5, null, array, 0, array.Length, SetDataOptions.None); _sampleMipmapColor = mainTexture;}

Cette méthode charge dans une variable locale nommée 6 LOD. Si quelque chose vous semble obscur de les explications suivent, reportez vous à la présentation du premier projet au tout début de ce chapitre. La première instruction

    Texture2D mainTexture = new Texture2D(this.graphics.GraphicsDevice,
        256, 256,
        6,
        ResourceUsage.Dynamic,
        SurfaceFormat.Color, //std 32 bits mode
        ResourceManagementMode.Manual);

créé la texture qui va contenir les LOD. Nous n'utilisons pas la classe Content pour la créer et nous aurons donc à la gérer nous même (nous reviendrons sur ce point plus loin). Une référence vers le device est bien évidemment donnée ainsi qu'une taille de 256*256. C'est à dire la taille du premier Level Of Detail. La valeur 6 représente le nombre de LOD que nous utilisons. ResourceUsage.Dynamic indique que nous laissons le driver décider ou placer le buffer contenant les données de la texture. En général si il y'a la place, celui-ci est placé dans la mémoire AGP, sinon dans la mémoire vidéo, sinon en dernier cas dans la RAM. Un bon jeu sais se référer à la taille mémoire pour placer les textures les plus utilisées en AGP et les autres moins importantes dans la RAM afin d'optimiser les affichages (nous vérrons celà dans la quatrième partie de cet apprentissage). Le paramètre SurfaceFormat.Color indique simplement que la texture aura un format de type 32 bits standard (ARGB : 8bits pour l'alpha, 8 pour la composante Rouge, 8 pour le vert et 8 pour le bleu, soit 256 variations par composantes). Enfin ResourceManagementMode.Manual précise que nous gérons nous même la vie de la texture (a nous de la recréer lorsqu'elle est "perdue". Vient ensuite le chargement des 6 LODs :

    Texture2D texture256 = content.Load<Texture2D>("MipmapTextures\\256");
    Texture2D texture128 = content.Load<Texture2D>("MipmapTextures\\128");
    Texture2D texture064 = content.Load<Texture2D>("MipmapTextures\\64");
    Texture2D texture032 = content.Load<Texture2D>("MipmapTextures\\32");
    Texture2D texture016 = content.Load<Texture2D>("MipmapTextures\\16");
    Texture2D texture008 = content.Load<Texture2D>("MipmapTextures\\8");

Rien de compliqué ici. La valeur "256" est le nom Asset de la texture et "MipmapTextures" le path vers celle-ci (voir premier projet au début de ce chapitre). Les instructions qui suivent créént le Mipmap. Mais qu'est ce qu'un Mipmap sur le plan technique ? Il s'agit (pour parler simplement) d'une sorte de liste chainée. Chaque texture à l'intérieur possède pour taille la moitiée de son prédécesseur et est deux fois plus grande que son successeur directe. La première texture de cette liste à la taille la plus importante, la dernière la plus petite. Cette liste va être "ratachée" à une texture qui va faire office de "pointeur". Suivant le degré de détail voulue, la texture va pointer sur telle ou telle élément de la liste. Créer cette structure en Xna/C# est relativement aisé. Il nous suffit d'associer une texture (notre pointeur) à un ensemble de buffers correspondant aux différents LODs. C'est les méthodes GetData et SetData qui vont nous permettre cela. Prenons exemple du chargement du buffer correspondant au troisième LOD :

    array = new uint[64 * 64];
    texture064.GetData<uint>(array);
    mainTexture.SetData<uint>(2, null, array, 0, array.Length, SetDataOptions.None);

Première instruction, nous créeons un array de uint (entier non signés) qui va faire office de buffer. La seconde instruction charge ce buffer à partir des données de la texture ayant pour taille 64 par 64. Enfin, la troisième instruction associe ce buffer au troisième LOD (index 2) de la texture "pointeur" (mainTexture). Le premier paramètre de correspond au niveau de LOD voulu, le second correspond à un objet de type Rectangle pour indiquer la zone du buffer que nous remplissons (ici null donc nous chargeons tout le buffer). Nous passons ensuite le buffer lui-même, indiquons à partir de quel index nous le lisons et sa taille. Le dernier paramètre de type SetDataOptions spécifie la manière dont on écrase le buffer déjà associé à ce LOD (si il y'en a un) : supprimé, comblé ou surchargé (soit respectivement SetDataOptions.Discard, SetDataOptions.NoOverwrite, SetDataOptions.None).

La partie LOD de notre programme est terminée ! Ne reste plus qu'à gérer le déplacement sur le terrain de jeu et la modification des différents filtres à l'aide des touches clavier. Pour cela, une simple analyse de la méthode Update vous suffira à ce stade de cos connaissances. Avant de lancer le programme, jetez juste un oeil à la méthode LoadGraphicsContent :

/// <summary>/// Load your graphics content. If loadAllContent is true, you should/// load content from both ResourceManagementMode pools. Otherwise, just/// load ResourceManagementMode.Manual content./// </summary>/// <param name="loadAllContent">Which type of content to load.</param>protected override void LoadGraphicsContent(bool loadAllContent){ if (loadAllContent) { } // TODO: Load any ResourceManagementMode.Manual content this.GenerateMipmapTexture(); this.GenerateMipmap(); this.GenerateMipmapCase(); this._terrain.Texture = _sampleMipmapColor;

}

Nous y plaçons le chargement de nos textures. Dans la mesure ou les 3 mipmaps sont chargés à l'aide de l'option ResourceManagementMode.Manual ce chargement se fait à l'extérieur du bloc conditionnel "if (loadAllContent)".

Il y'a deux types d'appel à cette méthode dans la vie d'une application Xna : le premier appel lors du lancement de l'application passe à cette méthode la valeur true. De ce fait toutes les ressources sont chargés à la fois dans le bloc if et à l'extérieur. Le second appel intervient lorsqu'il y'a perte de ressources (après un redimentionnement ou une réduction de la fenêtre ... tout ce qui peut obliger le device graphique à s'occuper d'une autre application au détriment de la notre), à ce moment là, Xna passe à la méthode false. Seules les ressources en dehors du bloc conditionnel sont donc chargés : à ce stade les ressources ResourceManagementMode.Automatic ont déjà été rechargée automatiquement.Dans la même sens nous devons gérer nous même la libération de ces ressources dans la méthode UnloadGraphicsContent :

/// <summary>/// Unload your graphics content. If unloadAllContent is true, you should/// unload content from both ResourceManagementMode pools. Otherwise, just/// unload ResourceManagementMode.Manual content. Manual content will get/// Disposed by the GraphicsDevice during a Reset./// </summary>/// <param name="unloadAllContent">Which type of content to unload.</param>protected override void UnloadGraphicsContent(bool unloadAllContent){ if (unloadAllContent == true) { content.Unload(); } this._sampleMipmapAuto.Dispose(); this._sampleMipmapColor.Dispose(); this._sampleMipmapTexture.Dispose();

}

là encore à l'extérieur du bloc conditionnel.

Pour preuve déplacez les quatres instructions de la méthode de chargement dans le bloc if. Lancez le programme et agrandissez la fenêtre : vous obtiendez une belle erreur spécifiant que le programme essaye d'accéder à une texture supprimée. Et pour cause au redimentionnement de la fenêtre les textures sont perdues et sont donc libérée de la mémoire. Lorsque le programme reprend la main il essaye d'utiliser ces textures pour l'affichage et plante forcement.

L'application

Les touches de l'application sont les suivantes : la touche 'A' pour anisotope, 'L' pour linéaire, 'P' pour point, 'G' pour Gaussian, 'Q' pour Pyramidal, 'N' pour aucun. Si la touche Shift est appuyée en même temps, le filtre s'applique en magnification, sinon, en minification. Si la touche Alt est appuyée, le filtre s'applique au Mipmap. Les touches fléchées permettent de se déplacer dans le monde. Les touches Page Haut et Page Bas permettent de prendre de l'altitude et de redescendre. Enfin les touche + et - augmentent le paramètre MaxAnisotropy (voir plus haut). Les mêmes touches avec Shift appuyé modifient le LodBias (voir plus haut). La touche espace ajoute une grille qui permet de bien discerner les cases du terrain de jeu (en fait le terrain est affiché une deuxième fois en mode WireFrame). Enfin les touches F1, F2, F3 affichent respectivement les texture de couleur, sol, damier.

Au lancement de l'application, vous obtenez l'affichage suivant :

Magnifiquement ... rouge, et pour cause : le mipmap n'est pas activé (None). Dans ce cas, le programme n'utilise que le LOD 0 qui correspond à la texture 256*256 qui est rouge. Appuyez sut les touches Alt et A pou lancer le mipmapping avec le filtre anisotropique. L'écran se change en :

Les différentes strates que vous voyez là correspondent aux 6 textures de LOD que nous avons chargée. On remarque parfaitement que suivant la distance à la caméra, les différentes cases du terrain de jeu affichent une texture adaptée à leur taille à l'écran :

Maintenant en maintenant la touche Shift appuyée appuyez sur la touche + (Add). Ceci a pour conséquence d'augmenter le Bias et donc le passage au LOD suivant :

Shift avec la touche - (Substract) réduit au contraire le Bias et prolonge la vie du LOD 0 :

Le filtre mipmap que nous avons utilisé ici (Anisotropique) est sans doute le meilleur. Le passage d'un Lod à un autre se fait de manière progressive et douce. Prennez un chouïa d'altitude à l'aide de la touche Page Haut. Si vous affichez la grille à l'aide de la touche Espace vous rendrez compte que cette transition ne dépend absolument pas de la case mais bien de la distance du "point" dans l'espace qui recoit la texture à la caméra :

Pour comprendre la puissance du filtre anisotropique, changez le filtre en filtre Point en appuyant sur les touches Alt + P. L'affichage qui apparait alors est rédibitoire ... :

Passons à un autre type de texture, la texture sol. Appuyez sur la touche F2 et annulez tout mipmaping à l'aide de la combinaisons Alt + N. Vous obtenez l'affichage suivant :

Aucun mipmapping et aucun filtre en mignification donne un résultat plus que décevant. Améliorons tout cela : Ajoutez un mipmapping avec filtre point (combinaison Alt + P) :

L'affichage est meilleur mais comme le montrent les deux lignes rouges nous voyons parfaitement les lignes de transition entre un Lod et un autre (avec la texture de couleur c'est encore plus flagrant). Et pour cause : le filtre point pour le mipmapping est des plus simples : lorsqu'il y'a besoin de faire une transition vers un autre LOD il utilise directement les texels de la texture voulue sans essayer de rendre la transition progressive. Si vous vous déplacez à l'aide des touches fléchées vous remarquez encore mieux cette transition. Nous pouvons toujours appliquer un filtre lineaire en mignification (touche L) :

mieux, mais la transition est toujours visible... Si on applique maintenant un filtre linaire pour le mipmapping (Alt + L), le rendu est quasi parfait :

On parle dans le cas du mipmapping avec filtre linaire de "filtrage trilineaire". Ce filtrage effectue une moyenne progressive entre les texels des textures concernées par la transitions d'un LOD à un autre. Même si vous vous déplacez, vous ne verrez pas la transition d'un LOD à un autre. A noter que le filtre trilinaire ou le filtre anisotropique donnent pratiquement le même résultat dans la mesure où nous affichons des formes relativement "droites".

Revenez à un affichage sans filtre (touche N et shift N) et sans mipmapping (touche Alt + N). Affichez la texture Damier avec F3 :

On voit que l'affichage n'arrive absolument pas a gérer les lignes horizontales et verticales de la texture. Combien même vous affichez un filtre Linaire en mignification et magnification on garde un affichage desastreux.

mais si vous appliquez un filtre mipmapping en anisotropie l'affichage est parfait :

Nous en avons terminé avec le mipmapping. Un point très important pour la fluidité et la beauté de nos applications 3D. Continuez à vous familiariser avec cette application qui met parfaitement en évidence les filtres de mignification et magnification et les filtres de mipmapping.

Conclusion

Vous pouvez télécharger le sample, les deux moteurs et les exercices ici.

Retourner au sommaire des cours

~~</ en construction / under construction>~~

Les MipMaps

valentin — Fri, 12 Jan 2007 13:06:00 GMT

Les mipmaps permettent une amélioration flagrante de la qualité de rendu des textures en fonction de leur distance par rapport à la position de la caméra qui filme la scène. Prenons la place d’un programme de jeu qui veut afficher un mur. Ce dernier utilisera un cube avec une texture de mur. Etant très maniaque ce programmeur va utiliser une texture de grande qualité afin d’obtenir un mur réaliste. Certes pour une vue de près l’effet voulu sera réussit, mais imaginez le gâchis pour une vue de loin : non seulement Direct3D va tenter d’afficher la forme avec une texture importante, en réduisant sa taille arbitrairement le tout pour un rendu moyen. Quelle perte de performance et de qualité !

Il aurait mieux valu, lorsque la caméra s’éloigne faire en sorte que une texture deux fois moins grande soit utilisée. Moins grande certes mais réalisée par le programmeur ou selon les désires du programmeur !

Pourquoi créer ses propres textures alors les filtres pouvaient aisément réduire une image. Tout simplement parce que les filtres ne sont pas intelligents : ils réalisent leur tâche bêtement sans se soucier du contenu de la texture ni de l’information qu’elle véhicule. Faites ce test : ouvrez votre logiciel de dessin, créez une image avec un texte et réduisez le de 50% avec un filtre bilinéaire.

Vous obtenez quelque chose de la sorte :

Figure 1 — En bas 50% en bilinéaire

L’altération de l’information est flagrante ! Aucun filtre ne peut avoir une vue globale de la texture dans la mesure où ils travaillent au niveau des pixels. Dans le même sens aucun filtre ne peut quantifier l’information véhiculée par la texture et tenter de la sauvegarder au détriment des informations moins importantes.

L’homme, lui, le peut … A lui de créer les différentes textures correspondant à cette perte d’information. Il doit déterminer à partir de quel point le message de la texture devient illisible et créer une nouvelle texture adaptée qui continue à donner le message dans une nouvelle échelle. Au processus de mipmapping de substituer la texture originelle par la nouvelle texture plus petite quand cela devient nécessaire.

Figure 2 — La texture réduite à la main est plus lisible.

1 Présentation

L’ensemble des textures successivement réduites forme un Mipmap. MIP correspond à « Multi in parvo » en latin, c'est-à-dire « de nombreuse chose au même endroit ». Chaque texture de cet ensemble est un niveau de MIPmap ou LOD (Level Of Detail). Chaque niveau doit avoir pour hauteur et largeur la moitié de la hauteur et largeur du niveau précédent. Le dernier niveau a bien évidemment au moins un coté égal à 1. Sachant que la taille conseillée pour une texture est de 256 pixels il y’a donc au maximum 9 LOD (256 puis 128 puis 64, 32, 16, 8, 4, 2 et 1).

Le mipmapping est très utile dans la mesure ou il permet de préserver l’information dans le sens voulu par le développeur mais aussi en évitant à la carte graphique l'affichage de grosses textures lorsque ce n'est pas nécessaire.

Filtre trilinéaire et mipmapping

Les transitions entre les différents LOD sont souvent visibles lorsqu’on regarde au loin. Le processus de mipmapping est heureusement capable de filtrer deux niveaux de mipmap consécutif pour en calculer la moyenne de couleur. La transition devient pratiquement invisible. Il s’agit là du filtre bilinéaire, mais, dans la mesure où il porte sur une transition entre deux texture on parle de filtrage trilinéaire.

LOD bias[1]

Il arrive que pour la beauté du jeu il faille garder un LOD plus longtemps que prévu en retardant le passage à un LOD inférieur lorsque la caméra s’éloigne. C’est le LOD bias qui permet de réaliser cette opération. Si une surface s’éloigne de l’utilisateur, augmenter le LOD bias revient à retarder l’utilisation du LOD inférieur. Au contraire, en diminuant sa valeur, on passe plus rapidement aux LOD inférieurs.

2. Notre Sample

Pour mettre en évidence tout ce que nous venons d’apprendre, rien de tel qu’un bon exemple en 3D. Tout comme le code précédent, nous allons faire en sorte de pouvoir modifier toutes les propriétés liées au mipmapping par l’intermédiaire des touches F1 à F8. Un mipmap est un ensemble de texture dont la taille décroît. Il est nécessaire de créer cet ensemble. Pour cela les textures suivantes seront utilisées :

Figure 3—Textures de couleurs...

Il s’agit d’une série d’image en couleur dont la taille décroît. Les couleurs permettront d’aisément discerner les différents LOD lors des modifications effectuées par l’utilisateur dans le programme. De plus pour avoir une idée plus précise du rendu à l’écran, un autre mipmap sera utilisé, cette fois ci pas de couleur, mais un motif : un sol pavé.

Figure 4— …Textures de sol.

Pour l’affichage, un plan fixe formé de 25*25 cases sera dessiné à l’écran. De même , un petit moteur de déplacement à la manière des Quake like sera programmé dans le but de pouvoir déplacer la caméra et admirer les conséquences sur les modifications de LOD.

Prêt ? C’est parti !

3. Etude du code source

Le fichier principal commence par la déclaration de deux structures : une structure Vertex définissant les propriétés des vertex utilisés dans le programme, et une énumération nommée Filtres qui nous permettra de donner un nom aux filtres voulus par l’utilisateur dans le programme.

Vient ensuite la déclaration de 4 Textures :

/// <summary>

/// Texture pour le mipmapping

/// </summary>

Texture textureMipMappingCouleur;

/// <summary>

/// Texture pour le mipmapping

/// </summary>

Texture textureMipMappingSolContour;

/// <summary>

/// Texture pour le mipmapping

/// </summary>

Texture textureMipMappingSolPur;

/// <summary>

/// Texture pour le mipmapping actuellement utilisée

/// </summary>

Texture texture;

Ces textures sont en fait des mipmap. Elles posséderont différents LOD. En fait une texture simple est un mipmap avec un seul LOD : le niveau 0. Nous aurons un mipmap pour l’étude sur les textures colorisées, un mipmap pour l’étude sur des textures de sol avec contour, et encore un pour les textures de sol sans contour. La dernière texture est en fait le mipmap actuellement affiché par le programme. Il pointera sur l’un des trois mipmap précédemment énumérés.

Terminons les déclarations par différentes variables de sauvegarde des paramétrages de l’utilisateur dans sa découverte du mipmapping :

/// <summary>

/// Filtres de base, on commence en linéaire

/// </summary>

Filtres magFilterType = Filtres.Linear;

Filtres minFilterType = Filtres.Linear;

Filtres mipFilterType = Filtres.Linear;

/// <summary>

/// Niveau d'anisotropy

/// </summary>

int anisotropy = 1;

/// <summary>

/// Level de détail à utiliser

/// </summary>

float mipMapLodBias = 0.0f;

/// <summary>

/// Inidique qu'une mise à jour doit être faite

/// </summary>

bool mettreAJour = true;

Trois variables de type Filtre pour les filtres utilisés avec la magnification, minification et le mipmap. Le niveau de l’anisotropie, la valeur du LOD bias. Un booléen enfin pour déterminer si l’utilisateur a modifié quelque chose.

Ce sont ChargementTexturesEtMipMap() et ChargementTexturesMipMap() qui vont initialiser les mipmap.

La première se présente ainsi :

/// <summary>

/// Charge les mipmap couleur, sol contour, et sol pur

/// </summary>

public void ChargementTexturesEtMipMap()

{

this.textureMipMappingCouleur = CreateTexture( device, "base.bmp", Format.A8R8G8B8);

this.textureMipMappingSolContour = CreateTexture( device, "scbase.bmp", Format.A8R8G8B8);

this.textureMipMappingSolPur = CreateTexture( device, "sbase.bmp", Format.A8R8G8B8);

ChargementTexturesMipMap(textureMipMappingCouleur, "");

ChargementTexturesMipMap(textureMipMappingSolContour, "sc");

ChargementTexturesMipMap(textureMipMappingSolPur, "s");

this.texture = this.textureMipMappingCouleur;

}

Elle créé les trios textures vue précédemment avec base.bmp, scbase.bmp et sbase.bmp. Chaque texture dans le programme possède le même nom mais avec un préfixe différent :

Pas de préfixe pour les textures du mipmap colorisé
« sc » pour le mipmap sol avec contour
« s » pour le sol pur.

Ces trois initialisations ne servent qu’à créer la texture car en fait leur contenu sera effacé par les différents LOD du mipmap.

Les trois instructions suivantes chargent le mipmap de chacun d’entre elles :

ChargementTexturesMipMap(textureMipMappingCouleur, "");

ChargementTexturesMipMap(textureMipMappingSolContour, "sc");

ChargementTexturesMipMap(textureMipMappingSolPur, "s");

La méthode ChargementTextureMipMap créée dans notre programme accepte en paramètre, la texture a charger en mipmap et le préfixe des textures à charger.

La méthode se termine enfin en faisant pointer la propriété texture sur le mipmap qui sera affiché au démarrage.

Analysons ChargementTexturesMipMap :

/// <summary>

/// Chargement des textures mipmap

/// </summary>

public void ChargementTexturesMipMap(Texture mipmap, string préfixe)

{

Texture[] textures = new Texture;

// Charge nos 6 textures

textures[0] = CreateTexture( device, préfixe +"256.bmp", Format.A8R8G8B8);

textures[1] = CreateTexture( device, préfixe +"128.bmp", Format.A8R8G8B8);

textures[2] = CreateTexture( device, préfixe +"64.bmp", Format.A8R8G8B8);

textures[3] = CreateTexture( device, préfixe +"32.bmp", Format.A8R8G8B8);

textures[4] = CreateTexture( device, préfixe +"16.bmp", Format.A8R8G8B8);

textures[5] = CreateTexture( device, préfixe +"8.bmp", Format.A8R8G8B8);

//création des surfaces pour le copier/coller

Surface destination = null;

Surface source = null;

int i;

for( i = 0; i < 6; ++i )

{

//pointer sur la surface texture du LOD i

destination = texture.GetSurfaceLevel(i);

//pointer vers la surface de la texture i

source = textures.GetSurfaceLevel(0);

//charger dans destination la source, sans filtre

SurfaceLoader.FromSurface(destination, source, Filter.None, 0);

}

//Libérer les textures temporaires utilisées

for( i = 0; i < 6; ++i )

textures.Dispose();

}

La méthode commence par charger dans un tableau de 6 textures les six LOD du mipmap. Elle va ensuite, charger à chaque LOD du mipmap passé à la méthode les 6 textures chargées :

for( i = 0; i < 6; ++i )

{

//pointer sur la surface texture du LOD i

destination = mipmap.GetSurfaceLevel(i);

//pointer vers la surface de la texture i

source = textures.GetSurfaceLevel(0);

//charger dans destination la source, sans filtre

SurfaceLoader.FromSurface(destination, source, Filter.None, 0);

}

Pour les 6 itérations, on fait pointer destination sur le LOD du mipmap. On fait pointer source sur le LOD 0 de la texture de la case du tableau lu. Chaque texture de ce tableau n’est pas un mipmap et une seule texture, il n’y a donc qu’un LOD : celui du niveau 0. A l’aide de la méthode FromSurface de la classe utilitaire SurfaceLoader on place dans destination le contenu de source. Le tout sans filtrage et avec une clé de couleur de transparence noire (la valeur 0). En gros cette boucle chaque dans le mipmap a chacun des 6 LOD, les 6 textures chargées au départ.

Cette opération étant effectuée, on peut libérer la mémoire prise par le tableau.

La création de mipmap est une opération relativement facile (on perd plus de temps à créer les textures des LOD !). Pourquoi s’en passer quand on voit le gain de performances et de qualité visuelle ?

Remarque : Pour déterminer le nombre de level d’un mipmap utilisez la propriété LevelCount de cette manière :

int nombreLOD = mipmap.LevelCount;

Trois méthodes, travaillent sur le sampler. Elles se présentent comme ceci :

private void SetMagnificationFilter()

{

if( this.magFilterType == Filtres.None )

this.device.SetSamplerState(0, SamplerStageStates.MagFilter, (int)TextureFilter.None);

if( this.magFilterType == Filtres.Point )

this.device.SetSamplerState(0, SamplerStageStates.MagFilter, (int)TextureFilter.Point);

if( this.magFilterType == Filtres.Linear )

this.device.SetSamplerState(0, SamplerStageStates.MagFilter, (int)TextureFilter.Linear);

if( this.magFilterType == Filtres.Anisotropic )

this.device.SetSamplerState(0, SamplerStageStates.MagFilter, (int)TextureFilter.Anisotropic);

}

Il existe aussi 2 autres méthodes similaires SetMinificationFilter et SetMipMapFilter qui travaillent de la même manière.

Les modifications sont effectuées par le groupe d’instructions :

this.SetMinificationFilter();

this.SetMagnificationFilter();

this.SetMipMapFilter();

device.SetSamplerState(0, SamplerStageStates.MaxAnisotropy, anisotropy );

device.SetSamplerState(0, SamplerStageStates.MipMapLevelOfDetailBias, mipMapLodBias );

this.Text = "Minification = " + this.minFilterType + " | Magnification = " + this.magFilterType + " | MipMap = " + this.mipFilterType + " | MaxAnisotropy = " + anisotropy + "|LOD = " + mipMapLodBias;

Les trois appels de methodes vues précédemment, suivit par deux modifications du sampler pour mettre à jour l’anisotropie et le LOD bias.

La dernière instruction mets à jour le titre de la fenêtre pour pouvoir connaître l’état des filtres.

4. Touches de l’exécutable

Page Haut/Bas : Déplacement en hauteur.

Flèches gauche/droite : Tourner la tête.

Flèches haut/bas : avancer/reculer.

+/- : Regarder en haut/en bas

Touche numérique 1/2/3 : Mipmap colorisé/sol avec contour/sol pur.

F1 : modification du filtre de minification.

F2 : modification du filtre de magnification.

F3 : modification du filtre de mipmapping.

F4/F5 : modification du LOD bias.

F6/F7 : modification de la valeur de l’anisotropie.

5. Etude de l’exécutable

Le code du programme étant compris voyons ce qu’il peut nous apporter. Lancez le, l’écran au démarrage devrait être le suivant :

Figure 5—On remarque bien les plans translatés et le mipmapping

En se déplaçant en avant en arrière on remarque les ondes des LOD suivre et s’avancez ou reculer. De même en s’approchant du sol, les LOD avec les index les plus petit (dont les plus détaillés) apparaissent (notamment la texture rouge et bleu).

En hauteur, la touche F1 qui modifie le filtre de minification agit. Le filtre point effectue ainsi une opération de mauvaise qualité. La minification agit car en hauteur les différents plans du sol ont une taille inférieure à la taille de la texture. Au sol si la minification ne fait rien, au contraire la magnification agit. Même remarque : le filtre point dégrade l’affichage (dommage, c’est le plus rapide).

Figure 6—Point et Lineaire … le choix est aisé.

Jouons maintenant avec le mipmapping (touche F3). Si nous prenons le filtre None (qui desactive le mipmapping) évidemment le sol devient rouge : il n’y a plus qu’une texture dans le mipmap. Avec le filtre point, on obtient un affichage certes hideux, mais très intéressant dans la mesure où on détermine bien les différents LOD. On peut passer en mode sol pur pour discerner au mieux l’effet dans un jeu.

Figure 7—Le mipmapping en mode point est … à éviter.

Avec un filtre Linéaire ou Anisotropique les différences de LOD s’estompent. Jouons maintenant pour terminer avec le LOD bias. Il permet de retarder ou s’accélérer le passage à un autre LOD.

Figure 8 —LOD bias = 0

Figure 9—LOD bias = 1 : on est plus rapidement à des LOD moins détaillés

Figure 10—LOD bias = -3 : le LOD détaillé en face reste affiché à une distance plus élevé de la caméra.

Ce petit programme d’exemple devrait encore avoir éclaircit nombre de point difficiles à assimiler (notamment les filtres). Quelqu’un qui maîtrise bien les fonctionnalités de cet utilitaire pourra tenter de discerner les nuances des filtres plus seulement avec le mipmap colorisé.

Télécharger le Sample

Vous pouvez télécharger le sample ici.

[1] Bias peut être traduit par correction ou affinage ici..