is it possible to light an overlay scene with the lighting from the main scene?

just wondering if this is possible without having to recreate/duplicate the entire level’s lighting and collision objects onto the overlay scene.
if so how?

thanks

Not as far as I know. The scenes are completely independent from each other.

Why would you need that?

Just trying to get a fps system working were your hands+gun doesn’t go through the wall when your up close to it. It would also mean that one scene (overlay) could have higher resolutions (guns and arms) without lagging the rest of the scene. I guess i could also animate the arms to hold the gun up against the wall but since i’ve been seeing people using LOD using a high and low res scene, i thought this idea might work.
thanks for the reply

I’ve been wondering about the same thing since overlay scene is the closest alternative to “render layers” as far as I understand. I’ve never done an FPS in BGE but I wonder if you could evaluate and transfer values for kind of mockup lighting. Overlay scene could have 2 hemis and you control light color and intensity or perhaps even rotate them.

Every first person view game that has view models uses this technique to stop clipping and also to have a different fov from the scene camera. Sadly it was possible a little while ago but stupidly someone reported this as a bug, the sharing of lighting across scenes. if the material was linked across scenes the lighting was copied from the first scene, this however I no longer think is possible as it was fixed as a bug if I remember rightly.

At the most basic level, you can transfer lighting between scenes by linking the lamps in the main scene to the overlay, that means that whatever lighting changes you do to the main scene will also occur in the overlay as it also has a reference to those objects.

Also, one of the primary reasons that the light sharing was regarded as a bug is because it messed with people’s GUI setups (ie. you have a GUI in another scene and you might want completely separate lighting for it), but I don’t see why one couldn’t have an option in the scene actuator to not restrict the lights to only the scene they are in.

This is what i was first thinking of doing originally however then you would have to set up player movement on the overlay scene as well as on the primary scene to ensure that you would get the correct lighting depending on which part of the map you are in.
On top of this you have the problem of a player constantly running into a wall:

the primary layer shows the character not moving but in the overlay scene the player continues to walk away from the light sources mucking up the whole system.

This means you would have to add an additional collision boxes/boundaries around the overlay “map” as well as the primary map meaning that the performance of your computer would be worse as it would have to calculate collisions for both layers (correct me if i’m wrong).

the primary layer shows the character not moving but in the overlay scene the player continues to walk away from the light sources mucking up the whole system.

This means you would have to add an additional collision boxes/boundaries around the overlay “map” as well as the primary map meaning that the performance of your computer would be worse as it would have to calculate collisions for both layers (correct me if i’m wrong).

You can just send the player xyz position and orientation to the overlay scene, no need to setup any collision or input.

Well I might be missing something but why don’t you just put your hands inside collision boundary of the player, so nothing can go throught them?

Exactly!

There is really no reason to let a player stand that close to a wall.
(It would hurt the avatar and you need to call the ambulance :evilgrin:.)

In practice it’s not feasible to make the player collider big enough to fit in larger weapons such as assault rifles with standard barrels. Player collider needs to be round in Z-axis so turning won’t cause colliding. This would result in huge need of space for player walkable space and two players couldn’t pass each other until the corridors were very wide.

This indeed would apply if the collision bounds are static and symmetric.
Dependent on the type of things to carry the collision hull can change. So there is a difference if the avatar carries nothing or a long pole.

Dynamic collision hulls are often discussed when it comes to crouching.

Nevertheless it makes a lot of sense that large objects interact with the environment. So it is somehow more plausible if the avatar can’t hide behind a wall if he carries a large device in front of him ;).

This is downright bad advice. You have to be able to look at the matter: BGE doesn’t offer good tools at the moment to FPS view model problem. But you don’t try to get around that with flipping your technical design around just because of that.

I’m going to say once more that in practice when talking about FPS multiplayer games, to have a dynamic collision with your weapon view model is going to be difficult to implement and also to translate into world of pain when you play.

Technically:

  • A player waving a physics object around is going to mean physics forces, torque and impulses to the game world resulting in more difficult interaction that needs to be synced with server.
  • Players switching weapons and dropping them would be complex physics situations. What would happen if you walk to a wall/narrow corridor empty handed and then equip a sniper rifle?

Gameplay:

  • What should happen if player tries to turn and gun physbox gets stuck somewhere? Drop the weapon, prevent movement?
  • Player would also be able to use his weapon barrel for a baseball bat effect. Adjust your mouse sensitivity (that has practically no upper limit) to result in infinitely fast spinning baseball bat that causes infinite physics damage and kills everything if it doesn’t break network functions first.
  • You try to navigate corridor and your weapon keeps bumping to every wall and corner as you turn and look around.
    = In multiplayer FPS: world of frustration even if it did work as intended without bugs

This is just absurd. Not everything that is technically possible or makes sense in realism point of view will translate into better gameplay or should be implemented.

I do not see any absurdity in this thoughts.

What you describe is the behavior I would expect as a player (getting stuck if the way is to small). Isn’t that what makes the difference to switch items? So you can be faster with empty hands and fit through smaller passages.

Yes, for simplicity of the game design this can and in most cases will be ignored.