On 11/29/2010 08:47 PM, Robert Bragg wrote:
Excerpts from Samuel Degrande's message of Mon Nov 29 15:41:23 +0000 2010:
On 11/29/2010 03:54 PM, Robert Bragg wrote:
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.
Just to let you know, I also have a create a stereoscopic version of
our 'virtual painting application'
(http://www.lifl.fr/~degrande/demoWabin/WabinPaint.avi)
heh, looks very cool!
We use 'active stereo' devices, that is consecutive frames, one for
left eye followed by one for right eye. So I don't have to get back the
framebuffer to compose the final image.
So currently do you organize your scenegraph so that you have a
container held by the stage where you can toggle the left/right eye view
transform for each frame?
I have to use quad-buffering. So each frame has to be rendered 2 times,
one with a specific transform for left eye in left buffer, one with a
specific transform for right eye in right buffer, and then comes the
switch buffer. That's how it works for active stereo devices.
I did not yet fully implement it in clutter. I just played a bit with
cogl transforms, to check if it could be easily done. So the idea is
now to create a 'stereo-stage', as adviced by ebassi.
The ClutterCamera was also something I had in mind, because that's how
I implement stereo-rendering in our other applications written 'from
scratch' (so without any 'high-level' lib).
It seems like it should be fairly straight forward to add this kind of
abstraction to Clutter and quite a few people are interested in this
now.
The first step could be to add a private ClutterCamera object and
re-factor ClutterStage so that ClutterStagePrivate has a default_camera
member to replace the viewport and the perspective/projection matrix
with this default_camera. (leaving the dirty_viewport/dirty_projection
flags in the stage but use "notify::viewport" and "notify::projection"
signals from ClutterCamera to set the flags.)
One fiddly bit may be defining a "projection" property for the
ClutterCamera object which should presumably take a CoglMatrix type
because currently we don't register a GType for CoglMatrix which is a
requirement for defining a GObject property. Adding a function like
cogl_matrix_get_gtype() to Cogl that registers a boxed_type with glib
should be ok I think.
In my other applications (no clutter based), I use a list of cameras (2
cameras for stereo rendering), and during paint I call each camera in
turn to:
1- setup the current drawing buffer
2- setup the current transformation matrix and viewport,
3- render the scenegraph.
When all cameras have been used, the front/back buffers are switched.
I don't know if such a way of doing is also usable with other kind
of stereo-rendering, such as interlaved frames or side-by-side frames.
I'd love to help someone take a stab at this!
Adding stereo is on my todo list for the month to come, along with a
lot of other tasks :-( I'll first write a quick-and-dirty mock-up.
I'll then need help to make it follow clutter concepts...
kind regards,
- Robert
--
Samuel Degrande LIFL - UMR8022 CNRS - INRIA LNE - Bat M3
Phone: (33)3.28.77.85.30 USTL - Universite de Lille 1
Fax: (33)3.28.77.85.37 59655 VILLENEUVE D'ASCQ CEDEX - FRANCE
_______________________________________________
clutter-app-devel-list mailing list
[email protected]
http://lists.clutter-project.org/listinfo/clutter-app-devel-list
