Parse error: syntax error, unexpected '$m' (T_VARIABLE) in /home/disckitt/public_html/pmwiki.php(468) : runtime-created function on line 1
disckitty.ca Gallery/CS488 - Assignment 3
Gallery

CS488 - Assignment 3

(:nl:)

September 01, 2014, at 05:09 PMerika

This assignment involves familiarizing oneself with heirarchical modelling. In other words, the ability to take, for example, a puppet, and by moving it's arm, the child nodes - like the hand and whatnot - move accordingly and smoothly. Other requirements included implementation a user-friendly 3d/trackball-like rotation, and having z-buffer/backface/frontface polygon culling. Read more...

We were given a very basic canvas to start off with: a grey background, with a white circle, which indicated where the trackball rotation boundaries are. At this point, without anything worthwhile to render, I immediately implemented z-buffer switches, back and frontface culling, as well as being able to turn the trackball boundary circle on and off. ''(It seems when I go to implement things, I figure out what the UI will look like, and then fill in the content from there - trivial things are gotten rid of immediately.)'' For those not in the know, z-buffer ensures that the objects closest to the user are drawn last, and those furthest are drawn (or appear to be drawn) first. If z-buffer is not on, objects might be drawn over top of each other in an order that isn't the normal front-to-back (eg. a car tire might be drawn after the frame is drawn, giving the appearance of a tire floating in the air). Back face culling ensures polygons which are facing away from the user are not drawn. Similarly front face culling, ensures polygons which are facing the user are not drawn. So having back and front face culling on draws nothing. It's most normal to have z-buffering on, and only backface culling on.

The base geometrical object for the assignment was a sphere. Although we could implement the sphere as a strip of quads (ie. rectangles) - which theoretically speeds up render times, I decided to leave such an extra until the end. ''(I ended up not having time to figure out the math behind it, and therefore did not implement it)'' Once being able to render a sphere within the provided framework, plus some implementation of material colouring, a default light, and some other mathie methods (eg. processing of scaling, rotation and translational abilities), I was able to get the basic a3mark.lua "puppet" to render similar to the given a3mark.png provided.

Once I could get the basic (no joints) a3mark to appear, I immediately began to model a basic puppet so as to test out joints and picking as I implemented it. We were given a diagram of what a minimal puppet should look like in the assignment specs, so I essentially implemented it in real life, plus some colouring. In order to do this effectively, I eventually created a Reload Puppet mechanism, that would take the current puppet file, and reload it. I knew this would be useful for my final puppet creation, rather than restarting the application each time I need to see if a joint/geometry is in the right place.

Picking is the means by which selection of an object occurs. So in the assignment, we're expected to be able to pick any geometry which will modify it's direct ancestor joint node. Having done this already in Assignment 1 for CS798, this part was extremely straight forward. Apparently it's most common to have the object become extra shiny when it's been selected (the specs say to highlight the selected geometries), but to me that makes no sense if you have an already maxed out shiny geometry (which would look awful anyways, but meh). So instead, my selected geometries take on an alpha transparency, and the OpenGL blending mechanism is turned on/off as needed.

Next on the list was the ability to rotate joints. Select a joint and rotate. Easy. The hierarchy, along with matrix multiplication, makes this extremely straightforward. So as an FYI, the different menus have the following functionality: Application allows for resetting of joints, or puppet orientation, or puppet position, or reset all of the above; quitting the application, reloading the current puppet, or selecting - from a file browser - a different puppet to load into the scene. It doesn't support multiple puppet loading, as I only had so much time. The Edit menu allows for undo/redoing the joint rotations. The Mode menu sets whether the current mode is for joint rotations, or for puppet position/orientation. The Options menu turns on/off z-buffer, front/back face culling, and the trackball circle. The Help menu has an about item, as well as a really irrelevant help item.

With joints implemented, and limited desire to sort out trackball rotation or undo/redo (evil undo/redo - actually, it wasn't that bad, I just didn't much care to implement it), I began implementing my Rainbow Brite character, as well as the associated primitives (geometries) that she would need/might need. Most terms, there is a graphics t-shirt created, which has all the puppets positioned in a scene, and some nice screen shots of a few projects/ray tracers scenes. In order to simplify puppet addition to the t-shirt scene, some staple geometries were set: spheres, boxes, cylinders, cones, and meshes. (Later textures were added - and someone did a great army transformer with it, but I didn't have time/desire to play with that for my puppet). In getting the mesh primitive to work, I used meshes from the Lua files provided in A4 (and discovering the ability to load .obj files, which would become a great help later on in the puppet). I ended up implementing vertex normals, based on the vertex's associated faces. Once that was all done, I began to build a basic Rainbow Brite character out of spheres and cylinders. I knew that I'd eventually model some funky meshes, but wanted to get a start on her anyways.

Oh, as a slight aside, I'll go into the decision making requires for my choosing Rainbow Brite. I've probably spent at least a couple of hours each year since entering university checking out the CS488 gallery and drooling/admiring all the cool puppets, raytracer pictures, and projects. So awesome. Something to aspire to achieve. Hence, I knew I'd have to create some great puppet for the site. Further, the more popular ones, as far as I can tell, are popular TV, movie, and video game characters: eg. Homer Simpson, Stewie from Family Guy, a fantastic Link character from Zelda, Batman. The cartoon ones always seemed to turn out better than the ones based off of real actors. When the term finally rolled around, and I got mid-way through Assignment 2, I started idea generating about puppets. My top 3 were Rainbow Brite, Strawberry Shortcake, and a realistic rendering of a lion (which is why I'm so proud someone did a lion this term). When I discovered some really awful things (Strawberry Shortcake is still an innocent child in my books, but I didn't want some horrible associates to result - further I consider all people equal regardless of gender, race, religion, sexual orientation, or any otherwise segregational feature, although I wouldn't mind castrating whichever fuckwad came up with Urban Dictionary's version of Strawberry Shortcake), I decided against doing Strawberry Shortcake. And after discovering some heartwarming comments about Rainbow Brite (I swear I found comments stating she has great leadership skills from a non-biased site, but I can't find it), and I decided she was the puppet for me. However, I spent a good several hours trying to hunt down a good image of her on the internet. Finally I found an excellent image, but really most images of her are either anime renditions, or cropped/small screen shots. Couldn't even find a torrent to style her off of! Also, FYI, Rainbow Brite's real name is Wisp (Played by the actress Bettina).She's a character in the children's 80's cartoon '''Rainbow Brite'''.

Having gotten meshes to work, and the beginning of a basic Rainbow Brite torso/head (oh! and a fantastic way of getting the eyes to move/rotate realistically!), I went home to model some of the other body parts. Unfortunately, most of them created massively messed models when imported - the basic shape seemed present, but with massively altered vertices jutting out every so often - so I went home to try again. When they were still messed, I discovered parse errors were interpretting really small values (2.3x10'^-9^') as massive numbers (2.3x10'^9^'), and did a quick find-replace to fix that. I then discovered that most all of the modelled objects had their normal facing the wrong way. (Some of the included images look ok, only because I have front and back face culling off, which means the normals given the appearance of looking alright) :( This I was not to ever fully fix. I discovered that a particular method of creation ensured normals were right more often than not, but not for all items.

----

----

I should point out that I didn't entirely get joint rotation to work on the first try. Angles were required to be fixed within a particular range, and mine appeared to be performing invalid rotations. After a quick talk with a TA, ends up, I was accumulating angles, wherein I should've been keeping them distinct. I eventually tossed in a copy-paste job (as was required - honest!) of the trackball code, with some modifications for OpenGL, and later a fix on the viewing matrices being multiplied correctly - accumulating by their transposes, not accumulating, and then being transposed. And finally buckled down - during all of the mesh messiness above - and implemented undo/redo. I wanted to be able to undo/redo any transformation (puppet or joint, or a reset call), but in the end just kept with the assignment guidelines, and only applied undo/redo to the joint rotations. We were required to indicate if an undo/redo occured when none existed, and after first using popups (gosh popups are annoying), I decided a status bar would look/work much better. I ended up further adding which mode (Puppet Adjustment vs. Joint Adjustment) we were currently in, as I kept on forgetting.

Finally, after a mostly unsuccessful last ditch attempt at mesh modelling (I kept going home to model, and returning to campus to check, as my bandwidth was toast at home), I gave up, and started using the provided primitives to generate the end puppet. No shadows, you'll notice, and there should be 3 degrees of joint rotation in the shoulder and leg sockets, but there aren't. All the fingers are moveable, as appropriate, the eyes move, the head, neck, hips, legs, thighs, and ankles move. Also, so as to present a smooth looking arm bend, each coloured arm bubble has a small rotation, that when rotated together provide a bent arm look. A lot of fellow students in the graphics lab complimented me on the hair while I was working on her. *so proud* :)

(:blogid:gallery:) (:entrytype:blog:) (:entrydate:1409605740:) (:entryauthor:erika:) (:entrytitle:CS488 - Assignment 3:) (:entrystatus:publish:) (:entrycomments:none:) (:entrytags::) This assignment involves familiarizing oneself with heirarchical modelling. In other words, the ability to take, for example, a puppet, and by moving it's arm, the child nodes - like the hand and whatnot - move accordingly and smoothly. Other requirements included implementation a user-friendly 3d/trackball-like rotation, and having z-buffer/backface/frontface polygon culling. Read more...

We were given a very basic canvas to start off with: a grey background, with a white circle, which indicated where the trackball rotation boundaries are. At this point, without anything worthwhile to render, I immediately implemented z-buffer switches, back and frontface culling, as well as being able to turn the trackball boundary circle on and off. ''(It seems when I go to implement things, I figure out what the UI will look like, and then fill in the content from there - trivial things are gotten rid of immediately.)'' For those not in the know, z-buffer ensures that the objects closest to the user are drawn last, and those furthest are drawn (or appear to be drawn) first. If z-buffer is not on, objects might be drawn over top of each other in an order that isn't the normal front-to-back (eg. a car tire might be drawn after the frame is drawn, giving the appearance of a tire floating in the air). Back face culling ensures polygons which are facing away from the user are not drawn. Similarly front face culling, ensures polygons which are facing the user are not drawn. So having back and front face culling on draws nothing. It's most normal to have z-buffering on, and only backface culling on.

The base geometrical object for the assignment was a sphere. Although we could implement the sphere as a strip of quads (ie. rectangles) - which theoretically speeds up render times, I decided to leave such an extra until the end. ''(I ended up not having time to figure out the math behind it, and therefore did not implement it)'' Once being able to render a sphere within the provided framework, plus some implementation of material colouring, a default light, and some other mathie methods (eg. processing of scaling, rotation and translational abilities), I was able to get the basic a3mark.lua "puppet" to render similar to the given a3mark.png provided.

Once I could get the basic (no joints) a3mark to appear, I immediately began to model a basic puppet so as to test out joints and picking as I implemented it. We were given a diagram of what a minimal puppet should look like in the assignment specs, so I essentially implemented it in real life, plus some colouring. In order to do this effectively, I eventually created a Reload Puppet mechanism, that would take the current puppet file, and reload it. I knew this would be useful for my final puppet creation, rather than restarting the application each time I need to see if a joint/geometry is in the right place.

Picking is the means by which selection of an object occurs. So in the assignment, we're expected to be able to pick any geometry which will modify it's direct ancestor joint node. Having done this already in Assignment 1 for CS798, this part was extremely straight forward. Apparently it's most common to have the object become extra shiny when it's been selected (the specs say to highlight the selected geometries), but to me that makes no sense if you have an already maxed out shiny geometry (which would look awful anyways, but meh). So instead, my selected geometries take on an alpha transparency, and the OpenGL blending mechanism is turned on/off as needed.

Next on the list was the ability to rotate joints. Select a joint and rotate. Easy. The hierarchy, along with matrix multiplication, makes this extremely straightforward. So as an FYI, the different menus have the following functionality: Application allows for resetting of joints, or puppet orientation, or puppet position, or reset all of the above; quitting the application, reloading the current puppet, or selecting - from a file browser - a different puppet to load into the scene. It doesn't support multiple puppet loading, as I only had so much time. The Edit menu allows for undo/redoing the joint rotations. The Mode menu sets whether the current mode is for joint rotations, or for puppet position/orientation. The Options menu turns on/off z-buffer, front/back face culling, and the trackball circle. The Help menu has an about item, as well as a really irrelevant help item.

With joints implemented, and limited desire to sort out trackball rotation or undo/redo (evil undo/redo - actually, it wasn't that bad, I just didn't much care to implement it), I began implementing my Rainbow Brite character, as well as the associated primitives (geometries) that she would need/might need. Most terms, there is a graphics t-shirt created, which has all the puppets positioned in a scene, and some nice screen shots of a few projects/ray tracers scenes. In order to simplify puppet addition to the t-shirt scene, some staple geometries were set: spheres, boxes, cylinders, cones, and meshes. (Later textures were added - and someone did a great army transformer with it, but I didn't have time/desire to play with that for my puppet). In getting the mesh primitive to work, I used meshes from the Lua files provided in A4 (and discovering the ability to load .obj files, which would become a great help later on in the puppet). I ended up implementing vertex normals, based on the vertex's associated faces. Once that was all done, I began to build a basic Rainbow Brite character out of spheres and cylinders. I knew that I'd eventually model some funky meshes, but wanted to get a start on her anyways.

Oh, as a slight aside, I'll go into the decision making requires for my choosing Rainbow Brite. I've probably spent at least a couple of hours each year since entering university checking out the CS488 gallery and drooling/admiring all the cool puppets, raytracer pictures, and projects. So awesome. Something to aspire to achieve. Hence, I knew I'd have to create some great puppet for the site. Further, the more popular ones, as far as I can tell, are popular TV, movie, and video game characters: eg. Homer Simpson, Stewie from Family Guy, a fantastic Link character from Zelda, Batman. The cartoon ones always seemed to turn out better than the ones based off of real actors. When the term finally rolled around, and I got mid-way through Assignment 2, I started idea generating about puppets. My top 3 were Rainbow Brite, Strawberry Shortcake, and a realistic rendering of a lion (which is why I'm so proud someone did a lion this term). When I discovered some really awful things (Strawberry Shortcake is still an innocent child in my books, but I didn't want some horrible associates to result - further I consider all people equal regardless of gender, race, religion, sexual orientation, or any otherwise segregational feature, although I wouldn't mind castrating whichever fuckwad came up with Urban Dictionary's version of Strawberry Shortcake), I decided against doing Strawberry Shortcake. And after discovering some heartwarming comments about Rainbow Brite (I swear I found comments stating she has great leadership skills from a non-biased site, but I can't find it), and I decided she was the puppet for me. However, I spent a good several hours trying to hunt down a good image of her on the internet. Finally I found an excellent image, but really most images of her are either anime renditions, or cropped/small screen shots. Couldn't even find a torrent to style her off of! Also, FYI, Rainbow Brite's real name is Wisp (Played by the actress Bettina).She's a character in the children's 80's cartoon '''Rainbow Brite'''.

Having gotten meshes to work, and the beginning of a basic Rainbow Brite torso/head (oh! and a fantastic way of getting the eyes to move/rotate realistically!), I went home to model some of the other body parts. Unfortunately, most of them created massively messed models when imported - the basic shape seemed present, but with massively altered vertices jutting out every so often - so I went home to try again. When they were still messed, I discovered parse errors were interpretting really small values (2.3x10'^-9^') as massive numbers (2.3x10'^9^'), and did a quick find-replace to fix that. I then discovered that most all of the modelled objects had their normal facing the wrong way. (Some of the included images look ok, only because I have front and back face culling off, which means the normals given the appearance of looking alright) :( This I was not to ever fully fix. I discovered that a particular method of creation ensured normals were right more often than not, but not for all items.

----

----

I should point out that I didn't entirely get joint rotation to work on the first try. Angles were required to be fixed within a particular range, and mine appeared to be performing invalid rotations. After a quick talk with a TA, ends up, I was accumulating angles, wherein I should've been keeping them distinct. I eventually tossed in a copy-paste job (as was required - honest!) of the trackball code, with some modifications for OpenGL, and later a fix on the viewing matrices being multiplied correctly - accumulating by their transposes, not accumulating, and then being transposed. And finally buckled down - during all of the mesh messiness above - and implemented undo/redo. I wanted to be able to undo/redo any transformation (puppet or joint, or a reset call), but in the end just kept with the assignment guidelines, and only applied undo/redo to the joint rotations. We were required to indicate if an undo/redo occured when none existed, and after first using popups (gosh popups are annoying), I decided a status bar would look/work much better. I ended up further adding which mode (Puppet Adjustment vs. Joint Adjustment) we were currently in, as I kept on forgetting.

Finally, after a mostly unsuccessful last ditch attempt at mesh modelling (I kept going home to model, and returning to campus to check, as my bandwidth was toast at home), I gave up, and started using the provided primitives to generate the end puppet. No shadows, you'll notice, and there should be 3 degrees of joint rotation in the shoulder and leg sockets, but there aren't. All the fingers are moveable, as appropriate, the eyes move, the head, neck, hips, legs, thighs, and ankles move. Also, so as to present a smooth looking arm bend, each coloured arm bubble has a small rotation, that when rotated together provide a bent arm look. A lot of fellow students in the graphics lab complimented me on the hair while I was working on her. *so proud* :) (:nl:)

BlogIt Side bar (:blogid:blog1:)

Recently Written

* Countdown * CS488 - Sample Assignments * CS798 - Assignment Samples * PM370 - Final Project * CS798 - Final Project * CS488 - Assignment 5 * CS488 - Assignment 4 * CS488 - Assignment 3

erika: end hiding comments and categories

erika: end hiding comments and categories

* login

Group-Specific Sidebar

Blix theme adapted by David Gilbert, powered by BlogIt