 |
Corus M2 Planning
From Rex community wiki
M2 will culminate in the release of 0.1
Schedule
First estimate of releases
- Milestone 2 release: End of December
Change Action Items
- Leverage Qt to minimize dependency problems (DBus, Gstreamer/DirectShow, ...)
- Per-company post-scrum in-person meetings
- Implement maintainership system with code review to minimize stepping on toes
- Use feature-oriented teams to avoid client or server-only silos
- Use documentation to keep the others informed on your work
R&D Tasks
| Ryan
| Research proposal for interaction design (and practical implementation)
|
| Ryan
| Investigate Qt DBus integration for Naali services and events
|
| Ryan
| Investigate Qt signalling mechanism or custom for Naali events
|
| Ryan
| Investigate QScript method overriding capabilities
|
| Jukka, Tuomo, Ryan
| How to share the screen real-estate with multiple modules who will each want to draw their own QWidgets.
|
| Ludocraft?, Ryan
| Storing custom rigs and skinning+morphing structures on the inventory/asset server.
|
| Ludocraft?
| Investigate large redesign of server-side story; protocol, server modules.
|
| Toni
| Investigate proposal for overriding and extending ReXLogic or other modules.
|
| ?
| Design a dependency build/package system.
|
| HeikkiT, Ali
| Investigate the overlap between Qt/Poco/Boost.
|
| Everyone?
| Cost benefit analysis of migrating entire viewer to be a Qt application.
|
| Ludocraft, Playsign, Ryan
| Document ideal content pipeline with game content creators.
|
Shared Focus Points
- Improve visual quality in world
- User interface and interactions, 2D and 3D
- World object scripting and interaction
- World editing and content creation pipeline
- Inter-personal communication and interaction
- Avatar quality, realism, and editing
- Infrastructure, Framework, Modularity, Extensibility
Product Backlog
The below is rough, un-prioritized, first product backlog.
- API/Module for client modules to manage their own embedded and standalone QWidget scenes
- Support for 3D UI scenes with QWidgets (html, video, vnc)
- Dialogs for creating, editing and deleting objects and managing the associated attributes
- Dialogs for maintaining used assets and their relationships
- Visual editing using transform/rotate/scale gizmos
- (Batch) import and export assets
- Standard editor-like tools: undo, redo, preview
- Ability to move data both ways in Content DCC <-> in-world
- Avatar basic visual features: appearance, attachments
- Avatar animations, post-animation morph targets.
- EC model for 3D UI content and avatar content.
- compete, easy to use, visually appealing, modern UI:
- see UI tasks in other categories
- full intra region teleport, intra trust domain teleport:
- Map UI (Terrain, avatars, objects etc.)
- Map teleport implemetation
- touch interaction:
- touch trigger (clicking object launches event in simulator, packet exists in sludp protocol)
- protocol addon: web dialog packet
- Render web dialog in client side for user input
- build and deploy in reversable pipeline:
- complete asset and inventory systems with basic security:
- implementing webdav protocol
- implementing webdav user acl
- http CB assets uploading
- asset reference architecture?
- user registration and integration of authentication
- chat (text and voice):
- refactor comm module (Telepathy-Qt ???, voip signaling) (*)
- fix windows patches for telepathy components (*)
- chat UI Qt Widget (*)
- presence UI, Qt Widget (*)
- voip streaming
- spatial chat/voice
- friends/contacts/social grouping
- easy deployment of servers
- seamless login from web, from viewer, and between worlds (teleport):
- Open a Naali from web browser (CB link)
- teleport to another world inside Naali (CB link)
- server deployment and management tools
- serialize entire world state to standard file format
- expose the relevant internal APIs to Javascript and/or Python
- QtScript and PythonQt can automatically use QObject properties, slots and signals. Is a possible technique for exposing viewer internals (scene data, services like raycasting).
- QWidgets can be defined using dynamic languages, so e.g. the dialogs for editing objects and managing assets could be implemented in py or js. Should be easier and quicker to do than in c++, and allow easier modification and extensibility by 3rd parties.
- for both local trusted code and untrusted code from network. Only trusted code using Python was implemented for 0.0.1 (is useful for system things like spawning new processes, listening to custom network ports in the viewer etc).
- running untrusted client side code, received over the net
- may be attached to objects, regions or other world or asset data
- using the same API as the local trusted code (viewer addons, parts of viewer itself), but possibly only a subset if necessary for security reasons
- only Javascript (QtScript) targeted 'cause it is built for sandboxing
|
|
