Scripting a Camera System
62- This is where our trace will come into play. We need to check and see if our potential
camera location will work, meaning that it won't put us in a wall. If we do run into a
collision issue, the camera will automatically offset itself by the value of the normal
of what we hit. This is perhaps the most complicated part of the code, as it involves
so much math:
/* Draw a trace to see if the potential camera location will
work/
HitActor=Trace(HitLocation, HitNormal,
PotentialCameraLocation, OutVT.POV.Location, true,,,
TRACEFLAG_BULLET);
/** Will the trace hit world geometry? If so then use
the hit location and offset it by the hit normal */
if (HitActor!=None&&HitActor.bWorldGeometry)
{
OutVT.POV.Location=HitLocation+HitNormal*16.f;
}
else
{
OutVT.POV.Location=PotentialCameraLocation;
}- Our last piece of code makes us declare the archetype that we will be using to access
our camera's properties. We'll cover exactly where we get this file path at the end of
our TutorialCameraProperties tutorial.
defaultproperties
{
/** This sets our camera to use the settings we create in the
editor */
CameraProperties=TutorialCameraProperties'TutorialPackage.
archetypes.Arc_TutorialCamera'
}How it works...
Flipping back and forth between an IDE and the editor to determine the exact numbers for
variables such as offset, rotation, and distance for our camera system can be a frustrating
and time consuming. By scripting one prototyping camera system from our IDE, we will be
allowed to change values on the fly from within the UDK editor. This way, we can not only save
valuable time and avoid frustration, but also quickly prototype new camera systems and see
how our current ones work.
We've created a camera system and exposed certain properties to the UDK editor to avoid
cluttering our editor, while at the same time allowing for easy manipulation of important
properties, such as rotation and vector.