Also got transparency rendering correctly. It wasn't enabled before. Oops.
…iding their own. Where appropriate, of course. The arcball example still explicitly provides a camera, even though it's actually the same as the default camera we'd get. But the point of that example is to show how to create and use an ArcballCamera, so it seemed counter-productive to take it out... Naturally the imageview example still uses an OrthoCamera, too.
…have a function for that in core VGL.
…r constructor. Updated all the examples as well.
No longer just an example. :-)
…rom BaseCamera, now that their signature matches what we need. Had to make some slight modifications to the arcball camera methods so that they work correctly with the values the default viewer gives it. The ArcballViewer class had been inverting the y coordinates before invoking the camera methods, but that should really have been done by the camera itself. Well, now it *is*. Was able to get rid of the ArcballViewer class altogether after that, which simplifies the example code nicely.
This is a fancy way of saying that I moved the OrthoCamera from the imageview example into the main codebase. :-)
…onality into a subclass called BaseCamera. Updated all the examples which define their own camera classes to inherit from BaseCamera instead. Added an include line for the BaseCamera header into vgl.h. Added it to the Makefile. Tested. :-) This is another precursor to integrating the arcball camera (and the ortho camera from the imageview example too, now that you mention it) into the main VGL codebase.
Roll works well enough now, but could be improved further still. In particular, when you reach the edge of the "ball" it just stops moving currently. It should transition to a virtual flat surface at that point instead and use that to determine how much to roll by. Move works... ish. The translation seems to happen before the camera transform is applied, so it translates along the world axes rather than the camera-local ones.
The z value of 0 that I was passing in to the unproject function was incorrect. 0 means on the near clipping plane, but what I want is 0.5 (halfway between the near and far clipping planes). Added an arcballMove function which attempts to move the camera in the plane perpendicular to the view direction, rather than in the global X-Y plane. It doesn't work correctly - see the WTF message in the code - and I'm too tired to figure out why right now. Hopefully it'll make more sense after some rest.
…orking properly. The unit tests only cover (some of) the quaternion functions so far, but the structure is there now to add more easily. Sadly the arcball code is still broken.
It compiles but is full of bugs. This checkin is just so I've got a safety net...
Removed the corresponding code from the imageview example too.
It shows loading textures and orthographic projection using a custom camera subclass.
…attribute IDs. - Added callbacks for additional attribute types: vec2, vec4, matrix3 and matrix4. - Parser callback functions now use integer constants to identify attribute instead of strings. - Updated the example code to match.