VR Expansion Plugin

[J.C. Smith]

[MENTION=24338]Mord[/MENTION]entral: Win64 Shipping. It should also be noted that I'm using an older version, the version right before the split of the Steam and NoSteam version of the plugin, haven't upgraded yet as this project is already a ways in. So this may be a non-issue on the current build. And on the build I was using it was only an issue when trying to compile as Shipping. I'm primarily adding the info to help anyone else who runs into that problem.

The main thing that was odd about it is that it compiled fine in Development Editor. Compiling it as Shipping or as Development (without Editor) I got the errors I posted in the original post. And then afterwards I noticed they were what looked like linker issues and FORCED INLINE.

[mordentral]

Hi mordentral! Awesome Plugin! But I found a small problem, DestroyPhysicsHandle - do not destroy phys completely! Still continues to be called an overlap event for this Phys Copy. It looks strange, but it is noticeable only in InteractiveHybridCollisionWithSweep, when first SetUpPhysicsHandle, then DestroyPhysicsHandle all overlaps event for this Grip Start duplicating for a physical copy and for non physical copy! This is clearly seen if we use OnComponentBeginOverlap.AddDynamic() for Grip Actor. In this Event(OnComponentBeginOverlap) A lot of copies are beginning to come(As if we have many identical objects)... This begins to happen when After the installation of physics we try to destroy it in DestroyPhysicsHandle .. Before this DestroyPhysicsHandle is all okey

You don't have any replication steps do you? I can't duplicate this or the continued rotation after destroying. I ran a break point and the destroying function never fails during hybrid and I am not getting duplicate overlaps, just the normal character intersection overlap spam that the engine throws.

[mordentral]

[MENTION=24338]Mord[/MENTION]entral: Win64 Shipping. It should also be noted that I'm using an older version, the version right before the split of the Steam and NoSteam version of the plugin, haven't upgraded yet as this project is already a ways in. So this may be a non-issue on the current build. And on the build I was using it was only an issue when trying to compile as Shipping. I'm primarily adding the info to help anyone else who runs into that problem.

The main thing that was odd about it is that it compiled fine in Development Editor. Compiling it as Shipping or as Development (without Editor) I got the errors I posted in the original post. And then afterwards I noticed they were what looked like linker issues and FORCED INLINE.

Can you PM or link in here the compilation warnings if you add forced inline back in? I didn't have shipping issues in previous versions either, but if its system specific I may need to inline them instead of FORCEINLINE to give the compiler a choice.

[anadre]

You don't have any replication steps do you? I can't duplicate this or the continued rotation after destroying. I ran a break point and the destroying function never fails during hybrid and I am not getting duplicate overlaps, just the normal character intersection overlap spam that the engine throws.

I tested this only in full Authority mode
I get an Overlaping, but not for actor himself(gripped Actor->RootComponent), but for the child to this RootComponent(for AGrippableStaticMeshActor Root is UStaticMeshComponent) I create a simple UBoxComponent(Attach for RootComponent(UStaticMeshComponent)) and set for this component OnBeginOverlap function( I try to overlap UCapsuleComponent) . This is only noticeable if you use VR controller, rather than keyboard simulation of hand, Since here it is important to move apart and a slight turn(the motion controller's hand is always slightly rotated when moved). You get a lot of intersections, even when the object is already Overlaped.. All intersection objects are valid and true, but it creates the feeling that there are many copies of the object In slightly different places, very closely spaced copies

void UVRMotionController::WeaponHitEvent(UPrimitiveComponent* OverlappedComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult)
{

	if (OtherActor && OtherComp) 
	{
		if(OtherActor->IsA(AEnemyCharacterBase::StaticClass())) 
		{
                       So Many Overlapp here, even we Already overlapped
.....

for this func:

UPrimitiveComponent* OverlappedComp = UBoxComponent - child for UStaticMeshComponent -> owner = AGrippableStaticMeshActor (Grip Actor)
UPrimitiveComponent* OtherComp = UCapsuleComponent(enemy)

I'm using the child(UBoxComponent ) element(not Root), because I need different type of intersections(different parts of the Actor)
and for different type of enemy component
I moved forward in solving this problem, the fault was setSimPhys(false for default -> set true(when colliding) - then false = Here the problems begin, before this first "true-false" all are okey!), not for u functions DestroyPhysicsHandle

[anadre]

Wow, i finally Solved the problem. The problem is actually very important, who will use many components of the collision and switching Phys Simulating

1)When we use SetSimPhys(true) for Root Component in BodyInsrance.cpp

void FBodyInstance::SetInstanceSimulatePhysics(bool bSimulate, bool bMaintainPhysicsBlending)
{
.....
// If we are enabling simulation, and we are the root body of our component, we detach the component 
		if (OwnerComponentInst && OwnerComponentInst->IsRegistered() && OwnerComponentInst->GetBodyInstance() == this)
		{
			if (OwnerComponentInst->GetAttachParent())
			{
				OwnerComponentInst->DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
			}
			
			if (bSimulatePhysics == false)	//if we're switching from kinematic to simulated
			{
				ApplyWeldOnChildren();  //THISS !!!
			}
		}

void FBodyInstance::ApplyWeldOnChildren()
{
.... Browse all the children
const ECollisionEnabled::Type ChildCollision = ChildBI->GetCollisionEnabled();
				if(ChildCollision == ECollisionEnabled::PhysicsOnly || ChildCollision == ECollisionEnabled::QueryAndPhysics)
				{
					if(UPrimitiveComponent* PrimOwnerComponent = ChildBI->OwnerComponent.Get())
					{
						Weld(ChildBI, PrimOwnerComponent->GetSocketTransform(ChildrenLabels[ChildIdx]));
					}
				}

2)And If U use ChildCollision == ECollisionEnabled::PhysicsOnly || ChildCollision == ECollisionEnabled::QueryAndPhysics type collision of u childComponent
This function makes all child bodies => IsValidBodyInstance() = false(kill our PxRigidActor)

3)This creates major problems in the Overlap Events for this child Component

4)To solve this problem need to set the ChildComponent->BodyInstance.SetCollisionEnabled(ECollisionEnabled::NoCollision, true);
For all Child who used ECollisionEnabled::PhysicsOnly Or ECollisionEnabled::QueryAndPhysics
Before SetSimPhys(true) On RootComponent in InteractiveHybridCollisionWithSweep type, or maybe From other places Where you want to enable Root simulation Or we cant use OnComponentBeginOverlapp for child Component normally

5)When we again SetSimPhys(false) on Root Component You need to return the old collision settings
ChildComponent->BodyInstance.SetCollisionEnabled(ECollisionEnabled::QueryAndPhysics, true); For all child Component Who had it before

[mordentral]

Oh so you are talking about attached children to a simulating component throwing bad overlap events?

I gather that you are talking about turning off collision on all sub components prior to simulation, something that I don't think I should do by default in the plugin as it may break intended behavior for other users.
What you are talking about is how the engine behaves in general, you are getting overlaps between children components when simulation is active correct?

I'm sorry your english is a little rough, its been hard to read over your posts, but I really do appreciate detailed feedback.

[anadre]

Oh so you are talking about attached children to a simulating component throwing bad overlap events?

I gather that you are talking about turning off collision on all sub components prior to simulation, something that I don't think I should do by default in the plugin as it may break intended behavior for other users.
What you are talking about is how the engine behaves in general, you are getting overlaps between children components when simulation is active correct?

I'm sorry your english is a little rough, its been hard to read over your posts, but I really do appreciate detailed feedback.

Yes, my English is not very good. But i try to explain. I Want to say When set RootComponent->SetSimPhys(true) All Child of this RootComponent get IsValidBodyInstance() = false(invalid bodies) becose all child bodies Are welding to the root and this make Trouble in the definition of a collision Event These children Component when we turn off SetSimPhys .
I agree that it maybe not be inserted into the plugin, but as a special case, it is possible for someone to use it.
I found another way to overcome this, just when we turn off RootComponent->SetSimPhys(false) use:

 
For all children ->

FBodyInstance *NewRootBI = &ChildOfRootComponent->BodyInstance;
//create new root
root->BodyInstance.UnWeld(NewRootBI);	//don't bother fixing up shapes if RootComponent is about to be deleted
			
NewRootBI->bWelded = false;
FPlatformAtomics::InterlockedExchangePtr((void**)&NewRootBI->WeldParent, nullptr);

bool bHasBodySetup = ChildOfRootComponent->GetBodySetup() != nullptr;

//if BodyInstance hasn't already been created we need to initialize it
if (bHasBodySetup && NewRootBI->IsValidBodyInstance() == false)
{
  bool bPrevAutoWeld = NewRootBI->bAutoWeld;
  NewRootBI->bAutoWeld = false;
  NewRootBI->InitBody(ChildOfRootComponent->GetBodySetup(), ChildOfRootComponent->GetComponentToWorld(), ChildOfRootComponent,
  GetWorld()->GetPhysicsScene());

  NewRootBI->bAutoWeld = bPrevAutoWeld;
}

Just Unweld and Init Body Again
We CANT use ChildOfRootComponent->UnWeldFromParent();
Because NewRootBI->bWelded always = false, and UnWeldFromParent() not worked ...it is bug or not.. but bWelded dont set = true when welding component in SetSimPhys
may be i report this problem(bWelded and UnWeldFromParent()) later

[Starkium]

I've got the most recent copy of this built and working in your example project, but I migrated it all to my project and I get this. What am I missing?

[VirtualLilies]

Some time ago I could easily build the template project, after downloading today though, there's no way I can actually get the template run in any scenario.

[mordentral]

I've got the most recent copy of this built and working in your example project, but I migrated it all to my project and I get this. What am I missing?

I have another plugin of mine that I packaged into the template to handle voice and sessions. You will have to delete the voice nodes on the character to get it compiled without that plugin.

Some time ago I could easily build the template project, after downloading today though, there's no way I can actually get the template run in any scenario.

Spoke with him on Discord, was using wrong engine version

[VirtualLilies]

Just to confirm, template project does compile only on 4.15.

[Starkium]

Thanks, just out of curiosity how easy would this be to slap into a project originally meant for an fps? Also I found the plugin and added it to my own project. Is that ok or is that not open source?

[mordentral]

Thanks, just out of curiosity how easy would this be to slap into a project originally meant for an fps? Also I found the plugin and added it to my own project. Is that ok or is that not open source?

Both plugins are under MIT, its fine.

Also adding it to a FPS wouldn't be that difficult, you would just have to handle AI, UI, and level layouts that may need tweaking for VR. And pacing of course.

[Starkium]

Thanks! Pacing isn't a concern. I'll dial back if I have too, but I'm throwing the player to the wolves as far as difficulty. I"m trying to merge this project with the multiplayer survival game template.

The bit with the server work you've got hooked up in here. Is that as optimized as you can get it? It's fairly sluggish. What might I need to add to an existing multiplayer system for it to be optimal for vr?

[mordentral]

Thanks! Pacing isn't a concern. I'll dial back if I have too, but I'm throwing the player to the wolves as far as difficulty. I"m trying to merge this project with the multiplayer survival game template.

The bit with the server work you've got hooked up in here. Is that as optimized as you can get it? It's fairly sluggish. What might I need to add to an existing multiplayer system for it to be optimal for vr?

You mean server finding? If you are testing it in LAN it is using a lan beacon which is slow to find servers, steam is faster to search generally.

That being said steam waits for all servers to return before displaying results, most companies start filling in lists as each chunk arrives instead, but its not my code, its epics subsystem backend handling it, I just interface with it.


Or did you mean something else?