Sunday, December 21, 2014

Unreal Engine 4 Tutorial: Smooth Zoom using Mouse Wheel for Top Down Template

Well, I had already written a tutorial for implementing Smooth Zoom functionality for Top Down Template. But it was based on keyboard inputs. Since most Top Down PC games use mouse wheel for zoom, I decided to make a tutorial for the same. The core logic here is the same as the one implemented by Ryan Jon for the custom camera in his RTS Community Project. If anyone's interested, they can get the code for the RTS Community Project here:

UE4 RTS Community Project

Anyways, he has replaced the default camera for the characters with a general camera since that's more ideal for developing an RTS game. Since a basic Top Down game with a single playable character does not need a separate custom camera, I decided to implement the same functionality for the default player camera in UE4's Top Down Template. So let's get down to it.

First of all we need to make a custom curve from the content browser. We will be using this curve to define the smooth camera movement while zooming in or out.
We want the zooming to start slowly, then pick up the pace and then gradually slow down towards the end. As a result, the curve is also defined in the same way. I've used the following values for defining the curve: (0.0, 0.0), (200.0, 0.8) and (1000, 5.0). Then I adjusted the blue hinges at the key values to get the desired angle. Here's the final result:

Following that, we move on to the 'MyCharacter' blueprint since our default camera is attached to the player character. First we define two custom events, 'ZoomIn' & 'ZoomOut' as you see here:

We'll be calling these functions when the player uses the mouse wheel scrolling. We then create a tick event and two variables. One float variable 'CamBoomLength' to store the updated the arm length for the camera, and a float curve variable 'ZoomCurve' to store the curve we defined earlier. The default value for 'CamBoomLength' is set to 800.0, which is the default value of target arm length. This ensures that the camera doesn't move around at level start to some random value on it's own. We then use an 'FInterp' node to interpolate from the default target arm length of the Spring Arm to the updated value that we will be storing in 'CamBoomLength'. We connect the delta seconds from the event tick to the interp node and set a value for the interp speed as well. Then we update the return value into the spring arm's target arm length. With that, we have added the functionality ready for updating the zoom amount.

Next, we move on to adding functionality for the custom zoom events that we created in the beginning. So this is where we'll be using the zoom curve. We extract the float value from the zoom curve using the target arm length as the input. We then multiply this float value by 100.0, as we're dealing with arm lengths in the range of 100s. We then clamp these values between the minimum and maximum float values for our zoom. Then based on whether 'ZoomIn' or 'ZoomOut' event is called, we subtract or add this value to the target arm length and store it in our custom float variable 'CamBoomLength'. Now we have implemented the logic for getting values for our our new target arm lengths. All that's remaining is to call these events based on player input. We're going to handle that in our player controller blueprint.

So let's go to our 'MyController' blueprint and add mouse input events for mouse wheel up and mouse wheel down. We then call our character class to access our custom zoom events. Now connect the mouse inputs to these events and we have a working smooth zoom system for the Top Down Template. Here's a screenshot of the player controller blueprint:

You can also see the zoom system in action in my project:

Alright, that's it for this tutorial. I'll be back next week with another dev update. Until then, feel free to check out my Youtube channel for my new dev videos:

Stormrage256' Youtube Channel

Friday, December 19, 2014

Unreal Engine 4 Dev Update #7: RTS Camera System for Top Down Turn-Based Games

In my previous dev updates, I had talked about how I implemented a grid based movement system in the Top Down template. Now that we got that out of the way, I decided to tackle the issue with the default camera system in the Top Down template. Since I needed the camera to smoothly move to focus on the active character, it was kind of troublesome to use the default cameras as they were each attached to their corresponding characters. So I got rid of them. And now I have a new RTS style camera in place of it. Now this allows me to smoothly move the focus between the cameras depending on the game state. I'll just give a brief overview of the features that I've implemented.

First of all, I created a separate blueprint for the new camera. At the most basic level, it needs to move freely anywhere along the map. So I mapped the WASD keys to move the camera along the forward/backward and lateral directions. I'll probably add mouse based movement as well in the near future. All the features that I had implemented in my previous camera were directly added to this well. This included both keyboard based smooth zooming capabilities as well as keyboard based camera rotation. I had included tutorials for the same in a few of my earlier posts. You can find them here:

Anyways, this time around I decided to add mouse based zoom and rotation as well. As suggested by one of the members in the Unreal Engine community, I have used an interp node to add a mouse wheel based smooth zoom functionality. Alongside, I've mapped the middle mouse button drag to camera rotation. So with the exception of mouse based movement, I now have a camera that can move around the map freely. Here's a video demonstrating it:
As mentioned earlier, one of the problems that I faced with the earlier camera system was the difficulty with having the camera move smoothly towards the active character. So obviously, that was the next thing to tackle before moving on. The functionality for moving towards the newly selected actor was already implemented, but moving forward in that direction didn't serve my purpose well. I also had to take in to account, the fact that the camera needs to focus on the A.I. character as well, when I click on the end turn. So I rewrote the functionality to automatically move the camera between the characters. Again I use the interp node and player/A.I. movement status tests, to have the camera smoothly flow in to focus on the player. You can see it in action in the following video:
[Note: My PC is not very powerful. The stuttering issues during certain animations are a result of using the screen recording software alongside the editor and not the animation itself]
In this video, I've only shown the camera switching towards the active player character and not the A.I. since I was doing some work on the 'End Turn' feature. Now that I've implemented a basic end turn functionality, I'm happy to say that the camera movement smoothly switches it's focus on to the A.I., when it makes an action. So that's it for now. If you're interested in seeing more of my work, feel free to check out my Youtube channel:
Stormrage256' Youtube Channel
In a day or two, I'll be uploading a new video with weapons and firing animations for the characters. Here are a few WIP screenshots until then:

Monday, December 15, 2014

Unreal Engine 4 Dev Update #6: Character switching, Holographic Localized grids & Auto-Activation of UI

After I got my basic Command UI & grid based movement system working, I started implementing some changes to the UI as well as the functionality for allowing the player to switch between the playable characters of his party. Lately I've been doing some extra work on Level Design for a game as well as some personal side projects. So I kinda got caught up with all that & wasn't able to post any update over the last weekend. Now that we're back on track, let's move on to the new updates:

Switching between playable characters

Until recently, I had been mainly working on a single playable character, making sure that it's movement was restricted to a grid system. So I decided to implement that across multiple playable characters. For now, I've implemented a keyboard based switching between the party members. Later I'll add a mouse input based selection as well. I got it working by having player inputs mapped to allow possession of the different characters. I've also added a cool little character selection material to display around the active character. It's added to a character whenever we possess it, and gets removed every time we unpossess a character. Here's a video of it in action:

Holographic Grid system
Well this one is more of a visual update. As mentioned earlier, I've got a grid system to facilitate the movement of the player and A.I. I'm actually dynamically spawning static meshes to display localized grid meshes. But it actually looked kinda ugly as every time I clicked somewhere, it just spawned a set of floor meshes. So taking inspiration from the awesome X-Com: Enemy Unknown, I decided to make some cool holographic styled grids. It's using the same meshes as before, I just switched the material to display a glow around it's corners. It looks a lot cooler now. Kinda gives the feel that you're actually the commander watching his troops deploy on the battlefield. You can check it out in this video:
If you want to create a similar holographic material, you can check out the video tutorial below by the Youtube user Liaret. He's made an awesome Tron glow material, that can be applied to meshes & BSPs.
Tron Glow tutorial - Unreal 4
Auto-activation of Command UI & Holographic Grids
After the above two updates, the next obvious thing to do was to combine them. I extended the possess character function to toggle the Command UI as well as the grids in the vicinity of the newly possessed character. So now they're activated automatically, every time the player switches between the playable characters. I'll leave you with a video of it here:
With that, we come to the end of this update. In the next update, we make some changes to the camera system and start with a basic Turn-Based gameplay system. Meanwhile, feel free to check out my Youtube channel, if you're interested in seeing some of my recent work on UE4:
Stormrage256' Youtube Channel

Sunday, December 7, 2014

Unreal Engine 4 Dev Update #5: HUD based Command UI, Grid based movement system & Dynamically Spawning Grids

Welcome back to the blog, it's time for another update. Starting with this post, I'll be posting only the details regarding the new development in the dev updates. I'll post tutorials for some of them as separate posts. I'm doing this since I don't have time to write the tutorials for each and every one of my updates. So I'll be making tutorials only for those topics which aren't available elsewhere. With that out of the way, let's get to this week's dev update. I'm already behind schedule by a few posts.

In my last update, I had written about how to implement keyboard input based camera rotation for Top Down games. You can find it here:

Unreal Engine 4 Dev Update #4: Camera Rotation for Top Down Games

Moving on to the updates, these are the main changes that I have made:
HUD based Command UI
Following my last update, I worked on implementing a basic HUD based Command UI. Since I hadn't worked on HUD Blueprints before, I looked into the HUD based Blueprint examples available in the UE4 Marketplace. After tinkering around with Blueprints, I came up with a basic Command UI. Since I'm trying to work towards a Turn-Based shooter, I added two buttons that serve the basic purposes - Movement and Firing. The 'Move' button basically ask the player character to move to the location under mouse click, while the 'Fire' button fires a projectile in the direction of the mouse click. It's pretty basic stuff, you can see it in action in this video:
Grid based movement system
Next up, I implemented a Grid based movement system. Initially my plan was to manually add box meshes around the level and then concentrate on the player movement separately. But since it was too much redundant work, I decided to spawn the meshes dynamically at level start. Well, not strictly dynamic since I hard coded the boundary of the playable area. Using the boundary data, I created an array by dividing the total game space grid by 100. For each of these 100x100 grids in game space, an element was added to the array. In order to store both X and Y coordinate data in the array, I used two 'For loops' while making the calculations. The vector data thus obtained was added to the array at level start, thus giving me a list of locations that the player can move to. As a temporary measure, simple box meshes are spawned along the grid at level start to depict the grid system. The data from the grid array is used every time the player character is issued a move command. Based on the click location and the array data, I was thus able to restrict the player movement to the grids. Here is a short video demonstrating the system:

Dynamically Spawning Localized Grids
After the UE4 update from v4.4 to v4.5, my level got a massive frame rate hit. With nearly 1600 grid meshes at level start, my system couldn't even run it at 10 fps. Hitting up the forums and UE4 Answer Hub didn't get me a satisfactory solution. As a result, I decided to move on to localized grids instead of an all-encompassing grid system. Instead of spawning the grids at level start, I switched to dynamically spawning localized grids based on player's mouse input. This helped reduce the number of grid meshes from 1600 meshes to just 9 meshes, and thus helped bring the frame rate back to speed. It also helped in keeping the game space clean. Now every time the player clicks on the floor, grids are spawned in the region corresponding to and surrounding the mouse click location. I'll leave you with a video for the same in action: 

Alright that's it for this update. If you're interested in seeing more of my work, feel free to check out my Youtube channel, as I generally upload my work over there before the weekly blog update.

Thursday, November 27, 2014

Unreal Engine 4 Tutorial: 180 Degrees Camera Rotation in Top Down Template

In my previous update, I had explained how to implement a 360 degrees camera rotation system in the Top Down Template using the Blueprints. If you're interested, you can check it out here:

Unreal Engine 4 Dev Update #4: Camera Rotation for Top Down Games

Yesterday as part of an experiment, I decided to try a 180 degrees restricted camera rotation system for the same using Blueprints. Well, it turns out that implementing a 360 degrees rotation system is far easier than a 180 degrees system. The additional complexity for doing this with the Timeline nodes comes from the fact that we can't do a loop in this case. As a result the starting position in the Timeline track will be a -90 degrees, while the rotation angle of the camera at level start should be 0 degree. So that makes it necessary to add a few more nodes to make sure that Timeline track starts for the first time at a rotation angle value of zero degree. I'm not sure if this is the most efficient way to do it in Unreal Engine 4. There might even be a better way to do in Matinee or with actual coding. But my method gets the job done in Blueprints, and so far I haven't come across any other methods. If I do, I'll update it in this blog. First I'll post a screenshot of the Blueprint below, as it'll make it a lot easier to understand.

As you can see, I'm using the keys 'Q' and 'E' as the input for rotation till +90 degrees and -90 degrees respectively. I use a Timeline node to make the rotation happen smoothly over time, rather than an abrupt change in the camera angle. First of all, I have created a float variable 'Time1' with an initial value of '-1.0'. I use this to see if I need to start the Timeline at t=0 or at any other specified time. This comes into play only during the first time camera rotation is used. This is because my Timeline starts at t=0 with a value of -90 degrees. At t=1, it reaches 0 degree and proceeds to 90 degrees at t=2. When the level starts, we're actually seeing the equivalent of t=1, i.e. at an angle of zero degree. But when we call the Timeline node for camera rotation, it always starts at t=0, which abruptly throws our camera rotation to -90 degrees, unless we tell it to start at t=1. So basically what I do is that, everytime the necessary input button is pressed, I check if 'Time1'=-1.0, which happens to be it's default value. Once the user has rotated the camera atleast once, I assign a value of 1.0. to 'Time1'. So basically checking if 'Time1'=-1.0 helps to see if this is the first time that the player has used camera rotation. If it is, we hardcode a value of 1.0 into 'Time1'. Then we call a sequence node to first set a new time for the Timeline with the new value of 'Time1'. Then we play the Timeline. If 'Time1' was not equal to -1.0 in the first place, we directly let it play the Timeline using the 'Play' or 'Reverse' input pins based on the player input. The Timeline then gets executed with a length of 2.00 from 0.0 to 2.0. It's a linear graph. Here's a screenshot of it:

We update the Yaw of the SpringArm Component with the key value of the Timeline throughout the 2 seconds. This continuous updating of the Yaw is what helps us to achieve the smooth rotation. Since I've done this in the Character Blueprint, I can directly access the SpringArm component to set it's new rotation. So basically that's how you get a 180 degrees restricted camera rotation using Blueprints in the Top Down template. You can see it in action in the following video:

If you're interested in seeing more of my work in Unreal Engine 4, feel free to check out my Youtube channel as I usually upload the videos there before posting updates here:

So that's it for now. At the moment, I've started working on a Turn-Based gameplay system. Will be putting updates about it soon. Until then, goodbye.

Thursday, November 20, 2014

Unreal Engine 4 Dev Update #4: Camera Rotation for Top Down Games

Hi everyone, welcome back for my next dev update, I had explained the process of implementing a Smooth Zoom functionality for the Top Down Template in Unreal Engine 4 Marketplace. If you want to check it out, you can find it here:

This time around, I'm going to explain how I implemented Camera Rotation for a Top Down Game in UE4. I've been meaning to make this one for quite some time, since I had received a few requests from my Youtube Video for the same. Since my motherboard and RAM got fried a few weeks ago, I was unable to do any work in UE4 for the past 3-4 weeks. I've ditched my old PC in the process and assembled a new one. So instead of waiting till the weekend to write all the remaining dev updates, I thought I'll get this one done with today itself.
Alright, Camera Rotation is a fairly simple process. Basically I just use a Timeline node that keeps looping after a key value of 360 degrees. This helps in giving a Smooth Rotation, rather than incremental values of say 90 degrees or so. I connect the input button press for clockwise and anticlockwise rotations with the 'Play' and 'Reverse' input pins of the Timeline node. This way, I just need a single Timeline node to go through the process. I then make a rotator using the Output track of the Timeline for Yaw and the default Pitch & Roll values of the Spring Arm component. Then I set this new rotation to the Spring Arm Component. Since I've currently implemented this in the Player Character class, I can directly call the Spring Arm component. But I might have to shift this to the Player Controller class soon. Here's a screenshot of the whole process in my UE4 Blueprint:

And below you can see the Timeline in action. I've made a track and set a range of 5 seconds, which is then set to loop. Key values are 0 at t=0 and 360 at t=5.

With that, we have a solid Camera Rotation functionality for our Top Down Game. You can see this in action here:

If you're interested in seeing more of my work in Unreal Engine 4, you can check out my Youtube channel as I usually update the videos there before posting updates here:

So that's it for this update. I'll probably do the next update on 'Implementing a HUD-Based Command System' for Top Down Games.

Wednesday, November 19, 2014

Unreal Engine 4 Dev Update #3: Smooth Zoom Functionality for Top Down Template

In my first UE4 dev update, I had written about adding a basic Zoom functionality for the Top Down template in UE4 using Blueprints. But as I had mentioned back then, I had implemented a step-by-step zoom system. You could only zoom in discrete steps depending on how many times the input button was clicked. Well that might be useful in certain cases, but I wanted to add a Smooth Zoom functionality to my game. So I went about making some changes to the earlier Blueprint. Most of the stuff remains the same, so changing to this newer version will hardly take a couple of minutes. As a result, I won't be writing much about the stuff that I had already explained in the first post. For reference, you can find it here:

Unreal Engine 4 Dev Update #1: Zoom Functionality for Top Down Template

Moving on, let's get to the topic at hand.

So basically, in my earlier post, I had made changes of 100 units to the 'Target Arm Length' of the player character's 'Spring Arm' component. In order to implement Smooth Zoom, I added a Timeline node. They allow you to make simple time-based animations. For learning more about Timelines, you can check out the official documentation here:

Unreal Engine 4 Documentation : Timelines

Alternatively, you can check out this Youtube tutorial:

Unreal Engine 4 Blueprint QuickShot - 7 - Changing Things Over Time

After adding a Timeline node, this is what my Blueprint looks like:

As you can see, instead of making discrete changes of 100 units each, I'm changing it continuously by units of 10, relative to the graph in the Timeline Node. Since I wanted the zoom to start out slow and then speed up, I've made a linear graph with respect to time. Here's a screenshot of the Timeline Node itself:

I have two key values in there: 0 at time t=0 and 10 at time t=10. I'm using the same values for both the Zoom In as well as Zoom Out Timeline. For now, I've kept the range to 10 seconds, but it hardly ever reaches that point, since I have a clamp in my Blueprint to restrict the maximum and minimum zoom. So I'll probably reduce the range to 5 seconds soon. Also I made sure that the Timeline execution always start from the beginning of the graph at each button press, by connecting to the 'PlayfromStart' input pin.

And that's it. We have implemented a simple Smooth Zoom functionality. You can see this in action in the following video:

If you're interested in seeing more of my work in Unreal Engine 4, you can check out my Youtube channel as I usually update the videos there before posting updates here:
And that's all for now. Next update on implementing Camera Rotation for the Top Down template, coming soon. Signing out. 

Wednesday, October 15, 2014

Unreal Engine 4 Dev Update #2: Basic Projectile System for Top Down Template

Alright, time for another update. In my previous post, I briefly discussed the system that went into adding a basic Zoom functionality to the Top Down Template in Unreal Engine 4. You can find it here: Unreal Engine 4 Dev Update #1: Zoom Functionality for Top Down Template. Moving onto the matter at hand, I've also added a Blueprint-based basic Projectile system to the template. Again a fairly simple task for beginners. 

First of all, I made a new projectile Blueprint from the 'New Blueprint' menu. Then I added a static mesh component inside it. I added collision for the mesh from the static mesh menu, but that's not necessary. So basically we have the projectile ready by now.

After that, I created a 'Fire Projectile' function inside my player character blueprint. I call this function when player presses the button for firing projectiles. Here's a screenshot of the function.

This function spawns the projectile in front of the player. Since the projectile already has a velocity assigned in the projectile Blueprint, it'll move in the assigned direction right after spawning. First I get the actor location to determine the spawn point. But if I just spawn it using the actor location, it spawns in the player's location itself. Since we usually want to spawn the projectile a bit ahead of the player, I get the actor's rotation first and then get a forward vector from it. Since it was a very small value, I multiplied it by 30 to get a value that's relative to the player character's size. I then add it to the player location and we have a spawn point location ahead of the player. Meanwhile I pass this location and actor rotation value to a Transform node so that I can send it as input into the Spawn Actor node. For the actor class, I chose the projectile Blueprint that I had created earlier. And with that we have created a function for firing a projectile. Once that's done, it's just a matter of calling this function on receiving the fire input from the player. 

And there you have it: A basic Projectile System in UE4. You can see this in action in the following video:

If you're interested in seeing more of my work in Unreal Engine 4, you can check out my Youtube channel as I usually upload the videos there before posting updates here:

Alright that's it for now. Next update on implementing Smooth Zoom functionality coming soon. :)

Tuesday, October 14, 2014

Unreal Engine 4 Dev Update #1: Zoom Functionality for Top Down Template

I've been meaning to put this post for quite some time. As mentioned in my previous post At the Crossroads, I've started working on Unreal Engine 4. On the side, I've also uploaded some videos of the stuff that I've been doing with the engine. Over here, in the blog, I plan to briefly describe the process for the same. So here goes the first update.

I started working on the default Top Down Blueprint template that came with the Unreal Engine. It basically contains a Top Down game template with the default blue player character and a camera adjusted so as to give it an isometric view. There's a basic level built using some BSP brushes and you can move the player around. That's all the functionality that comes with it by default. So first thing, I decided to add a basic Zoom functionality. Since I was more interested in Blueprints, I went through a few tutorials on it and then dived right into action. After tinkering around the engine for a while, I got a basic zoom system running. It zoomed in and out only in increments of 100 units at a time, yet it was a start. Below, you can see a screenshot of the Blueprint scripting that went into it.

It's pretty simple if you look at it. It's just a matter of understanding what functions and commands are available at your disposal, atleast for matters like these. It's completely done within the My Controller Blueprint that already exists by default. The Controllers are used to control the pawns (or characters) in Unreal Engine. I've assigned two input buttons for Zoom in and Zoom out in the Project settings. Basically what happens is that, as soon as either of those buttons are clicked, I call my player character blueprint, which contains the camera and settings for changing it's location/ orientation relative to the player. I then access the camera object and add or subtract 100 to it's target arm length property, which controls it's distance to the player. I also add a clamp at the end to restrict the maximum and minimum zoom settings. Finally, I set the new value to the target arm length of camera.

So there you have it. A Blueprint based basic Zoom functionality for the Top Down template in Unreal Engine 4. You can see a video of it in action in my Youtube Channel as well:

So that's it for the first update. Will put the rest of the updates soon. Until then, goodbye.

Thursday, July 17, 2014

Random Sketches

Just a collection of my recent sketches. They were all sketched with pencil/pen and later edited digitally to add highlights/motion blur etc.

Raptor Strike Suit from Strike Suit Infinity

Kid Gohan from DBZ

Goku from DBZ

Wednesday, July 2, 2014

How to export models from Blender to Skyrim

About a few days back, I decided to try out Skyrim's Creation Kit during my free time. I had bought Skyrim during last year's Steam Winter Sales. Back then, I played it for a while, but never got to finish the game. I think I hit up the Creation Kit a couple of times, but didn't go ahead since I knew nothing about it. And it looked vastly different from UDK. So this time, I checked out a few tutorials in youtube before diving into Creation Kit. For starters, I checked out the tutorial series by BestinSlot. It covered the basics required for making your own mod with custom quests, dungeons, etc. And he does a good job of explaining how to start working with the Creation Kit. You can find the playlist over here: 

I did not go through all of those tutorials. Just the areas that I wanted to focus on for now. And then I started looking for tutorials on how to export my Blender models into Skyrim. Surprisingly, in spite of having such a huge modding community, I was disappointed to notice that there weren't any useful tutorials in youtube for what I was searching for. Sure there were a handful of them, detailing bits and pieces of the process. I had seen this issue when I first worked with UDK. Doing something based on a video, only to realize that there was some other video explaining some other part of the workflow. I didn't wanna go through the same shit again. And the import/export thing was starting to look like a more difficult process this time around with the Creation Kit. I got a few links from some of my friends, but all those tutorials covered only certain parts of the process. So I started checking out other websites for tutorials on how to use Blender models in Skyrim. I soon came to realize that, it was a more time consuming process compared to the Blender UDK workflow. And yet again, I failed to find all the necessary details in one single place. So I decided to make one myself. I'm not going to explain all the steps in detail over here. This is just a collection of useful resources that people can use to get their models in Skyrim. However, I will give a small description about the links that I have posted over here.

First of all I'll provide the links to all the softwares that you need to download. For some of them, details about how and where to install them are given below. I'm using Windows 7 64-bit version, but you can find 32-bit versions of the softwares in the same links. So depending on your version, feel free to download the appropriate installer of these softwares.

1) Blender v2.49b 32-bit >> [Note: If you're a Blender 2.6,2.7 user, no need to fret. There is a workaround listed below. Just download the 32 bit version of 2.49b first]
7) 7-zip Archiver >>
8) GIMP (or Photoshop) >>
10) DDS file support plug-in for GIMP >>

For BSAopt and DDS plug-in for GIMP, I've given links below on how to install them. As for the rest of the softwares, just install all of them. They're pretty straight forward.

For importing your Blender models into Skyrim, first you need an existing Skyrim mesh to act as the template for copying it's settings to your mesh. This is where BSAopt comes in. It can be used to unpack the .bsa game files into nif files that we can use for our modding purposes. Instructions can be found here:

Creation Kit recognizes only the .dds file format for it's textures. So your .png file is not going to cut it. If you're using GIMP, you can download the plug-in from the 10th link given above. For setting up the plug-in for GIMP, you can check out this video: 

Once that's done you need to convert the textures for your model into .dds format. Youtube user Vornez has covered that part in this tutorial: (6:00 to 9:00)

Also, if you're like me, and would like to use Blender 2.6/2.7 versions, this link is for you:
However, note that you do need a 2.49 version at least for exporting the models in nif format. For the rest of the modeling process, you can use your own version. I run a 64-bit 2.7 version for my modeling purposes and 2.49b only for exporting it.

After all the installations are done, first create a model in Blender. And then you can hit up this link:
[Note: He uses two softwares called Nifconvert and ChunkMerge. There's no need to download them. It's already part of your NifUtilsSuite that you installed earlier]
He explains it really well. It consists of the workflow from Blender to NIfskope only. You can see the rest in the next link.

Once you set up your model in Nifskope properly, you can easily import your model into Skyrim. First save your nif file. Details on how to use it in the Creation Kit can be found here: [Note: Go directly to part 6: Exporting mesh to Creation Kit]

Other links which might be useful:
3) If you're having trouble with your textures not getting displayed in NifSkope, in spite of having it in the Skyrim textures folder in .dds format, post#7 in this link might be worth checking out:

So there it is. All the resources that helped me get my first model into Skyrim. I hope this would be helpful to others who are new to Creation Kit. And here's a picture of my Skyrim character standing proudly next to my first in-game model. :D

A miniature version of my tower mesh from Helm's Deep

Friday, April 11, 2014

Experiments with Textures - Part II

Well this is a continuation of my last post. By the end of my last post, I had managed to bake a normal map, a height map and an A.O. map. I intend to use that normal map in UDK's material editor. As for the A.O. map, UDK already has it's own ambient occlusion scene going on. So I decided to take my A.O. map and merge it with my original diffuse map in GIMP. Currently I'm using DirectX 9 to render the game, and so that means I do not have access to the Tessellation features in DirectX 11 version. I'm doing this for two reasons. One is that seams in UV mesh tend to tear up the mesh when Tessellation is enabled. The second is the performance drop it would cause for the small increase in the detail of my meshes. A height map will also have to be added thus increasing the memory footprint. I might enable Tessellation later on for Landscape objects and objects like rocks which actually benefit a lot from displacement maps and Tessellation. In that case I could probably hide the area where UV seams occur so that mesh tearing isn't evident to the player. Anyways for my current situation, I decided to merge my height map with my diffuse texture as well. All this can be done pretty easily using GIMP. Below I've shown a detailed description with screenshots of how to set this up in GIMP. So this post is basically like a tutorial for people who are starting out with GIMP and game development. First open up the diffuse texture in GIMP. You'll get a screen like what's shown below. Nothing fancy, just the image that you've opened. 

Now similarly open up the Height map as well as the A.O. map in GIMP as well. So basically there'll be three windows: one for diffuse, one for height map and one for A.O. map. What we need to do is to have all this in the same scene. But directly copying it into another will just put the second image on top of the first. So first go to the diffuse map window, in the menu bar, go to Windows menu and click on new ToolBox. So now you can see a basic Toolbox with all the different types of tools you can use in GIMP. Press M to select the Move tool.

Now we need to add layers. Layers enable different textures to be merged together based on a set of factors like opacity and blend types. This way you can add more textures on top of the diffuse without losing it's detail. For that, a layers toolbar has to be added. This can be done by again going to the Windows menu >> Dockable Dialogues >> Layers. Simple Ctrl + L would suffice, but if you're a beginner like me, it helps to know where to find all the toolbars.

The layers toolbar can be added to the main toolbox in order to keep it clean while working with multiple windows. Just click on the layers tab in the toolbox like you would for a tab in google chrome, then move it into the the main toolbox. 

Once that's done, we need to add a new layer so that the other images can be added on top of the diffuse. Currently there'll be one default layer in the toolbox, which you can rename by right clicking on layer and clicking on 'Edit Layer Attributes'. Now onto adding a new layer. Click on the extreme left button at the bottom of the layer toolbar.

A pop-up window will appear. Give some name to the new layer and ensure that the resolution matches the resolution of the original image. Now go to the A.O. map window, press Ctrl + A to select the image and Ctrl + C to copy. Go back to the diffuse window, click on the second layer in the layer toolbar. Then click on the image and Ctrl + V to paste. As soon as you do this, a new floating layer gets added on the layer toolbar as well as a new image on top of the existing image. Now in order to merge these two images, right click on the floating layer in the layers toolbar, and click on Anchor Layer. It gets anchored to the new layer that you just added before. 

Now as you can notice, the original image is lost behind this current image. This is because the layer mode is set to normal. This can be seen in the mode option under the layers toolbar. Change it to Overlay or Multiply and you have that problem solved. Also try changing the opacity to see what fits your description. In my case, I set the mode to Multiply and an Opacity of 60.00 %.

Do the same process for you height map. Try playing around with the different layer modes as well as the opacity settings until you get the desired look. Make sure the original diffuse image doesn't lose too much color, as that is the texture we intend to use in UDK. For height map, I set the layer mode to Overlay and an opacity of 40.00 %. 

So basically that's all you have to do inside GIMP. We need the normal map inside UDK, so no point in adding it here anyways. Just to show the difference between the original diffuse texture and the one we get after adding the A.O. and height maps, I will post the images below. You can see that the texture starts to develop more features as the other two are added to it.

Original Diffuse Texture

Diffuse + A.O.

Diffuse + A.O. + Height Map

From the last image, it can be seen that the various features ranging from the small slopes along the bricks to the gaps in-between them are more visible now. After checking in UDK, I then reduced all the images from 2048x2048 to 1024x1024 as it hardly made any difference in-game. But the memory footprint can be reduced by a pretty good amount by doing so. Also you need to make sure that the textures are in power of 2 resolution before importing it into UDK. UDK also doesn't accept all image types, so I use PNG format for all my textures. Now that we have a game-ready texture available, it can be added to the UDK for use in the game. I'll have that in a different post. Lots of images to load in a single page already. So goodbye till then.

Thursday, April 10, 2014

Experiments with Textures - Part I

As mentioned in my previous post, the development on my game is going through an almost complete overhaul. Everything from textures to models are getting changed or optimized. However the level layout remains pretty much the same for now. Moreover I've taken a liking to the 3rd person view, so I'll most probably end up using that as the default view in the game. I feel that it kind of gives a better sense of the scale of the level. I may add an optional 1st person view later on.

Anyways my initial search for a new texture for the walls from some of the popular free texture sites ended up in vain, as I didn't get anything satisfactory. But somehow after almost a day of searching, I ended up in deviant art. And there I found the perfect texture in the gallery of the user AGF81. It was a seamless texture and had a pretty good variation in the size of bricks. Plus it came in a power of two resolution, which means I didn't have to do any cropping or resizing in order to import it into UDK. Also AGF81 was kind enough to let everyone use his textures for their personal uses. A thousand thanks to him. You can find his page in the link given below. He has lots of good textures in his gallery.

So basically this is the texture that I've selected for the walls. The color doesn't match the one I want, but I've already managed to change it in UDK's Material Editor. So that's not a problem.

Stone Texture from DeviantArt

The texture is pretty good by itself, it has some good details that can be extracted into normal and height maps. But as I realized during my previous iterations, when you directly apply it to a static mesh in UDK, it will look like some poster that is stuck on top of some rock rather than actual bricks. I didn't want to make the same mistake again. So I thought about ways to make it more realistic, and then the idea struck me. I could get the normal and height map from it using CrazyBump and rather than directly using it in UDK, I could first use it on a plane mesh in Blender. I could then amplify the details on the plane using the displacement modifier. Of course the mesh had to be a very high-poly in order to get the fine details right. I could then bake the details onto a low-poly version of the mesh using xNormal. Below are the original normal and height maps that I made using CrazyBump.

Original Normal Map

Original Height Map
Using them on the high poly plane mesh in Blender, and then baking the textures into the low poly version using xNromal, I was able to generate my new normal map, height map and ambient occlusion map.

Enhanced Normal Map

Enhanced Height Map

Enhanced A.O. map

I tested out these new textures on a plane mesh in Blender to see the rendered results before proceeding any further. Both using the default Blender Render as well as the Cycles Render. 

Blender Render 

Cycles Render (Used A.O. map and controller specular effects, hence less concentrated reflection)

I was pretty satisfied with the results. But just out of curiosity, I applied the same process once more to see if it would provide better results.

Another pass in Blender Render

There seems to be a noticeable increase in depth, but it kind of became overkill. There were just too many unnecessarily amplified distortions. So I just decided to stick with previous version. It had the right amount of beauty. This one seemed like it had an obvious layer of additional make-up. So basically I got my normal map, height map and A.O. map ready for use in the game. I made some changes to the original diffuse texture as well, but I'll give a detailed description about that in the next post. This post has already become a bit lengthy. Alright so that's it for now. Goodbye.