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

StatefulObjects #1759

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft

StatefulObjects #1759

wants to merge 7 commits into from

Conversation

riccardobl
Copy link
Member

@riccardobl riccardobl commented Jan 20, 2022

In the engine we have the concept of state updates for some objects that represent both jme logical objects and opengl native objects.
This pr extends this approach by introducing a way to store custom states for objects that extend the StatefulObjects class.

This can be used to implement self contained renderers as modules that don't need any change in the core to work nor to maintain large maps to point jme objects to their local representation.

This also allows multiple contexts to be updated and invalidated separately without them being aware of each other and without polling for changes.

As an example let's say we have a Mesh that is needed by the rendering engine and the physics engine:

  • both engines append a state to the mesh (eg. GLMeshState and BulletBodyState )
  • after some time the mesh is changed (eg. the vertices change position)
  • both the states are invalidated
  • the GLMeshState will notify the renderer to submit the new vertices to the gpu, at the same time BulletBodyState will notify the physics engine to update the rigidbody associated to this mesh
  • the two states can update out of order and asynchronously

This pr implements StatefulObjects for some objects that have a representation in our current rendering backend:

  • All the native objects
  • Spatial and Node : for model -> world transform matrix
  • Camera : for view/projection matrices

Obviously there is nothing that can benefit from this PR atm, but it will allow future development to be less reliant on the core module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants