Don't want to use navemesh for player, my solution

quentin_wantiez · December 11, 2021, 10:02pm

i … realy don’t want tu use navmesh for player so i made this to calculate the angle betxeen vrroot upvector and the hit result normal vector (if inclination is too steep you shouldn’t be able to teleport and you also shold not be able to teleport to a wall) (i also turn the cilinder 90° for it to align with hitresult normal vector (i have to figure somthing else for the destination maker material tho it dosn’t look quite right when tilted as it has been made for flat surface))

if (BCol)
	{
		DestMarker->SetWorldLocation(RetCol.Location); 

		//calcul angle between up vector and normal vector 
		FVector playerVec = VRRoot->GetUpVector();
		FVector normalVec = RetCol.ImpactNormal;

		double Ajusted_adjacent = FVector::DotProduct(normalVec, playerVec) / normalVec.Size();
		float angle = acos(Ajusted_adjacent / playerVec.Size()) * 180 / PI;
		
		//activate desactivate destination maker

		FRotator ColNormRot = RetCol.ImpactNormal.Rotation();
		if ( angle < 20)
		{
			DestMarker->SetVisibility(true);
		}
		else
		{
			DestMarker->SetVisibility(false);
		}
		FRotator CorrectionRot = FRotator(90, 0, 0);
		DestMarker->SetWorldRotation(ColNormRot + CorrectionRot);
	}
	else
	{
		
		DestMarker->SetVisibility(false);
	
	}

then in my input function for the button press to teleport, i check if destination marker is visible and also i save the destination of the position of the marker before moving to prevent it from moving when i make the timer thingy.

void AVRCHAR::a_left_but_press()
{
	if (DestMarker->IsVisible())
	{
		FVector destination = DestMarker->GetComponentLocation();
		SetActorLocation(destination);
	}
}

beegeedee · December 13, 2021, 5:14pm

That’s fine if teleport is the only movement. The navmesh handles moving around via other means, i.e. walking around.

quentin_wantiez · December 13, 2021, 5:39pm

i am a vr player myself and i like having control over how i move, and so i plan to give player the choice but i have somthing in mind tu handle teleportation that might differ form the usual way first as i am not good engouth with material (i whanted the teleport marker to align with with the hit result normal but as the unreal assest used uses absolute world location maked by Z (blue) it won’t align. I triend stuff but i’m bad with material) i’m swaping for a niagara particle system for mow until i swap for the teleport mode i envisione …

i just have to make the destination maker material invisible and i’ll be set (i also whant to change particle color based on hit return normal orientation but i’ll see to it later.
by the way no need to have a navemech to walk around enven on this course you were walking around prior to implementing a navmech, character uses colision with static objects to alow it. but for ai character pathing it is indeed usefull but i’m not sure i’ll be using ai characters … i’ll see. Anyhow thanks for the reply.

beegeedee · December 13, 2021, 5:47pm

Won’t this shift the calculations onto the GPU. For devices like the quest 2, this might actually be costly.

For PC VR, it should be fine.

quentin_wantiez · December 13, 2021, 5:58pm

i guess it would but thats not a huge particle system and also … i’m still looking to find a way to get the teleporter material to align with the hit result normal … i fidled and fidled with it to no avail i know what the material does (take world position substract the item location to get the shifted world location centered on the object but as it is masked by z it hide the bottom part of the object) i would like to have the masking deppend on the normal but i can’t manage to find out how i gues i might have to use somthing else rather than absolute world position (as the object itself is aligned to the normal) but i’m still clueless about doing that.

beegeedee · December 13, 2021, 7:08pm

You’d have to have a good understanding of materials for this sort of thing. Niagara is also computationally expensive - any particle system is. This is why you’d normally avoid any kind of particle system on mobile development, and stick to simple meshes and materials. The heavier they are, the more battery drain you’ll have. For PC VR, not really too much of an issue.

Re positioning - for materials, you want to expose co-ordinates as an input and pass in the information into a material instance. As for particles, it’s about getting centred in the right place and then it should fall into place. within the system, it’ll use relative positioning based on its world position.

I’m not sure how you’d return normals to the game however to determine whether or not you can go somewhere. NavMeshes are generally the most efficient way of doing this and least costly.

quentin_wantiez · December 13, 2021, 8:19pm

as i have a vive i’m not to worried about perfs and i can still have it as a ttoggle for low end devices i’m familiar with niagara so my emmiter have local cone force a spawn and are under world gravity for the rest and as my niagara system is attached to the destination marker it will take the orientation of destination marker. i think i’ll keep them even if … nailed it ! it was much simpler than what i was doing in the first place, unreal has a handy transformvector function in material editor (invaluable value)

now i’m on with material parameters (to indicate to the player if he can tp to the location or not) witch are easy to work with … all of the hassle fo that a simple solution.
For the normal it is easy and the job is already done, the hit result give you the normal of the hitted face (i already use it to align the teleport marker to the normal see below) and now that i got rid of the material problem with normal i’ll use it only for destination marker orientation.

void AVRCHAR::UpdateTPMarker()
{
	//function variables
	FVector location;
	FHitResult normal;
	//call to function that handle the line trace and return the location vector and hitted normal vector
	bool hitsomthing = GetTPLocation(location, normal);
	//if we hit somthing
	if (hitsomthing)
	{
		//we set the tp marker location to the location we hit
		DestMarker->SetWorldLocation(location);
		//calculate angle between vr root up vector and hit normal 
		FVector playerVec = VRRoot->GetUpVector();
		FVector normalVec = normal.ImpactNormal;
		double Ajusted_adjacent = FVector::DotProduct(normalVec, playerVec) / normalVec.Size();
		float angle = acos(Ajusted_adjacent / playerVec.Size()) * 180 / PI;
		//orient marker rotation to line up with hit normal
		FRotator ColNormRot = normal.ImpactNormal.Rotation();
		if ( angle < 20)
		{
			//DestMarker->SetVisibility(true);
			//set dynamic material input_normal parameter (might remove is we use myagara particle instead)
			DestMarkerMaterial->SetVectorParameterValue("input_normal", normalVec);
		}
		else
		{
			//DestMarker->SetVisibility(false);
		}
		//correct for initial marker rotation offset (TODO: Change model of hit marker to avoid that or move to a particle system)
		FRotator CorrectionRot = FRotator(90, 0, 0);
		DestMarker->SetWorldRotation(ColNormRot + CorrectionRot);
	}
	else
	{
		//if we hit nothing turn marker invisible
		//DestMarker->SetVisibility(false);
	
	}
}

quentin_wantiez · December 13, 2021, 8:32pm

yehaaa !!! https://youtu.be/K5mXmlmJnY0 it works just as planed !!!

beegeedee · December 14, 2021, 9:11am

Nice!