Introduction
Gather high-level product requirements here in the Product Backlog.
Detailed implementation tasks are listed in each Sprint Backlog.
Ideas of Product Backlog and Sprint Backlog from Scrum http://en.wikipedia.org/wiki/Scrum_(development)
Product backlog
The following was created in consultation with what Product Owners could be found. This list should contain an ordered list of desired end-user visible features. This list can be generated based on market research, community consensus, or business needs.
- Cross-platform build system and installer/uninstaller
- View World (static scene: avatar, prim, meshes, terrain, weather, camera)
- Draw GUI and issue Keyboard/Mouse commands (including maps)
- Translation to Japanese (and other languages)
- Chatting/IM
- walk, fly, sit, teleport (with resp animations), and touch objects
- Import mesh and texture data (COLLADA)
- Simple transforms on inworld objects (scale, rotate, translate) through GUI
- Social cues: animations such as waving, emoticons, status icons
- Customize avatar with predefined textures or bodies
- Streaming audio/video
- Web integration/browser embedding into viewer
- Particle system
- 3D Spatial Voice
- IPv6
- Search for land and people
- Skinning GUI/HUD (for games)
Sprint backlogs
Before Sprint 1
- new libSL packet decoding in C# for testing (compare results with C# libsl)
- new libSL packet network transmission in C# for testing (borrow OpenSim C# packet handling code)
- new libSL network test: "hello world" application written in C++ or C# and using Johan's new C++/C# libSL
- Must login, send/receive packets to OpenSim, logout
- new libSL packet decoding with C++ back-end
- new libSL packet network transmission in C++ (rewrite OpenSim C# packet handling code in C++)
Sprint 1
List here the detailed tasks to be completed in the first sprint.
Later we can split off the sprint backlogs into separate pages.
Unsorted tasks for a future sprint
- Python wrapper for Johan's new C++ libSL
- new libSL network test in Python: "hello world" application in Python using Johan's new C++ libSL back-end
- Must login, send/receive packets to OpenSim, logout
- Linux Build system using CPython instead of PythonNet
- no more C# libSL, use new Python-wrapped C++ libCL
- build Python-Ogre modules, Python-new-libSL modules
- PyGTK GUI
- Windows build system using CPython instead of PythonNet
- Mac OSX build system using CPython instead of PythonNet
- Packet event management in Python
- event/subscriber pattern in Python to listen for packet events
- periodically poll for incoming packets, generate all events for all incoming packets
- prefer to avoid multithreading at first to simplify debugging
- Primitive object management on viewer
- What happens when an object changes texture, shape, hollowness, etc. You must keep track of the correspondence between primitive objects on the server and ogre entities.
- Render position of incoming OpenSim primitives
- Render orientation of incoming OpenSim primitives
- Linear velocity interpolation of incoming OpenSim primitives
- Primitives continue to move with their last reported linear velocity until a new packet comes in that changes the linear velocity
- Angular velocity interpolation of incoming OpenSim primitives
- Primitives continue to move with their last reported angular velocity until a new packet comes in that changes the angular velocity
- Render shape of incoming OpenSim primitives except sculpted prims
- Difficult due to extrusion, twisting, hollowing. Use something like FractalSpline library.
- need to interpret packet parameters
- Render shape of incoming OpenSim sculpted prims
- Render static texture of incoming OpenSim primitives
- Render incoming OpenSim terrain shape
- Render incoming OpenSim terrain texture
- Avatar rendering (big task, requires further analysis)
- Allow avatar movement and send avatar position/orientation packets to server
- includes camera handling and any camera data that must be sent from viewer to server
- Render water level with water mesh
- what is the water level height? can it change?
- Render texture animations
- Render particle systems
- Handle deletion of primitives
- Handle changing of primitive properties (texture, location, velocity, animation, etc) - may be big task and require breaking down into smaller tasks
- PyGTK and Ogre main loop integration with separate GUI and rendering windows
- Embed Ogre rendering window into PyGTK canvas
- Determine transformation matrix between OGRE coordinate system and OpenSim coordinate system
- IPV6
- 3D picking basic - given 2D screen coordinate, determine which 3D object was clicked
- 3D picking menu display - after clicking on an object, pop up a menu with options for that object
- Rendering engine independence (tentative thoughts, not clear yet)
- ability to swap out rendering back end
- must avoid storing scene graph state or object state on the local 3d engine; all state comes from the server
- must avoid using the 3D engine's utility functions e.g. matrix or quaternion routines
- this will slow down development until we can find a general-purpose 3d math library that supports everything we need for viewer-related object computations
- dependencies on rendering engine:
- use of engine's 3D matrix/quaternion math routines
- use of engine's 3D picking facility
- use of engine's model loading/unloading capabilities
- use of engine's bone animation routines
- use of engine's scene graph, collision, spatial structures, intersection tests, etc
- use of engine's animation facilities
- etc