• Home
  • Resume
  • Experiences
  • Blog
  • Story about myself
  • Contact

Charlie's chat room

EAE6320 Assignment08

10/29/2015

0 Comments

 
Picture
This is my human-readable effect file. Simple enough, it indicates path for vertex shader and fragment shader in a key-value pair pattern. There's no special reason for such a design but simple enough as well as fulfill user requirements for now. This may face redesign in future.
Picture
This is my binary effect file. As we can observe, it simply contains two strings which represent name for binary vertex/index shader separately. And after each string, an '\0' is added to indicate string end. This is used when reading strings from buffer. At run time, the first string is get by std::string(buffer). std::string ctor will automatically truncate string at first '\0' it meets. Then the beginning index of the second string is got by offset = strlen(FIRST_STRING) + 1. Do another std::string(buffer + offset) will get the second string.

I choose to use one builder for both shaders as JP did. Optional arguments will be practical for many builders so it's a capable candidate to add to AssetToBuild file. I would consider slightly increasing in build time acceptable compared to duplicate code. For assets need optional arguments to build, structure looks like this:

{
    Tool = "ShaderBuilder.exe",
    Assets =
    {
        "lininterpvertex.shader",
    },
    Optional =
    {
        "vertex",
    }
}

Other assets look like this:

{
    Tool = "EffectBuilder.exe",
    Assets =
    {
        "default.effect",
    }
}

The reason for having custom defined macro for shader is to make it more flexible. We can have different sets of defined settings such as having a logo version and a no-logo version but both with debugging enabled.
Picture
Picture
Above 2 figures are debug vs release version of d3d vertex shader. Release version is much shorter than debug version. This is because we pass in an allowing optimizing argument for release version. It's the shortest possible but containing all info.
Picture
Picture
Above 2 figures are debug vs release version of gl vertex shader. Release version is slightly shorter only because it gets rid of newline character in the file. It's reasonable to do so in a release build because we need less readability on release version, while we need to see a better line-divided organizing file while debugging.

Here's a copy of my executable
assignment08.zip
File Size: 42 kb
File Type: zip
Download File

0 Comments

EAE6320 Assignment07

10/10/2015

0 Comments

 
Picture
So this week we worked on getting things moving around. In my case, you could use "aswd" (lower case) to move both triangles around.
The first intuitive thing that could help could be thinking over to decide which engine structure to apply for future. I finally took the component approach which kind of intentionally mimic Unity. I have GameObject which contains position and name info. It also keeps a list of possible components. Every component keeps a reference of the GameObject to which it is added. Renerable inherits from component class and keeps a static list of renderable components. It calls every renderable component to set effect (if necessary), set uniform position obtained from GameObject reference, and then draw mesh. Controller is another child class of component. WSAD controller used for triangles inherits from controller class which keeps a list of all controller component waiting to be called in update just like renderable components. As two separate controller is added to each triangle, time class is refactored into class whose instance is kept with controller instance to measure time separately.

During refactoring, forward declaration is preferred in order to save compile time as well as avoid circular dependency. Meanwhile, I was unfortunately that I met the weird bug that d3d9xshader is could not be found during building. Forward declaration also works for solving this problem.
Compared to vertex data, uniforms are variables that could be modified during frame to affect graphic effects. Vertex data is more "fixed" data that used to express all-time constant such as relative position of vertex from the center of gameobjects. The benefit of using uniform for representing offset is that we could change relatively fewer parameters compared to changing all vertex data. In future assignments, uniforms will also be added to fragment shader to manipulate color effects. 

Here's a copy of executable:
assignment07.zip
File Size: 46 kb
File Type: zip
Download File

0 Comments

EAE6320 Assignment06

10/1/2015

0 Comments

 
So this week, we started push a little bit further on both mesh processing and shader creating.
Picture
Above is a figure showing my whole binary file for a square and a triangle.

As you may see, the sequence of 4 pieces of data in my case is NumOfVertex, NumOfIndice, VertexData and IndiceData. The reason to put counts ahead is simply that their size is fixed. In the case of processing multiple lua meshes, we need to rewrite part of the file. If 2 counts comes first, then we just need to move IndiceData from its beginning because we will write in new VertexData, while previous VertexData doesn't need to be moved.

The reason number must come first is that they should be used to calculate the size of the data chunk. No one would know how much we should read unless we know how many corresponding data there are.

Binary data is fast in process because it's pure std library work with the minimum data size. It saves time when loading a scene in the game. It's also smaller in size. The more human readable an asset is, it's more likely to be large sized compared to its binary peer. When we ship a product build, we also want to save disk space for users. Human-readable assets has its advantage just as the name suggests. As asset author or engineers, we need to look into assets efficiently to modify assets. So that's necessary to have both binary and human-readable version of the same assets for our case.

My triangle lua mesh is 4096 bytes while binary mesh is just 56 bytes.

Here's my code loading binary mesh data into memory:
Picture
I also modified my AddTriangleMesh to static class that no longer holds instance of separate triangle mesh pieces.

Here's a picture showing how I load my shader file.
Picture
The class shader collection also contains a map keeping key-value pairs which represent effect name and effect instance. User of the class could create multiple effects with different name and set them during rendering call with their own name.

Here's how I call set effect in rendering code:
Picture
Simple and short enough. If a name is not given at creation, an effect instance will have a default name, this name will also be used as the default input of set effect method.

Here's a copy of my executable:
assignment06.zip
File Size: 36 kb
File Type: zip
Download File

UPDATE:

So I made an inappropriate decision merging multiple binary file into one. Doing so means it's hard to have different effects for different meshes. I modified my TriangleMesh class back to preserving a static multimap keeping all mesh instances labeled with a name ("default" by default). DrawAllMeshes method is used to draw all meshes. DrawMeshesWithName method is used to draw all meshes with the same name.

Here's the new executable:
assignment06.zip
File Size: 37 kb
File Type: zip
Download File

0 Comments

    Archives

    January 2016
    December 2015
    November 2015
    October 2015
    September 2015
    August 2015
    January 2015

    Categories

    All
    Campus Game Programming
    Free Bla

    RSS Feed

Powered by Create your own unique website with customizable templates.