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:
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:
 |  |
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.
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 |
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:
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
}
{
-- 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 |
RSS Feed
