Summer of Code 2008

Google has a regular Summer of Code event where they sponsor students from all around the world to contribute to Open Source projects. OpenSG is one project that is applying to get support to further the project and get new people excited about the project.

Basic Requirements

Check out the Google SoC Student Advice page on general advice and requirements.

OpenSG is a C++ system, therefore every student that wants to work on it needs to have good understanding of object-oriented programming using C++. How good depends on the specific project, high-level extensions can probably get by with being able to understand how to use things like STL, while lower-level work needs to be comfortable to write STL-like code. If we find somebody that can understand/write boost-level code that would be very exciting! We strongly prefer people that have experience in working on a project, either of their devising or another Open Source project.

OpenSG is also a 3D graphics system based on OpenGL. It would be very helpful and for most project even required to have a basic idea of how 3D graphics and OpenGL work.

Just like every project it would help to get an overview what OpenSG is and does, and at least make sure you're able to compile and run the tutorial examples. For all but the most basic extensions being able to compile and run the actual library will be necessary, so give that a try, too. On Linux systems it will be pretty simple, for Windows it's a little more complicated, but check out wiki:Building to see how to do it. If you have problems feel free to ask, we're happy to help.

We expect everybody working on a SoC project to be an active part of the community. You will get an individual mentor, but you'll be part of the community and everybody's here to help you. To do that you will have to join the users and core mailing lists, check out MailingLists for details on how to do that.

But here's the meat:

Ideas for OpenSG SoC projects

This is a list of possible SoC projects. It's not complete in any sense of the word. If you have any idea of a project thta is not on this list we're always open for new things.

1. Extend Collada Loader

Difficulty: Fairly low. Nothing beyond the basic requirements should be necessary.

OpenSG's Collada loader is functional, but far from complete. It can handle basic geometry and basic materials, but Collada is much more than that. The goal of this project would be to extend it to include a larger part of the spec, especially shaders and maybe animations. How much exactly would be up to you to decide.

2. Cluster Rendering extensions

Difficulty: Medium. You do need to understand and extend the Clustering code.

Clustering is one of the strong points of OpenSG, but there are some areas that could use some extensions. The composition pipeline is currently straight C++ source. It would be interesting to have a version that uses SSE to speed up the operations, to have support for HP's Parallel Compositing Library, or to use graphics hardware for it.

It would also be interesting to add support for Infiniband networking to speed up the network transfer. We have Infiniband systems to develop on.

Last but not least there is currently no system that supports compositing of transparent objects. We have ideas on how to do it, but this will require some creative ideas and commitment to make it work. On the flipside this could end up being a research publication in the graphics/visualization community.

3. Terrain Support

Difficulty: Medium. You do need to select an appropriate terrain algorithm, know OpenGL and create a new NodeCore in the system. Not magic, but not trivial.

Terrain is not a core component of OpenSG, but more and more applications are interested in it, thus so are we. There are a number of approaches to render large terrains, from fairly simple like ChunkedLOD to very sophisticated out-of-core paging Gigatexture methods. We would be interested in a system that can work from a high-resolution height/texture map and displays data in a view-dependent interative way. The level of sophistication is a choice of the student, at the least we would like to see ChunkedLOD-level work.

4. FileIO Redesign

Difficulty: Low. This is a very low level part that does not require graphics and complex C++ experience.

We have had a number of discussions about how to redesign the FileIO layer to allow better and more flexible file reading and writing, as well as plugin handling. Now we just need to find somebody that has the time to implement it. The discussion is at Dev/FileIO, please use that as a guideline to formulate the project proposal.

5. Integrate a Physics Engine

Difficulty: Medium. You need to understand adding a number of components to the system, and how to get the information the physics needs in and out.

There are a number of high-quality physics engines available now (like ODE or Bullet). We would be interested in an integration that allows simulations to use OpenSG as the structural basis. We have an old attempt to integrate ODE that could be used as a basis.

6. Update Striping Code

Difficulty: Medium. You need to understand geometric data structures.

Reordering vertices in an object is one way of optimizing throughout, depending on the object quite significantly. OpenSG has a basic striper, but new research has come up with much simpler and better methods, see http://www.cs.princeton.edu/gfx/pubs/Sander_2007_%3ETR/index.php or http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4376184. The goal would be to integrate either one into OpenSG as a preprocessing option.

7. Manipulators

Difficulty: Medium. You need to get fairly deep into the system to add interactive components.

One way to interact with 3D scenes is to have interactive manipulators (see Coin3d for an example). The goal would be to create a library that supports manipulators for OpenSG applications.

8. Scene Viewer Redesign

Difficulty: Low. This requires 2D GUI (most likely Qt) experience and some basic OpenSG usage.

We have an example program to load models, but it's fairly simplistic and not very easy to extend. The goal of this project would be to design a new scene viewer that supports more of OpenSGs features (shadows, lighting etc.) and that allows to create arbitrary size screens shots.

9. Using OpenSG Clustering for Multi-User Applications

Difficulty: Medium. You need to use OpenSG cluster distribution and work with ChangeList storage and filtering.

OpenSGs clustering is mainly used for one-way communication for tiled display systems. But the basics are very capable of being used for two-way communication. It just has never been done. The goal of this project would be to write an example application that has two users manipulating their own scenegraph and having those changes reflected on the other side. It would be great if basic locking mechanisms were supported.

10. Volume Rendering

Difficulty: Medium. You need to learn or know shaders, and get into OpenSG FBOs and multi-level rendering, and implement it in a new OpenSG NodeCore.

Volumetric data is becoming more available, especially large data. New algorithms use ray marching on the graphics card for efficient volume rendering. The goal of this project is to add a current volume rendering node to OpenSG.

11. osb export-plugin for 3ds (including animations)

Difficulty: High. You need to understand the 3ds Plugin-SDK and 3ds' internal datastructures, you need to understand the animation support (which is/will be experimental), you need to know almost all aspects of the SceneGraph (Materials, Geometries, etc). Anyway, there is some code to start with. You need a commercial license of 3ds to get access to the SDK.