Basic input class #665
Basic input class #665
Conversation
|
You guys are epic and so fast! With pointer events I can already see how it can simplify our drag PR ! I didn't realize we can just do things like that and keep performance. |
|
I'm working to at least include all the basic functionality in this PR with pointer state as well. @almarklein Eventually we could consider rebasing the controllers on the input class. The main benefit is that you can isolate most of the event handling logic in the input class, and support configurable key maps there as well, so that controller's don't need to be aware of all of that stuff. |
|
This is now working. Could one of you give it a try locally and review? @almarklein I was thinking to move the FPS controls into a controller class, but it will have a different architecture and design than the other controllers. I also don't want to refactor all of them. Do you have any ideas on how to deal with that? I was thinking about creating another subpackage |
|
|
||
| @property | ||
| def delta(self): | ||
| """Returns the time in seconds since the last frame.""" |
There was a problem hiding this comment.
This is actually the time the previous frame took to render 🤦♂️
There was a problem hiding this comment.
It's likely even longer than the time it took to render the frame (fps limiting).
Would we want to perhaps smooth this value, to avoid variations in it from affecting the way the interaction feels?
There was a problem hiding this comment.
After thinking about this some more, I think it's correctly implemented:
- For every
after_flushevent, there is only 1 call toperf_counter(), so we don't "lose time" - The
deltashould have the same value for all update handlers running in a given frame - The
deltashould be equal to the time since the previous point in time where update handlers were executed, which is usually right afterafter_flush
Also see https://docs.unity3d.com/ScriptReference/Time-deltaTime.html
|
Tried it and it works really nice! Also feels immersive because the mouse is grabbed.
Yes, I think that makes the most sense. I think controllers are quite different because they closely relate to cameras. Perhaps we can (later) refactor the controllers to make use of the input class(es) to make them simpler. I think wrapping makes more sense than subclassing here, what do you think? |
|
The example works well for me along with small modifications to try out various things (moving the torus and the view, sensitivities, etc.) 😄 |
The example is "done" I think, next step is reorganizing the code into a |
| First person shooter controls with GLFW GUI | ||
| ========================================= | ||
|
|
||
| Example showing how to use the Input class to implement FPS controls. |
There was a problem hiding this comment.
Explain the controls here in the docstring
|
The more I think about this the more I feel like it should be a part of wgpu-py's GUI layer... I will see what that feels like by trying it out on a branch. |
|
I'll give this a shot in wgpu if you can hint me at where it would go! |
|
|
Closing. We will get back to this when we work on #495. We see two approaches, but we'll have to see at the time:
|
Closes #664
Adds a basic Input class with an example demonstrating how to implement simple FPS controls with it