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).
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.
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.)
3) texture the inside faces of the sphere with a panoramic image (UV mapped).
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.
6) Videos are rendered onto a textured subsections of the sphere to
create the animated parts of the game world.
>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?
On Thu, Jan 28, 2010 at 2:02 PM, Robert Bragg <b...@o-hand.com> 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
>
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
