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

arcball #11

Open
unpossible opened this issue Feb 25, 2015 · 4 comments
Open

arcball #11

unpossible opened this issue Feb 25, 2015 · 4 comments

Comments

@unpossible
Copy link

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..

@HoneyHazard
Copy link
Collaborator

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.
But it still is a quick dirty hack to get WavefrontOBJViewer to become a more flexible test bench. I would absolutely love to see a better solution.

David (https://github.com/jeske) would be the guy to talk to if you'd like to include a demo with SimpleScene.

@jeske
Copy link
Owner

jeske commented Feb 26, 2015

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.

@unpossible
Copy link
Author

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.
On another note, the ObjLoader was failing for me with bigger models. I thought it might be a type thing, and upped some of the indexes to Int32 from Int16 (eg the Face struct), but it ended up hanging :( Any chance you're looking at bigger models? Works fine for blender output of smaller stuff; thanks very much.. although, hmm, why isn't it in the lib, rather than a project outside it?

re: branches; it would merge or manually move easily, it's only 3 additional methods. I've only looked at the main branch.

@jeske
Copy link
Owner

jeske commented Mar 20, 2015

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).

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

No branches or pull requests

3 participants