EAE6320 – Assignment 4 – Mesh File

The first part of this assignment was to combine our .glsl and .hlsl shader files into one. We used #if defined in the shaders to separate code for each platform type. Along with this, we had to make some changes in our shader loading code so that the appropriate #define directives are defined before loading the shader. I chose to name my vertex shaders .vert and fragment shaders .frag . This not only immediately tells me what that file is, but the extensions also remain small in size.

I didn’t try to make any improvements towards combining the two types (glsl and hlsl) of shaders; in their current stage they are very simple. Because, I don’t have as much experience with graphics and I don’t know where the class is headed, I decided not to put time into preemptively working on shader code and do things that may just not work in future.

The second and more important task of this assignment was to write a system to load our square mesh from a file instead of hard-coding the data. To do this we first had to come up with a format in which to represent our mesh data. The requirements are that it must be described as a valid Lua table and that it must return itself. Here is what my mesh file format looks like:

    vertices =
        {    pos = { 0.0, 0.0}, rgba = { 1.0, 0.0 , 0.0, 1.0 }    },
        {    pos = { 1.0, 0.0}, rgba = { 0.0, 1.0 , 0.0, 1.0 }    },
        {    pos = { 1.0, 1.0}, rgba = { 0.176, 1.0 , 1.0, 1.0 }    },
        {    pos = { 0.0, 1.0}, rgba = { 0.0, 0.0 , 1.0, 1.0 }    },
    faces =
        { 0, 2, 3 },
        { 0, 1, 2 }

There is a lot of emphasis on making the file easy to read and understand. What is easy to read can be subjective. I like this format because its concise, and avoids any redundant labels, names etc.  I also prefer to represent triangle faces than just a list of indices. I wrote a similar mesh exporter before where I exported to a custom XML format. In my experience it makes it easier to debug when I can count lines and jump to a triangle and see its vertices.

The winding order of my vertices is anti-clockwise. This follows OpenGL and Maya. Also my color requires 4 values. This makes the most sense to me because alpha values are natural to color and I can just set them to 1.0 when I need it to be opaque. This removes one more factor from the equation and avoids unnecessary complexities about alpha.

My mesh file currently has the .lua extension. I chose this because it really is a Lua file. This can lead to confusions between other Lua files that are actually scripts and not data assets. To deal with this I prefix all mesh files names. So for example, the square mesh is stored as Mesh_Square.lua.

Most of my time was spend in writing the code to load and process this mesh file. Before beginning the assignment I spend quite some time researching other Lua-C++ bindings. Based on my research I came to the conclusion that its preferable to avoid such libraries as much as possible. This is because the performance trade-offs aren’t well understood and it introduces dependencies that may bite us back in future. I think its okay to bear the painful Lua C API for code that is going to be written once and probably not something I would iterate on. If I had to write game logic or something that would go through a lot of iteration I will definitely use some library to help me out.

Once I was able to load the vertex and index data from the mesh file, all I had to do was call createMesh which I made in the last assignment and everything worked from there.

Like last time, here is the colorful square, now loaded from a file:


Controls: Press Esc to quit


Leave a Reply