FP cam collision with animated elevator ground

Questions
1

Dears,

I have a ‘noob’ game developer question around the use of colliders with the first person camera. My apologies for that :grin: :wink:

Case is simple: I have animated (from BJS) elevators and a basic first person elipsoid camera with colliders. As I can see from other posts and from a recent answer of @Deltakosh in this topic, collision with animation is currently not provided (is it or isn’t it?).

From the readings I did and this latest answer, I understand I have two options only. Either remove the animation and use moveWithCollisions or rely on intersection with an update through a beforeRender, correct?

Or is there anything else I could use? Like I noticed that when I move the camera while inside the elevator, the collision seems to occur and update (could it be or is it just a ‘feeling’?). What if I was to freeze the y.position event of the camera with a trigger when the elevator starts to move and update the y.position with a registerBefore function to match the elevation of my elevator ground? Do yours believe this could work?

In short, I’d like to understand what would be the best (simplest, less performance demanding) option for this simple ‘move with elevator’ event?
Thanks in advance for your always precious input and for sharing your invaluable expertise with me :smiley:
Meanwhile, have a great day :sunglasses:

1 Like
2

@Cedric any ideas?

3

I would try to use a physics engine (preferably ammojs).
create a sphere impostor for the camera. each frame, set the camera position inside the sphere.
Then, for the movement, apply linear velocity to the intended direction.
And elevator as a static animated impostor.
I’d be curious to see if it will suffer from jitter with the elevator ground pushing the sphere each frame.
I believe some games ‘lock’ the player in the elevator once he gets in.
Some game elevators are also fake and player respawn in other part of the level or in another level.
But I digress :slight_smile:

2 Likes
4

Thanks for taking the time, for your advise and expertise.
Yes, at first I also did think of using a physics engine but it demands quite a lot of resources (especially ammo.js) and I don’t really have another need for this physics in my scene. I want to spare as many resources as I can for everything that will be displayed and interacted with in my scene.

So, this morning I chose to first give a try at my alternate solution quickly explained above. I know, it’s not very ‘corporate’ and one could say " why ask for advise if you don’t want to follow them?" Again, my apologies for that. I certainly do value your expertise and in most cases would go with the solution provided by the experts. But here I found that my very simple alternate solution, not relying on physics and not relying on observables at all times would probably nicely do the job. And, well, I think I ended-up with a good solution for this use case.

I also had the same questionning as you stated about the potential jittering when pushing the camera (either with an imposter or a value through a beforeRender). Turns out that when I’m forcing the camera on the y.position only to match the position of my animated elevator floor, it seems to run really smoothly. I’m not sure it would be the same with a physics imposter (if I have some time, I will also check with your solution - would be nice to be able to compare, wouldn’it?).
I can also still move around and look around freely while the elevator is moving. Only thing is I cannot ‘jump’. But then, jumping inside an elevator is not recommended for safety anyways;)

So, here is what I sketched and plan to implement for all of my 5 elevators in the scene. It is also easy and simple because all elevators are already instances of ‘elevator’ and they are all sharing the same functions, logic and animations.

Scenario: When the player clicks on an elevator control panel to select a floor, the logic first checks if the doors are open or closed and, if open, closes the door before moving the elevator. This is where I run an onCollide check of the camera with the elevator floor to make sure the player is still inside the elevator when the doors are closing (because it would be possible to press a floor and next quickly run outside the elevator). On the next step, when the elevator starts to move, I already have a variable to record this state and I’m using this to run a beforeRender function pushing the camera on the y.axis alongside the position of the elevator animation. Here again, it works for all elevators at once, because they are instances and share all functions and animations. Finally, I also have an ‘after’ function triggered when the elevator reaches the destination. This is where I simply unregister the camera animation.

You can make an early check of this logic set on just one elevator and one floor. I now just need to move my function and calls to have it trigger and work for all floors and all elevators.

https://media-geneva.ch/demos/bjs/museum/museum.html

To check this behavior (at this early stage, sry for the buggy colliders, not done yet):

  1. Load the scene
  2. Press ‘2’ key to switch to the first person camera
  3. Click the 'call elevator’ button on the console for the elevator that’s in front of you
  4. Enter this elevator
  5. Select ‘hall’ level (this is where the function is currently implemented for testing)
  6. You can open the console and alongside of a ton of logs my small brain needed to understand my elevator state and behavior, you can notice when the function for moving the camera up is registered and when the function for checking the onCollide is register
  7. When at destination, notice that both have been unregistered/removed.

Hope you don’t mind me having found this alternate solution (for once I do have an alternate that seems to work… sort of :wink:

Well, thanks again and if I get the chance to try the version with physics, I’ll let you know.
Meanwhile, have a great day :sunglasses:

Edit: Also thanks to @RaananW for debugging my camera.onCollide removal of event.
Edit2: I clicked @Cedric as a solution (although I will likely use my alternate solution) simply because I do believe it is a solution.

1 Like