GSoC Ideas - Revision history

Kulik at 13:53, 3 March 2012

2012-03-03T13:53:06Z

Crazyeddie: Executive edit: Adding this here, since I my account at the WF wiki was not approved (yet?)

2012-03-03T13:28:35Z

Executive edit: Adding this here, since I my account at the WF wiki was not approved (yet?)

Kulik: Moved to worldforge wiki

2012-02-24T17:02:29Z

Moved to worldforge wiki

Kornerr: /* Revamp Ogre Renderer to be more high level */

2012-02-19T14:34:03Z

‎Revamp Ogre Renderer to be more high level

Fusion44 at 12:33, 19 February 2012

2012-02-19T12:33:29Z

Kulik at 09:48, 18 February 2012

2012-02-18T09:48:12Z

Kulik at 13:42, 16 February 2012

2012-02-16T13:42:06Z

Kulik: /* Canvas (custom render independent drawing) + SVG subset */

2012-01-31T19:54:09Z

‎Canvas (custom render independent drawing) + SVG subset

Kulik: /* Canvas (custom render independent drawing) + SVG subset */

2012-01-31T19:39:55Z

‎Canvas (custom render independent drawing) + SVG subset

Kulik: /* Canvas (custom render independent drawing) + SVG subset */

2012-01-31T19:37:46Z

‎Canvas (custom render independent drawing) + SVG subset

← Older revision		Revision as of 13:53, 3 March 2012
Line 1:		Line 1:
−	All except ~~Focus implementation~~ have been moved to http://wiki.worldforge.org/wiki/Summer_of_Code#CEGUI_Ideas<br />	+	All except nothing have been moved to http://wiki.worldforge.org/wiki/Summer_of_Code#CEGUI_Ideas<br />
	Do further editing there.		Do further editing there.
−
−	~~==== GUI Navigation ====~~
−
−	* '''Summary''': Create a GUI navigation and visual focus implementation.
−	* '''Description''': Currently, primary interaction with CEGUI takes place via the mouse input device only. CEGUI should be enhanced to allow other devices - such as the keyboard - to be used for interacting with and navigating the GUI and to provide appropriate visual feedback.
−	* '''Technical Details''': The idea here is to provide some form of abstract interface for navigating a GUI layout, and then provide an implementation of that interface that uses the keyboard. Other challenges will include adding appropriate mechanisms to provide navigational hints to the core GUI classes, and extending the core window rendering classes to provide a uniform approach to visually indicating which GUI element has current focus.
−	* '''Specification''': TBD
−	* '''Difficulty''': Medium / Hard
−	* '''Required Skills''': C++, some XML knowledge
−	* '''Mentor''': Michael Kapelko

@@ Line 2: / Line 2: @@
 Do further editing there.
-== Focus implementation ==
+==== GUI Navigation ====
-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
+* '''Summary''': Create a GUI navigation and visual focus implementation.
+* '''Description''': Currently, primary interaction with CEGUI takes place via the mouse input device only.  CEGUI should be enhanced to allow other devices - such as the keyboard - to be used for interacting with and navigating the GUI and to provide appropriate visual feedback.
-mentors: kornerr (ack)
+* '''Technical Details''': The idea here is to provide some form of abstract interface for navigating a GUI layout, and then provide an implementation of that interface that uses the keyboard.  Other challenges will include adding appropriate mechanisms to provide navigational hints to the core GUI classes, and extending the core window rendering classes to provide a uniform approach to visually indicating which GUI element has current focus.

@@ Line 1: / Line 1: @@
-IMPORTANT: Nothing is final, CEGUI might or might not get into GSoC! Feel free to add ideas though! :)
+All except Focus implementation have been moved to http://wiki.worldforge.org/wiki/Summer_of_Code#CEGUI_Ideas<br />
-IMPORTANT2: I have arbitrarily chosen the mentors, mentors please add (ack) if you agree with my choice. Edit yourself out otherwise. Thanks!
+Do further editing there.
-−
-== Samples framework ==
-Currently, samples are separate applications that are run separately. It would be nice to have some sort of a 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++).
-−
-Part of this task is to create new demos, improve existing ones or possibly remove them if they don't make sense anymore.
-−
-difficulty: Medium
-−
-mentors: Jamarr, fusion44 (ack), 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, 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 (ack), Kulik (ack), kornerr (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). You will be able to reuse timeline and other components from CEED for the editor.
-−
-difficulty: Medium
-−
-mentors: Jamarr, fusion44 (ack), 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 ==
@@ Line 52: / Line 9: @@
 mentors: kornerr (ack)

@@ Line 29: / Line 29: @@
 difficulty: Medium
-mentors: Jamarr, fusion44 (ack), Kulik (ack)
+mentors: Jamarr, fusion44 (ack), Kulik (ack), kornerr (ack)
 == Animation staging ==

@@ Line 11: / Line 11: @@
 difficulty: Medium
-mentors: Jamarr, fusion44, Kulik (ack)
+mentors: Jamarr, fusion44 (ack), Kulik (ack)
 == New Font API ==
@@ Line 20: / Line 20: @@
 difficulty: Medium
-mentors: Jamarr, fusion44, Kulik (ack)
+mentors: Jamarr, Kulik (ack)
 == Revamp Ogre Renderer to be more high level ==
@@ Line 29: / Line 29: @@
 difficulty: Medium
-mentors: Jamarr, fusion44, Kulik (ack)
+mentors: Jamarr, fusion44 (ack), Kulik (ack)
 == Animation staging ==
@@ Line 36: / Line 36: @@
 difficulty: Medium
-mentors: Jamarr, fusion44, Kulik (ack)
+mentors: Jamarr, fusion44 (ack), Kulik (ack)
 == LookNFeel editor for CEED ==
@@ Line 59: / Line 59: @@
 difficulty: Hard
-mentors: Jamarr, fusion44, Kulik (ack)
+mentors: Jamarr, Kulik (ack)

@@ Line 53: / Line 53: @@
 == 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. Implementing a CEGUI [http://code.google.com/p/skia Skia] renderer would help greatly with that.
+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 [http://code.google.com/p/skia Skia] renderer would help greatly with that.
 difficulty: Hard
 mentors: Jamarr, fusion44, Kulik (ack)

← Older revision		Revision as of 19:37, 31 January 2012
Line 54:		Line 54:
	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.		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. Implementing a CEGUI [http://code.google.com/skia Skia] renderer would help greatly with that.		It would be cool if we were able to draw a subset of SVG with this API. Implementing a CEGUI [http://code.google.com/skia Skia] renderer would help greatly with that.
		+
		+	mentors: Jamarr, fusion44, Kulik (ack)