Difference between revisions of "GSoC Ideas"

Revision as of 19:54, 31 January 2012

IMPORTANT: Nothing is final, CEGUI might or might not get into GSoC! Feel free to add ideas though! :) IMPORTANT2: I have arbitrarily chosen the mentors, mentors please add (ack) if you agree with my choice. Edit yourself out otherwise. Thanks!

Samples framework

Currently, samples are separate applications that are run separately. It would be nice to have some sort of an unified framework for defining samples. That way you can start CEGUIDemos executable and browse through samples, switching them, etc... New samples should be coded in C++, Python or Lua (all languages CEGUI officially supports), so this framework should have bindings for Python and Lua. The GUI for choosing samples should of course be done with CEGUI.

Ogre has a similar sample framework (but samples can only be written in C++).

difficulty: Easy

mentors: Jamarr, fusion44, Kulik (ack)

New Font API

CEGUI exposes a lot of pain regarding text rendering and realtime 3D graphics to the user. You have to explicitly instantiate the font in sizes you will want, you have to instantiate bold, italic, etc variants as separate fonts, ... This task would involve changing the API around to make it simpler for the user. You would be able to define a Font you want to use and sizes would be loaded into textures dynamically (including garbage collection).

freetype2 and/or fonts vs OpenGL/DX experience would be very valuable for this task

difficulty: Medium

mentors: Jamarr, fusion44, Kulik (ack)

Revamp Ogre Renderer to be more high level

CEGUIOgreRenderer uses some intimate Ogre internals knowledge, we use lowlevel _ prefixed methods to draw. This is suboptimal for various reasons, the renderer is prone to Ogre changes that normally don't affect users. Render targets behave odd in OpenGL, DX10 and DX11 is somewhat supported in Ogre but CEGUI renders with various quirks with it, etc...

The idea is to use high level Ogre constructs to render, ManualObject as GeometryBuffer, Materials instead of manually altering the state via Ogre::RenderTarget, etc... All of this has to have comparable performance to the old Ogre Renderer.

difficulty: Medium

mentors: Jamarr, fusion44, Kulik (ack)

Animation staging

Animation in CEGUI only works on a single window. It would be great if users were able to stage complex animations (think main menu appearing). The idea is to fire off multiple animations on a whole widget tree at the right times. This task also involves writing an editor in the CEGUI Unified Editor for it. The API should be rather simple and easy to do, the editor will be harder (IMO).

difficulty: Medium

mentors: Jamarr, fusion44, Kulik (ack)

LookNFeel editor for CEED

As of now, CEED edits layouts, imagesets and animations. LookNFeel editor would be a killer addition. Basically would allow artists to create new skins without touching XML code. This has always been a feature that many requested.

difficulty: Hard

mentors: Kulik (ack)

Focus implementation

There's no focus implementation so far in CEGUI, i.e., you can't have both mouse and keyboard focuses. Only one widget has focus, and gets all inputs. This complicates game development and decreases GUI flexibility. More info: http://www.cegui.org.uk/mantis/print_bug_page.php?bug_id=113

difficulty: Hard

mentors: kornerr (ack)

Canvas (custom render independent drawing) + SVG subset

CEGUI only draws rectangles at this point (it binds textures to them but they are still rectangles). This task would be about adding the ability to draw other shapes to surfaces of widgets. The API should reuse concepts from other libraries. It would be cool if we were able to draw a subset of SVG with this API (preferably having a subclass of Image called SVGImage). Implementing a CEGUI Skia renderer would help greatly with that.

difficulty: Hard

mentors: Jamarr, fusion44, Kulik (ack)