Excerpts from Adam B's message of Fri Jan 29 21:10:39 +0000 2010:
> Thanks for the thorough response, Robert. Cogl sounds like an
> interesting option and my needs are not very complex, (I don't need
> lighting because all the graphics will be prerendered raytraced images
> and videos). Also, I like the idea of using an abstraction API like
> Cogl because it makes the game more portable. I'd venture a guess
> that Cogl could even be implemented on top of DirectX if Microsoft
> ever succeeds in killing OpenGL on their platform).
*theoretically* such a port might be possible in the future :-)
>
> Perhaps then I don't really need to break out to raw OpenGL. Let me
> summarize how the game would be rendered:
> 1) Setup a perspective matrix, (~65deg FOV), and reset the modelview
> matrix so that no rotation, translation or scaling is occurring.
you can use cogl_set_projection and cogl_set_modelview to load custom
matrices.
> 2) draw a fine UV sphere centered on 0,0,0. (Because we have not
> done any translation the camera is effectively "inside" the sphere.)
The CoglVertexBuffer API should give you enough control to be able to do
this.
> 3) texture the inside faces of the sphere with a panoramic image (UV
> mapped).
This should be a case of adding a gl_MultiTexCoord0 attribute via
cogl_vertex_buffer_add (); one thing to note though is that the
CoglVertexBuffer API can't work with sliced textures.
Cogl supports sliced textures to handle hardware that doesn't support
non-power-of-two texture sizes or for very large textures that exceed
the hardware's texture size limits. Currently only primitives
implemented directly by Cogl - such as cogl_rectangle or cogl_polygon
- are capable of understanding sliced textures and in the case of
CoglVertexBuffer we have no plans to ever try and support sliced
textures.
You just need to use the COGL_TEXTURE_NO_SLICING flag when you load your
texture using cogl_texture_new_from_file ();
> 4) As the player moves the mouse I rotate the sphere so they are
> essentially looking around at the panoramic "world".
> 5) If the user hits a certain key or mouse button I bring up the Clutter
> GUI.
This should all be doable with Clutter's input handling, and then just
clutter_actor_show/hide() your GUI actors as needs be.
> 6) Videos are rendered onto a textured subsections of the sphere to
> create the animated parts of the game world.
This bit sounds a little tricky. I think the way you should look at
getting video into your game is by using ClutterGst. The problem with
ClutterGst for you is that it creates an actor that simply maps video
onto a rectangle. What you should be able to do though is pluck out the
CoglMaterial from the ClutterGst actor (it's a sub-class of
ClutterTexture so just do clutter_texture_get_cogl_material ()) You can
then use this material with some more CoglVertexBuffer geometry.
So the idea for the video is that you would tessellate smaller curved
patches of geometry that would be positioned just-above the surface of
your sphere and be textured with the CoglMaterial plucked from a
ClutterGst actor.
One awkward detail I can think of is that you may need to create a
ClutterGst sub-class and implement your own paint() method so it doesn't
paint anything. The reason I say that is that ClutterGst probably stops
updating the internal CoglMaterial while the actor is hidden, so I guess
you'll need the actor to be mapped, but because you are handling the
rendering in a special way you don't want the actor itself to paint
anything. If you take this approach then the idea would be to ensure
your ClutterGstNOP actor gets "painted" just before you use the material
so that it's updated with the latest frame.
An alternative to implementing a nop paint method could be to directly
draw using the CoglVertexBuffer API in the paint() method of a
ClutterGst sub-class. In this case you could make the game actor that
sets up your projection matrix and draws the sphere implement the
ClutterContainer interface and then make your ClutterCurvedGst actors
children of this container. I think an awkward aspect of this approach
may be the 2D centric layouting semantics that Clutter has, but you can
probably work around them. (You can just "allocate" your
ClutterCurvedGst actors an arbitrary size, and ignore the allocation in
your ClutterCurvedGst::paint method)
This is roughly how I would imagine your scene graph to be structured
and painted:
Stage::paint ()
GameActor::paint ()
save clutter's projection
cogl_set_projection ();
cogl_push_matrix ()
cogl_set_modelview ()
draw_sphere ();
cogl_push_matrix()
//transform to video0 location
ClutterCurvedGst::paint ()
cogl_vertex_buffer_draw ()
cogl_pop_matrix ();
cogl_push_matrix()
//transform to video1 location
ClutterCurvedGst::paint ()
cogl_vertex_buffer_draw ()
cogl_pop_matrix ();
cogl_pop_matrix ();//restore original modelview
cogl_set_projection (); //restore clutter's projection
GameGUI::paint ()
Note: due to you modifying the projection matrix you will have
difficulties if you try and transform input coordinates relative to
actors inside your game actor using the Clutter APIs. You should be able
to ignore this problem though and simply capture input events on the
whole game actor and deal with all game input manually. I.e. don't
expect input to work correctly for ClutterCurvedGst actors and so don't
make them reactive.
>
> From what you describe it sounds like I could do all this with Cogl
> and a custom Clutter actor. Knowing these details do you foresee any
> problems?
The video stuff sounds trickiest to me and playing with the projection
matrix will confuse Clutter's input transformations inside such actors
but I think overall its doable and a better way to go than raw OpenGL.
If you have any difficulties with using Cogl please say and I'll try to
help. The reference manual can be found here:
http://www.clutter-project.org/docs/cogl/1.0/ but we don't have any
tutorials / guides for newcomers yet.
kind regards,
- Robert
>
> On Thu, Jan 28, 2010 at 2:02 PM, Robert Bragg <[email protected]> wrote:
> > Excerpts from Adam B's message of Thu Jan 28 05:55:05 +0000 2010:
> >> Hello all,
> >>
> >> I'm starting work on a puzzle/adventure game which will use OpenGL. I
> >> think Clutter might be able to help me with two things:
> >>
> >> 1) I need to build a pleasing 2D GUI to allow players to save/load
> >> games and configure options etc.
> >> 2) I need to render video to an OpenGL texture. (It seems that
> >> Clutter-gst can do this quite well)
> >>
> >> My concern is that, Clutter might not like being a 2nd class citizen
> >> in a larger 3D OpenGL game. For instance:
> >
> > We do support breaking out into raw OpenGL to some extent, though we
> > wouldn't really recommend it.
> >
> > cogl_begin_gl() and cogl_end_gl() can be used to delimit where you are
> > manually using OpenGL and they will basically try and normalize the
> > OpenGL state and flush any of Cogl's cached OpenGL state. The important
> > limitations of this mechanism are:
> > 1) It's your responsibility to save and restore any OpenGL state that
> > you need to change while rendering your puzzle game.
> > 2) We don't currently provide any guarantees about how we normalize the
> > state only that it's consistent each time you call cogl_begin_gl () We
> > can potentially improve this though:
> > - Currently we just setup a simple CoglMaterial and flush the state to
> > OpenGL as a way to normalize the state, the problem is that we may
> > change how CoglMaterial is implemented which will change how the state
> > is normalized.
> > - An alternative would be to guarantee that we restore everything back
> > to OpenGL defaults; this would be quite difficult for us to support
> > but could potentially be done. The OpenGL state is owned and cached by
> > different Cogl components, but we could potentially add a
> > _cogl_<component>_normalize_gl_state () to each component to help
> > do this in a relatively maintainable way.
> >
> > Asside from cogl_{begin,end}_gl we don't provide an easy way to
> > integrate with an existing game engine (probable the best way at the
> > moment would be to start with a Clutter backend for the game engine),
> > but if its something simple you are writing from scratch then I would
> > recommend that you just leave Clutter responsible for creating the GL
> > context.
> >
> > If you create a custom Clutter actor and add it to the stage then you
> > can use the paint function as the point where you break out and render
> > your game scene.
> >
> >>
> >> 1) When the user is playing I need full control of the OpenGL
> >> pipeline. I need to setup the perspective matrix, rotate/translate
> >> according to mouse movements , setup textures, draw geometry, etc.
> >> More bluntly, Clutter needs to stay out of my way.
> >
> > It might not expose all the feature you want yet, but have you
> > considered using the Cogl API instead of OpenGL? Cogl gives direct
> > control over the perspective/modelview matrices, it gives access to
> > offscreen framebuffers, vertex buffers, blend modes, loading textures,
> > controlling texture combining and a clipping API.
> >
> > It sadly doesn't yet have lighting support, and some other fairly basic
> > things but it may be feasible to add missing features to Cogl depending
> > on how much you need?
> >
> >>
> >> 2) I need to render video onto a rectangle face and be able to place
> >> that face precisely using 3D coordinates.
> >
> > ClutterGst can give you a ClutterActor that displays video and you can
> > position actors in 3D. The difficulty may be if you want this right in
> > your game scene which has a custom projection matrix? I can think of
> > some approaches but they all sound quite hairy. Need to think a bit
> > about this one.
> >
> >>
> >> Is this level of control feasible with Clutter?
> >
> > I think you will come across some difficulties and probably some Clutter
> > bugs, but its potentially doable. If you could use Cogl instead of
> > OpenGL that would avoid the awkward state management issues but that may
> > not be feasible for your game.
> >
> > kind regards,
> > - Robert
> >
> > --
> > Robert Bragg, Intel Open Source Technology Center
> >
--
Robert Bragg, Intel Open Source Technology Center
--
To unsubscribe send a mail to [email protected]
