Download

Hiding one section of a level from another

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.

Does the game have

  • planets or a sun,
  • 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?

Curious if anyone has ever gotten ^THIS^ working well, as no one ever follows up.
See the following from the @TheJamsh. Where’s the ‘based movement’ property…
‘Can be Base for Character’ = CanCharacterStepUpOn, or its not available in BP?

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?

1 Like

Cheers for sharing… :+1: Whenever I’ve tried to make this work in UE4 / UDK (lots of times), it works some of the time, but its not 100% reliable. A lot depends on ship speed / change of direction, and whether the character tries to jump or crouch or shoot a projectile.

The most common issue is the Character simply passes through or falls out of the ship (collision breaks down even with CCD enabled). Or the Character interrupts the acceleration / movement of ship, as if they’re blocking it (standing in front of it).

Or it works in single-player without any issues, but multiplayer clients especially break down for the reasons mentioned above. Would love to hear of a reliable working solution though, as Render-Texture window tricks while easier to do - only get you so far.

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.

1 Like

Interesting idea. Could be a drain on resources (duplicating an entire 20 vs 20 team-deathmatch ship-interior firefight), and it could be lots of added work / complexity… But have to say I like the pure out-of-the-box thinking - as you could see it working in practice. The only issue might be perceived input response time / update lag / multiplayer glitches? :thinking:

1 Like

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.

:man_facepalming: Some of what you wrote feels like unreliable assumptions tbh. So how are you testing things? Instead of keeping core ship meshes as SMC’s attached to the root, maybe you built ships using external actors or child actors that fought the collision of the root. Or maybe there’s other aspects here that you’re not telling us. But drip feeding multiplayer / replication late in the day isn’t going to help you or this thread either for sure. :stuck_out_tongue_winking_eye:

I’d recommend starting out with a ship comprised of interior and exterior mesh components inside a single BP. If you don’t want to do that and still prefer render-texture, then maybe look into UWorlds or marketplace solutions for multiple-loaded-worlds first, before committing to anything else, as Level-Streaming doesn’t feel quite right for this imo. Depending on how many players there are, you may even just be able to hide the other ship mesh using distance-culling / only-owner-see / client-side replication tweaks.

Try and create small isolated side-projects / experiments now and test each aspect to see the work that awaits, as bolting-on multiplayer later is tricky. To start you probably won’t be using the CMC for this, so you’ll have to create all the movement code manually. If the ship uses Physics for movement things will get even more complex. Personally I’d make this entirely multiplayer or just stick with single-player, as the solutions / problems you face are vastly different. Maybe start a work in progress thread to get specific feedback.

2D / 3D infinite runners are great for moving all the actors around the world. But that approach can be seriously expensive and complex in full-3D games (unless the world is very sparse or low-poly). To get an idea of how expensive, search for threads about Origin-Rebasing. But it may also lead to other problems anyway, such as visual sync issues / glitches, which will be especially noticeable at high speeds and produce lag in multiplayer. Basically attached actors move in perfect sync. But separate actors often lag. So I would drop the whole moving the world thing altogether unless Origin-Rebasing will be needed anyway (which it won’t for UE5 once source is all converted to doubles). Good luck!