gl-engine
gl-engine copied to clipboard
gregtatum
Camera stuff
What is the best way to manipulate a glam camera? Looking for a simple "orbit style" controls example.
It might help to integrate some of these modules and/or their dependencies: https://github.com/Jam3/perspective-camera https://github.com/Jam3/ray-3d https://github.com/Jam3/orbit-controls (WIP)
:+1:
Yeah I was going through those the other day. I haven't focused on API ergonomics of the cameras at all. The code as it exists has mainly been about getting the matrices computed and in place. I think ultimately the controls like orbit need to be first class citizens, and easy to use.
I like the idea of keeping the transform property in place as a clear API practice, but in practice the camera is going to have different needs on what's computed, and it won't use a scale property.
I need to read through the source code of the existing camera modules and get a better handle on them.
I just reviewed all of this and it's great stuff. I'm thinking about cannibalizing the perspective-camera code to make it more in-line with some of the existing glam conventions, but it feels a ton better than what I have now.
Cool 👍 if there's anything that could be shared we can split into its own module. Ideally orbit-controls could be cleaned up so that it works with a variety of frameworks.
Sent from my iPhone
On Dec 26, 2015, at 11:00 AM, Greg Tatum [email protected] wrote:
I just reviewed all of this and it's great stuff. I'm thinking about cannibalizing the perspective-camera code to make it more in-line with some of the existing glam conventions, but it feels a ton better than what I have now.
— Reply to this email directly or view it on GitHub.
camera-look-at.js seems to be the only thing in perspective camera that might fit the bill in an initial look.
I think orbit controls should be able to plopped in with just a little bit of glue.
fwiw, I've found that having camera input modules operate on a ray (i.e. origin + direction) makes things modularise really well. camera-spin does this, albeit with a bunch of extra sugar, and it means that while you can use mat4.lookAt to generate a view matrix, you can also do stuff like plug it into a raymarching shader with hardly any extra effort :)
Is it important for the camera to behave inside of the scene hierarchy? If I don't have to add the matrix parent/child calculation the camera will be a much simpler thing. I'm thinking of just glueing perspective-camera in now that I'm looking at implementing it. Plus adding the camera to the scene is kind of an awkward step when you're already passing it into the render() call already.
I ended up using the straight modules with some glue. I really like the idea of offloading the internals of how these things work to modules. It was fairly painless to get it integrated.
