Max Proof: Finishing the HUD

  Hey guys, I know I said in one of my previous blogs that I would go over the last few functions of the HUD class or in other words the Inventory. In this blog I actually wanted to go over the final pieces of the Inventory functionality that I created for Max Proof. These last four functions are fairly simple and once one of the functions were created I was basically able to transfer that functionality over to the other functions. To begin, I mention in my previous blog that once quantity of an item is equal to zero, the graphic of an image will change. These four functions will handle that logic. For each item in the inventory I created a binding to the Brush.

  Upon creating a binding to one of the graphics in the inventory I begun creating the logic. Before I went about doing this though, I created four variables of type Slate Brush; CurrentImageG, CurrentImageB, CurrentImageT and CurrentImageL. The purpose of these variables is to hold the brush values. In the beginning of the function I want to do a check. If CurrentQuantityG is equal to zero then set CurrentImageG to the graphic that indicates to the player that we are out of this item. If false have the default image be the image assigned. Afterwards we want to return CurrentImageG. Having this function binded to the brush allows us to dynamically change the inventory graphic depending on what quantity is.

  Now that we have this function done I begun duplicating the logic onto the other functions I binded to the graphics. Thus completing the HUD for Max Proof! The great thing about having our logic like this for the HUD and as well as creating a dynamic item class is upon creating other levels for Max Proof, all we have to do is throw hazards of Item into the scenery and everything will work perfectly. Having achieve this we were able to minimize the amount of additional logic we would have to create when beginning a new level. With that being said, onto the next task!

Max Proof: Finishing Item Blueprint

  Hey guys, I wanted to continue from where I left off with the Item Blueprint. Previously in the blueprint I was working on creating the construction script for the class to where we can allow anyone such as designers or anyone in my team to be able to change the items mesh, material and collision. Having complete the construction script I was ready to jump into creating the full logic for the item class. To give a brief description of the classes purpose; in Max Proof, players have the opportunity to grab different hazards in the level and move them to prevent Max from getting hurt. These hazards are considered to be Items in the level. So with that we know well one, players need to be able to have the ability to drag and drop them in the game world and two, if the player fails to move them from Max's reach well there's a point deduction. With knowing this information we can begin our logic for this class. Very similar to how we creating the drag and drop for our HUD items, we can apply this same logic for our Item class.
  You may recall in one of my previous blogs that I discussed the issue with creating a smooth drag and drop with the HUD versus any other class blueprint. In any other class blueprint, we have the option of creating on click and on release events. In widget classes we only have the option of creating on click events. When it came to creating the movement logic for our item class, it was far more smoother and vastly simple to do. To begin I created a function called SetActorPos.

  In SetActorPos I created three variables; bool MouseBtnHeld, vector MousePos and Item ItemObj. The purpose of MouseBtnHeld is to check when the mouse is being pressed on an item. So with this check we can say hey, when this is true at every tick get the mouses position and assign that to the actor position. Now this is where MousePos comes in. MousePos gets and updates the X,Y position of the mouse. You may be wondering, whats with ItemObj? Looking at the picture above we assign the target of SetActorLocation to ItemObj. Keep in mind ItemObj is of class Item so we're basically saying hey...For every hazard of class Item, we will update it's position upon click. Now the different thing we did with this variable is allow it to be editable. Doing this now allows you in the editor to say what each instance of the class is. So let's begin the logic! When SetActorPos is called we do a check. If MouseBtnHeld is true, continue the logic; set MousePos which is given through breaking a vector that receives a hit result under a mouse cursor. Afterwards SetActorLocation using the parameters ItemObj and MousePos. Now that we have this done we can begin creating our last two functions.
  These next two functions I created were more towards if someone decided to play this on PC. In all honesty we could've took these functions out during refactoring but we decided to leave it for the moment. The two functions I created are basically HoverBtn but for hazards. So whenever we go over a hazard, the mouse cursor changes images. These two functions I created are called SetHold and ReleaseHold. In SetHold we say hey, we have officially clicked and are holding on a hazard so change the image. In ReleaseHold we are saying, we have now released the mouse button so now changed the image once more. So let's begin!

  Looking at the image above upon calling SetHold function we are setting the mouse cursor's image to GrabHandClose and the target is Get Player Controller. Afterwards we set MouseBtnHeld to true because when it's true we're able to dynamically move the actor. Similarly in ReleaseHold we have the same logic but Instead we have the image be GrabHand and we set MouseBtnHeld to false.

  Thus ending the last two functions. Now that we have that over we can now begin the last part of the class which is the Event Graph. To make this class come to life in Max Proof we now need to call these functions made. On InputTouchEnter and OnBeginCursorOver we set the mouse cursor image to GrabHand. On InputTouchLeave and EndCursorOver we set the mouse cursor image back to default. On Click and OnTouchBegin we call the SetHold function. We do this because upon clicking the image, we want it to look like its visually being held and plus it allows the SetActorPos to become active. To continue this OnRelease and OnTouchEnd we call the ReleaseHold function. Lastly to end the class on EventTick we call the function SetActorPos.

So now if we were to throw instances of this item class into the level, we can drag and drop now.

Max Proof: Item Blueprint Construction Script

  Now that we have the majority of the Inventory working I wanted to jump into our hazards logic. The point of hazards in Max Proof is to basically have items that are dangerous become obstacles for Max when he ventures in the level. Upon stumbling on a hazard, points will be deducted. When we thought about creating hazards for Max Proof we wanted to make this as dynamic as possible. Having four years experience with Unreal Engine 3, I know the hassle you would have to go through to create logic for each individual item that does the same thing. Fortunately for Unreal Engine 4 they have class blueprints. So if I wanted to create a door that opens and closes, I can do it once and drop the blueprint as many times as I want in the level and the logic will remain. So when considering this how can we have a dynamic class that keeps consistency of the same logic? We can definitely do interfaces. In fact interfaces would be perfect for situations like this. Now having said that, we actually went a different route. My goal for this was to have one class that does it all. Thankfully in Unreal Engine 4 they introduce Construction Scripts.
  In a Construction Script, you have the freedom to create logic that will run while in the editor. So what we did was create a generic item blueprint. In this Item blueprint we wanted to throw it in the level and then in the details panel be able to change the default mesh to whatever mesh we want it to be, change the material for that mesh, as well as the collision response for that mesh. So what we we're doing here is hey, all logic for the items are the same however, these items are different visually. Upon creating the item blueprint I two components; a static mesh and a trigger volume as a child of the mesh.

  After doing that I went into it's construction script and created four variables. One of type Static mesh and I called it Custom Mesh. The other of type ECollisionResponse and I called it CollisionResponse. The next one of type ECollisionChannel and I called it CollisionChannel. The last was of type Material Instance and I called it Material. After creating all variables I went to each one and checked Editable. Now comes some logic for the construction script.
  At the beginning when the construction script runs we have it where we set a static mesh, the target is CustomMesh. Then we set Collision Response to Channel. The Channel is CollisionChannel and and the response is CollisionResponse. After that we set Material of the mesh and the target is Material.

  So if we were to jump into throwing an Item blueprint into the level, once clicking the item in the scenery we can see a few things added into the details panel. In the editor we can now change the item's static mesh, material, and as well as the collision response/channel. Now you may be wondering what's up with ItemObj and what does that mean. ItemObj actually identify s what object it is of that class. This will be discussed in a future blog where I get into creating hazards that can similarly to the inventory be able to pickup and drop into the world. Stay tune!

Max Proof: Polishing the Inventory

  Hey guys, haven't been on for a while and thought it be good to continue from where I left off on the Inventory for Max Proof. The great news is we fine tuned the Inventory and everything is working smoothly! After we completed the inventory we did some refactoring and took out anything we felt was unnecessary. Sadly considering this project is under development for mobile, we decided to remove the "HoverBtn" function. To give an idea of what HoverBtn was about, well the purpose of the function was to dynamically change the mouse cursors image when the player hovers over an inventory item or even a hazard in the scene. Having said that I wanted to go over the neat features we added on to the Inventory.
  To break it down, we added in the feature of quantity..So whenever the user touches or clicks a button, depending on the item in the inventory, a deduction in quantity will occur. Upon quantity of an item being zero, we changed the graphic to the same graphic but with an X to indicate that hey...You probably can't use this item now. We as well made it that upon quantity being zero, all other logic for that specific item would not work. Considering this, we created a few getters and setters. But before I get to ahead of myself we need to graphically input quantity into the inventory.
  Jumping to the design view of our HUD blueprint I created four text box's having them overlap each button individually. Each text box I named them accordingly to its designated item such as; BoardQuantity, TapeQuantity, LockQuantity and GateQuantity. After doing so in Content > Text I hit create binding for each of them. The point of doing this is to well...Bind a function to the text. The function I want to bind is a kind of function that will practically know what the text should be and how it behaves. What great way to use getters and setters! So in other words the function i'm creating that's going to be binded to this text is a getter function.

  To make my life simple since I know we will have four getters due to four items in the inventory, i'm going to need four integer variables that hold a value for the text; CurrentQuantityB, CurrentQuantityT, CurrentQuantityL and CurrentQuantityG with each default value of five. After creating the bind for the first item; board, I had the function basically return a text of CurrentQuantityB. After doing that I continued the process of binding for the other three items.

  Once completing the binding for each item in the inventory I begun creating the setters. The point of the setters for quantity is to well...Deduct. So when the function calls do CurrentQuantity -= 1; Now after doing this I ran into the situation where yea my logic works but for some reason every now and then when I grabbed an item from the inventory it would just decrement to the negatives which was weird. So I basically hard coded it to make sure it remains zero once reaching zero. In the setter function that I created for the Board I basically said, set the CurrentQuantityB -= 1 and if CurrentQuantityB equals zero, set it to zero. Having done this resolved the issue preventing the quantity from continuously decrementing when it shouldn't be. After doing this I continued this same logic for the other items in the Inventory. Thus ending the quantity logic.

  But wait, similar to the drop item function if we were to play the game you would see nothing from quantity. Reasoning why is because we never implemented it in the Event Graph. Jumping to the Event Graph we ended up fine tuning some of the logic on the events OnClicked. For OnClicked(IS0) we previously saw, on click > DropItem and thats it. Now for each of these events there's more logic that helps polish the inventory further. Since we implement a timer in the game we begin by checking hey if isTime0 false then do this; set BoardBtnClick to true then check if CurrentQuantityB is equal to zero. If False continue the logic; Drop Item and then set BoardBtnClick to false. Now your probably wondering whats with the bool statement with time and where did BoardBtnClick come from. To answer the question if that was a thought well... BoardBtnClick is a bool variable I created. The purpose of this variable is to check when the button has and has not been clicked. If it has been set to true, then use the setter function we created. Unfortunately, I won't be going over our timer functionality because I don't want to take credit from my partners work but I will say he did a fantastic job! To get back on topic I continued this logic for the other four buttons.

  To dive in further so we can actually get the quantity running when playing the game I added on into our drop item function. Inside the function I added a few more if statements. If BoardBtnClick is true; use it's setter...If false check if GateBtnClick is true; use it's setter and continue on with the other two items. Having create this logic, when running the game the quantity works now...Which is awesome!

  All that's left to completely end the Inventory is a few things that need to be added into our game loop. In our game loop we currently have it where we can dynamically set the mouse's position as well as the actors position. On top of that we can drop the item anytime we want. So what are we missing? Well originally when I created the logic for the game loop I had it when we click the item. Keep in mind the primary development of this game is to have it set to mobile. Having said that we need to add logic in that also checks when the user touches it using a smartphone. In the logic where we check Is Input Key Down > Left mouse Button. We added an OR operator to the Boolean statement. So if Input Key Down > Left mouse Button OR Input Key Down > Touch 1. This will allow us to check for both PC and Smartphone. To continue our loop logic we needed to consider our timer. We don't want the player to grab items in the inventory while the timer is equal to zero. To prevent this from happening in the beginning of the loop we added a if statement. If isTime0 is true, destroy actor > Target Actor. If False; continue the logic.

  Now you may have notice from the image above that there's another function by the name of MouseOverVolume. The way we wanted this game to work was to allow the user to only drop inventory items at specific locations. The purpose of MouseOverVolume is to do that. In the function MouseOverVolume we check a hit result. If the mouse cursor (considering the actor follows the mouse position) hits any object type of destructible, set a new variable called Collided to true. Otherwise set it to false. Now you may be wondering why did I choose destructible? Well in the list of arrays to choose from, we had no option of only grabbing actors or specific actors. Considering we're not planning on creating a fracture meshes or anything like that, why not make our actors more specific by saying their destructible.

  So now looking at our Event graph, at every tick we call this function. Since we added this function we also need to do another check. If we have Collided, then now we are able to drop the item, if we choose to not drop it then continue calculating the mouse position and setting it to the actor position. If we were to play the game now everything is practically working as it should. We can grab the item in the inventory, drop it at a specific location as well as see that quantity on a item is being deducted. This concludes the majority of the inventory functionality. All that's left is creating logic that swaps out the graphic of the inventory item when quantity is zero. That part I will go over in a future blog!

Max Proof: Creating the functionality for the Inventory

  So good news, the design for the inventory is practically done! After having finished the design of the inventory we begun the production phase where we created the functionality for the inventory. Being familiar with Adobe Flash and creating user interface with it, I knew this would be fairly simple, seeing there were similarities between flash and widget blueprints. The only worries I had were well basically getting the item to drag and drop upon pressing a button. So taking from what we know and had to be done we begun creating logic in the event graph of the inventory. To make this fairly easy and dynamic I created a function called Drop Item with the parameters of Class Actor and a array of Image.

DropItem Function

  With these parameters I would be able to plug them into statements that would allow me to spawn an actor of type class and changed the opacity of an array texture 2D image. To begin the function we said if button is click is false, play a sound. Afterwards spawn an actor of type class and the parameter we will put in for this is our input parameter Actor. Still in the same statement we spawn this actor at a Vector MousePos. The point of MousePos is to hold the position of the mouse's X,Y coordinates. So upon clicking the button, spawn an actor at mouse position. To add onto this function we set the return value of spawn actor to Target actor and then set the opacity of the input image to fifty percent. So upon clicking the button we want to give that look that hey... We pressed a button so all other buttons are disable, visually speaking. To continue this we set button is click value to true at the end of the function. Thus ending the function of Drop Item. Now if we were to test this out in the game nothing really would happen because we never called the function. To actually make something happen in game we added four given functions into the event graph. These functions were OnPress for IS1, IS2, IS3 and IS4. What we basically said was on each button press, call the DropItem function. For each of these methods we made sure to assign two parameters in the DropItem function. In IS1 we assigned the board, IS2 we assign the Duct tape, IS3 we assigned the lock and IS4 we assign the gate actors. For each of these methods we also made sure in the array parameter to set all four images in there.

Button Click Events

  So now in the game world upon clicking on a button something would actually happen. Upon click, a mesh will spawn on the mouse position and all four images of the button would be somewhat translucent. Now if the player were to move the mouse, well the mesh wouldn't move. Why? The answer for that came from the game loop. We never stated in the game loop to dynamically set the mouse position at every tick. Before continuing on I wanted to say, me and my partner spent a while figuring out how to get the inventory to drop while dragging. The logic is pretty simple and fairly easy however it became difficult after finding out on UE4 with widget blueprints, you can't specify On Release events for buttons. Which is odd because you can specify On Release events for actors in a scene. With knowing this though, we still were able to add this functionality in the game loop using two tests. So if button is click is true and left mouse button is not down, at every tick set the MousePos to the actual mouse position on screen and then set the actor location. If left mouse button was down, don't do this but instead set button is click to true. Having this logic will allow us to basically drag and drop.

Event Tick Event

  

  Upon playing the game now if I were to hit any of the buttons what will happen is a mesh would be spawned at the location of the mouse position and at every second the mesh will follow the mouses position until I click again. Having completed this logic was very satisfying mainly because, in Max Proof it isn't just the inventory where you can drag and drop items, but items in the game world too. So you can probably assume, creating the logic for the actors in the game world was fairly easy! In all honesty, the drag and drop functionality in the game world looks way more clean than the inventory mainly because I can actually do On Release events! Now enough about that, that will be for another blog. From looking above your probably wondering why I never mention about the hover button function as well as the refresh button function. My goal is to actually go over that in the next blog as I finish up polishing the inventory in Max Proof. Stay tune!

Max Proof: Designing an Inventory

  One of the things many people are told is that you gain more experience in a specific skill whether its doing more on hand tasks at a new job or doing more in a degree that your pursuing. All I can say is it's true. To start this off while pursuing my Bachelors in Game Programming as a junior I took Midterm project. Our project at the time was a first person puzzle game made on Unreal Engine 3 where the character is trapped in some ruins. The goal of the game was to get out of the ruins through solving puzzles. One of the main mechanics I can recall for this game was an Inventory System where the user can switch between a torch or a lighter,  even have the ability to pull different books out of the inventory to read. Now out of all the things me and my group were taught in our major, creating an Inventory system was something that was never taught before. Although of that, as a programmer your known for creating problems and solutions. With all the material gather, chances are you can use that knowledge to create your own Inventory. At the time however, I guess you can say we weren't as experienced enough to just dive into creating an inventory for our midterm project. So where am I leading with this?

  Well to dive right into it, I am currently a senior now attending senior project. The project that was assigned to us was Max Proof. In Max Proof players are given an inventory of items where the user can drag and drop to baby proof an area. So here it is again, an Inventory that has to be created. To top it all off, through our entire time as a Game Programmer we were taught the ins and outs of Unreal Engine 3. Seeing that Unreal Engine 4 came out we decided as a group to dive into that instead and it was a huge transition I must say. 

  With Unreal Engine 3, creating UI would have to be done through Scaleform which in turn would have to be done through Adobe Flash where you use Scaleform to transition that SWF file onto Unreal Engine 3. Looking at Unreal En
gine 4, there isn't any Scaleform, instead there's Widget Blueprints where you can create the UI through there. Personally from seeing that I was thrilled because it saved me the time to go through of having to do one thing in a program to another. So what is the difference between me and my group from where we were a junior taking midterm project versus now?

Ruin Game

  The difference I would say is we now know how to create an Inventory. In fact, as a programmer we've learn that not only does it take a lot of hands on work to gain experience but it also takes much research as well to be able to expand your knowledge. The goal for the inventory in Max Proof is to allow the user to grab items and place them into the level. With the items it will cause a list of events. These items are, a lock, duct tape, boards, and gates. Knowing the inventory will consist of these items means we will need four graphics that are buttons (Gate graphic in progress). Upon clicking the buttons a polygon mesh will come out where the user can drag the mesh and drop it into the game world. Having this information I was able to know how to design the inventory. The great thing about Unreal Engine 4 is that Scaleform is not integrated into it. Did I say that before? 

  In Unreal Engine 4 we have something called Widget Blueprints where developers, designers, even programmers can create UI with but enough of that, lets get into the implementation.

  I would like to break this implementation down through three phases, design, production and polish.  During our design phase we created a Widget Blueprint called Hud. In this widget blueprint we started off by creating a horizontal box in the canvas and placing it below in the canvas with the length filled to where its fully expanded. This horizontal box we called "inventory". Inside Inventory we also threw in four buttons naming them IS1, IS2, IS3, IS4 which standed four Inventory Slot with an associated number to it. To continue this we made should to have some padding with each button to create a space between them all. After actually being comfortable of the buttons placement in the Inventory we threw in an image inside each button. So the hierarchy looked like Canvas >  Inventory > IS1 > image , IS2 > image, IS3 > image, IS4 > image. The purpose of placing these images in the buttons well was of course to create the look that the buttons were truly the images. Thus doing this practically completed our design of the inventory. But is that really all we had to do for designing the inventory? Not at all! We had a few more steps.

  This last steps consisted of creating a new blueprint class that derived or inherited from a HUD. After creating this new blueprint GameHud, we basically grabbed our widget blueprint and added it to GameHud through using the event graph. In the Event graph we basically said... At the start of the level create this widget blueprint called Hud and place it in the viewport. At the same time, set the current mouse to show on the screen. From doing this we allow ourselves to actually have the Inventory appear when playing the game but how does the compiler know to actually call this GameHud blueprint? This is where the game mode comes in.

  With Game mode we can actually assign things like what the player controller class is, the pawn class, the hud class or the camera class. With that knowledge we created a Game Mode blueprint and had GameHud integrated in it. Thus, the HUD is officially done with the design.

Animating Max: Creating his Walk Cycle

  One last step and Max will be finally ready to be integrated in Max Proof.  This last step is Animating Max. My goal is to create a walk cycle for him so when we throw him in the game, we can at least have a working AI. The method I used for creating his Walk cycle is actually the second time I've used this which is using the CAT Motion Editor

  The CAT Motion Editor is a great way to edit animations. To begin creating Max walking what I did was go to the motion tab and while on there click the CAT Parent object in the scene. This brings you to the animation properties. While in the properties I added a CAT Motion Layer and toggled the animation mode to play which in turn, assuming I have an animation would allow me to now officially play it. Having the CAT Motion layer added in I hit the CAT Motion Editor and open the character walk animation. With the character walk animation added into the layer I was now able to see Max walking however it wasn't pleasing. The reason being is because Max's arms were bending and twisting to much as well as the body. Considering Max is a baby, my goal was to make the walk animation as if it was really a toddler walking. Still in the editor, I begun going to different groups such as RibcageGroup >  Arms > Bend or PelvisGroup > Pelvis > Twist and messing with the parameters. While changing the parameters I made sure to have the animation playing to see how the parameters would effect Max's walk cycle.

  I did this for quite a bit, maybe an hour or two honestly only because the original walk cycle had so much twisting and bending occurring. On top of that when it came to animating Max and messing with the animation parameters in the CAT Motion Editor, I was able to truly see what part's of the body were stretching. After seeing, I would have to go back to skinning and re adjusting weights on bones. Eventually on though, I was able to get Max walking without any stretching occurring. And man must I say, I feel accomplish! After completing Max's animation I was ready to export him so that we can integrate him in our game. To do this simply, I went to File > Export after giving the export a file name in the presets, I checked on Smoothing groups, Converting Deforming Dummies to Bones, Checked Animation on and set the walk cycle to the key length of the animation. Now some may be wondering why I set converting deforming dummies to bones and well when it came to importing to Unreal Engine 4 I ran into the issue where the bones would actually fuse with the mesh to where it actually shows in game. Going back to 3ds Max and setting converting deforming dummies to bones actually allowed me to export and import perfectly with no problems. That being said hope you guys enjoy the model and animation!!

Skinning Max

  Phew, I got Max fully modeled and rigged. All there's left is skinning Max and animating him. Skinning sounds like a simple process to do because practically what your doing is adding the bones to the model and then adjusting weights on the bones to prevent any stretching occurring on the textures.

  I like to think of this process as guess and check, not literally but you get the picture. To get into detail what I mean is, adjusting the weights of the model and then checking based on that adjustment.. How the textures look on the model. Is there any stretching still because the bones were adding? To actually begin skinning, in the modifiers tab I chose Skin. With Skin being selected in the stack I hit Add right next to bones. Having hit Add I chose Max's Pelvis and hit Control C. Doing that allows to select all bones child to Pelvis. Having done that I hit select which adds all those bones to the Skin modifier or in other words.. Adds the skeleton to the model. Now if we wanted to we could go straight to animating and the actual model would move. The problem is, now that the skeleton has been added to Max there is possible stretching that may occur. The weights of each bone can affect not only the textures but the actual model itself. With the picture above you can see what I mean. Having selected one of the bones in the body brings out a capsule as well as a few color. I like to think of the color as temperature. So the cooler the color is, the less the body will be influenced by the bone and the hotter the color the more influence is occuring. As you can see above, having select the middle bone you can see its influencing part of the arm. Wait what? Why would that bone influence an arm? So what this means is if we were to move or rotate this bone, the arms would be influenced as well. I'll just say it, we don't want this. If anything there shouldn't be any influence what so ever between these two. This is where editing envelopes comes along. The capsules are the envelopes which produce different temperature representing the influence level the bone gives out. The goal I had was to have minimal influence in locations that would make sense to not have influence in.

  As you can see with the picture above, by clicking the quads envelope, the influence levels are only or mainly at the quads and minimal from top to knee. So how did I minimize the influence levels you may ask. Actually I just learn how to do this in a more simple way. Having selected an envelope I hit vertices and begun selecting all the vertices I wanted either more or less influence on. After selecting the vertices I went to weight properties. In Weight properties there's a spot called Abs Effect. In Abs Effect you can adjust the weight's influence level of a bone through numerical values. 1.0 being the hottest to 0.0 being no influence at all. So what i did for each envelope was select vertices I wanted no influence at and set the Abs Effect to 0.0.

  After doing this to all envelopes and becoming satisfied, I was able to begin animating the model. I'm not going to lie, after finishing with skinning Max I got more excited because I was dying to integrate him in the game already. Well let's jump to animating now!

Rigging Max

  In all the things I have ever done on 3ds Max, the baby model Max was the most complex! I spent way more than thirty hours on just that model. One of the things I wanted to say before I begin how I rigged Max is after finishing everything with polishing Max I actually used a modifier called Turbosmooth. Seeing how so complex Max is with polygons, Turbosmooth worked perfect for him. What Turbosmooth does is iterate the number of polygons on the model and smooth it out more. Now after getting that off my chest lets dive into how I rigged Max. The method of rigging Max is different from all the other ways I ever rigged a model. To start it off, I begun by going to the create tab in 3ds Max and choosing helpers. While in helpers I chose CAT Objects from the drop down. In CAT Objects I selected CAT Parent. With CAT Parent selected I clicked and dragged on the screen to create the basis of where the rigging will begin. Now before, I said the method of how I rigged Max was different and this is where the different process comes along. Usually I would create the rig from scratch such as the bones but for experience I wanted to get more familiar with Max and so I used a preset for the rig. The way I went about doing this was while having the CAT Parent selected in the scene, in the details panel clicked the folder called "Open Preset Rig". The rig I chose was the Base human rig which basically gives you the skeleton for a character. In all honesty for the first time going with this approach, I would actually recommend it only because it's literally creating a skeleton for you assuming the model is a character versus doing the manual way which would produce the same result. Now after loading this preset there still was so much to do such as positioning of the bones, scaling to match the model size as well as rotation.

  In the picture above, the skeleton to the right is the original base human preset skeleton. The skeleton to the left is the edited version that I did of the base human preset. As you can see there's a huge difference with positioning and sizing.

  After creating the skeleton I position it to have it exactly meet the location of the model. Once doing that I begun increasing the size of each bone to match the body through going to each bone and increment the length, width, height or depth. Once becoming satisfied with the sizing of the bones I positioned them in the desire location. For the pelvis bone, I brought it a little back more and rotated it. For the arms, I made sure to translate it to where the bone is in the middle of the mesh. After doing that I begun rotating the arm bones so that the rotation mimics the actual mesh itself. The great thing about rigging and something I just learn is there's a functionality similar to mirror and symmetry. Let's say I position rotate and scale a bone to my liking. Let's say its the arm. There's a button called, copy/mirror limb settings and with that it copies a parameters for that bone. So when I go to the other arm I can hit the paste/mirror limb settings to paste those parameters right on to mimic the other arm. Having said that I did that for the arms and legs. Completing the rigging for Max. If we wanted to we could begin animating the skeleton however upon playing the animation Max wouldn't move. The reason being is because we never skinned the bones onto Max or in other terms welded the bones on to him. The next task you can probably already guess. Skinning Max!

Polishing up the Baby Model

  Good news, the basis of the baby model is completed so I was able to jump to polishing up the model more in details. Some of the features I needed to polish on the baby was well more on the head; dealing with the size of the head, the shape of the nose and mouth as well. Then there's the hands that need polishing, back, butt and lastly the positioning of the arms which I'll get to later. When given this project, one of the things the client wanted with the baby model was the model having a big head. Having this information I was able to make the head bigger through selecting all polygons on the head and scaling them up in all axis. Once doing that I shrink the top vertices of the neck a bit to make it look better

  If you were to look at my previous blog, the last image posted showed the baby's back straight. My goal with the back was to create a more realistic back; to curve it more. Essentially that's what I did and this process was long. Creating this curve from the back well... Most 3D modelers would have an idea how I did it. The idea is pretty simple however the process took some time. Basically what I did was grab a few desired vertices and move them towards the stomach and as I descended down to the next edge, I would go in more with the vertices giving that inward look for the back. Towards the middle I begun grabbing vertices and pulling them away from the stomach to create that arc look. Now as odd as it sounds, if you were to look at the butt... It's pretty flat. It should be rounded more. 

  As you can see with the picture above, I was able to succeed that. Through some observation you can definitely pin point that I added a lot more edges to the stomach to round it out more but as well as to begin working on the butt. Modeling the butt was very similar to polishing the bottom of the back. I begun pulling vertices out and then inward. After doing so I begun rounding the butt out more that that it doesn't look flat on the sides. If you were to compare this picture above with the first picture in this blog, the noses are different. In all honesty the nose's shape was bother me a lot and after accomplishing the arc on the baby's back I was thinking... Why not do the same for the nose. So similar to the back, I arc the nose to create more realism and appeal.

  Unfortunately around this time I stopped creating different versions of saved files and continue polishing with this one, so I wouldn't be able to pull up the progress of how I did certain things with the model. Fortunately because I made this baby model, I can go into details on what I did as far as processes goes. After getting the shape of the head, the neck, the back, butt and nose..My next task was positioning the arms. 

  

  The problem with the model is that it's in T Pose. Upon texturing it where practically texturing the armpits as if it was stretched. So upon moving the arms down when rigging, the texture for the arm pit's would still be stretched. Knowing this would be an issue I changed the baby's posed from T to relax, as you can see above. Now wouldn't this be a hassle to do for both arms? YES! This is where mirroring came along. I grabbed half of the models polygons from one side and deleted it. Upon deleting it, in the modifiers tab, I selected Symmetry. Symmetry is just like mirror but the difference is, it has a auto weld function that upon collapsing the stack of modifiers... It welds the symmetrical half, to the original half. With symmetry, it makes a copy of the model and then you can choose which axis the copy is in. Where I'm going at with this is, all I had to do is re position one arm and boom! I'm down with the other side! Now re positioning one arm was bad as it is. What I had to do was select a ring of polygons that would separate the arms from the shoulders and delete it. Once deleting that ring allowed me to gain access in maneuver just the arm of the model and not the arm and the model at the same time. So when I did this, I translated the arm down a bit, rotated it as desired. Once I was satisfied with the position I had to re attach it to the model. From using 3ds Max for a while now, I'm very comfortable and confident when it comes to doing crazy things. Re attaching the arm back to the body is very possible. The way I did it was selecting border. With border I selected the opening of the arm and hit Cap which creates a face in the opening. I did the same with the shoulder. After doing this I selected both new faces and hit bridge. Hitting bridge connected both the new faces together which in turn.. Connected the arm to the body.

  Having re position the arm I had a few tasks left for the baby. This came from rounding the head out more and polishing the hands. To give an idea of how I rounded the head... I begun moving vertices inward to give less of boxed head shape and more of a sphere shape.

  After accomplishing that I begun polishing the hands more. The hands to start off were just spheres in the beginning. Considering Max the baby, would grip on objects, we needed a more realistic hand.  I was able to accomplish this through very similar methods. Pushing and pulling vertices in and placing them in desire locations. I also spent a lot of time on rounding the hands out more so that they don't look like there are any sides that look squared. Thus after doing this finished the baby model! Well at least modeling it! As you can see there was a big jump from pictures as far as progress went. My teammate had textured the baby for me. After texturing was completed meant we were one step closer for integrating the baby. The last things left are Rigging, Skinning and Animating the baby. Hope you guy's enjoy the model!

Creating a Basis 3D Baby Model

  Currently I am enrolled in my senior project course and I must say, I'm really excited. This course is divided up into two eight weeks where we will be developing a product based on a project a client has given us. The project me and my group have been given is called Max Proof which will be a game where players have to baby proof an area so that Max; the baby can walk safely. The game is in isometric view and will take place in the babies home. Before the baby begins to walk in the area, players are given thirty seconds to baby proof the area.This can come from securing doors using locks, fill in holes using boards, even moving items in the scene to different locations. As a group, we are given the task to of course deliver the complete project to our client. So as a group how have we spread the work out? Well for what I can say, I was assign to create the baby model, rig and skin it, as well as create the animations for the baby. To continue this I was also assign for helping develop the inventory with one of my team members on top of doing the collision functionality in the game. For me, senior project is a big deal so I can say this 3D baby model has been the most complex model I have ever developed and I am very excited to continue to work on it. So lets dive into it!
  Having begun a few side projects before senior project I was developing a character model for a game. When I got to senior project I had three options; create the baby from scratch, use the character model I was already working on and make it into the baby or use a model I had completely finish that was just for fun. The option I went with was of course, the character model. The model I had completed for fun was a model many might be familiar with; sack boy!

  This was a very fun model to work on and I've been dying to implement this model in a game. Unfortunately because I am not a 3D modeler but a programmer there are a few bad things about the sack boy model I created. Such as cleanliness and location of polygons. When it came to the sack boy model, it was not organize as far as polygons went. I basically went nuts as you can tell. On top of this, if you look at sack boy's legs... His legs are to far from the hips and they are already bent. With that creates a lot of issues with rigging and animating because since they are already bent, we may get a lot of illegal geometry when straightening the legs in animation. Thanks to those reasons I was able to come to conclusion to go with the other model because it was very clean.

  As you can see above, this was the character model I was working on based off a tutorial I was watching. I went with this because it was way more cleaner in polygons here. A lot of the placements as well made a lot more sense. In all honesty, before I actually get started to show how I develop the baby, I just want to say I'm really excited to show how much of a transformation I made from this model above to what the results are now. So when I begun modeling the baby model using this one I develop as a template, I started off with the hands and feet first. The way I went about creating the hands and feet was through the tool called bevel. Bevel is just like extruding but with outline in it where you basically pushing or pulling a polygon out and either scaling the face more or less. When it came to the hands I selected the face that pointed forward and used Insert which created another face in the polygon and shrink it down. Having that new polygon created I bevel it out to create the thumbs. Thus ending the basis of the feet and hand.
  The next step was proceeding on the stomach...Giving the baby a belly! This honestly was the most fun part because it was pretty hilarious to work on. I mean when I first was doing this I was like wait...This guy looks pregnant, he can't look pregnant!

  Eventually though I was able to get it right. The way I went about doing the baby's belly was very simple. I selected one edge going vertical, hit Ring which selects a ring of edges that's horizontal to the one I originally selected and then hit Connect. Doing this creates a new ring of edges going horizontal that connects to the ring of edges going vertical. Having three new rings of edges, I basically started selecting vertices and bringing them out, creating that round shape belly. After doing that I selected all polygons on both legs  and scaled them down on the Z axis and stretched the legs out a bit on both the X and Y axis to created that look as if the legs are fat. I also did this for the arms as well. So with this being said, I practically had most of the basis down! Just needed a head next!

  If I were to give any detail on how I did the head, the most descriptive way I would say I accomplish this came from how I did the hands. Basically beveling things out, scaling polygons down. As you can see with the picture above, I bevel quite a bit to create the head. Before I went crazy though, I made sure to extrude first to create the neck. The next step was creating the eyes and and nose for the baby. Just like anything else, I messed around with either Insert or Outline and then extrude it. Well for the most part of the nose. One of the things I did do with the nose though was also translate some of the polygons as well as shrink them more as desired. On top of that as I got towards the nostrils, I beveled inwards to create that hole; making sure that the polygons that was going in was not overlapping any existing polygons.

  When it came to the eyes I actually did not have to do anything with Outline, Insert or Bevel. If anything I would think of it as just planning it out. My goal for the eyes were to get it at least an oval shape which I achieved through moving vertices to desire locations. You may be wondering now, how come in the picture above the other eye looks weird. The reason why I left the other eye alone was because I knew I was going to end up deleting half of the model in the future so that I can mirror it and eventually weld the two together. It sounds confusing but when I go over it later on, you'll see what I mean. The last step for creating the basis of the baby was the mouth and man I must say this was the most difficult thing to work on. It wasn't fun at all only because it gave a weird look as if his cheeks were going in. Just like how I did with everything else, I used the friendly bevel tool. With the mouth I beveled inward and eventually begun extruding by small iterations inwards. After having what I needed to work with as far as polygons I begun shaping the mouth more by moving the vertices to desire locations. Just like with the eyes, I tried going an oval shape. The difference between doing this and the eyes were well... I needed lips and I needed a hole for the mouth. After having the final part extruded out I also beveled inwards to create that hole for the mouth but as well give me more opportunity to shape the lips more. Thus finishing the basis of the entire. Model. Now keep in mind, I said basis! All of this is just a foundation of what I'm really going to work on. Still very excited to show off the baby!

Unreal Engine 4: Lift Demo v1

  After having to get Leap Motion integrated in Unreal Engine 4 I immediately jumped into learning a few new things through going to the Leap Motion website where there was an example implementation of Leap in Unreal Engine 4. Having spend some time looking at the different projects offered I felt I become somewhat familiarized with what I wanted to do. One of the things I like to do now is whenever I begin a new project, create a requirement list. To me creating a requirement list is very helpful because you can use the list as a way to debug your project further or to see if everything is matching what your requirements are for the project. For this project, I created a small requirements list.

Lift Demo
Requirement ID	Description	Status
1.1	The system shall recognize when a hand is added	Complete
1.1.1	If the system recognizes if a hand is added, the system shall set the hand mesh to visible	Complete
1.1.2	The system shall recognize when the hand is removed and set the hand mesh to not visible	Complete
2.1	The system shall be able to determine when a hand has collided with a handler	Complete
2.1.2	If a hand collides with the right handler, the system shall move the ball right with some torque	Complete
2.1.3	If a hand collides with the Left handler, the system shall move the ball left with some torque	Complete
2.1.4	If a hand collides with the back handler, the system shall move the ball backwards with some torque	Complete
2.1.5	If a hand collides with the forward handler, the system shall move the ball forward with some torque	Complete
2.1.6	If a hand collides with the top handler, the system shall have the ball jump based on an impulse	Complete
3.1	The system shall be able to change the balls material if both hands collide with one another	Incomplete
3.1.2	If two hands collide with each other, the system shall be able to change the balls collision status	Incomplete
4.1	The system shall be able to grab different objects in a scene using two hands	Incomplete

  As you can see above, I still have quite a few major aspects to still implement in the demo but other than that, I was able to get one portion working fine! So to begin the process I started off with a new project using the rolling ball template in Blueprint. Looking at some of the functionality I changed some methods, added a few functions as well as integrated the Leap Motion Controller onto the pawn blueprint. But that's not really saying much or diving in is it?

To dive into it, in the pawn blueprint of the ball I added the component Leap Motion Controller

   When I first did this, I ran into a problem. Upon starting the game, the hands would appear assuming you had your Leap Motion Controller set up. But considering the pawn is a ball that roll's, the hands would roll too. In order to prevent this from occurring I actually just attached the controller as a child of Spring Arm. Thus, the hands would not rotate. So the hands were integrated in the pawn's blueprint, but what is it doing? Nothing really. My goal was to have the hands control the movement of the ball. The way I went about doing this was creating Handlers. Each handler would determine which way the ball would maneuver when a hand collided with it. Thanks to UE4 this was simple in the Pawn's blueprint. I created five box collisions. The names I gave to these handlers were RightHandler, LeftHandler, TopHandler, Forward, Backward. All child's of Spring Arm so there relative rotation are not relative to the ball.

  After creating these new components, I placed them in the desire location close to the Leap Motion Controller. Now begins the logic! To begin with the logic I created three functions called MoveRightLeft, MoveForwardBackward, and Jump. These functions say what they need to do. Move the ball right, left, forward, backward or jump. Clicking the + sign at the top right of functions I created my MoveRightLeft function. In it was really only three statements. Setting a boolean called HandCollides to true and if HandCollides is true add a torque to the target ball. In the torque pin, I broke out the vector where I multiplied a float called RollTorque of 50000000.0 value to the parameter XAxis and plugged the value of that to the X coordinate of the vector. To end the function, I created an Input parameter called XAxis of float type.

 
  Thus ending the MoveRightLeft function. The MoveForwardBackward function was very similar. The only difference was, I use the resultant value and plugged it in the Y coordinate and changed the input paramter name to Y Axis.

  Lastly, I just needed one more function left. The Jump function. This one was already given, I just made it into a function for organization.

  Having the functions finished, I jumped back to the Event graph to get the implementation running in the game loop. Actually implementing was fairly easy, all I had to do was on each begin overlap of a handler, call the desire function relative to the name. On end overlap set HandCollides to false which disables the ball from continuing moving.

  Thus completing most part of the Demo. All I needed left was the material changing dynamically on the mesh as well as the ability to grab objects with the Leap Motion Controller. As far as it came down to dynamically changing the mesh, I was very familiar how to do it upon a key press... But not sure how to go about doing it if both hands collided with one another. To actually get the balls material to change dynamically and with it's collision I created an input event called I. My logic behind this was if the ball was not invisible, set the material to visible and set the collision response to ignore all on all objects that are dynamic. If the ball is invisible, change the material back to the original and set the collision response to block world dynamic.

  After doing this I decided to just jump into the level to see how the integration worked out and man it's so cool! My goal before actually calling this demo completed is to not only complete my requirements list, but to create the balls movement more smoother through creating a Gyro Ball. Based on the hands location in the gyro ball I want the ball's location to increase whether the hand is moving forward in the ball, forward left ect. Personally I feel this route is much cleaner. My other goal is to actually spend some time designing the level. The current level was just something I threw in to see how the functionality of the pawn works. Can't wait to release version 2 of it!!