Camera Collision [take 2]

Lumberyard Discussion Physics
#1

I’ve followed the instructions here trying to get camera collision to work. This process doesn’t work correctly at all. I’ve also tried to implement the desired functionality with a number of different variations of the linked instructions. Some of the issues are as follows:

  1. Don’t get collisions between the camera and any object with ‘Static Physics’.
  2. Don’t get collisions between the camera and any object with a ‘Mesh Collider’ if that mesh is a surface (i.e. it isn’t a mesh which encloses a volume, e.g. a plane)
  3. Using a lower-level functionality, e.g. PhysicsSystemRequestBus.GatherPhysicalEntitiesAroundPoint also has the above issues.
  4. Setting custom gravity for an object with ‘Character Physics’ only works until you ‘Set’ any of the properties of the object with the PhysicsComponentRequestBus.
  5. If instead of setting the camera world transform (as is done in all of the scripts in StarterGame) the camera is given an impulse which would take it to the desired location in one tick, the controller breaks entirely - camera only moves up+down while in the air; only when it’s on a surface does the left/right/forward/back impulse work.
  6. Acceleration according to PhysicsComponentRequestBus is always 0 even when object is under the influence of gravity and is clearly accelerating.
    I’ve looked at how this is accomplished in the StarterGame. It seems to use some horrible hack based on raycasting (which doesn’t even work - if you stand beside a wall on the left, the camera is pushed out of the wall; on the right, it is not). Using raycasting to accomplish this is not an unacceptable solution, both performance-wise and in terms of the maintainability of the logic.

The collision system is the preferred way to implement this. To be specific, I would like an entity

  • which collides as a ball,
  • is not affected by gravity,
  • has very high ‘friction’ even when not in contact with anything, and this friction is not affected by the type of surface with which the entity is in contact,
  • receives a forward velocity (i.e. is not simply ‘teleported’ to the target location as SetWorldTm does) when pressing a specific key
    Each of these requirements is easy to implement separately. However, I haven’t been able to implement them all together due to the issues described above.

To summarize: Is there a complete example anywhere of camera collision without raycasting? Or an example of e.g. a spaceship or some other vehicle whose locomotion is implemented with scripting, which collides with its environment as a rigid body? Did the linked instructions never work or were they broken by some update since their posting? Is it just me or is the physics system generally very broken?

#2

Have you tried the PhysX gem, yet?

I have not - I’ll give it a go when I have a chance.

Am I correct in assuming that this gem only works with NVIDIA GPUs? Or will it run on the CPU for non-NVIDIA cards?

We are still building out this system on the lumberyard side, but PhysX should provide all the functionality you desire

It’s good to know that the system is coming; for the time being, it is probably cost-prohibitive to work on this system as we’d almost certainly be implementing functionality which will eventually be written by the LY team.

Am I correct in assuming that this gem is intended to replace CryEngine physics?

Could you describe what you mean by ‘very high friction’ in more detail?

This is a trivial issue compared to the bugs I’ve encountered. The behaviour should be that the object slows down in the absence of any input making it move. When moving an object by setting its transform this isn’t an issue; when doing so by setting the velocity, in the absence of this effect, the object would accelerate indefinitely.

This can be implemented roughly by e.g. multiplying the speed by a number less between 0 and 1 on every tick (the closer to 0, the higher the ‘friction’). I write ‘friction’ in quotes because this isn’t really friction (the object is not necessarily in contact with anything) - maybe a better term is ‘braking’ or something like that.

It sounds like you have tried several variations and gotten part of the way there in each case.

Exactly right.

You can move static objects easily and they will not fall in gravity, but generally, they won’t trigger any collision responses

Indeed, I’ve discovered this since writing the OP through a combination of trial and error and reading the source code.

what type of physics object are you attaching to the camera?

I’ve tried:

Static Physics: Responds to collisions, but not with other static objects, and you can’t give it a velocity.

Character Physics + Custom gravity: Breaks as described in the OP.

Rigid Body Physics + Collision response enabled: Can’t set the gravity, but the object must not fall (and the values returned by GetAcceleration are bogus).

Rigid Body Physics + Collision response disabled: Works pretty well, but receiving OnCollision events is unreliable - the events will often be on the other side of the object with which the camera collided, and the collision normal will be pointed the opposite direction as you expect.

#3

Hi @yuriy000,

Have you tried the PhysX gem, yet? We are still building out this system on the lumberyard side, but PhysX should provide all the functionality you desire (for example, this is how PhysX handles your gravity issue, and we plan to make all of this accessible through LY), though it may require some additional code work until we finish building the system out.

Could you describe what you mean by ‘very high friction’ in more detail? The other issues are definitely common problems and should be resolvable. We haven’t put together many examples with the PhysX system yet, though we will be adding more features rapidly through the next couple releases and want to make everything you are talking about straightforward and clear!

For your current Cry implementation work, what type of physics object are you attaching to the camera? You can move static objects easily and they will not fall in gravity, but generally, they won’t trigger any collision responses. It sounds like you have tried several variations and gotten part of the way there in each case.

#4

Hi @yuriy000,

  1. Actually, it should work in general. PhysX can run in a variety of modes, but in general, most physics computations are done on the CPU, so the GPU doesn’t matter in most cases. Even still, although it is undoubtedly optimized for NVidia cards, if hardware mode is enabled (GPU mode) there are ways PhysX can run on other cards, and if it can’t, it will default to CPU.

  2. Yes, the goal is to replace CryPhysics entirely. PhysX provides many powerful tools and the Lumberyard team really wants to provide those as soon as we can.

  3. Yep, that’s a classic solution (and isn’t a bad idea). As you noted, generally friction refers to contact with a surface, and should vary. ‘Air resistance’ maybe? If you really want to be physically based, you could even have the resistance increase at higher velocities.

  4. Looks like you’ve been trying a lot. I don’t believe gravity control for single objects has been exposed in any way through Cry, but just off the top of my head, a quick (and dirty) solution could be to apply an opposite force (velocity in this case) to the camera to cancel it out. Yeah… I completely understand how you might feel about this!

Let me know if these answers help!

#5

Hi @Chronos, about PhysX gonna replace current default physic, I got this code

EBUS_EVENT_ID(m_PlayerComponentID, AzFramework::PhysicsComponentRequestBus, SetVelocity, m_vPlayerVelocity*10.0f);

Do I need to update this kind of code in the future when PhysX is the official physic for Ly?

Thanks.

#6

Thanks for your help. I’ll revisit this at a later date when the PhysX system is fully integrated.