The conclusion to our series on using Unreal Studio for interactive rendering and configuration.
Welcome to the fourth and final part of our series on Unreal Studio* for engineers. In this entry, all our hard work will pay off as we create a final product for our interactive sportscar rendering. But first, a quick recap of how we got to this point.
In Unreal Studio for Engineers Part 1, we introduced the basics of Unreal Studio, including how to set up the program and navigate its user interface (if you haven’t done so by now, you can still download the beta of Unreal Studio for free). Part One also described how to use Datasmith to import CAD geometry and other 3D data. We brought in a SOLIDWORKS model of a 2015 Mercedes AMG GT (courtesy of Yusuf Buwanguzi; you can find the model here) and a SketchUp model of a hangar to house it in.
In Unreal Studio for Engineers Part 2, we began with a deeper look at applying materials to our scene. First, we downloaded the Automotive Materials Pack from Epic Games and added it to our project. Then, we looked at how to create our own custom materials with Unreal Studio’s Material Editor system. Next, we examined the lighting of our scene and learned about baked lighting, real-time lighting and how Unreal Studio handles UV mapping. Finally, we took a brief look at using Volumes in Unreal Studio.
In Unreal Studio for Engineers Part 3, we began by using Blueprints to configure an X-Ray material, which we used as a template for a new Material Instance. We then looked at how to use Variant Manager to create two different configurations of our vehicle, a useful feature for customizable products. Finally, we looked at how to enhance our user interface with custom button widgets and multiple camera setups.
Completing the User Interface
We created a nice user interface widget in Part 3, but let’s add some additional functionality to make the experience better for our users. Our eventual goal is for potential customers to be able to navigate the 3D world on their own, examining the model as they see fit. We want to give them an intuitive and easy way to do this.
Let’s start off by adding another camera to our setup, giving the user four pre-configured views of the car. As a reminder for how to do this, go to the Modes window to the left of the viewport, select All Classes and scroll down until you see the icon for a Camera Actor. Or, just type Camera in the search box near the top of the window.
Drag the Camera out into the viewport wherever you like. We’ll put ours on the passenger side of the car at a low angle to make the Mercedes look mighty. You’ll see an immediate preview of the camera’s point of view whenever it’s selected in the viewport.
We want to add a button for the camera in our UI widget, just as we did in Part 3. It’ll be easy to do since we already set up the cameras earlier. Let’s go into our Widget Blueprint, which we’ll access by double clicking on the icon called GUI in our Content Browser:
This opens up our Blueprint editor, starting with the Designer Mode (where we graphically layout our UI).
You’ll notice we have two buttons to toggle between X-Ray and Normal viewing modes and three buttons to toggle between camera views. For our fourth camera view, we’ll add two components from the Palette panel: a button (which we’ll name “btn_cam4”) and a text box (which we’ll set as “Cam4”). They’ll show up in our Hierarchy panel, and we can drag them into position on the main viewport.
To add the required logic to this new button, switch to the Graph mode in the top right:
In the new viewport, this is what the logic for the first three cameras looks like:
We simply need to add a few new nodes into the existing pattern. Right click anywhere in the viewport and start typing to search for nodes. Look for a “Set View Target with Blend” node and add it to the workspace. Then, look for the “Get (a copy)” node (it’s getting an item from an array, so make sure you grab the block from the Array heading).
If you can’t find the node you’re looking for, try unchecking the box in the right corner that says “Context Sensitive.” Alternatively, you can select one of the existing nodes and copy and paste it.
For the last node, “OnClicked (btn_cam4)”, click on btn_cam4 in the My Blueprint panel to the left of the viewport. Then, in the Details panel below it, simply click the green plus next to the Event “On Clicked”. The node will automatically be created in the viewport.
Then, all we have to do is wire up the nodes exactly as the first three are wired:
Note that we changed the index of the new “Get” node to 3 (since indexes start at 0, this corresponds to our fourth camera). The “Blend Time” option in the “Set View Target with Blend” node allows us to control the speed that we transition from one camera to another. If you want an instant cut between shots, set it to 0. We’ve got it at 1 second.
Right now, our wires are crossing all over the place. In a larger Blueprint model, this can get confusing quickly. To organize the wires better, we can double click on any wire to create a reroute node in the spot we clicked. Not only does this let us control our wire like a spline, it gives us a secondary access point to a node’s output.
Now things are a little more organized. A few more tips when working with Blueprints: you can alt click on any wire to delete it; right click on any input node and you’ll see the option to “Straighten Connection to…” the incoming node (for those who like straight lines); and if you don’t care for the spaghetti strands that Blueprints creates by default, here’s an add-on that will wire up nodes like a circuit board instead (straight lines all the way).
Okay, now that we’ve had a refresher on the Blueprints interface, let’s add a little more advanced functionality. We want customers to check out our pre-set camera views, but we also want them to be able to move around our model as they please. For this, we’ll need a player character.
Let’s minimize the Widget editor and go back to the main interface. In the Modes palette, under Basic, select Player Start and drag it onto the viewport. Wherever you place this component, which resembles a game controller and flag, is where our player will start. In the game, the player will by appear as a floating sphere by default.
Next we want to add a button that will let us switch to this character and walk (or rather, fly) around our model. Back in the Widget editor, add another button (call it “btn_player”) and a text box that says “Player”.
Now let’s add the Blueprints logic.
Go back to the Graph tab, find the camera logic, and add one more “Set View Target with Blend” node. Find our newly created btn_player and create an “On Clicked” action. Now, instead of connecting these nodes to a camera, we’ll simply set the new target as our reference target from “Get Player Controller”.
Now we can easily switch between our preconfigured camera views and a controllable first-person view. However, as it stands, the controllable character will hang out wherever we happen to leave it when we switch to a camera. To make the experience a little smoother, lets make it so that the character can take over from whatever camera view we switch to. That is, we want to teleport the player to the position of a camera whenever we switch to it.
We’ll need to grab a few more nodes. Start by searching for “Get Owning Player Pawn”. This gives us control of the pawn (representation of the character) used by the player who sees our GUI widget. Then look for “SetActorLocation”. This node will allow us to move our pawn to whatever location we want. Wire them together immediately after the “Set View Target with Blend” node for camera 1:
The Sweep and Teleport switches on SetActorLocation specify how the character moves. If Sweep were selected, the pawn would physically move through space to the new location. Since Teleport is selected, the pawn instantly moves to the new location.
Now we need to specify the new location for the pawn. We want to grab the coordinates of camera 1, which we can do with a “GetWorldLocation” node. Simply wire it up to the “Get (a copy)” block containing camera 1 (a conversion node, with the input and output of Target and Root Component, will be created automatically between them).
We’re close, but there’s another detail to take care of. Right now, our character is simply being translated to the coordinates of camera 1. For a seamless transition, we also want the character to rotate to look at the car (otherwise you might switch to the player and find yourself facing the hangar wall or floor).
We can do this just as easily by using a “GetWorldRotation” node, hooking it up to the “Get (a copy)” block for camera 1 as before, and feeding that into a node called “Set Control Rotation”. That node requires us to use “Get Player Controller” like we did for the cameras. Here’s what it all looks like:
Now, when we click on camera 1 and return control to the player, we start off with the exact same view as the camera, making a very smooth transition. Of course, we want this behavior for all cameras, so let’s repeat the same steps for each camera. Here’s what we end up with:
We’ll stop here; but note that there are infinite ways we could tweak the user experience. You might experiment with mapping keyboard buttons to the cameras instead of the on-screen buttons. Or, you could use the “On Pressed” and “On Released” functions of the buttons to automatically give control back to the player whenever the camera switches. You could try adding functions to change the lighting of the scene or the appearance of the character. We’ve only scratched the surface of what Unreal Studio and Blueprints can do.
Exporting the Finished Product
Now that we’ve got everything behaving the way we want, it’s time to move onto the final step: packaging. Now, this isn’t strictly necessary—you can always play your level in the Unreal Studio viewport (which is very helpful for testing), but it’ll look more professional if we can simply open an executable for a client or send it directly to them. This is called packaging.
Unreal Studio files can be packaged for a number of different platforms, including Windows, Linux, Android, iOS, HTML5, and more. We’ll focus on Windows, but it’s easy to extend the concept to the platform of your choice. First, lets see what options we have. Navigate to File->Package Project->Packaging Settings.
This presents us with a number of options for how we want our final project to be packaged. The Build Configuration gives us options for debugging and development, and the Staging Directory specifies where to output the package. If you plan on submitting a package to the Google Play store or Apple App store, you’ll need to check the “Distribution” checkbox. You likely won’t need to worry about any of these, and can simply leave the defaults checked. If you’re unsure, check out the full documentation for Packaging Settings.
Before we can package our project, it’s crucial that we specify which level (map) we want to load on startup. We forgot to do this at first, and got a blank screen and an error message when we tried to run the application. But you can avoid our mistakes. Go to Edit->Project Settings and click on Maps and Modes. Set the Game Default Map as the level which contains the car (we called ours TOP).
Now we have everything ready to go, and its time to package the project. Go to File->Package Project and click on the target platform of your choice. We selected Windows 64-bit.
You’ll be asked to select a directory (if you haven’t already specified one in the Packaging Settings), and that’s it. You’ll see a notification pop up that packaging is in progress.
For us, the process took six and a half minutes, but it will vary based on the project complexity and your computer’s specs. In any case, you’re still free to use the editor during the packaging process, so you can make adjustments and play your level in the viewport. When the packaging is complete, you’ll hear a short electronic noise and a notification will pop up that says “Packaging Complete!”
To test your package, go to the directory you specified. For Windows, it will contain a folder called “WindowsNoEditor”. Open the folder, and look for the .exe file with the same name as your project. Double click it to launch your application.
And voilà! Our application is up and running. We can walk around the car and switch between our pre-set cameras. We can turn the X-Ray variant on and off. We have a fully packaged, beautifully rendered, interactive model that we can share with customers. And though the learning curve starts off a bit steep, now that you know the basics of Unreal Studio, you can create applications like this in no time.
Good luck! Here are some additional links that may come in handy:
- Unreal Studio for Engineers Part 1
- Unreal Studio for Engineers Part 2
- Unreal Studio for Engineers Part 3
- Unreal Studio beta download
- Unreal Engine 4 documentation
- Unreal Engine forums
- Automotive Materials pack
*Editor’s note: With the release of Unreal Engine 4.24, all Unreal Studio features have been rolled into Unreal Engine. Datasmith is also included as a standard Unreal Engine feature.
Epic Games has sponsored this post. All opinions are mine. –Michael Alba