Local Field Volume

Greetings Community,

The video above very briefly shows what Local Field Volume is about. The left platform is contains no LFV, while the right one has an LFV and manages to keep the objects on it. You can also see that the character behavior is different on both platforms.

The short way to explain it is that it is a volume that tries to simulate the feeling of being inside another instance or level with local reference grid. The ball bouncing inside that volume should behave exactly like it would be bouncing on a flat immovable surface, independent of the volume movement.

This was initially supposed to be a marketplace submission but I changed my mind due to following reasons:

  • It needs a very specific PhysX substepping setup on project to work
  • I am a bit of a perfectionist and found some of the implementation a bit unsatisfactory for some marginal cases, therefore I did not consider fair to charge for it
  • I would like to contribute something to the community
  • It might serve as a semi-decent portfolio item

So please give it a shot and feel free to use it in your projects or as a learning material. I’ll be happy to answer any questions you might have.
[HR][/HR]
THIS SPACE WILL CONTAIN SOME INSTRUCTIONS AND TECHNICAL DESCRIPTION SOON
[HR][/HR]
DOWNLOAD LINK
[HR][/HR]

1 Like

YES! This looks like exactly what I’m looking for!!!

Feel free to add me to Skype (Skype logo under my avatar on the left) so I can provide some support if needed. I’m glad it is useful

Yeah this is awesome, can’t wait to try it.

Hey @Irakli - So is this basically the local physics grid system from Star Citizen?

If so how well does your system handle rotations and such with multiple players or characters? (Example: Troop Transport or Frigate)

Video for demonstration on what I mean -

Lastly does this work well in a multiplayer environment?

Its funny you mentioned Star Citizen’s local Physics grid, because it was the actual inspiration for this project. yes I was aiming to create something of that nature, and right now it does not handle rotation, only location change. I tried to implement this system without instantiating another physics volume/instance, which is what Star Citizen does and it results in a big performance hit. The idea was to track rotation and location changes from previous frame and apply them to the tracked objects (there is also an option to track velocity change instead of location and apply that, it is not very effective).

This had several problems:

  1. You need to setup sub-stepping with maximum sub-step time less then 0.01, otherwise the objects seem stuck/laggy
  2. When the volume is attached to a Physics simulating platform that is sliding on the floor and you place a cube on top of the platform, the result is weird. This is because the cube stays on top of platform due to its frictional interaction with platform. When the volume applies additional offset to the cube, it looks like the cube is sliding on top of platform for no reason. Do the same exercise with a sphere though, and it looks natural, because the platform-to-sphere interaction is not significant. It is significant to say that in this case the velocity offsetting feature works the best.

Above limitations made me realize that it would be unlikely to implement this in a satisfactory manner. SO I left off where it does a couple of things but well: if you have a non-physx simulating platform that you move around and you want objects inside its volume behave more or less like the Star Citizen local grid (no rotation right now but it should not be hard to add) then it will work for you pretty well. The downside is a pretty specific sub-stepping setup.

I’ve never tested this in a multiplayer scenario, but I highly doubt it will produce satisfactory results. This may help with some artifacts while creating some platformers or fun jumping/physics game, but unfortunately won’t achieve what I initially set out to achieve, real local physics grid.

Hope this helps at least several people, if someone wants to polish or modify it, more power to you! I’ll be happy so see your results.

EDIT: Character handling worked pretty well, there is a separate logic for character where it checks if the character is standing or not and only applies the offset if character is NOT standing. If character is standing it will continue to follow the floor it is standing on, so there is no need to give it a location offset change, however if character is jumping we make sure he moves with the volume.

EDIT2: I think it is possible to implement this properly in C++ (without instantiating another physx instance), if anyone decides to, I think it will make a great community or marketplace contribution

Thanks for the reply @Irakli - Either way it looks super interesting and a good basis for starting out on.

My pleasure @HeadClot, thanks for your interest. If you decide to pursue the remake or try to enhance this, feel free to add me on Skype so I can pass on problems/issues I encountered so far, so that you do not have to find them