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

Charlie's chat room

EAE6320 Assignment05

9/28/2015

0 Comments

 
So this week, we move more functionalities of building assets into lua-controlled.
Here's the effect after adding a new triangle mesh and make it enlisted in the AssetsToBuild lua table:
Picture
Next week we're going to work deeper into customizing our various assets builder. To prove that I could step-by-step debug it. Here's a screen shot of debugging MeshBuilder:
Picture
Just like BuildAssets.lua, I placed new AssetsToBuild.lua into the same folder of "Scripts". It's intuitive for me to do so because it keeps the same structure as the file directory on disk. These two files should be placed together because they work closely together that BuildAssets method in BuildAssets.lua is coded according to the design of key values and file structure in AssetsToBuild.lua. 

I'll keep the simplest structure of AssetsToBuild.lua as JP proposed. Info of a certain asset is kept under each array table. The array table contains key-value pairs which are convenient for lua program to access. Lua function simply visit array table one by one and call corresponding asset builder.
Picture
But obviously, this "raw" structure is not concise and systematic enough. I'll regroup and redesign the structure according to the classification of the assets.

​For BuildAssets project, I deleted input arguments of the custom build step when calling AssetBuilder.exe. The reason is straight forward that AssetBuilder.exe only call lua function with pre-determined asset list, AssetsToBuild.lua. In that, specific asset builders are designated and called. AssetBuilder as a main entrance doesn't need to take in any argument because it works on a predefined routine now.

BuildAssets shall depend on all the asset builders, by the end of this assignment, they are AssetBuilder, GenericBuilder and MeshBuilder projects. The reason is that BuildAssets will call AssetBuilder which will call other builders. All the builders should be ready when BuildAssets is done building.

AssetBuilder should depend on Lua project for sure because it has intensive interaction with lua scripts. Other than that, it also depends on Windows project for utilizing helper functions. It's worth noticing that although AssetBuilder will call GenericBuilder and MeshBuilder, it shouldn't depend on these two because it's a run-time dependency. AssetBuilder doesn't need anything from GenericBuilder or MeshBuilder in order to finish compiling and linking. As BuildAssets depends on all of them. It's already ensuring by the time AssetBuilder is running, GenericBuilder and MeshBuilder will be ready to be called.

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

0 Comments

EAE6320 Assignment04

9/19/2015

0 Comments

 
This week we combined shader for different platform into one. Also spent quite some stamina on changing from hardcode vertex/index buffer information to read them in from lua file and process them to make meshes.

The name I chose for my shaders are lininterpfragment.shader & lininterpvertex.shader. The reason for choosing these two are pretty straight forward that we're doing linear interpolation for color based on geometry info of the vertex. This name would be used to distinguish from other possible effect shader we'll make in the future.

I didn't make any improvement besides simply copy-paste two shaders together and add necessary macros. Reason besides laziness would be that the mechanics for the shader pair is simple. If asked to simplify that, I'll define common macro for float4 and vec4 to use in main method. Then the methods could share the same body. I doubt if there's too much we can do for declaring parameters because the layout vs semantics syntax difference.

About mesh file from which we get info to create meshes, I have to confess my crime here. I have two files for vertex and index separate. I hope this doesn't make the situation too bad. Here's a screen shot of part of my vertex (left) and index (right) mesh file:
Picture
Picture
Here I choose left-hand winding. Reason is pretty simple that I'm right handed that I could hold my mouse as the same time as using my left hand to mimic the gesture in order to figure out the sequence of the indices.

I'm keeping a 3-value input for color now. We're currently not bothered with transparency. What I did in the code is to set the a to 255 in the ctor so that we don't have to think of it for now.

The name for these two files are square.vertex.mesh & square.index.mesh. This name is very straight forward that reader will instantly know what they could expect to see in these two files.

Actually I was not planning to add the index value in each vertex table. But I changed my mind and I have a relatively good reason for it. My code for reading & creating meshes supports any number of vertex and indices. As a result, I prefer to use a while loop to get all the vertex info instead of using a for loop where the number of sub-tables needs to be known. Here I find the problem that the lua_next method which I'm using in while loop to iterate through the table doesn't have a fixed sequence. So I have to manually add index for them and do some tricks in code that if the vector is not large enough then just simply resize it to match the current index. There's no big problem for that. Also because of using lua_next, the key-value pair is automatically pushed into the buffer that I don't have to push a key and call lua_gettable for that. So what we can see as the names like v0, v1, i0, i1 are not necessary. It's just short and makes enough sense for the reader.

Again, the main goal for this particular design is to support all kinds of shapes that triangles can make. My detailed decisions are all made based on that. The reason for keeping indice and vertex in separate mesh file is that they're different concepts just like fragment and vertex. They should go different for better management. If I'm not right on this, I'll be very happy to hear some corrections.

Here's a copy of my executable. From here we can simply modify the mesh files and see the changes running the executable. It makes me feel much better and also gives me another reason for why keeping assets and coding separate would benefit.
assignment04.zip
File Size: 82 kb
File Type: zip
Download File

Update:
According to JP's advice. I made 2 major changes:
1. 2 separate mesh files -> 1 single mesh file. This also brings in the changes of file loading and processing. Here's the new structure of the mesh file:
return
{
-- vertex
    {
        position = 
        {
            0,
            0,
        },
        color =
        {
            1,
            0,
            0,
        },
    },
-- other vertex...
-- index
    {
        0,
        3,
        1,
    },
-- other index
}

The way to tell between a index and a vertex is by telling the size. luaL_len will return 0 when the state passed in is a key-value pair instead of pure array. According to the design above, vertex table length will always be 0 while index table length should be 3.
2. The other major change is to use for loop instead of while loop. A huge reason for this is to avoid the random sequence of reading sub tables for lua_next in while loop. The reason for me using while loop previously was because I didn't come up with the idea to distinguish vertex table and index table without a name (which makes them into key-value pair and thus gives up the ease of using purely for loop).
Here's my new executable. It can be seen obviously that there're only 3 files in data folder now, which fulfills the assignment requirements.

assignment04.zip
File Size: 141 kb
File Type: zip
Download File

0 Comments

EAE6320 Assignment03

9/12/2015

0 Comments

 
Picture
So this is about assignment 3. This week we run into some structure design besides copy existing code and modify them. 

We moved from using vertex buffer only to using both vertex and index buffer. Take the square which is made of two triangles as example, using only vertex buffer means we need to write position (2 floats = 8 bytes) and color (4 uint8_t = 4 bytes) for 6 vertex into vertex buffer. This takes 12 * 6 = 72 bytes. While using vertex and index buffer together means need to write position and color for 4 vertex (12 * 4 = 48) into vertex buffer and  6 indices (6 uint32_t = 24), sums up also equals to 72 bytes. Here the difference might be small because we're only drawing two rectangles. When the number of primitives grows, let's say 10 triangles. Vertex only approach takes 12 * 30 = 360 bytes while using both takes (4 * 30 + 12 * 10 = 240 byes. No need to mention situations in real industry where there's hundreds/thousands of primitives. Besides the advantage mentioned above, it's also more intuitive friendly logical to separate data and index of data.

My approach to represent mesh is considering each mesh as a triangle which takes 3 fixed index and 3 user defined vertex. Then everything becomes clear that from the user point of view, we want to do things like "CreateTriangle(vertex0, vertex1, vertex2)". I provided this interface to the user in my code. In our situation, it's not necessary to keep the vertex in mesh struct/class because it's passed into vertex buffer and nothing changes after that. I still keep a vertex[3] member in my mesh class in case of future use. Above that, I keep a static vector containing all mesh instances for render purpose per frame. OpenGL simply use vertex array id to find vertex buffer where we pushed relative info into. But I still keep the vector as the common structure in two implementations.

I was careless enough to miss the fact that direct3d uses a bgra instead of rgba. It takes more than half a hour to find out. Then I added preprocessor macros in order to make vertex struct work as it should for both implementations. As memory management, I make ctor and dtor private. Ctor is called when user calls AddTriangleMesh(v0, v1, v2). Then buffer is allocated by calling create buffer functions which used to be in Graphics implementations. Correspondingly, I have a shutdown function (cleanup might be a better name though...) which calls clear on the vector which then call all the mesh dtor to release buffer. For Direct3D implementation, direct3dDevice is needed in rendering, I pass this in with an initialize interface which takes a void pointer argument then reinterpret cast it back to direct3dDevice pointer in implementation. I hope to learn better ways to do that.
Common interface is always preferred because this normally means saving compiling time because changes could be changed in relatively small area. And this should be done sooner better than later when it grows larger, which means implementations are so different that separating them could be painful and hard to achieve. People need to take more time to get used to the different interface between them. It also helps when doing parallel comparison between different implementations.

My draw function DrawAll (poor name again...) is a static method in mesh class which takes no argument and return boolean to indicate result.
Picture
This is where it's called in GL and D3D implementations:
Picture
Picture
As mentioned above, direct3d doesn't have a "getDevice" method so I use void* pointer to pass device into mesh class. Also, for left handed and right handed difference between the two APIs, the buffer creation is also modified a little bit in order to share the same input.

Here's a copy of the executable part of the solution:
assignment03.zip
File Size: 28 kb
File Type: zip
Download File

0 Comments

EAE6320 Assignment02

9/6/2015

0 Comments

 
Picture
So here's how image looks like due finishing assignment 02. Looks like an rectangle but actually assembled by two separate triangles, the cheapest 2d primitive in rendering.

The overall object for this assignment is 1. getting basic lua supporting set up, being able to call functions bidirectionally. 2. get familiar with vertex rendering procedure by alternating various parameters. Particularly, I put the lua in both AssetBuilder project and also Scripts folder in my solution file. Reason for this is that when working in a group, there're people with different intuitions on this. My approach is to make them able to locate the file naturally with no extra costs. As long as these two files are pointing to the same file on disk. It's a safe and easy thing.

Getting to know more about lua is a good thing to me. The expression for me after the assignment is that it's a weak-type language with extensive friendly cross platform interface. It's also widely used in game industry so that's critical skill to possess. In our assignment, the building asset procedure is moved to a lua file which allows us to decompose the possible frequently changed code away from the structure code. It could be a very beneficial approach in real industry for avoiding conflicts. 

The function of the whole AssetBuilder project remains unchanged. It's a processor for incoming assets. The core of the process will be done in lua file in the future although it's now just ensuring the existence of the assets and target folder, then copying them over. Using lua for class is not only for preparing entering industry, it's a flexible tool that separated from the compilation process. In a real industry environment. Compilation could take painfully long. Changes in script language doesn't need recompile. Another reason could be there're situations when we want to control the number of staffs who would actually dig into compile code. People working in script language like lua could help on this tool.


Getting to know something new about how different graphic APIs work is always a pleasure. In my previous course, the concentration is basically on algorithm and concept related programming like ray tracing. This time I got a chance to look into more function-oriented side of graphics. The size of vertex buffer is something I didn't look into before. Allocating exactly as large as we'll use is a nice principle to keep in mind. I'm also looking forward to work with various memory buffer soon. The application of Depth buffer and Stencil buffer such as mirror effect can be super fun to me. 

It's a pity that I didn't attend the class. It's apparent that I don't have too much to conclude for the materials on the course. Hopefully we can get the recorded class content online sooner or later so I can go over that remotely.

The time spent on this one is about 6 hours in total. Although this one is not exceptionally tough, it still broadens the possible routes we could run into in the future. More graphic stuff is coming soon I guess. By then I'm eager to vary the rendering process of two APIs more. 

Here's a sample of my executable.
assignment02.zip
File Size: 26 kb
File Type: zip
Download File

0 Comments

EAE6320 Assignment01

8/30/2015

1 Comment

 
Picture
So, this is about assignment 1. The basic idea of this one is to assemble a solution with an efficient structure which contains necessary tools for how visual-related assets could be "reinterpreted" and get explained on the screen. Specifically, an asset builder and corresponding helper were added to the solution to process raw assets (currently we make a simple copy of it). Then renderer could make use of these assets (shaders in our case) to generate rendering contents on screen. More details will come after this course proceeds.

The figure showed above is built in a combination of 64 bit Direct3D platform and Release configuration, as required.

Some of the projects require windows platform specific methods which are wrapped in Windows.lib. It contains our own definition besides basic windows defined methods. And it locates in Engine section of the source code which is reasonable considering it's purpose and frequency being referenced.

Our build-generated files are located in a folder named "temp", which is excluded from source control. A main purpose for this could be saving time push/pull these frequently changed but relatively large-in-size files. It's helpful keeping them locally to avoid extra building time in real industry production though. But this may also cause serious problems. I'll take a personal example on that. In a Microsoft build server, there're different configuration about if clean up the previous build. Administrator could set it to completely clean up (intermediate and output), partial clean up (just intermediate), or no clean up. In my company, our gated check in build queue is set to be no clean up because it saves plenty of time (16 mins compared 4 hours) that more than 10 changeset could be merged per day. Of course, after passing gated check in. There're extra build servers and testing machines performing some verification procedure on that. Some one who doesn't perform full-build (all cleanup) on testing build queue merged in his change with bugs that polluted the gated check-in queue. So extra time would be spent on clean up the queue so that commits after could be merged in. I think it's always a good idea to keep the public-access domain as clean as possible, just as the same as being requested in this assignment.


As a way to work better with artists, we may want to get their work as input and get data we can use directly in code as output. The whole processing procedure is done by asset builder. The general part such as dissecting every possible kind of file and passing the data buffer through interface should be discrete from the actual game code simply because different game implementations could take different approach to further process these data buffers. This is also the reason why we may keep the general function into some section called "Engine" or "Tools", leaving only the specific traits into the actually game code.

I'm pretty sure this course will improve my design/architecture skill. And that's what I want most out of the class. Solid debugging skill may also come together. I really like the part of recording each class so that I can review that as many times as I can. By the end of the semester, I would say that I could get a further understanding of every procedure involved from translating raw data to in-game use data processing. I haven't got a particular detailed expectation of what exactly I want to get out of the class. But I'm generally interested in graphics related algorithm such as applying octree in ray tracing. This could be a little far from the course though.

Item below is the executable. It takes around 8 hours to finish this one.
assignment01.zip
File Size: 337 kb
File Type: zip
Download File

1 Comment

2015 spring semester

1/15/2015

0 Comments

 
So it comes, my second semester in U of Utah game programming.
I'm taking 3 courses this semester.

Game project 1 is the first part of 3-semester thesis project. We're going to work out a published version of a new title. By the end of this semester, we're going to work out the alpha version of the game. Currently, I'm at the step of coming up with game ideas. We're going to work on teams after we choose a game idea we're all interested in.

Game Engineering 1 is a continuous class from c++ game programming. Based on the engine I worked out last semester, I'm going to add more modules like renderer to the engine. Also, different from last semester when engine is non platform based, it comes to be more specific for windows platform.

Narrative in Game Design is a course concentrating on story telling. I choose this as my selective course. I'm an engineer but I still want to see how we can make a complete and attractive story line. I'm pretty curious about how to make confusing conflicts in games which cause players to think throughout the story line.

More updates will come out as the semester progresses :-)
0 Comments

I start my website :-)

1/11/2015

0 Comments

 
Well, I finally make that and publish it. I want to use this one as a portfolio and also part as a blog to record my status.

An important thing to do is to finish the experience section, to provide a detailed description to the experiences on resume and also those not on it.

Finally, A Big Welcome!
0 Comments
Forward>>

    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.