-
Notifications
You must be signed in to change notification settings - Fork 71
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
arcball #11
Comments
Yes, the pssm shader is a laptop killer. Yes, the failures should be handled more gracefully and I will try to address this soon. When talking about the camera, are you talking about the camera in the master branch or particle-system branch? The one in the particle-system branch is likely to succeeed the camera in the main branch. David (https://github.com/jeske) would be the guy to talk to if you'd like to include a demo with SimpleScene. |
The current third person camera doesn't have "gimbal lock" per-say .. it's designed to always maintain Y-up by design. This produces a camera locking effect at the top and bottom of rotation which might feel like, but is not technically gimbal lock. I think an arcball camera option would be great. At some level we need to decide how to switch between camera modes. I like the idea of merging multiple modes into a single camera class and letting you switch between them. Is your code like this? An additional mode? Or does it replace the existing mode? Either way... send me a pull request, and I'll get it integrated into an "arcball mode" of the camera, alongside the existing functionality. |
Sorry, thanks for the rapid response; I see your point. Arcball seems to be only useful within close range of something, preferably ball-shaped, otherwise things get odd. I'm back to using the delta proc that's there. I like the Up and Right stuff; very easy to move the camera around. I do have a test winforms app with a "UseArcball" checkbox, I could try the pull request thing, not done it here before. re: branches; it would merge or manually move easily, it's only 3 additional methods. I've only looked at the main branch. |
Yes, it turns out it's a "feature" of the current "Turntable" style camera that the horizontal rotation axis is always perpendicular to world-up. WIthout it, in just a few mouse-rotations, the camera orientation will be completely unglued from any reference axis, which is usually not desired. That said, it's easy enough to make alternate camera rotations models. That said, I do have some ideas about how I want to change the camera classes to make it easier to switch camera-navigation models for the same camera object. Hopefully it'll get to that soon. The wavefront-obj loader (like other Util components) is not and should not be dependent on anything in simplescene. It is in a separate subproject to make sure this remains the case. As for trouble with larger models, I'll take a look. Yes, the indicies should probably be int32 at least. There are also some unimplemented features, such as line continuations, which a larger file might be making use of. If you have an example model you can share, email me (davidj at gmail dot com). |
Hi. I quite like this, having removed the ppsm shader call to get it to work on my laptop - would be nice if it dealt with this more gracefully..
Anyway, I noticed the camera mouse delta update code suffers from gimball lock (though it's all quaternion based.. I thought it would be ok).. so I've implemented an arcball-like solution on top of what's there. It's only a couple of methods on the camera class.. seems to work ok.. would you like it?
I've got it running inside a opentk GLControl, which was also a little fiddly. Might be nice to sort out that and include a demo..
The text was updated successfully, but these errors were encountered: