Abatron - the making of a UE4 Hybrid game =)

Fun With Beams!

This video shows the Ship Creature’s charge up affect as it prepares to blast the ground to create new structures or deal with unauthorized base visitors!

In this video I am using several kinds of beams in several different ways!

The first part of this video demos how the flying creatures now maintain a certain height above the terrain, calculated while taking their rather unusual shape into account :slight_smile: This height can be controlled by Designers in my BP Defaults for the creature.


**Beam Types**

1. straight beam, with source in local space, target in world space. Target is set in C++ to match position of the unit.

2. arced beam, with a tangent that is getting set in code, source in local, target in world/absolute space

3. straight beam with a source point in world space that is set in code, and a target that is in world space, also set in c++.

4. Electrical beam whose noise factor is a particle parameter that I set in code to match the duration of the effect as chosen by Designers via BP defaults.

Notice how the electrical beam starts scattered and becomes focused over the duration of the effect, again all controlled in C++.

The Hardest Part

The hardest part of what you see in the video was making the tangents for the arced beams stay consistent no matter which way the ship is looking in order to point directly at its target!

I had to use an odd hybrid of world and local space to accomplish this :slight_smile:

Here’s what the code ended up looking like!



//World Space Location of Target
NewBeamLoc = FMath::VInterpTo(
	NewBeamLoc,
	(VISVALID(Tracking_Actor)) ? Tracking_Actor->GetActorLocation() : Tracking_Location,
	GDELTATIME,
	12
);

 
//Half way between Eye of Creature and Target Location
const FVector MidPoint = (NewBeamLoc + GetEyeLocation())/2;
	
int32 Index = 0;
for(UParticleSystemComponent* Comp : BeamArcs)
{
	if(VISVALID(Comp))
	{
		//TEMP SHOULD REALLY BE HGIHER UP
		Comp->SetVectorParameter(FName("Target"),MidPoint);
		
		//Set the particle tangent position!
		if(ArcTangents.IsValidIndex(Index))
		{
			//Local Space settings set by Designers in Editor
			// 	as this controls the overall appearance of the arc.
			// 		not modified during runtime.
			FVector BPTangent = ArcTangents[Index];
			
			//World Dir
			FVector DirToTarget = (NewBeamLoc - GetEyeLocation()).SafeNormal();
			
			//World Right Vector
			FRotator WorldRight 	= FRotator(0,DirToTarget.Rotation().Yaw,0);
			WorldRight.Yaw 			+= 90;
			 
			//Oddly enough, Tangent has to start at 0!  Strange but true!
			//		(would have thought it would be be the beam anchor location)
			FVector Tangent 			= ZEROVECTOR;
			 
			//Forward
			Tangent = DirToTarget * BPTangent.X;
			
			//Right
			Tangent = WorldRight.Vector() * BPTangent.Y;
			
			//Up
			Tangent.Z = BPTangent.Z; 
			  
			//Tangent Beam Particle Parameter
			Comp->SetVectorParameter("Arc",Tangent);
		}
		Index++;
	}
}




Things to Note In My Code

1. The Designers can control the actual arcs of the beams in local space using a dynamic array of Vectors that I exposed to BP Defaults for the creature.

2. I am having to obtain the world direction and the world right direction between the eye of the Creature its current target, and then convert the local space coordinates set in BP into world positions. These world positions are the locations for the beam tangents that I set via beam particle parameter in Cascade.

3. **The end result is that the beam arcs stay consistent no matter how the creature rotates,** but, the beams are still tracking a world space location and the arched beams end at the midpoint betwen ship and its world space target!

Enjoy the Video!

♥

Rama

Fantastic Job Rama!
I can already think of some fantastic uses for this :smiley:

Out of curiosity, how hard would it be to make the beam that is attached to the target (lag behind) a bit if the target moves too fast?

[QUOTE=JBaldwin;170407]
Fantastic Job Rama!
I can already think of some fantastic uses for this :smiley:

Out of curiosity, how hard would it be to make the beam that is attached to the target (lag behind) a bit if the target moves too fast?

[/QUOTE]

I could do that right now!

I am already interpolating the beam endpoint as you can see here:



//World Space Location of Target
NewBeamLoc = FMath::VInterpTo(
	NewBeamLoc,
	(VISVALID(Tracking_Actor)) ? Tracking_Actor->GetActorLocation() : Tracking_Location,
	GDELTATIME,
	**12**
);


I could simply slow down the interp speed to accomplish your goal!

So instead of 12, I would use something like 3 or 7 !

Great to hear from you Jeremy!

:heart:

Rama

PS: the thing that makes the above code a little complicated is that I am using the ternary operator ? : to determine whether the target location is a moving target or a stationary point where building construction will begin :slight_smile:

Thanks alot Blackrock, I totally agree on having more hybrids. We will need playtesters :wink:

Looks really good…the scifi landscape is probably the best ive seen in ue4 yet

@WarpSpasm, thanks for the compliment. I’ll post shots of that level as Kevin has been spending alot of time with it improving areas. :slight_smile:

Nice Rino character

Thanks, I loved Rocksteady as a kid and always wanted to do a Rhino character :wink:

The team did a great job putting him together.

Monsters in the deep, Kevin & Rod working on scene development.

cfafae8bc704be120c5246a07ca2f584b5eb8c3b.jpeg

Rama PhysX Rock Vortex

I’ve been doing some low level PhysX coding and used a pure C++ class to control all the apex pieces of a destructible actor!

After an initial regular apex explosion that sends the pieces flying and bouncing off the landscape and anything else that is around, then the apex pieces are lifted into the air and made to spin in a Vortex shape!

This effect has no noticeable performance impact!

The lowest ms I ever see is 11.11 on my computer, and after my affect activates the ms is still 11.11 / my FPS is at my chosen max of 90 !


**Blueprints**

I exposed my entire PhysX Rock Vortex to Blueprints!

Any of the settings can be controlled from Blueprints all the way down to the PhysX code!

Rock Collisions

Notice that the PhysX pieces collide with each other and anything they encounter even while they spin the vortex formation I made for them in code!


**Pure C++**

Each Apex piece is being controlled with a pure C++ class that applies impulses to the apex piece to keep it in its proper orbit.


https://youtube.com/watch?v=7KpkQPhvBKA


Enjoy!

Rama

Particles, particles and even more particles.

I have been spending time doing particle work for the game. I just released a 50+ custom Vector Field library for the marketplace. I authored the vector fields in Maya 2015. It was alot of fun and produced some nice effects. I particularly love the energy wall, napalm effect, & the poisonvent :wink:

5a299a19907adfc1343e375ee879573a14d403a8.jpeg

Vote here Trello if you want to see more :wink:

After doing some much needed props for game mechanics. Leo is back to new character work. Here is an early Enchantress bust.

220aaf6731edaf2fece76a4ab82fab40c232c180.jpeg

Gun Impact particles. I have been deep into Particle FX as of late intermixed with UMG, Animation, & Coding. I did just finish another particle pack for the marketplace (if I get enough votes).

VOTE HERE

bcd258a80c3051162e202e734727da337e9bb92b.jpeg

These are aligned perfectly to be plug & play with surface normals plus exposed Vector parameters for reflection velocity debris sprays.

Enjoy and have fun with your Gamedev!

[QUOTE=Rama;170048]
Fun With Beams!

This video shows the Ship Creature’s charge up affect as it prepares to blast the ground to create new structures or deal with unauthorized base visitors!

In this video I am using several kinds of beams in several different ways!..

I love it! Great security system! Ha ha

Thanks ! I would love that kind of security! =)

Muzzle flash mania! I’ve spent some time getting acquainted with Cascade by doing muzzle flashes for Abatron. My latest work is up for Marketplace voting, 100+ muzzle flash library.

Vote Here if you like what you see! =)

I like the game progress :slight_smile:
About the muzzle flash pack, a lot looks the same, i think proposing some 30 base ones would suffice and people can adjust parameters to make variations (quality over quantity).

Thanks Galeon. I totally agree with you on the quality over quantity. However on this specific case, I found it was rather “hard” for a non-cascade user to make bigger instances of the muzzle flashes. I know that my level designer said the same thing. “Can’t I just scale it up?”, and the answer was not really. One of the things I really dislike with Cascade and hopefully Niagara doesn’t have the issue is the sprite orientation process.

The most believable look is to use use the sprite velocity for alignment and have it rotate along that velocity vector for facing the camera. Then ontop of that you should scale the size at the same rate it is moving out of the barrel. Finally, I put a drag over life to slow the sprite down after the initial “blast”. When I tried to size up the effect, it was a balancing of the velocity vector math, size over life, & drag variables. To make my long explanation short, I figured it was a little too difficult for a non-cascade user. Plus my level designer didn’t want to learn the particle system in that depth for modifications. =)

You are right that there are 13-14 base muzzle flashes with 8 different size variations. I hope that explains the pack a little more. I’ll make sure to make that clear to people!

Thanks for clarification, and you are right having premade ones is better for people that don’t know Cascade.

This isn’t quite true. It is more accurate to say that Maya 2015 is better at baking normal maps for Maya 2015’s viewport.

What you’re calling ‘shadowing’ is actually the normal map attempting to compensate for the gouraud shading of the low poly model. The problem is, the way each program renders normal maps is different (due to what tangent space they use), so how xNormal renders this compensation is different to Maya. To avoid errors like this, both the tool you’re using to generate the normal map and the system rendering it should have synchronised tangent spaces. Epic have said that xNormal is pretty close to UE4’s tangent space. In my experience it’s fairly close to Max’s too, which I prefer to use to xNormal anyway for many reasons. So those errors you’re pointing to may not show up in Unreal - ultimately, Maya is not a good way to judge the final look.

There’s 2 ways to avoid it: split the smoothing groups of the low poly, so you reduce the amount of compenstation (tension) in the normal map, or use Handplane to generate synced tangent space maps from an object space map. Unfortunately it doesn’t support UE4 yet.