-
-
Notifications
You must be signed in to change notification settings - Fork 56
Cameras and controller overhaul #457
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
Conversation
Is it a lot of work to also implement fly controls?
It's much more convenient to navigate scenes like sponza with this kind of control scheme. |
I would love to have that too. But let's do that in a new pr. Made #471 to track. |
This is looking amazing! What do you think about allowing the Controller to be "enabled" or "disabled". For the PanZoomController it seems like this might be possible by:
Usecase, when using the mouse to move objects (see the dark gray rectangle) it also moves the camera. If a controller can be enabled based on a key event or other event (the user can define their own event handling) it makes this nicer: selector_controller_mixed-2023-03-05_20.13.07.mp4 |
I think that's a great idea (was planning for adding this already 😄 ) |
Ok, so I managed to hide the extent stuff. Still works but is much simpler to explain.
So now you can just specify either the width or height in addition to the aspect. But the recommended approach is to use any of the
Good point. I left the Remaining point is the registering of events. A proposal:
|
Proposal is 👍 |
@Korijn I want to make sure that you approve the current state of the PR before I update the remaining examples (since that would make the PR harder to review, and I want to avoid duplicate work). (if needed, take your time, I can work on a fly controller or something) |
I think you did a great job here, after playing around with this and reviewing the code I have the following to say:
Other than that, feel free to update the remaining examples. I'm good with this, it looks really nice. |
All green 🚀 |
Addresses #403
Tasks
Contributions outside of cameras and controllers:
WorldObject._look_at
which has a flag to indicate whether it is a light or camera.show()
func considers a given camera as already having a good initial view. Plus a few small tweaks inshow()
.To do:
renderer
into controller's init?Wrapping up:
show
methods.After this:
Explanation for some decisions
Notion of extent
As I made the controllers work with both the ortho and perpective cameras, I introduced a notion of scale or scene size, which I called "extend". For the ortho camera this is simply the mean of
width
andheight
. For the perspective camera, I needed to introduce a newextent
prop. It is set bylook_at
,show_object
and the newshow_rect
.The extent is an indication of the size of the scene being viewed. It can be used to determine the distance to the scene (taking fov into account), and thus can be used by the orbit camera to know around what point to rotate. Further, it is used to automatically determine the near and far clipping plane to sensible values.
Camera class hierarchy
Interestingly, the
extent
/aspect
pair, and thewidth
/height
pair, are two ways to set the same thing! With that insight, the two cameras are kindof the same thing: an orthographic camera is simply a perspective camera with a fov of zero.So I made the
PerspectiveCamera
more generic by allowingfov=0
, and theOrthographicController
a thin wrapper that limits the fov to zero. With a perspective camera and an orbit controller, you can change fov by scrolling while holding alt/option. You can then lower it all the way to zero, smoothly transitioning from a perspective camera to an orthographic one 😄(At some point I introduced a
GenericCamera
from which both cameras inherited, but when I started to write the guide, that felt overly complex.)Controller class hierarchy
The orbit controller has the same method as the panzoom camera, and some more. And they work the same way. So I made the OrbitController inherit from the PanZoomController.
Camera updates
This PR covers everything in #403, except that changes are applied to the camera automatically (and directly). That's a consequence of the fact that the controllers do not have state by themselves.