Currently working on a proof-of-concept of a space game. The game involves a spaceship with an interior, and an exterior that the ship “flies around” in.
To solve the issue of having to move a bunch of actors with the interior, we’ve made the interior static. The exterior of the ship then has a scene capture that renders as a window in the interior. This scene-capture (the “exterior ship”) can then fly around freely without worry about the interiors.
Some of you might have already figured out my issue. The exterior ship can “see” the interior. Both exist in the same world, so it is just there. We are in space so there is no real good place to hide it either and I’d rather avoid that if possible.
So what I want to accomplish is to hide the interior from the exterior camera. Even better if it’s possible to in some way have them in entirely different… areas? So that there is no risk of the interior flying through the exterior.
I’ve tried using HideActorComponents on the camera, and simply put every single actor from the interior ship in that list. There are some problems with this, however. Like every single object having to inherit the same interface (which is impossible for things like brushes as far as I know). Tried just getting every actor and just adding those within a range but found issues with some classes not getting picked up (brushes, again).
Searching around, level-streaming is sometimes suggested to hide part of a level, however, that won’t work here as both must be loaded at the same time.
With all the background out of the way, what I want to achieve is:
Hide the interior of the ship from the exterior
An easy way the declare an area as “interior” (perhaps a volume) so that every actor in that area is hidden.
Wishful thinking:
Make the area entirely separate, almost as if it is on its own level.
any other stationary objects that are not moving ships
an area outside of traversible space that no ship will ever enter?
Put the interior in there. The area doesn’t have to be big since the interior doesn’t have to match the exterior scale. If you disable shadow casting for the thing you hide the interior in, the interior will receive shadows and lighting just as if it wasn’t hidden inside another object.
As it stands, given that we are mostly just testing out concepts and seeing what can and can’t be done… no. There isin’t really a good place to hide it, and while we could probably declare an area out of bounds it is something we’d rather avoid. So yes, if there is no alternative that is probably what we’d do to solve it.
But I’m looking around to see if there is any other solution to the problem hidden in the depth of the engine, as it were.
Okay, since you’re still in the prototyping phase, what made you decide to not move the interior around with the ships? Why not have the interior be attached to the exterior and call it a day?
I’m a bit confused here. Are you saying that both needs to be persistent?
Calling it level streaming is a bit deceiving as in some 3d applications it’s referred to as X-ref. Technically speaking both interior and exterior are children of the persistent level so you have this
Wishful thinking: Make the area entirely separate, almost as if it is on its own level.
You can then change viability behaviour by changing the Level to always loaded or by blueprint.
Level streaming can also be used for progressive loading so would be your means of creating a volume of assets to turn on and off visibility as a group.
CanBeBaseForCharacter is a virtual function defined on the Actor base class that returns true if the character can walk on it. It’s not exposed to Blueprint, but that’s not really a problem since it defaults to true. That means it’ll be true for every actor unless you specifically override it. CanCharacterStepUpOn is the equivalent for components. If it’s true, the character can walk on it.
Will your space ships move freely in 3D space and will characters be inside during that time? in that case you need to take some care to stop the character movement component doing its thing. Also, if you plan on having AI characters, do note that Unreal Engine’s navmesh implementation only supports Z-up.
Still, with the little I know about you overall project goals it seems to me that my suggestion above is the easiest and most straight forward solution. Are you still gathering ideas or have you tried anything?
I would suggest using the tag system. Tag everything that’s part of the interior, then in Blueprint, add all items with that tag to HideActorComponents
Random idea:
Why not simulate the character in a separate static interior, then copy that animation to a character inside the ship? The character inside the ship is what the player sees, but the character in the static interior is what the player controls. That way, the movement of the ship won’t affect the movement of the character. Plus, since the interior the player sees is in the actual ship, there is no need for scene capture tricks.
So the reason the ship is static, is to be able to make easier use of features already in unreal. For example, if the ship is moving it has to be one big actor (or have code that moves every single actor in the ship with it) making designing it more cumbersome. The child actor system in unreal is uh, not great in my experience. It also makes network replication (I guess I forgot to mention the coop aspect) a whole bunch more annoying and having to deal with each player moving relative to ship.
An alternative would be to skip the external ship, and just move the world relative to the ship. Of course that results in its own set of problems. But I’m considering it as well. That Does give the advantage of being able to move in a near-infinite level, but it means all movement for everything else in the world has to be calculated constantly and I’m not sure how I’d handle physics (for effects, movement can’t be physics based because that also makes network replcation a nightmare).
So the solutions can be summed up as:
Move everything, lose a lot of unreal engine map building tools in building the ship, complex player movement + replication
Move the world, less replication issues, more complex actor behaviours.
Move an external “fake” ship, problems having to hide the ship, needs a good fake window effect (solved, capture2d moving relative to player)
I deemed the last point had the least amount of problems to overcome, since it’s only hiding the interior left that I actually have to do. I may try the second solution (moving the world), I just need to come up with a clever way to make everything just inherit the relative-movement ability and figure out how best to move that many actors in a frame.
This part doesn’t sound right to me. The ship doesn’t have to be one big actor, it can easily be an actor with a bunch of actors attached to it. I also don’t see how this is cumbersome. Just spawn the actors, attach them to the exterior actor’s root component and you’re done. Wherever the parent moves, the child moves.
I don’t know the first thing about multiplayer, so I can’t say how difficult replication is. I trust your judgement on this.
I feel that if you want us to provide really meaningful help, you need to tell us more about your idea of what the game is supposed to be. “Forgetting” to mention coop is kind of a biggie because multiplayer makes everything more difficult (I guess I know that much…). Like, things that I would want to know:
Is it MP or not?
How many players in the same level at any given time?
Will there be AI-controlled characters?
How many ships are there? Is it just one (it kinda sounded like it) ore more?
How large are the ships? Is it a couple thousand verts ore more in the neighborhood of a hundred thousand and more?
How many moving parts does a ship have? Can it be equipped with different loadouts?
Can players leave the ship?
What’s the navigational model for the ship like? Left-right, up-down, or full 6-DOF movement?
What happens in space around the ship(s)? Are there planets, asteroids, fancy stuff going on?
Each of the solutions you mentioned might be the right one going forward, but I don’t think we can help you to figure out which it should be with what we know at this time.
So I realized that you would also need to sync the sun and any other lights that cast into the interior whenever the ship moves & rotates, as well as any objects outside the ship that cast shadows inside the ship (ex. another ship, rocks, or debris). I then realized that the ship also can cast shadows onto other objects outside the ship (can be seen at the beginning of the video). Taking this into account, it would be simple just to have the character in the ship, that way, everything works naturally. So I tested my idea.
Looks good so far. The only problem is the camera can be kinda janky sometimes, but the ship is small, so that may be it.
Notes:
The player’s pawn is still the character, and the ship is an actor with a skeletal mesh and camera, and the view target is set to the ship. The character and interior is under the level.
The ship has the character as a prerequisite tick actor (the character always ticks before the ship) so that the character’s transform & variables are up-to-date when the ship reads it.
The ship’s skeletal mesh has its own animation blueprint; it’s the exact same as the character blueprint, just that the “Get Owning Pawn” is replaced with “Get Player Character.” This is actually necessary because the character’s skeletal mesh animation stops updating when far away, so copying the pose can cause the ship’s skeletal mesh to stop animating.
The only things that are being copied are the character’s skeletal mesh transform, the camera’s transform, and any variables the animation blueprint needs (which is just velocity and “Is Falling”).
Haven’t tested this in multiplayer yet, but it’s a good start.
Edit: The interior can be hidden by setting “visible” to false or “hidden in game” to true; the character still simulates even when not visible. You can use collision channels to keep the interior and exterior physics from affecting each other. The interior should be put at (0,0,0) so that the character’s world space position is also its ship space position.