Once we've created our rendering system, we will create a scene. To create a scene we will use a Scene Graph. A Scene Graph is simply a system which will let us define how our scenario is. In this case, imagine we have a scene with 5 rooms our graph will be defined as, on one side, all the rooms, which will be nodes, and on the other side it will be defined by some lines which will be the doors between those rooms. Alright? So this means our A room will be connected with rooms B and C. C room will be connected to rooms A, B and D. Room D will be connected to room E. Room B will be connected to rooms A and C; room D will be connected to C and E will be connected to room D. We will detect the room where the player is, and we will paint the adjacent rooms, from this position, from the room where the player is. So if the player paints himself in room B and we say we want to paint with depth 2, we would paint rooms B, A and C. We wouldn't be painting rooms D or E. It depends on the design as it has to paint the scene so that from room B we never see rooms D or E. That's the trick. We will do it with a Graph. A Graph or a star-like tree to paint the depth. To do so we have created the C scenario class which contains the following information: on one side it has the objects' object list, which as we have seen is the list of the geometrical elements we will be able to paint, the room's depths list, a vector of ASEObject names in aim to be able to load them, a vector of wholes vectors, which will tell us the communication between rooms, the number of total rooms our scenario has, the door, the current room, in which the player is, the maximum depth in which we are going to paint and the last room in which the player was. Everything has a private method, render by def, which is a recursive method we will explain next, and non starter, which is part of the html lecture I will now explain. Builder, destroyer, load ASEObjects method, which will download all the ASE Objects of the rooms list, and the room, which will give us back the room where we are from the position, the renderscenary, which will paint us the scenario depending on the depth from the position we give it, the render, which renders all the rooms without distinguishing the graph and then the depth Set and Get methods. Let's see how all this works. The first we need to see is that the scenary class comes from the xml pass class, which means it will be able to read an xml file. So we find the xml file it is going to read inside an executable folder, data, models, world, world.xml and this one is the xml file we are going to read. The xml file we are going to read says that our world has 5 rooms, that rooms are defined by room 0, and that the ASE File name is Room0.ase. Room 1 is room1.ase, room2 is room2.ase, room3 is room3.ase, and finally room 4 which is room4.ase. These are the five rooms. And then, from lines 9 to 32 it tells us the doors or links between the different rooms. In this case, in the line 1 it tells us the room which has the identification "0", that is, room0.ase, has doors to rooms 1, 3 and 4. This is lines 9 to 13. For the room with index 1, it has 14, it will have a door to rooms 0, 2 and 3, as we see in lines 15, 16 and 17. For room 2, it will have doors to room 1 and 3. For room 3 it will have doors to rooms 0, 1, 2 and 4. And for the room 4 it will have doors to the room 3 and 0. So in our code we have to read this XML file in aim to be able to create our game scene's graph. Obviously, as the external XML file is a code, we could easily modify the XML, without the need to recompile or regenerate the game code, and we could modify the game scene. Let's go back to the scenario class. We have the builder which starts the member variables, the destroyer where we delete the elements or rooms in our scenario. Then we have the start element method. The start element is an overwritten method of the XML parcel class, which is called by each of the tags we get from the XML. So, if we get to the tag world, we will read the number of rooms and we will build the rooms list, the ASE file names list, the doors list and the room depths list based on the number of rooms. If we get a room-type element, we will put off the room identifier and we will establish the ASE file name we get from the XML. If we get a doors tag, we put off the current gate, that is, the room that will define us the current door or room with the link between the rooms. And if we get to a door from this current gate, it will tell us that the first room is adjacent to the second room of the gate. OK? Those would be lines 40 to 50. Then we have the load absent objects method, which will simply go through the file absent list, create an ase object, load the room file and put it inside the rooms vector, the member variable m_rules. Next we have the sets and the depth gates with the maximum depth we want to paint. then the render method, which as we said is a method which discriminates the graph, which means it ignores the graph and paints all the rooms, one after the other, no matter how many rooms we have, without the need to use the graph. The room method, which uses the method IsOnTheBox from LaserObject, to tell us in which room we are by a geometrical position. In case we aren't in any room, outside of the rooms' containing boxes, they will give us back -1. And on the other side we have the methods renderscenary and RenderByDef. RenderScenary will initialize the depths of each room, it will take the current room and will paint based on the current room's depth, calling the RenderByDef method. RenderByDef is a recursive method. It gives the recursive method the device and the room where we are painting, and as it is the first room, the depth is 0. So if we get to the RenderByDef method, which as I said is a recursive method, the first thing it does is making the exit conditions of the recursive method. If the depth we get is higher than the maximum depth we are going to paint, we go back, that is, we don't go on. If the maximum depth of the room we are using is smaller or equal to the depth we are getting, this means it has already been painted or we have passed by this room previously, so we go back we don't want to continue because we have already gone over the graph with this depth. Otherwise, if we want to go on, we update the room depth based on the depth we received and we check if the room is inside the camera frustum through the fear visible method we explained in the first session, and we paint the room. Lines 119 to 122. Once we've painted -or not- the room, we paint the adjoining rooms but we do it with a +1 depth. So based on our room, we have different adjoining rooms through the doors and we paint the adjoining rooms calling the render by def method, a recursive method with def+1 and depth +1. And this successively until we paint our scenario's part.
