Excerpts from Bobby Moore's message of Fri Nov 26 23:48:16 +0000 2010: > Thanks a lot for your detailed answer about this subject. I've taken into > account the different constraints to achieve a reality-like 3D effect, the > so-called "toe-in" approach not being ideal (thanks by the way for the link, > which I've come to know is quite a reference in this matter). > My idea is to generate the couple left-right views, not to be merged with > color artefacts, but having two separate views to be sent to a 3D display > (see Philips' WOWvx 3D display as an example) that accepts 2 HD (1080p/i) > frames (packed side-by-side or interleaved). This packing format is to be > the 3D standard to come, so might as well focus on that. > Using two framebuffers/fullscreen-textures seems to be the reasonable > choice, as long as the switching time follows. Such displays have a circa 60 > Hz frequency, 30 Hz per view. The great advantage of the Clutter API is that > it makes it simple to develop attractive interfaces with the most widespread > OpenGL(ES) derivatives, the (mandatory) downside being that it introduces an > additional layer (COGL), thus an additional processing time. > > Comments are welcome.
cool, It sounds like you have more experience than me on with the stereoscopic bits; it would certainly be good if you could consider how to integrate some of this with Clutter proper. My current thinking for Clutter integration is that we should add a ClutterCamera object. Internally a ClutterStage should manage a list of ClutterCameras. When a stage is first instantiated then it will only have a single "default camera". The main state a camera owns is: A viewport transform, a projective transform and a view transform. A camera also has an associated framebuffer. The default camera will be associated with the stage window itself. Potentially stereo cameras could be instead made to reference separate offscreen textures/framebuffers. Being the Cogl maintainer I figured I should say something about your comment ;-) I'm not sure you should worry too much about Cogl being an "additional layer". You are technically right, but more often than not it actually helps us improve the performance of Clutter, also when you consider running on GLES quite a bit of the value comes from having consistent utilities such as a matrix-stack which isn't an API layering, it just provides some important utilities that everyone ends up duplicating in all their different GL frameworks anyway. (other examples could be vector types or quaternion types) For instance graphics hardware typically can't be re-programmed fast enough for it to be effective to allow Clutter actors to draw directly with OpenGL (consider that most actors aren't much more than a few textured rectangles) so the work Cogl does to batch geometry drawn via the cogl_rectangle* APIs measurably improves performance. If you come across anything where Cogl actually impacts your performance compared to doing the equivalent in OpenGL then I'd love to hear feedback about that. On some hardware with open documentation we can potentially also side-step OpenGL in some cases or we can work with upstream to devise extensions to make sure we get the best performance. If we didn't have the Cogl API that would make it hard to take advantage of these special vendor extensions and sidestepping the driver would never be an option. That said though, Cogl isn't perfect so if you do have any particular concerns I'd be very interested to hear about them. kind regards, - Robert > > Bobby Moore > > > 2010/11/25 Robert Bragg <[email protected]> > > > On Thu, Nov 25, 2010 at 10:42 AM, Bobby Moore <[email protected]> > > wrote: > > > Hi, > > > I am really interested to use the Clutter API to design a 'true' 3D > > > application on an embedded platform. The application would send 2 > > > side-by-side packed views (left eye - right eye) to a 3D display. > > > > > > To get the 2 different views of the scene from the left and right eye, I > > > previously used the gluLookAt function of OpenGL, and the equivalent > > > matrices model in OpenGL ES 2.0. Having gone through the Clutter > > > documentation, I believe cogl_set_projection/modelview seems to do the > > > trick, providing access to the opengl matrices. > > > > > > Then I would need to get a handle on the image displayed on the screen > > (left > > > or right-eye view), the glReadPixels function and equivalent in COGL will > > be > > > too slow. Is there a way to get a handle on the buffer where everything > > is > > > rendered in Clutter ? > > > > Hi, > > > > I think if you want to do stereo rendering we need to investigate > > adding support in Clutter itself. This is something I've wanted to > > find the time to investigate but still haven't had a chance. > > > > At the Cogl level it is possible to redirect rendering to an offscreen > > texture, so then your handle is a texture that you can later use to to > > render onscreen with. You could potentially render your left eye into > > one texture, then the right into another and then composite onscreen > > by masking out different color channels. It would probably be more > > efficient if we exposed an equivalent for glColorMask when rendering > > to a framebuffer though so you wouldn't need intermediate textures, > > and certainly that is something I'd like to expose at some point. > > > > see cogl_offscreen_new_to_texture and cogl_push/pop_framebuffer if you > > want to experiment with this approach, but you should understand that > > without a more integrated approach it won't really be easy to get > > clutter to draw a whole stage of 3d actors in stereo. it *might* be > > possible, but you may need some nasty hacks. > > > > As a quick aside; what you said about using gluLookAt above implies > > you were using the "toe in" approach. That can have parallax issues > > such that the straight lines of 2D content on the Z = 0 plane will no > > longer appear straight which may not be desirable. There are other > > approaches that involve setting up asymmetric frustums for each eye > > such that 2d content on the z=0 plane will match up exactly for each > > eye. You can see some discussion of that here: > > > > http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/stereographics/stereorender/<http://local.wasp.uwa.edu.au/%7Epbourke/miscellaneous/stereographics/stereorender/> > > > > If you would be interested in investigating a solution that is > > integrated with Clutter I would recommend look at the code in > > clutter-stage.c, and take a look at _clutter_stage_do_paint() as this > > is where rendering for the whole stage kicks off. In essence we need a > > way to be able to call clutter_actor_paint (CLUTTER_ACTOR (stage)); > > twice with a different perspective matrix for each eye, and we need > > some way to combine the results. (using glColorMask internally to do > > anaglyph style rendering would probably be an ok starting point > > though) > > > > I hope that helps a bit, and don't hesitate to ask if you have more > > questions about this stuff. > > > > thanks, > > - Robert > > _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
