OpenSG 2 Roadmap

This page shows a high-level roadmap, in priority order, of things that need to be done before we can release OpenSG 2. It is at a higher level than the individual tickets, to give a more condensed and more global picture. Each of these points needs to be broken down into individual, self-contained tickets (if you think you have a good grasp of the problem, feel free to split it into tickets). The tickets associated with one of these high-level points are listed after the point. If you're interested in working on any of these points and what you want to do is not yet listed as a ticket, please make sure to open a new ticket for your part (including estimated completion time), and add it the list of tickets of the point.

If you're interested in an even higher-level description that skips highly technical issues, please see wiki:OpenSG2Vision. The points below are based on the vision, but at a more detailed level, and split up into individual pieces that are somewhat independent. These are not hierarchical to simplify doing pieces with different priorities. For the actual technical discussion please don't add that here, to keep this page short and (as far as possible) concise, but add that to a separate page (or maybe to the wiki:Planning2_0 page, even though that will probably go away).

  • Do the transition to a C-pointer based FieldContainer implementation. (Discussion Tickets: )
  • Definition of the new edit paradigm (i.e. commitChanges: When, where and why?). (Tickets: )
  • Handling of plugins and pathes. (Discussion Tickets: )
  • File I/O (network, formats, extensions, etc.). (Discussion Tickets: )
  • Clean up rendering action(s) (Tickets: )
  • Port over clustering support from OpenSG 1 (Tickets: )
  • Port over shadow support from OpenSG 1 (Tickets: )
  • Port over other features/bugfixes from OpenSG 1. (Discussion Tickets: )
  • Redesign volume rendering module for more shader-based operation (Tickets: )
  • Define documentation model, document components(Tickets: )
  • Change unclear/confusing names (Discussion? Tickets: )
  • VBO integration (Tickets: )
  • UnitTest? Integration and Implementation (Tickets: )
  • Redesign and implement OpenGL ID handling for multi-threading and clustering (Discussion Tickets: )
  • Add support for face-based data to Geometry (Tickets: )
  • Write example programs for integration into other toolkits (Tickets: )

It might be nice if we could have a query to list all the tickets associated with a bullet, to get a quick overview and to judge completeness. But to that we need to associate some information that identifies the bullet with the ticket, and I'm not sure how to do that. The easiest might be to make them components, but that would give us a lot of components... --DR

Last modified 7 years ago Last modified on 01/17/10 01:11:44