Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add interface for contact processing #121

Open
MrDmitry opened this issue Jul 5, 2018 · 0 comments
Open

Add interface for contact processing #121

MrDmitry opened this issue Jul 5, 2018 · 0 comments
Assignees
Labels
applied everything that is not directly related to the math or physics, if it's CI fix, CMake fix etc feature major new functional

Comments

@MrDmitry
Copy link
Member

MrDmitry commented Jul 5, 2018

Current state

All contacts are detected and resolved locally within Pegasus.
There is pegasus::Debug::s_collisionDetectionCall callback hook allowing user code to process detected contacts for debug purposes only

Use case

Trigger some events upon any contact selected Primitive is a part of.
Examples:

  1. play some sound whenever Primitive collides with anything
  2. create particle effect whenever Primitive collides with anything

Points to consider

Meta information regarding collision can also be interesting. Not only Primitive handles that are in contact, but also calculations about their collision.
Example: relative velocities can be used to determine the volume of the sound or amount of particle effects.


I will test existing pegasus::Debug::s_collisionDetectionCall callback to see how handy this model would be if this information was exposed via some public interface as opposed to debug hook. Ultimately triggers/logic based on these contacts is inside user code so as long as traversing contact collection does not result in some huge overhead, it would be a viable solution.

Sidenotes:

  • these use cases apply only to physical objects; logical contacts/collisions can be (and probably should be) processed externally using Arion itself
  • callback/trigger mechanisms are not a part of this feature; data about collisions shall suffice
  • it's hard to completely account for possible scenarios; it is possible that number of triggerless objects in the scene would be far greater than the ones that have some actions associated with contacts
@MrDmitry MrDmitry added the feature major new functional label Jul 5, 2018
@ilia-glushchenko ilia-glushchenko self-assigned this Jul 5, 2018
@ilia-glushchenko ilia-glushchenko added the applied everything that is not directly related to the math or physics, if it's CI fix, CMake fix etc label Jul 5, 2018
@ilia-glushchenko ilia-glushchenko added enhancement additional functional that does not introduce new major code entities and removed enhancement additional functional that does not introduce new major code entities labels Dec 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
applied everything that is not directly related to the math or physics, if it's CI fix, CMake fix etc feature major new functional
Projects
None yet
Development

No branches or pull requests

2 participants