Tuesday, 21 February 2012

In yesterdays post I taked about some updates to the ShaderLib to allow registering of the uniforms, and as I was driving into work I decided to add some more code to parse the shader source and look for any lines containing the word uniform and automatically add it to the uniforms list.

The glsl spec contains a full list of the grammar for glsl, and we can break down the declaration of uniforms to the following

The simple case of a single uniform is easy to parse and can be accomplished by reading the shader source and looking for lines containing the uniform keyword.

The array version however is more complex as we need to determine if we have one of two different cases. Either a hard coded array value or a constant defined by a #define statement.

The lucky thing is that the #define must always be executed before it is used, so we can store these values and do a lookup on them.

The downside of this is the fact that each element of the array must be registered.

This is further compounded by the fact that the data type may be a structure. I'm not going to worry about the structure side of things and only worry with accessing normal arrays of the type uniform vec3 points[3] for example.

Lets get a boost++
In general C++ string processing is not that good, however there are several really good libraries in boost that allow loads of different string processing. For this example I'm going to use boost::tokenizer ,boost::format, boost::split and boost::lexical_cast, all of these are header only templated classes so don't require external compiled libs and all work well with the usual stl containers.

Overview of the process
I've created a new method for the ShaderProgram class which will loop for each attached shader and grab the shader source code string (the whole shader is stored as a single std::string ) this is then split based on the tokens \n\r and a space.
Each line is then searched to find the following keywords "uniform" and "#define". The code to do this is as follows.

To find if the string contains our keywords we use the std::string find method which will return a value not equal to std::string::npos if found (basically the index but we don't need that).

If this is found we can process the respective values.Parsing #define
To store any #define values I'm going to use a std::map<std::string, int> to store the value, and also make the assumption that we will always have the form #define name [int]. This is a very safe assumption as array subscripts must always be positive and in the case of glsl most implementations only allow very small arrays.

The overall process is quite simple, I tokenise the string as above, however now we copy this to a std::vector <std::string> using the assign method and then use the subscript to access the elements we want, as shown below

bool ShaderProgram::parseHashDefine(
const std::string &_s,
std::string &o_name,
int &o_value
) const
{
// typedef our tokenizer for speed and clarity
typedef boost::tokenizer<boost::char_separator<char> > tokenizer;
// these are the separators we are looking for (not droids ;-)
boost::char_separator<char> sep(" \t\r\n");
// generate our tokens based on the separators above
tokenizer tokens(_s, sep);
// now we will copy them into a std::vector to process
std::vector <std::string> data;
// we do this as the tokenizer just does that so we can't get size etc
data.assign(tokens.begin(),tokens.end());
// we are parsing #define name value so check we have this format
// we should as the glsl compiler will fail if we don't but best to be sure
if(data.size() !=3)
{
return false;
}
else
{
// data [0] [1] [2]
// we are parsing #define name value
o_name=data[1];
o_value=boost::lexical_cast<int> (data[2]);
// all was good so return true
return true;
}
}

You will notice that the boost::lexical_cast is used to convert the string into an integer, and that both the values are returned to the main program and stored in the defines map ready to be passed into the next function to process the uniforms.ParseUniform method
The parseUniform method is split into two sections, we first check to see if the string has a [ or not as this will depend upon the parse method. If no [] is present we can process in a similar way to above, however if there is an array we need to further refine the parse, and then loop and register all the uniforms. For example the following glsl code

#define numIndices 4
int indices[numIndices];

would need all the uniforms registered so we would register

indices[0]
indices[1]
indices[2]
indices[3]

The following code shows the complete method

void ShaderProgram::parseUniform(
const std::string &_s,
const std::map <std::string,int> &_defines
)
{
typedef boost::tokenizer<boost::char_separator<char> > tokenizer;
// first lets see what we need to parse
if(_s.find("[") ==std::string::npos)
{
boost::char_separator<char> sep(" \t\r\n;");
// generate our tokens based on the seperators above
tokenizer tokens(_s, sep);
// now we will copy them into a std::vector to process
std::vector <std::string> data;
// we do this as the tokenizer just does that so we can't get size etc
data.assign(tokens.begin(),tokens.end());
// uniform type name
// we should as the glsl compiler will fail if we don't but best to be sure
if(data.size() >=3)
{
registerUniform(data[2]);
}
}
else
{
boost::char_separator<char> sep(" []\t\r\n;");
// generate our tokens based on the separators above
tokenizer tokens(_s, sep);
// now we will copy them into a std::vector to process
std::vector <std::string> data;
// we do this as the tokenizer just does that so we can't get size etc
data.assign(tokens.begin(),tokens.end());
// uniform type name
// we should as the glsl compiler will fail if we don't but best to be sure
if(data.size() >=3)
{
// so in this case data[3] is either a number or a constant
int arraySize=0;
// so we try and convert it if it's not a number
try
{
arraySize=boost::lexical_cast<int> (data[3]);
}
// catch and lookup in the uniform array
catch(boost::bad_lexical_cast)
{
std::map <std::string, int >::const_iterator def=_defines.find(data[3]);
if(def !=_defines.end())
{
arraySize=def->second;
}
} // end catch
// now loop and register each of the uniforms
for(int i=0; i<arraySize; ++i)
{
// convert our uniform and register
std::string uniform=boost::str(boost::format("%s[%d]") %data[2] %i);
registerUniform(uniform);
}
}
}
}

Most of the code is similar to the other parse methods, however we use the fact that boost::lexical_cast throws and exception to check to see if we have a number or a string as the size of the array, first I try the cast, if this throws a boost::bad_lexical_cast exception we look to see if we have the value stored in our defines list.Conclusions and Future work
This works quite well and is fairly robust (as the glsl compiler will fail if the code is wrong anyway), however as mentioned above it doesn't cope with registering uniforms which have structures. I may refine this at a later date to cope with these but it would require storing each structure and element of that structure and registering each element.

This will eventually be made redundant due to the use of the new glsl Uniform Buffer Objects however at present my mac doesn't support them so will have to wait.

I may also just write a full glsl parser using the excellent boost::spirit library one day as an exercise in parser writing (as I quite enjoy writing parsers)

This code has been integrated into ngl and the latest source tree has been updated to inclue it all.

Monday, 20 February 2012

Just a quick post to explain some updates to the ngl::ShaderLib sub-system. First of all this doesn't break any existing code, but has in some situations increased frame rate by 10-15%.

First a bit of background, all of the shader lib functions use the getUniformLocation function to query the location of the uniform in the current program and use this GLuint offset to load the values to the uniform in the shader.

This works ok, and generally this only called at the start of the program so doesn't cause too much of a bottleneck. However in most of the demos we load the Model/View/Projection matrix to the Shader each time we move something, and the MVP value will be loaded using the following code (from the ngl:: source)

This will register the uniforms, now when we load the matrix values to the shaders, we can use the "registered" versions of the functions which will look up the values in the map and use the uniform's stored there. This will work unless the shader source is changed and re-compiled. In that case they will need to be re-registered.

previously we have discussed the different types of operator overloading and the differences between the Member operators and Free operators. In this part we are going to implement a basic * Scalar operator which will multiply each of the Vec3 components by a floating point scalar value.
In the .h file we can implement the following definition for the operator

We get the following compiler error error: no match for 'operator*' in '2 * a'
This is due to the fact that we have no operator for scalar * Vec3. To solve this problem we can generate a Free function version of the operator and a scale method to scale the vector by a scalar value.

As you can see both methods require the extra scale method, however if we use the free function version we can remove the member operator. In some cases this will not be required (for example if the operands are of the same type)

In the previous post we looked at the mandated member operators, for this part I'm going to look at the different types of operators we can generate and provide examples of each.

For ease I will split this section into relational operators and arithmetic operators. We can represent the relational operators using the following diagram

These operators will always return a boolean value which will be the result of some form of comparison.

Arithmetic operators will return an object of some type which depending upon the context may be either the same object or a new type of object. Later we will also add the += style operators which will mutate the current object rather than returning a value.

Equality Operators

In the case of the Vec3 class there are only two equality operator which make sense to implement, these are the == and != operators. Also we must ensure that we are doing correct comparison as we are storing floating point values. ( see here for an in depth discussion of floating point comparison ). For this example I'm going to generate a very simple FCompare macro which will be used to do a comparison via a simple epsilon error value.

For the free function operator we have to write some additional code again to allow the free function access to the attributes. In this case we are going to write a method called isEqual ( note that my coding standard says this kind of method should be formed as a question as it returns a bool)

Finally we write the main function code, not that as they are no longer class methods it is no longer valid to mark the methods as const (in fact you get the following error with g++ error: non-member function 'bool operator==(const Vec3&, const Vec3&)' cannot have cv-qualifier )

Friday, 17 February 2012

In the previous post I discussed some of the basics of operator overloading and the difference between "Free Operators" and "Member Operators" and we overloaded the << insertion operator so we could use our Vec3 class with the std::cout method, in this section I'm going to start with the assignment operator which is one of the operators which must be a Member operator.

The assignment Operator
The assignment operator must be a member operator to ensure that they receive an lvalue (basically an expression that refers to the object) as the first operand, also if we follow the "rule of three" we should define a copy constructor as well, in this case we could get away without writing an assignment operator as we don't create any dynamic memory in the class, however good practice dictates it's best to always do this. If we did any dynamic allocation in this class we would need to do a "deep copy". The following code is added to both version of the project code to add the copy constructor and assignment operator.

We can also create more than one assignment operator passing in different types to the right hand side parameter, for example if we had a 4x4 matrix class we could call Mat4x4 v=1.0 to set the values to the identity matrix. The following example will set all of the Vec3 components to the floating point value passed in

assignment operator from float called
[0.5,0.5,0.5]
assignment operator from float called
[0,0,0]

Obviously caution should be applied to this approach in your design, however it is quite common in graphical applications to be able to do this (for example renderman tuple types and glsl Vec types both support this type of assignment so I have used it in ngl)
The [] operator
The [] subscript operator is a useful operator to overload as it will allow assignment and access to the internal elements of the class. This does however have the side effect of exposing these private attributes and break encapsulation.

To access the data we really need to have an array as well as the individual m_x style elements, to do this we can use a union however this will effectively make things public anyway (see this post about how g++ does this but not clang ). The following code will modify the class so we have a union

You will notice in the above example the use of the assert function (from #include <cassert>) this will abort the program if the index is out of range, in this example as we are using an unsigned int for the index we only need to check for the higher bound as the index can never be negative. However our client code could use an int for the index which we should also check the negative bound, to make a fully safe version we should really write both [int] and [unsigned int] versions of the code.
Testin this code with the following program

Note : it is also possible to write the same operator without the union, by using the following code

return &m_x[_index];

Whilst this will work it does make several assumptions on how the data is packed in your header,in this case we assume packed alignment and that m_x m_y and m_z are contiguous, while this is generally the case it is not the safest way of accessing the data and the union should always ensue that the correct data packing is in place.

Thursday, 16 February 2012

We introduced the concept of operator overloading today in the first year lecture / lab session and there was quite a lot of confusion, so I've decided to do a more in depth article about it here.

There is a wealth of knowledge online about operator overloading and a good starting point is this article as well as the venerable c++ faq, however I'm going to use the excellent book by Martin Reddy "API Design for C++" as he discusses some interesting differences between the ways we can implement Operator Overloading.

So what is Operator Overloading
The main reason to overload operators in your own class design is to make them behave like the built in types (intrinsic types). It can also make things more intuitive when writing our own classes, especially if they are representing something mathematical. For example imagine the following class

We have three attributes of type float in the private section, and (assuming a constructor has been written ) we could write the following code

Vec3 a,b,c;
add(add(mul(a,b), mul(c,d)), mul(a,c))

But that is almost unreadable and the actual mathematic being implemented is $$ a*b+c*d+a*c $$ which is much more readable, and when trying to implement a mathematical function from a paper much easier to check when debugging.

So we can use operator overloading to make our classes work like mathematical data types even when they are not.

However, it is important to only overload operators which seem natural to do so and follow the semantic you would expect. For example it is natural to overload the plus + operator to meen addition or for string based objects concatenation.

Vec3 Class
For the purpose of this discussion I will be using a simple floating point Vec3 class which represents a three tuple vector and will be used to perform mathematical calculations and comparison operations. The basic header file we will be using is

In the above example we construct a Vec3 a and assign it some values, and be will be constructed using the default parameter values 0,0,0. By default the compiler will implement a simple assignment operator for us and a==b. (don't worry we will create our own soon).

Free Operators vs Member Operators
Reddy defines two different types of operator, "Free Operators" and "Member Operators" Member operators are members of the class, and as such have full access to the private data areas of the class, there are some operators that can only be implemented using Member Operators ( = [] -> ->* () (T) new / delete) however all the other operators can be implemented in both ways. In this example I'm going to implement both type using two different project files (which can be downloaded from the link at the top of the page).

Free Operators are not part of the class, and are declared as functions separate to the class, this means that the function doesn't have access to the class private data area so we must write some form of accesors for the attributes for it to work, however this does have the advantage of allow us to reduce the coupling of the Vec3 class to our other implementation.

The other advantage of Free Operators is that they give us better symmetry and allow us to do something like 2*V and V*2 in the same code.

Insertion Operator
The first operator I'm going to implement is the << insertion operator, this will allow us to use std::cout to print the contents of our class, this is perhaps not the best one to start with as it actually add extra complication to what we are doing as we need to send data to the std::ostream class and it will need to know about the internal structure of our Vec3 class. The easiest way of doing this, and in most texts the way shown, is by using the friend prefix this indicates that the method is a friend of the class and it can access the private data. This does however break encapsulation and promotes many coding arguments.

The following code will implement the << operator as a member operator in is placed in the Vec3.h

To generate the free operator version we actually have to write a lot more code in the Vec3 Class. As I mentioned earlier the free operator version is defined outside of the class definition, usually I still prefer to keep the definition and the code in the same .h and .cpp files however this is not mandatory anymore as the free operators are not part of the class.
The following code shows the prototype of the free operator

std::ostream& operator<<(std::ostream& _output, const Vec3& _v);

Now as this is no longer a friend to our Vec3 class we need to implement a method to gather the data we require and return it to the free operator in this case I'm going to implement the member function getString() as follows

/// @brief a method to get the data as a string
std::string getString() const;

Here we construct a stringstream object and pass the formatted data to it. This is then converted to a string and returned from the method. Finally the free operator can access the data from the class as follows

Tuesday, 14 February 2012

In the previous pos I got the ship moving, and on the way to work I decided it would be good to make a better background to the game, so I created a very simple StarMap class which loads two textures and creates two rotating sphere with alpha blended textures. This is shown in the following video and I will write a more detailed explanation when I get a chance. I've also got a new model form Turbo Squid until I get a better one.

The star map image is from here and I recommend this site in general especially the cool geometry stuff here. The planets were taken from here

Monday, 13 February 2012

In the previous post we designed different ways of linking our objects together, now to get the basic movement of the ship going I decided to modify the Advanced Game Key control demo from the ngl:: demos, I was originally going to use the format described in this post however the method I'm going to use here is a lot more flexible and is based on some code written by Rob the Bloke

This video shows the code in action

This code is spread amongst several classes but the main control codes are stored in the following structures in the file GameControls.h

This enum allows us to create a simple bit mask for each of the keys we require, in this case we define the main up/down & left right keys, then using a logical or we can create valid key combinations such as up and left etc.
Next we are going to define a structure to contain the movement values for each key combination, for now these will be the x,y movement and rotation values in x,y and z

This structure is very useful as we can tweak the position and rotation values for each of the movements and it is easy to update the key combinations to add more.
The next stage of the code is to combine this with the SpaceShip class, the class used in the previous versions of the code have been modified to remove the move and rotate methods and been modified to use the following method

The key combinations set in the GLWindow class are passed to this method as a uint8_t data type, we then uses this value to find the index into the motion table and set the SpaceShip position and rotation values. Finally the values are clamped to ensure the ship stays within the visibile area of the screen (this may change once I get some more of the game developed)
Setting the Key Values
To set the key values we add a new attribute to the GLWindow.h class

/// @brief the keys being pressed
uint8_t m_keysPressed;

Now when the keyPress and release method are called in the GLWindow class we set / free the m_keysPressed attribute to the key combinations in the GameControl.h file as shown

When any of the keys are pressed the m_keysPressed attribute will set the correct key flag in the data structure by using a logical or. This means that if the flag is not set it will be set, however if already set it will remain active. When the key is released we need to turn this flag off, which can be done as follows

In the previous post I created a simple SpaceShip class, to contain the state data for the Ship, I also outlined different methods. In this post I'm going to discuss different ways of associating the classes with each other. In this case we have the SpaceShip class which contains the state data, and the Models class which will contain the actual Mesh to be draw.

I'm going to then highlight three different ways of associating the classes so the SpaceShip class can access the model and draw.

In all these version we will have an instance of the SpaceShip class created in the GLWindow class called m_spaceShip, and we need to pass the global ngl::Camera to the SpaceShip class as well as the instance of the Model class.

Pass By Reference version
In this version we are going to pass into the draw method both the model and the camera, we declare the draw prototype as follows

You will now note that this method is no longer marked as const, this is because in the loadMatricesToShader method we need to access the m_transform object and grab the current matrix. This will force the transform object to calculate the transforms and mutate itself, and hence is now a non const method.

/// @brief load our matrices to OpenGL shader
/// @param[in] _cam a reference to the camera use to grab the
/// VP part of the Matrix for drawing
void loadMatricesToShader(
const ngl::Camera &_cam
);

So the draw method will basically load the Model View Projection matrix to the shader by calling the method above we then need to access the model and call the draw method, this is shown in the following code

In the loadMatricesToShader method we have already loaded the shaders to the ShaderLib class and we then just call it when required. We can now use the following code in the GLWindow class to draw our SpaceShip

m_spaceShip.draw(m_model,*m_cam);

Which gives us the following

As you can see the orientation is wrong at present but I will fix that later.

Class Global Pointer Version

The next version is going to have two global pointers one for the Camera and one for the Models, these will be set in the spaceship class on construction and then used in the draw methods.

The code to generate the Ship is now different, firstly the SpaceShip class in GLWindow.h must now be a pointer and we need to build the object once we have created our camera and models as shown below

m_cam= new ngl::Camera(From,To,Up,ngl::PERSPECTIVE);
// set the shape using FOV 45 Aspect Ratio based on Width and Height
// The final two are near and far clipping planes of 0.5 and 10
m_cam->setShape(45,(float)720.0/576.0,0.05,350,ngl::PERSPECTIVE);
m_model.addModel("bigrock","models/RockBig.obj","textures/rock_texture.bmp");
m_model.addModel("spike","models/RockSpike.obj","textures/rock_texture.bmp");
m_model.addModel("spaceship","models/SpaceShip.obj","textures/spaceship.bmp");
m_spaceShip = new SpaceShip(m_cam,&m_model);

Both these methods work in more or less the same way, not passing the parameters to the draw method does reduce some of the stack overhead with accessing the data however simple timing tests give both methods the same speed of approximately 60FPS
Game State Object
The final method I'm going to describe is going to use a global game object. This object will be a singleton class, it will have public attributes for the camera and the models, which must be set when the class is first used.
The SpaceShip class will then access this when required.

The main C++ code looks like this and is a standard singleton, in this case we don't have to worry about managing the lifetime of the class as it will only contain const pointers and the other classes will manage their own lifetimes

As you can see this method breaks some of the OO rules about encapsulation but will require less re-working of the code if we wish to change game elements or add / remove elements to be shared with the rest of the game objects.
Another speed test puts this at about the same speed as the others. So there is no clear winner at present for any of the methods.
All of the code for the three examples can be found here, for now I think I'm going to use the GlobalGame object method as it will make the development cycle quicker as I only need to add things to the singleton class.

The main premise of the game is we are going to have a read view of a SpaceShip which the player can move around the screen in x and y. The user can also rotate the ship around the different axis.

The sketch above shows the view of the ship and the axis of rotation, the class sketch below show the initial design of the SpaceShip class

The SpaceShip will have a shield with initial value of 100% which will be changed based on the game play mechanic (for example collisions will reduce the shield and I may update the value based on collecting assets)

By default the player will have 3 ships which will be decreased based on gameplay / collisions and there will be opportunities to add more ships based on score etc.

The following class diagram is a more formal version of the above

And in code looks like this

#ifndef __SPACESHIP_H__
#define __SPACESHIP_H__
#include <ngl/Vec3.h>
#include <ngl/Transformation.h>
/// @file SpaceShip.h
/// @brief the basic spaceship class used for the game
/// @author Jonathan Macey
/// @version 1.0
/// @date 13/2/12
/// @class SpaceShip
/// @brief this class encapsulates the spaceship state, and also controls, it does
/// not have a mesh assosiated with it this is stored in the Models class
class SpaceShip
{
public :
/// @brief the ctor
SpaceShip();
/// @brief the dtor
~SpaceShip();
/// @brief move this will set the position of the ship
/// @param[in] _dx the change in the x position
/// @param[in] _dy the change in the y position
void move(
float _dx,
float _dy
);
/// @brief rotate the ship in the three axis
/// @param[in] _dx the change in the x rotation
/// @param[in] _dy the change in the y rotation
/// @param[in] _dz the change in the z rotation
void rotate(
float _dx,
float _dy,
float _dz
);
/// @brief draw the ship
void draw() const;
/// @brief get the life value
inline int getLife() const {return m_numLives;}
/// @brief remove life
inline void removeLife(){m_numLives-=1;}
/// @brief get the sheild strength
inline int getShieldStrength()const {return m_shieldStrength;}
/// @brief reduce the sheild strength
inline void reduceShieldStrength(int _s){ m_shieldStrength-=_s;}
private :
/// @brief the position of the ship
ngl::Vec3 m_pos;
/// @brief the x,y,z rotation values of the ship
ngl::Vec3 m_rotation;
/// @brief our transformation used to load to the matrix
ngl::Transformation m_transform;
/// @brief load our matrices to OpenGL shader
void loadMatricesToShader();
/// @brief the number of lives for the ship
/// this is set to 3 initially and will then change as the game progresses
int m_numLives;
/// @brief the strength of the sheild starts at 100% and reduces during the game
/// based on collisions
int m_shieldStrength;
};
#endif

We can now write most of the methods if we ignore the drawing elements of the class. These are as follows

It is now possible to construct a simple SpaceShip class in the main GLWindow and use it for storing the data values for the ship However drawing the mesh for the class is going to be a lot more complex and this will be put into the next post. For now here is the basic code and part three is here

It's programming assignment time again, and I've decided this year to write a simple game to demonstrate some of the features of NGL and to show you how to go from the initial design stuff into code.

For this game I've decided to do a simple 3D style asteroid game which uses a number of obj meshes to draw the different asteroids and the ship.

The main focus on these blog posts will be the sharing of data across different classes and the stepwise refinement from the class design to writing the code.

My initial design for the system is shown below

I'm going to concentrate of the basic design of each of these classes, then implement and test them separately. The first class will be the models class.

Models

The models class is a container for the meshes, and allows us to share meshes for each of the other classes. For example in this game we will have a number of Asteroid objects, however each one will only have a single mesh. We could load a mesh for each Asteroid object we create, however this is going to be slow and wasteful of resources as we only have a limited amount of GPU memory and texture memory. Using the Models class we load all our models and textures at program startup, then each of our classes that need access to the models will have a pointer to this class and access models via it.

To store the Obj meshes I decided to use std::string name lookup and the easiest way of implementing this is to use the std::map container and use the build in iterators to access things. Another concern when designing is to ensue we have const correctness built in from the outset. In this case as we only have one method that doesn't mutate the class (the draw method) it is quite easy to do this.

Finally I wish to ensure full documentation of the class, I will be using Doxygen to comment everything and as usual it is best to write this at the time of creating the class. The code below shows the fully .h file for the class

#ifndef __MODELS_H__
#define __MODELS_H__
#include <string>
#include <map>
#include <ngl/Obj.h>
/// @file Models.h
/// @brief a class to contain all models used in game
/// @author Jonathan Macey
/// @version 1.0
/// @date 10/2/12
/// @class Models
/// @brief this class contains all meshes required for the game level
/// we use this as we only need to load meshes once but may need to attach
/// to many objects in our game
class Models
{
public :
/// @brief our ctor
Models(){;}
/// @brief our dtor this will clear the models and remove
/// all of the meshes created
~Models();
/// @brief add a mesh with no texture
/// @param[in] the name of the model we wish to use for lookup
/// @param[in] the path / name of the mesh
void addModel(
const std::string &_name,
const std::string &_mesh
);
/// @brief add a mesh with a texture
/// @param[in] the name of the model we wish to use for lookup
/// @param[in] the path / name of the mesh
/// @param[in] the path / name of the texture
void addModel(
const std::string &_name,
const std::string &_mesh,
const std::string &_texture
);
/// @brief accesor to the model, incase the caller
/// wishes to modify the mesh etc
ngl::Obj *getModel(std::string _name);
/// @brief method to draw the mesh, all tx must be executed before
/// the call to draw
/// @param[in] the name of the mesh to draw
void draw(std::string _name) const;
private :
/// @brief a map to hold our meshes by name
std::map < std::string, ngl::Obj *>m_models;
};
#endif

As you can see the constructor doesn't do anything in the class, however we need to implement a destructor to call the ngl::Obj destructor and clear out all the mesh data etc.

The destructor uses the std::map::iterator to grab the front and the back of the map, we then loop through and use the ->second accessor to delete the ngl::Obj * class.
The rest of the class is fairly simple, to add a mesh we use the following code

It has occurred to me, whilst writing this up that using a std::map may not be the fasted way of using this class as we need to iterate to search by name. It may actually be better to use a std::vector and have some form of index based enumerated type to search for the models. Once I start testing the rest of the classes I will do some comparisons for speed, which will test this.