dev:soc_2007 - Aqsis Wiki

Trace: » joron » stegu » survey1_results » dev » dsm
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Google Summer of Code (2007) ======

===== Overview =====

We have, for the first time, secured a place within Google's latest [[http://code.google.com/soc|SoC]] initiative to aid in the development of Aqsis, helping to improve our solution(s) for those interested in advanced professional 3D rendering.

This page will act as the hub/repository for this year's SoC activities, from proposal through to implementation - Simplifying maintenance and monitoring (single 'Bookmark').


==== Status ====

Google's application period has now ended and 2 students have been accepted...

  * [[dev:soc_dsm|Zachary Carter - Deep Shadows]]
  * [[dev:soc_multithreading|Manuel Antonio Fernandez Montecelo - Multithreading]]

==== Mentors ====

Our current mentoring candidates are as follows...

  * Administrator/Co-ordinator & Mentor - [[bio:pgregory|Paul Gregory]]
  * Mentor - [[bio:tcolgate|Tristan Colgate]]
  * Mentor - [[bio:joron|Michel Joron]]
  * Mentor - [[bio:c42f|Chris Foster]]

===== Ideas/Proposals =====



==== Planned Tasks ====

  * Raytracing implementation, which is a necessary pre-requisite for global illumination
    * 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. It would operate in the context of the //trace()// RSL command.
  * Global illumination and raytraced ambient occlusion implementation
    * Efficient implementations of the //gather()// and //occlusion()// RSL commands, utilizing the raytracing subsystem described above.
  * Multi-threading support
    * The internals of Aqsis are inherently single threaded. To take advantage of the new generation of multi-core processors, it will need to adapt to allow multiple threads to process the scene being rendered concurrently.
  * [[doc:dsm|Deep Shadow Maps]] implementation for the rendering of coloured and hair/fur shadows
    * A new form of shadow map that stores rich depth information as functions. This allows shadow mapping to be extended to support partially transparent surfaces, and colored shadows without the need to use raytracing.
  * New (advanced) //Framebuffer//, similar in nature to [[http://www.3delight.com|3Delight]]'s [[http://www.3delight.com/ZDoc/i-display.html|i-display]]
    * The idea here is to provide a more feature rich version of the //framebuffer// that includes such features as:
      * Multiple images open, allowing the artist to flip easily between renders/passes/frames.
      * Separate process, not tied to a running Aqsis, communicating via IPC.
      * Combining multiple open images using various compositing modes.
  * Brickmap and point cloud (3D texture) support.
    * 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. Particularly useful to cache expensive illumination calculations for subsequent use during beauty renders. Can also be used to implement translucency or indirect illumination.  This project will involve:
      * Design and implementation of file structures for brickmaps and point clouds.
      * Stand-alone tool to convert point clouds to brickmaps.
      * Stand-alone ([[http://www.fltk.org|FLTK]]? or [[http://www.tcl.tk/|Tk]]? -- since that is what RenderMan Artist Tools uses) brickmap visualisation tool.
      * Implement shadeop to query brickmaps.
  * Render playback tool.
    * A tool to take a sequence of high-resolution images on disk (i.e. the output of a render) and flip through them at full frame rate speeds.
  * Level set support.
    * A //level set// is a voxel-based data structure which efficiently represents complex implicit surfaces, such as splashing water.  This project is to implement support for rendering level sets in Aqsis.

==== Other Interests ====

  * Layer rendering, using a mechanism like AOV, allowing different objects to be rendered into different images - Useful for compositing.
  * Hardware-accelerated rendering, for improved render-times (similar to [[http://film.nvidia.com|Gelato]] or [[http://www.bee-www.com/parthenon|Parthenon]])
  * Additional visualisation tool(s) to aid the 'Creative' process (for example, interactive 'Print Preview' and/or 'Viewer')

<note>More (verbose) information can be found on our [[dev:roadmap|roadmap]] page.</note>

===== Getting Involved =====

==== Ideas 2.0 ====

  * Like to expand upon an idea/proposal, taking it further or a different direction than the original scope?
  * From a different field (realtime, software engineering, scientific visualisation, etc) but have something to add?
  * Have something to offer that hasn't already been mentioned?

If so, **don't** be shy, we'd love to hear from you!

Just create a user account on our main [[http://www.aqsis.org|website]], if you haven't already, and use the 'Login' option at the top-right of this screen.

You'll then be free to update this page, for others to read and review.

<note tip>Those looking for inspiration should browse our fairly recently [[feedback:survey1_results|user survey]].</note>

==== Google Submissions ====

Students looking to submit proposals to Google can do this via their [[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants|online tool]].

==== Development ====

For each accepted project we will create a new branch of the sources within our [[http://sourceforge.net/svn/?group_id=25264|SourceForge SVN]] repository, allowing each candidate to be free in their work without conflicting with our main (stable) codebase.

All projects will have continuous monitoring via our [[http://build.aqsis.org|build system]] giving those without access certain hardware the ability to still see the results of their work across different platforms.

The same system also handles automated generation of binaries/tarballs, allowing others (including non-technical users) to test your efforts and provide valuable feedback.

Naturally, at a point when your code works and everyone's happy it will be merged into our main codebase... ready for prime-time usage!

===== Conclusion =====

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 guideance.

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

Personal Tools

Search

Toolbox
