Google Summer of Code (2009)

Google's Summer of Code initiative allows budding academic developers to work with established open source teams as an alternative to a typical summer-job, helping improve projects and maintaining the OSS ecosystem.

This page contains a list of project ideas and some information on how we expect the mentoring process to work this year. As previously, each accepted student will have their own wiki page to flesh-out ideas and implementation details.

Google's application period has now ended and 3 students have been accepted…

• Daniel Walters - Distributed rendering
• Rafael Campos - Geometry cache
• Trevor Lovett - Dicing optimisation

Refer to the Google SoC timeline for details about future deadlines.

The role of mentors is to help students out with both conceptual and technical issues. We intend for mentoring to include a strong component of code review - code reviews are extremely important for maintaining overall code quality. They're also helpful for newcomers to understand stylistic issues related to the codebase.

Our mentoring candidates are:

• Administrator/Coordinator & Mentor - Paul Gregory
• Mentor - Chris Foster

One of the keys to a successful project is good communication between the student and mentor, as well as the rest of the team. The development team has several communication channels which we'd like the students to make the most of:

Firstly, we have a weekly meeting at #aqsis on the freenode IRC network. Students will be expected to provide an informal weekly progress report at each meeting in the same way as the rest of the developers. Meetings are also a useful platform to discuss difficult problems while you have the attention of the entire team. For a typical example of how a meeting runs, check out some of the past meeting summaries and associated IRC logs.

In addition to the weekly meetings, the aqsis developers regularly hang around on the #aqsis IRC channel. The wiki provides a good place to write down designs in more detail, and the wider aqsis community can be reached via the mailing lists and forums.

Accepted students should sign up to all three mailing lists. The aqsis-commits mailing list is particularly important to keep up to date with current development. The aqsis-development list is used as a place to discuss commits and general design issues. Finally, the aqsis-builds list is connected to the build system, giving those without access to certain hardware the ability to check the results of their work across different platforms.

Ideally, we're looking for people with

• A strong interest in computer graphics
• Good C++ skills, particularly in “modern” C++ design (familiarity with the boost libraries is a plus)
• A reasonable level of English and enthusiasm to communicate with the team.

Students looking to submit proposals to Google can do this via their online tool.

Here's a rough list of checkpoints related to getting involved:

1. Students write the initial proposal and submit it to google. You are welcome and encouraged to interact with the community at this stage.
2. Accepted students refine their proposals with help from the mentors until everyone is happy that the basic issues are understood enough to begin implementation.
3. Students should read the relevant developer documentation - in particular the code guidelines - paying special attention to the example code in the trunk/aqsis/coding_standard/ directory in svn.
4. svn access will be provided to the students. Depending on the nature and scope of the changes, a source branch will be created for the work to progress.
5. Students start committing code. Mentors will review commits wherever possible, especially in the first stages as the students get up to speed.
6. The code should be tested as it is developed. The aqsis regression test suite (RTS) is helpful to ensure that changes don't break existing behaviour. Where possible, a suite of unit tests should also be developed to test the code as it is created.
7. The progress reviews required by google will provide good points to stop and take stock of how we're going. If necessary we'll revise the project goals to encompass more or less depending on the current progress.

Following is a list of projects which we think are worthwhile. These are arranged in a rough order of precedence, starting with the projects which we think are most exciting and realistic.

A brickmap is an efficient method for storing arbitrary 3D data. They are designed to represent dense 3D data efficiently, in such a way that the data can be reloaded and reused during subsequent rendering passes for efficiency. A fairly accurate technical analogy is that brickmaps are the 3D equivalent of a mipmapped texture in two dimensions.

Brickmaps are particularly useful to cache expensive illumination calculations for subsequent use during beauty renders and can also be used to implement translucency or indirect illumination.

This project would involve at least

• Design of data structures to hold and efficiently sample brickmaps in memory.
• Design and implementation of file formats for brickmaps and point clouds.
• A tool to convert point clouds to brickmaps (integrated into teqser - the aqsis texture processer)
• Implement a shadeop to query 3D textures.
• Implementing a shader function to create point clouds - bake3d().

If time permits, the project could also implement a brickmap-visualization tool, possibly integrated with the aqsis advanced framebuffer.

For further reading, it's worth first checking out the paper from pixar on the subject. The references therein may also be useful.

Renderman interface filters are a way to modify the stream of RI commands just before they are executed by the renderer. This can be very valuable in a complex rendering pipeline: it allows the user to add or remove parts of a scene independently of the source of the calls to the API. For example, an RI filter could be used to remove all spheres from a scene, turn all polygon meshes into subdivision surfaces, or even grow hairs from a given object.

Pixar defined the RI filters interface for PRMan, but their documentation isn't officially available on the web. One source of useful information on the interface is the 3delight documentation on RI filters.

The aims for this project would be

• Document the Rif API in sufficient detail to be compatible with other RenderMan renderers.
• Implement the API by modifying the Ri* API functions to call filters where necessary.
• Create an interface which allows filters to access the RenderMan state (traditionally this is covered by the “Rx” API).

The recently implemented advanced aqsis framebuffer is very functional and already a big improvement on the old framebuffer. However, it lacks user interface polish and features.

The aim of this project would be to improve usability and implement a range of features such as

• Combining multiple images using various compositing modes.
• Improved image visualisation - gamma correction, depth map visualisation
• Improved image comparison tools - locked zoom and pan for pairs of images, possibly an image diff tool.
• Selection, reordering and rescaling of arbitrary image channels for viewing AOV data.

One advantage of this project is that piqsl is isolated from the core renderer so less work would be required to become familiar with the existing codebase.

Aqsis needs a separate raytracing subsystem to complement the current Reyes based system. The implementation would need to work alongside the current system, utilizing the shader VM and therefore needs to implement an efficient surface caching system.

We realize that writing a raytracer that integrates efficiently with a full reyes renderer is a complex task which is beyond the scope of a single summer of code project. However it would be valuable to have a proof of concept prototype available.

Implementing a raytracing engine can be split into the following broad and nontrivial tasks:

• Implement a geometry cache. We would need:
  1. Data structures for storing grids which have been diced at multiple resolutions and displacement shaded.
  2. A strategy to keep the resident cache size under control.
  3. Efficient ray intersection against the geometry held in the cache. This will require a choice of spatial partitioning scheme.
• Make the shader virtual machine reentrant. The shaderVM must be able to efficiently process calls to the trace() shadeop.

Much of the core renderer code is less efficient than it could be. Aqsis has an optimization sub-project called project beaker which is currently addressing this issue. One or several of the optimization projects listed there could usefully form the core of a SOC project.

In particular, the proposed redesign of shaderVM inner loops would be a fruitful place to start looking. It would involve some advanced template metaprogramming in order to reduce the amount of code duplication while increasing the execution speed. Some initial proof of concept code for this already exists in the trunk/testing/prototypes/shaderVM_codegen/ directory in svn. If template metaprogramming techniques turn out to be too difficult to apply for this purpose, some other code generation technique will be necessary.

There are many other optimization opportunities throughout the aqsis core, more than we have developers to deal with! If people are interested in optimization, talk to us and we can probably find something interesting and useful for you to do.

A level set is a voxel-based data structure which efficiently represents complex implicit surfaces, such as splashing water. This project would implement support for rendering level sets in Aqsis.

Because the “blobby” objects in RenderMan are also implicit surfaces, it should be possible to reuse much of the code for rendering blobbys. A first place to begin looking at this is the code in trunk/aqsis/renderer/render/blobby.{h,cpp}.

Tasks:

• Implement an implicit surface class (child class of CqSurface)
  1. We need code for surface splitting, bounding, (and dicing?) - see the blobby code for ideas.
• Decide upon and implement an interface for getting implicit function values into the renderer. This needs some careful thought:
  1. The interface should integrate well with the standard methods for specifying geometry (probably via a call to RiGeometry)
  2. Perhaps it would be worth considering a custom file format for efficiently storing level sets (perhaps prefiltering also makes sense?)
  3. Could a callback interface for large datasets be worthwhile? (only useful from the C API)

There's plenty of other areas where students could usefully contribute code, some of these include

• Layer rendering, using a mechanism like AOV, allowing different objects to be rendered into different images - Useful for compositing.
• Hardware-accelerated rendering (GPGPU), for improved render-times - Similar to Gelato or Parthenon.

Additional ideas may be found on our roadmap page and on a user survey from a couple of years back.

If you don't find something you like above or have a great idea of your own, we'd love to hear from you! It's probably best to contact us first on any of

• the #aqsis IRC channel on freenode,
• the aqsis-development mailing list, or
• the aqsis forum.

Tell us about your idea, and we can help you create an outline to add to this wiki page. Even if you're going to use one of the ideas above, we'd love to hear from you anyway.

This should be a great opportunity for anyone looking to get more involved within the world of 3D rendering, with an experienced multi-faceted team on-hand offering invaluable guidance.

Now, time to get this show on-the-road!