Common Art Sprint #Final Delivery

 This sprint is all about solving problems and refining the look of the FX.

        I have added a function to make the UV rotate from the center, and use that to add warps to the original texture. By doing this I get a more complex look on the ripples.

I first finds out that the final level sequence is using the animation sequence itself, rather than using blueprints for each separate sequence shots. To solve this problem, I have moved all the detection logic into a BP_Animation Notifyer State, which is then attached to the animation sequence. Right now, the trail FX will only rely on the animation sequence, no more blueprints are neede. (See Below)

After I have done this, a new problem occures. The animation sequence has changed, and is constantly updating. Each time the animators import a new animation sequence with a different name and start using the new one, all my notifyers are gone, forcing me to do all the work again. After two rounds of re-applying all the notifyers, I get informed that there's no guarantee a "final version" for the animation sequence. 

At this point, I realized that since we are using a level sequence to control everything, there has to be a method to make the FXs only rely on the Level sequence itself which I always refuse to admit. Eventually I get it to work by making the trail to base on a spline and place both the trails and the ripples in to the level sequence.

(The Spline based logic)

(Stack everything into the level sequence)

The Final Look

    

P4 Prove

Common Art Sprint #4 Delivery

For this sprint, I have made a sticky particle FX. This FX will take in a static mesh as an input, then spawn particels only in the bottom half of the mesh. This is done by killing particles if the Dot Product of the normals from mesh and the positive Z axis in world space is bigger than 0. 

The main consept is to animate the drag component. With proper numbers, these particles will look very sticky.

I have tryed to use Move to Nearest Distance Field Surface GPU to allow particles to move along the surface of the mesh, but GPU particles are not able to generate location event, this make the trail of these drops more difficult to achieve. So I ended up chooses another approach.

  The next step will be implementing this FX to our character, and choose a suitable texture according to the vibe.

P4 Prove:

Common Art Sprint #3 Delivery

For this sprint, I keep adding more details to the trail FX. The consept of this FX is to simulate our character walking through water. To do that, I have made a web-like texture to fill in the gaps. This is the final look:

I have also solved some technical difficulties: I make the ring FX to line up correctly to the character's footstep. I have also fixed the edge jittering issue that has bothering me for a very long time. See Below:

In this version, you can see that the inner edge of this ribbon is overlapping itself, this is because "spawn rate" will not spawn particles uniformly through out the process.When there is a sharp turn, or if the spawning source is moving too fast, there will not be enough particles to support the ribbon. Therefore, I need to use "Spawn Per Unit" to uniformly spawn particles through distance.

Common Art Sprint #2 Delivery

 In the previous sprint, I have faced a lot of challenges. First: the FX will exist through out the whole animation, while I want the FX to exist only when the character is moving. Second: the follow position is not stable. Even after I use the method from last time, the projected point will have a lot of unpredicted motions. This will cause the ribbon to jitter a lot.

To solve the first challenge, I made a custom animation notify state which acts like a switch. This controls the boolean which then spawns and deletes the particle system. 

   To solve the second challenge, I have used the VInterp node. This node will output a smooth transition from current position to target position over time.

After solving this two challenges, I start to make shaders for the trail, them emplement these FX back into the animation sequence. I have also made a ripple FX for more details.

This is the final look:

Common Art Sprint #1 Delivery

 My main task on this project is to make a trail effect when main character walks on the ground. Here are the references I have found:

This FV includes two challenges: The effect itself, and how it can follow along the character.

I initially don't think it's hard to make it follow character. In common workflow, I need to get the character's velocity, or at least the world position for a niagara system to follow, but in this case, we only have animation sequences. In animation sequences, The actor location won't move, there are also no velocity.

My first attempt is to connect this FX on a joint. This can make the FX move with character, but since the joints are always moving in three axis, the FX no longer looks like trails, it will move up and down with the joint. Offset won't work because the joint location in constantly moving.

Scene component in BluePrint doesn't work because of the same reason. Since this animation sequence has no motion on it self, make the Scene component as the character's children can't solve the problem as well.

I have then tried to add notify states in animation sequence(Timed niagara effect). This can solve the problem of: "I want the trail only appears when there's an motion happen in the X,Y plane", but can't solve the jittering problem

My solution to this problem is by finding the pelvis joint, then make a line trace from pelvis to the floor. Now, we have a projection of the center weight of this character on the ground. The new location will have only two axis of freedom. The result of this method is very stable, but it will happen through the entire animation. I will need to combine the "notify states" method to this method to solve this problem.

It will not fly all around the character anymore. Blueprint see below:

TechArt W7HW _ Animation State Machines

To begin with, I have set up a blend space to control transitions between differen animations: idle; jog and sprint using a variable (BSSpeed).

  In the animation blueprint, find the "State Machines". This is where all the magic happens. I have created a loop, starting from Locomotion to  "Hit the Ground"; "FiringRifleLoop"; "BackOnYourFeet" then finally go back to Locomotion. Each state represents an animation sequence, and each transition icon stands for the conditions that required to move on to the next state.

 

These are the conditions, reading from left to right, from top to bottom.

                         

The float variable (BSSpeed) comes from the vector length of character pawn's velocity. The boolean variable (Firing) comes from the boolean (Is Firing) in the Character blueprint.

  In the Character blueprint, the "EnhancedInputAction IA_Fire", which triggers when the F key is pressed or released, will affect the boolean variable "is firing". When implementing this variable into movement mechanic, I am able to stop the movement input when Is Firing equals True. I added another boolean "Is recovering" to make sure that when "Is recovering" equals True, the movement input is delayed by 1.5 seconds.

  Finally, I create a custom GameMode for my character so that I don't need to set it up everytime.

I have recreated the process on the Mutant character, and instead of old animation states, I made him roar at the end of the fighting action.

 I made some changes in the character BP to make this anim cycle a bit more smooth. This logic divides time into repeating segments of 80/30 (AnimFrame / FramesPerSecond). If the current Triggered-Seconds is less than the threshold, it delays by the remaining time until the threshold. If it’s greater than the threshold, it multiplies the threshold by the segment count, then calculates and delays by the difference between that value and the current Triggered-Seconds.

Perforce Prof & Position:

Tech Art W6HW_Game Animation

First, I imported two skeletal mesh assets: one from the previous rigging assignment, and the other from Mixamo.

After that, I created a ROM animation to demonstrate how the joints work, and imported it along with another animation I found on Mixamo.

By setting up solvers and assigning them the correct IK goals and roots, I was able to retarget the animations onto each other.

Finally, I added an additional "Wave" animation to the skeletal mesh from the previous assignment. The following shows how they look together as a whole.

Perforce Prof:

Tech Art_W5HW_Basic Rigging

 I initially skin the whloe model in one piece, but soon finds out that there are a lot of points hidden behind different meshes. This makes weight painting almost impossible.

By separating this model into different layers from inside to outside, I am able to make sure all meshes have proper weights.

After I have finished, I add controllers to complete this simple FK.

Update: I have added the clavicle controls:

 

All the relavant directory structure:

TA_W4_HW_Intro to Blueprints

Scope: I plan to make a simple FPS game setup. When G key is pressed, draw a line trace from camera. When the trace hits the target, the target will then starts to dissolve.

Step one: Build the scene

Step two: Set up overlap event, enemy spawn

Step three: Set up Dynamic material / dissolve

Final step: Set up line trace when G key is pressed, when enemy is hit, it starts to dissolve.

In game view:

P4 prof: