Hi, so I have these pick-up items that also simulate physics, in the game.
To pick them up, I’m using a line trace from the player camera. When it hits one of these pick-ups, it checks if the hit component (or one of its children) implements an “interact” interface. If yes, then it can be picked up.
In the pick-up actor, I’m using a box collision to simulate physics and to get hit by the player line trace; and a static mesh that implements the “interact” interface, with collision disabled (so no physics).
My question is, which of these components should be a child of the other? Do any of them need to be set as root, or should I just leave the default scene as the root?
What’s the proper hierarchy for physics to work properly?
Is there any official documentation related?
Both Actors use a scene component as Root. This allows you to manipulate the location and rotation of child components within the actor.
e.g. rotating the gun to lay flat as if on the ground.
An Actor is any object that can be placed into a Level, such as a camera, Static Mesh, or player start location. Actors support 3D transformations such as translation, rotation, and scaling. They can be created (spawned) and destroyed through gameplay code (C++ or Blueprints).
A Component is a piece of functionality that can be added to an Actor. Unlike Actors, Components can’t exist by themselves. They must be attached to an Actor. When adding Components to an Actor, you are putting together the bits and pieces that make up that Actor as a whole.
A Scene Component is an Actor Component that exists at a specific physical position in the world. This position is defined by a transform, containing the location, rotation, and scale of the Component.
Scene Components have the ability to form trees by attaching to each other, and Actors can designate a single Scene Component as “root”, meaning that the Actor’s world location, rotation, and scale are drawn from that Component.
I was trying to avoid using physics on the mesh because I read it’s more expensive and less accurate than a collision component. Is that true?
Also, if you have physics on the mesh, then what’s the point of the collision component?
I should mention by items will always simulate physics. It think you mentioned yours go to “sleep”?
Performance gains in Collision Component vs Mesh physics comes from the simplicity in geometry of the collision component. It’s a primitive shape collision. Static meshes tend to have more complex collisions (custom imported UCX) or multiple primitive shape collisions.
Physics uses collision hulls. Without collision physics will not be applied. Think of it as though physics is moving the mesh collision, then snapping the mesh to the new location/rotation.
All collision hulls of the component which physics is being applied have to be analyzed each sub-step. So more complex collisions cost more per sub-step.
The overall complexity of the actor or component chain also has an affect on performance. When you move an actor/component all child components are moved as well. Every sub-step Set Location and Rotation is called on the chained child components.
Using my PropActor hierarchy physics is moving the mesh, then calling Set Location and Rotation on the Interactive collision. Every component that is a child of the mesh would be moved in this fashion.
In this setup you want the “Visual Element” (mesh) to be the component that physics moves. World interaction would look weird if you used another collision vs the actual meshes.
e.g. imagine a sphere collision for the interactive. I do use sphere/capsule for some items because they work better in certain scenarios. But they tend to roll and the mesh would float above ground.
The Collision component is dedicated to strictly interaction. It only uses the Visibility channel, All others are ignored. It also uses a custom preset to differentiate itself from all other collisions that block visibility… which is 99.9999% of all collisions.
Thanks, so it seems, in my case, I might as well ditch the collision component and just use the mesh for both physics and interaction, because my items always simulate physics and their only functionality is to be destroyed when added to an inventory.
You mentioned high speed projectiles though.
In that case physics is being applied to the collision component (which is root), right? Not to the mesh?
Overall performance wise you are in fact extremely better off going with the process I outlined with the two actors. Especially in multiplayer. This is discussed in the message video I sent you.
Projectiles (PMC) does not use physics. It uses sub-step sweeping on the root, then set location & rotation on the child components.
The FirstPerson Template provides a base projectile. Its component structure is the proper way as noted in my other posts. Essentially Epic Games themselves says this is the way to do them.
Run a 2 player test. Have player 1 pick up a gun and have it equipped (in hand). Then have player 2 walk over and interact with player 1’s gun.
If you do not use a collision component for interaction then your mesh collision will trigger interaction. Only way around this is to modify the collision settings on the mesh after it is added to inventory. Then change it back when you drop it.
Other side of this is the memory (RAM) requirements when using a single actor for both ground loot and the active item.
PropActors are low data simplistic.
RealActors are the fully functioning actors like weapons. They have visual presence via skeletal mesh, and there are other components. Niagara Particle component (muzzle flash), Audio component (shot sound), camera component (for ADS), potentially a point light (muzzle flash light effect). Then there’s all the code for firing, reloading, toggling fire mode. Animation blueprint etc.
Lets say each PropActor instance requires 100KB of memory and RealActor requires 1MB per instance.
These are just simplistic values for argument sake. Real numbers would look at the SK mesh (2,230KB) and the Static mesh (512KB) along with code, variables etc. So closer to 600 vs 3000 per.
On large maps where you have a lot of these items it adds up very quickly. Less resources for anything else.
