wacki

UE4 Smoothed Normal from Line Trace in Packaged Builds

Sat, 29 Apr 2017 09:10:00 +0000

I needed a way to get a smoothed surface normal from a line trace in Unreal Engine 4. So of course the first thing I did was research the topic. I found a lot of good resources that I linked at the bottom of this post. However none of the forum posts mentioned the solution to accessing mesh data in a packaged build. This might’ve been because I was searching the wrong keywords. I included my code to calculate the interpolated surface normal for both Static Meshes and Spline Meshes in Unreal Engine 4.

Most of the resources I found were talking about getting UV coordinates for a Line Trace hit. And many didn’t consider Spline Meshes at all which is my primary usecase. And one important thing I didn’t find mentioned anywhere is that you need to enable Allow CPUAccess on static meshes that you want to access during runtime in a packaged build. I found that one while digging through the source code, although it’s a pretty obvious thing in hindsight.

To be able to access mesh data in a packaged build bAllowCPUAccess must to be set to true.

The following code is part of my static c++ function library. It accepts a FHitResult reference and calculates an interpolated normal based on the triangle that was hit. This works for both Static Mesh as well as Spline Mesh Components. However this code is by no means perfect and I am sure there is a lot that could be improved.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
bool GetSmoothNormalFromTrace(const FHitResult& HitResult, FVector& Normal, bool DebugDraw)
{
    // We don't care if this isn't a blocking hit
    if(!HitResult.bBlockingHit)
        return false;

    // See if a static mesh and/or a spline mesh component were hit
    UStaticMeshComponent* StaticMeshComp = Cast<UStaticMeshComponent>(HitResult.GetComponent());
    USplineMeshComponent* SplineMeshComp = Cast<USplineMeshComponent>(HitResult.GetComponent());

    // If we hit a spline mesh component we should also have hit a static mesh component
    if(!StaticMeshComp) return false;

    // Retrieve static mesh. If we hit a spline mesh component we also hit a static mesh component at the same time.
    // So we can just use it to get to the actual static mesh.
    UStaticMesh* StaticMesh = StaticMeshComp->GetStaticMesh();

    // Return if the static mesh isn't set (shouldn't happen)
    if(!StaticMesh) 
        return false;

    // In cooked builds we need to have this flag set or we'll crash when trying to access mesh data
    if(!StaticMesh->bAllowCPUAccess)
        return false;

    // Return if RenderData is invalid
    if(!StaticMesh->RenderData)
        return false;

    // No valid mesh data on lod 0 (shouldn't happen)
    if(!StaticMesh->RenderData->LODResources.IsValidIndex(0))
        return false;
 
    int FaceIndex = HitResult.FaceIndex;
    FTransform ComponentTransform = StaticMeshComp->GetComponentTransform();
    FStaticMeshVertexBuffer* VertexBuffer = &StaticMesh->RenderData->LODResources[0].VertexBuffer;
    FPositionVertexBuffer* PositionVertexBuffer = &StaticMesh->RenderData->LODResources[0].PositionVertexBuffer;
    FIndexArrayView IndexBuffer = StaticMesh->RenderData->LODResources[0].IndexBuffer.GetArrayView();

    // Storage for the actual triangle verteces
    FVector VertexPositions[3];
    FVector VertexNormals[3];

    for(int i = 0; i < 3; i++) {
        // Get vertex index
        uint32 index = IndexBuffer[FaceIndex * 3 + i];
        // Get vertex position and normal
        VertexPositions[i] = PositionVertexBuffer->VertexPosition(index);
        VertexNormals[i] = VertexBuffer->VertexTangentZ(index);
        
        // Transform position and normal into spline mesh space
        if(SplineMeshComp) {
            // Get transform along spline component
            const FTransform SliceTransform = SplineMeshComp->CalcSliceTransform(USplineMeshComponent::GetAxisValue(VertexPositions[i], SplineMeshComp->ForwardAxis));
            // Remove spline forward axis from vertex position, it will be added back by transforming the position into spline mesh space
            USplineMeshComponent::GetAxisValue(VertexPositions[i], SplineMeshComp->ForwardAxis) = 0;
            // Transform position and normal into spline mesh space
            VertexPositions[i] = SliceTransform.TransformPosition(VertexPositions[i]);
            VertexNormals[i] = SliceTransform.TransformVector(VertexNormals[i]);
        }

        // Transform position and normal into world space
        VertexPositions[i] = ComponentTransform.TransformPosition(VertexPositions[i]);
        VertexNormals[i] = ComponentTransform.TransformVector(VertexNormals[i]);
    }
    
    // Determine the barycentric coordinates
    FVector U = VertexPositions[1] - VertexPositions[0];
    FVector V = VertexPositions[2] - VertexPositions[0];
    FVector W = HitResult.ImpactPoint - VertexPositions[0];

    FVector vCrossW = FVector::CrossProduct(V, W);
    FVector vCrossU = FVector::CrossProduct(V, U);

    if(FVector::DotProduct(vCrossW, vCrossU) < 0.0f) {
        return false;
    }

    FVector uCrossW = FVector::CrossProduct(U, W);
    FVector uCrossV = FVector::CrossProduct(U, V);

    if(FVector::DotProduct(uCrossW, uCrossV) < 0.0f) {
        return false;
    }

    float Denom = uCrossV.Size();
    float b1 = vCrossW.Size() / Denom;
    float b2 = uCrossW.Size() / Denom;
    float b0 = 1.0f - b1 - b2;

    // Determine the hit normal
    Normal.X = b0 * VertexNormals[0].X + b1 * VertexNormals[1].X + b2 * VertexNormals[2].X;
    Normal.Y = b0 * VertexNormals[0].Y + b1 * VertexNormals[1].Y + b2 * VertexNormals[2].Y;
    Normal.Z = b0 * VertexNormals[0].Z + b1 * VertexNormals[1].Z + b2 * VertexNormals[2].Z;
    
    // Just to be safe here
    Normal.Normalize();

    // Debug draw
    #if !UE_BUILD_SHIPPING
    if(DebugDraw) {
    	// Quick and dirty debug draw
        FColor DebugColor = FColor::Red;
        float DebugDrawDuration = 30.0f;

        for(int i = 0; i < 3; i++) {
            // draw triangle points
            ::DrawDebugPoint(StaticMeshComp->GetWorld(), VertexPositions[i], 16, DebugColor, false, DebugDrawDuration);
            // draw triangle edges
            ::DrawDebugLine(StaticMeshComp->GetWorld(), VertexPositions[i], VertexPositions[(i+1)%3], DebugColor, false, DebugDrawDuration);
            // triangle normals
            ::DrawDebugLine(StaticMeshComp->GetWorld(), VertexPositions[i], VertexPositions[i] + VertexNormals[i]  * 200.0f, DebugColor, false, DebugDrawDuration);
            }

        // draw actual impact normal
        ::DrawDebugPoint(StaticMeshComp->GetWorld(), HitResult.ImpactPoint, 16, DebugColor, false, DebugDrawDuration);
        ::DrawDebugLine(StaticMeshComp->GetWorld(), HitResult.ImpactPoint, HitResult.ImpactPoint + HitResult.ImpactNormal * 200.0f, DebugColor, false, DebugDrawDuration);
        ::DrawDebugLine(StaticMeshComp->GetWorld(), HitResult.ImpactPoint, HitResult.ImpactPoint + Normal * 200.0f, DebugColor, false, DebugDrawDuration);
    }
    #endif //!UE_BUILD_SHIPPING
    
    return true;
}

Resources used:

MachX Item Pickup Models

Sun, 23 Apr 2017 09:10:00 +0000

Item pickup models for a racing game I am working on as my final project at VFS.

Hover racer untextured by wacki on Sketchfab

Dynamic snow/sand shader for Unity

Mon, 02 Jan 2017 12:10:00 +0000

A while ago I shared a small project I was working on. I finally had the time to clean up a bit and try a few more things. The goal was to achieve an effect similar to the sand in Journey. Even though in my case it’s snow at the moment.

The project includes a few example shaders and it’s easy to write your own. The effect is achieved by drawing into a height map texture using a stamp or brush texture. A custom material allows for full control over how we overlay that stamp texture. In the shader we have access to the height map pixels as well as the stamp pixels.

Included stamp shader variants.

I like how it turned out so far, but there are still a few things I want to do:

Clean up some more, make it easier to use.
Optimize.
Make the effect work with Unity’s terrain system.

I haven’t really thought about how to get this to work with Unity’s terrain yet. One option might be to use a seperate tiling system for the snow tiles overlaying the terrain. The shader is already using distance based tessellation, so LOD shouldn’t be an issue. However this approach will most certainly lead to stitching issues along LOD seams. This sounds like a completely separate terrain system already, ugh… Maybe I could augment Unity’s terrain shader and add some tesselation to it? Then just use a big enough texture atlas for the dynamic height map tiles. I guess I have some research to do.

Source code:

First video about this project.

Khaya - VFS 2D project

Wed, 28 Dec 2016 09:10:00 +0000

I am currently working on a 2D platformer as part of a student team. The project is part of the Game Design course at VFS. I am handling the programming side of things as well as some special effects and UI. The prototype version of the game is done and we should hit alpha in about three weeks.

At its core the game is about speed and skillful traversal of levels. The twist is an aura surrounding the character that shrinks should the player stand still for too long. If this aura gets too small the player will die.

Current state of the prototype. Note: Art, animations and audio are still only placeholders for now.

The movement in its current form feels fun and engaging. However there are still quite a few areas where we need to tweak and balance things. The most difficult being the aura mechanic.

How the aura works:

If the player is moving at an average velocity larger than a set threshold then the aura will grow / stay at maximum size. As soon as the player falls below that velocity threshold a timer will start after which the aura starts to shrink. If the aura gets too small the player will start taking damage. The aura is also responsible to trigger frozen objects in the level should it come in contact with them.

There are still a bunch of design challanges ahead of us. Most of them involve giving the player proper feedback for their actions. Especially the aura will be hard to get right in this regard. And of course some smaller tweaking and balancing is still necessary as well.

Unfinished digital raptor drawing

Thu, 10 Nov 2016 11:00:00 +0000

Tried myself at digital drawing again. It's unfinished but given the time constraints I had to work with I am quite happy how far I got. This is about 2h worth of work.

Current state of the drawing.

I was debating wheather or not I should post this but I think I should just go ahead and post more stuff in the first place, so from now on that is what I'm going to be doing.

Timelapse of the drawing process.

Hover Racer 3D model made in blender

Sat, 11 Jun 2016 16:46:00 +0000

My first try at actually modelling something from scratch.

Hover racer untextured by wacki on Sketchfab

Painting a pavement texture

Mon, 06 Jun 2016 16:46:00 +0000

My first try at hand painting a texture in Photoshop.

Finished texture.

I wanted to dive into this topic for a while but couldn’t find a good starting point until recently. While browsing youtube for some good photoshop painting introductions I came across a texturing workshop led by Jamin Shoulet at the Academy of Art University. Through this video I found the channel Metric Meditation and this video which is using many of the same techniques that Jamin introduced in his workshop. So I thought trying to make something similar would be a good way to get my feet wet.

Timelapse of the painting process.

Just like you (should) prototype before going into production or doing a rough blocking out of your animation before adding detail, I think the same applies for making tileable textures. Although I am happy with the style of my texture I don’t like how it repeats. The big stones are way too prominent and stick out when using it on a large area. This would’ve been apparent if I just took an earlier version of the texture and slapped it onto a large plane. I could’ve then tweaked the shapes of the stones until the tiling looked pleasing.

VR GUI Input Module for Unity (HTC Vive)

Sat, 04 Jun 2016 07:00:00 +0000

I created a simple GUI input module for Unity to be used in VR. The project includes an implementation for the HTC Vive controllers.

Unity GUI working with the Vive controllers.

I am fortunate enough to be able to use an HTC Vive at my workplace. After starting out in Unity I soon found myself wanting to use Unity’s uGUI system in VR. So of course the first thing I did was head on over to Google and check if someone had already done the work for me. Sure enough I came upon a solution by vrinflux who put their results on Github for everyone to use. I liked their solution but I wanted something not as tightly coupled with the vive and that would support more than just two controllers. I am also not too fond of the cursor they used in their project. What I had in mind was more in the line of how the steam VR overlay did things, using a sort of laser pointer as a visual guide.

SteamVR Steam overlay.

LaserPointerInputModule
This is the actual Unity Input Module. It handles GUI interaction and lets IUILaserPointerControllers know if they enter or exit a GUI element.

IUILaserPointerControllers
Is the abstract base class for all controllers that want to interact with LaserPointerInputModule. Concrete classes have to provide an implementation for button up and down functions. The class also handles the actual laser pointer visualization.

ViveUILaserPointerController
Is the (currently) only concrete implementation of the laser pointer controller. It uses the haptic pulse feature of the Vive controllers to let the user know whenever he enters a new GUI element.

Here you see the current state of the project.

You can check it out on Github:

I am pleased with the current state of this project. The only thing I’d like to change whenever I get the time is the laser pointer visualization. Currently the IUILaserPointerController handles the visualization of the laser pointer. I do this mostly because I require the LaserPointerInputModule to tell me the results of GUI raycasts and this way I can just do it all at one point. It would be much better though if I could have a self contained laser pointer visualization component that can do GUI raycasts without having to rely on an Input module. It shouldn’t be that big of an issue actually and when I get the time to do it I’ll update the project.

Creating sand footprints in Unreal Engine 4

Sun, 13 Dec 2015 15:13:00 +0000

I wanted to keep with the theme from my last post and do something with sand again. My rough goal was to use Unreal Engine 4’s (UE4) third person template and enable the character to leave footprints in the sand. I used this to look at blueprints, particle systems, materials and finally working with C++ in UE4. The “finished” project can be found on github, a link is included at the bottom of the post.

The final look of the terrain material and footprint effects

The first step when starting something new and unfamiliar is to always look for similar examples. While doing that I stumbled on this tutorial series by Kodi Myatt. It is a four part video tutorial about creating footprints in UE4, exactly what I need. The tutorial seems to be on hiatus at the moment, but the first video has quite enough information to get me started.

I found the best way to develop something in 3D space is to visualize every step of the way. But first we need to figure out when something has to be drawn. So let’s find a way to get a message on screen whenever the character’s feet touch the ground. This is actually quite simple in UE4. All we have to do is add a custom AnimNotify to the animation blueprint at the timestamps where a foot touches the ground.

Adding custom AnimNotify to the third person character

We can now use these notify events in the graph of the animation blueprint to do something. For now we’ll print the string “left” and “right” based on which foot hit the ground to see if it works.

I made progress with my own footprints by using a ray shoot, or rather line trace as UE4 calls it. I am able to figure out where on the terrain a foot “hit” the ground. I then spawn a decal actor using the floors orientation at that point to display any texture I want.

Instead of printing a message we will shoot a ray from the foot’s position downward to find out where on our terrain we have to draw a footprint. This ray shoot or rather line trace as it is called in UE4 also returns the surface normal of where we hit the ground. Using the normal and location we can position a decal actor and orient it to match the floor. All that is left now is to create the actual decal to look like a footprint. Let’s dust off Blender and try to create a footprint.

Blender footprint model

This looks good enough for now I think, a bit too artificial for my taste but we can always come back later and change it.

Back in UE4 we create a new deferred decal material and use the baked normal and displacement maps from blender to achieve a sense of depth.

Decal on default grey floor

The decal seems to work on the grey flat floor, but what about actual sand terrain? Let’s dive a little deeper into the material editor and create a desert material for testing purposes. We can use some of the assets from Epic’s vehicle example which already has good quality sand textures.

Sand material graph

The decal looks too smooth on this new terrain, we have to add some sand grains to it as well so it will blend in a little better with the rest of the terrain.

A big problem when using this decal method is overlapping footprints. It looks really fake when this happens. It might be possible to mitigate the effect through some blending technique, however a more interesting approach might be to use an additional height map. The game Journey has a great sand simulation where you can slide down hills and leave a trail behind. They used additional detail height maps that reacted to players foot prints on top of the terrain (source). I guess tessellation for certain ground types like sand and snow might in fact be the ideal solution and I definitely want to come back to this topic at some point in time.

We still have a problem: our decals never go away. It would be great if the decals could handle their lifetime themselves and get deleted automatically. We can do this by creating a new blueprint that inherits from DecalActor. In the graph of this blueprint we define a life time and fade out time. Using these values we can then slowly fade out the actor before removing it completely. The fade out works by manipulating a fade parameter in the decal material.

Custom DecalActor that fades out after a while

Finally I want to add a little sand kick up effect whenever a foot touches the ground. This is a job for a particle system. We can create a new particle system by right clicking in the content browser. Double clicking the effect opens up Cascade, which is UE4’s particle system editor. The UI looks a bit overwhelming at first, but it is actually laid out quite logically. Basically we can stack multiple emitters on top of each other in the emitters window. Each emitter has a range of different modules that can be added or removed, such as lifetime, velocity control or acceleration. These modules can further be controlled by editing them in the details panel or use an animation curve to control their values.

Simple sand kick up effect using Cascade

Let’s see the effect in action by adding it to our decal spawning blueprint.

It is working, but the color doesn’t match the terrain at the moment. This is because I used height based coloring for the terrain to give the sand some variety in color. We have to apply the same coloring system to our particle effect material. This is a great excuse to use material property collections. These collections are just what the name suggest, a collection of properties for a material, like our height color values. We can then use these collections inside our materials and only have to change the values in one place to affect them all.

Material property collection

The blueprint prototype is working properly, everything looks good, we can now go ahead and port some of the functionality to C++. This might not really be necessary in this case but the point is to get a feel for the workflow for future projects.

We start by adding a foot down function to our third person character which will get called instead of our current blueprint function.

protected:
    void Trace(FHitResult& OutHit, const FVector& Location) const;

public:
    UFUNCTION(BlueprintCallable, Category = "Character")
    void FootDown(const UArrowComponent* FootArrow) const;

Then, in the implementation of the functions, we’re going to just display the surface normal to get something on screen again.

void AFootprintsCharacter::Trace(FHitResult& OutHit, const FVector& Location) const
{
    FVector Start = Location;
    FVector End = Location;

    Start.Z += 20.0f;
    End.Z -= 20.0f;

    //Re-initialize hit info
    OutHit = FHitResult(ForceInit);

    FCollisionQueryParams TraceParams(FName(TEXT("Footprint trace")), true, this);
    TraceParams.bReturnPhysicalMaterial = true;

    GetWorld()->LineTraceSingleByChannel(OutHit, Start, End, ECC_Visibility, TraceParams);
}

void AFootprintsCharacter::FootDown(const UArrowComponent* FootArrow) const
{
    FHitResult HitResult;
    FVector FootWorldPosition = FootArrow->GetComponentTransform().GetLocation();
    
    Trace(HitResult, FootWorldPosition);    

    // Debug vis
    DrawDebugLine(GetWorld(), HitResult.Location, HitResult.Location + HitResult.Normal * 100.0f, FColor::Blue, false, 10.0f, 0, 5.0f);
}

Result of the code above

The basics seem to be working again so all that is left is to spawn our decal and particle effect. Let’s go a bit further than the blueprint version however, how about we spawn a different effect based on the ground type that we hit? We can create a custom data asset to hold our effect references per surface type. To determine surface type we use the Physical Material present on a material.

Custom data asset for defining footprint effects based on ground type

Using this data asset we are now able to query the current physical material of the ground and select the correct decal and particle effect to display. All we need to do to support a new ground type is to create a specific effect and add it to the list.

Updated FootDown function:

void AFootprintsCharacter::FootDown(const UArrowComponent* FootArrow) const
{
    FHitResult HitResult;
    FVector FootWorldPosition = FootArrow->GetComponentTransform().GetLocation();
    FVector Forward = FootArrow->GetForwardVector();

    Trace(HitResult, FootWorldPosition);    
    UPhysicalMaterial* PhysMat = HitResult.PhysMaterial.Get();

    // Retrieve the particle system and decal object to spawn for our current ground type
    UParticleSystem* ParticleFX = FootprintTypes->GetFootprintFX(PhysMat);
    TSubclassOf<ADecalActor> Decal = FootprintTypes->GetFootprintDecal(PhysMat);
        
    // Create a rotator using the landscape normal and our foot forward vectors
    // Note that we use the function ZX to enforce the normal direction (Z)
    FQuat floorRot = FRotationMatrix::MakeFromZX(HitResult.Normal, Forward).ToQuat();
    FQuat offsetRot(FRotator(0.0f, -90.0f, 0.0f));
    FRotator Rotation = (floorRot * offsetRot).Rotator();

    // Spawn decal and particle emitter
    if(Decal)
        AActor* DecalInstance = GetWorld()->SpawnActor(Decal, &HitResult.Location, &Rotation);
    if(ParticleFX)
        UGameplayStatics::SpawnEmitterAtLocation(GetWorld(), ParticleFX, HitResult.Location);
}

Of course if you’d like to see the rest of the source code or try the project for yourself you can get everything on github:

Video of the finished project

Using World Machine to create natural looking terrain

Sun, 29 Nov 2015 20:20:02 +0000

Here it is, the first real post of the blog and already I’m doing something only somewhat related to my main goal, which is learning UE4. I have a game in mind and I’m not going to go into too much detail here, but basically you’re controlling a large vehicle in a desert environment. Well I thought I could try and create small parts of the game as a way to learn how to use the engine. Another idea would be to recreate a simple arcade game like Space Invaders. I might still do that later on but for now I am interested in the topic of terrains. Terrains in UE4 seem to be a big selling point since they released the kite demo. And their results speak for themselves. So after doing some research I found out that Epic used World Machine for an errosion pass over their heightmaps to achieve a natural look. This is why I figured World Machine would be a good starting point for me. Luckily there is a trial version of World Machine to play around with.

After opening up World Machine for the first time it seemed instantly familiar to me. This is because back when I started to learn openGL, some of my first projects involved procedural terrain generation. And although not being anywhere near of what World Machine can do, the basics are the same. Generate and combine some different noises and run a few erosion passes on it. After playing around with World Machine for a while I decided to try and create a few simple sand dunes for now and then move on to something different. Below you can see my current state.

This is what I came up with after some trial and error in world-machine

This is what it looks like inside UE4

While looking for terrain examples and stuff other people had done, I stumbled upon this (source). which is much more in the vein of what I want my dunes to look. When I revisit this topic I’m going to use this as a resource. For now I’m happy to have the basics of World Machine down and will move on to other topics.