Google Summer of Code 2007

From K-3D

Jump to: navigation, search

Overview

K-3D has been accepted as a mentoring organization for the Google Summer of Code 2007, a program providing $4500 summer stipends to students contributing to Free and Open Source Software. The program is finshed now, see Google Summer of Code 2007 Report for results.

Students

If you're a student interested in contributing to K-3D:

  • See our Brochure.
  • See the Student FAQ.
  • Look through the following project ideas, browse through our Future Work page for more ideas, or develop your own project idea!
  • Contact any of our mentors or the K-3D Mailing List with any questions.
  • Writeup your project proposal. You can contact us on the mailing for suggestions.
  • Go to the Student Applicant page to register your proposal.

Note that students are free to develop their own ideas for submission, the following projects are just suggestions - we're open to your own original ideas, and your odds of success are better if you propose solving a problem you're passionate about. Please don't flood the mentors and administrators with applications. Decide on one project for which you think you can do a great job, and concentrate on writing one great proposal, with lots of detail about what you plan to accomplish and by when.

Some advice for students:

Mentors

The following mentors will be available to work with students on their projects:

  • Timothy M. Shead, tshead@k-3d.com
  • Joaquin Duo, joaduo@gmail.com
  • Bart Janssens, bart.janssens@lid.kviv.be

Some advice for mentors:

Multi-Core / Parallel Processing

Mentor: Timothy M. Shead, tshead@k-3d.com

Description: As physical limits make it increasingly difficult to improve CPU speeds, hardware manufacturers are turning to "multi-processor" machines and "multi-core" processors to meet demands for greater computing power. The change from traditional single-CPU, single-core systems to ubiquitous multi-core, multi-processing machines will likely lead to significant changes in the way software is written. K-3D's pipeline architecture is uniquely suited to exploring these new architectures. For a given visualization pipeline, computation can be spread across multiple execution units in many ways:

Goal: Exploit multi-core, multi-processing hardware using K-3D's pipeline architecture. Create multi-threaded filters, explore distributing pipeline processing among different threads, different hosts, or any combination thereof. Develop empirical data on which techniques are best under different circumstances.

Requirements: A successful project will require strong C++ experience, and a knowledge of current multithreading and/or RPC techniques. Familiarity with 3D graphics and data structures is useful, but not required.

References:


GPU-Based Processing

Mentor: Timothy M. Shead, tshead@k-3d.com

Description: Many modern graphics cards include powerful programmable pipeline functionality. Because K-3D is used mainly for offline rendering using dedicated render engines such as RenderMan, much of this GPU functionality goes to waste. Even when using the GPU's programmable functionality for online rendering, rendering normally cannot begin until K-3D's pipeline processing is complete.

Goal: Explore using GPU processing in the implementation of K-3D filters.

Requirements: A successful project will require strong C++ programming skills, and a familiarity with writing GPU programs. Use of GLSL is preferred for portability, but not required.

References:

  • http://www.gpgpu.org/ - General-purpose computation on GPUs website.
  • http://libsh.org/ - A high-level, open-source library for programming GPUs in C++.
  • "Metaprogramming GPUs with Sh"
  • "GPU Gems"
  • "GPU Gems 2"
  • "OpenGL Shading Language".

Pipeline Visualization

Mentor: Timothy M. Shead, tshead@k-3d.com

Description: K-3D is designed around a flexible Visualization Pipeline architecture, where data sources, filters, and sinks are interconnected by users to create a document. Currently, there is only rudimentary support for providing users with a graphical view of the pipeline.

Goal: Create a scalable, portable user interface component for visualizing K-3D's pipeline. Any solution will have to scale both in the number of nodes, properties, and connections, as well as providing users with a useful (not overwhelming) display of their document. We leave the nature of the display deliberately vague, to encourage out-of-the-box thinking. See Visualization Pipeline Display for ideas.

Requirements: A successful project will require good C++ programming skills and familiarity with graphical user interface programming. Experience with / interest in infoviz topics such as graph layout and visualization will be of great help.

Energy Simulation Integration

Mentor: Timothy M. Shead, tshead@k-3d.com

Description: Energy Plus is a stand-alone simulation engine for modeling energy flows within buildings. The United States Department of Energy makes Energy Plus available to the public at no charge to encourage the design and construction of energy efficient buildings, reducing global greenhouse gas emission and reducing our dependence on non-renewable energy sources. Energy Plus does not provide any graphical user interface, relying on external tools to read and write its file format.

Goal: Create K-3D readers, filters, and writers to integrate with Energy Plus. Ideally, users should be able to:

  • Create geometry in K-3D, assigning material properties and other simulation attributes
  • Export an Energy-Plus-Compatible file
  • Run a simulation using Energy Plus
  • Import simulation results back into K-3D for 3D visualization and analysis.

References:


Aqsis Integration

Mentor: Timothy M. Shead, tshead@k-3d.com

Description: K-3D currently relies on external render engines to perform high-quality "offline" rendering. In particular, K-3D provides exceptional support for RenderMan, a de-facto film-industry standard for communicating scene descriptions to high-quality render engines. Although this approach is flexible, allowing K-3D to work with any RenderMan-compatible render engine (of which there are many), it does lead to a high volume of support requests from users due to versioning and installation issues, incorrect PATH settings, etc.

Goal: While leaving K-3D's current support for external render engines in place, integrate one or both of the two available Free-Software RenderMan render engines (Aqsis and Pixie) into K-3D as plugins, providing a one-install solution for modeling and rendering. Provide improved integration between the embedded render engines and the existing K-3D graphical user interface.

References:


K-3D + GIMP

News!: Gimp is actually pointing towards using Gegl wich has a lot to do with this idea. This should turn a bit the direction of this project and make faster its development.


Mentor: Joaquin Duo, joaduo@gmail.com
Description: Give GIMP the advantages of procedural generation. In the current GIMP if the user wants to change a parameter that is on the history of the creation s/he will have to undo all the steps after it, change the parameter and redo (but not automatically) the steps after that change. Instead, on procedural generation the user goes back on the "node history" (object stack) and simply changes the value. On the fly it is calculated and displayed to the user.
Lets suppose there is a photo of n number of steps to create it. That means the steps to recreate the image without having to undo and redo (as if the user knows what s/he wants as the final image without any undo). Now the true is that the user will do a lot of trial and error with the undo/redo tools until s/he came with the final result. If the users do a lot of undo/redo steps the real number of steps made by the user will be proportional to . While in a procedural image editor it will be proportional to n. As we can see if the image is very complex the proportion between one user using procedural and other using non-procedural grows linearly proportional to n. That means one user will do it n times faster.
Prototype Images:

Goal: Create a Gegl front end using K-3D, ports and extend its data types, filters and tools. Encourage interproject collaboration and integration (GIMP and K-3D). Attract more K-3D users and developers.

Requirements: A successful project will require strong C++ experience, and a knowledge about Glib, Gegl and GIMP.

References:


Here you can read more about Integrating K-3D with other application programs.

Fluid simulation

Mentor: Bart Janssens, bart.janssens@lid.kviv.be

Description: Add physics-based simulation of liquids to K-3D. The goal of this project is to implement a fluid simulation module for K-3D. The student is free to choose the method of simulation, but it should be based on the Navier-Stokes model for liquids to ensure realistic motion. During the implementation, care should be taken to define a clear interface between K-3D and the simulation engine, in order to facilitate the later implementation of other simulation methods. The simulation engine itself may be built from the ground up, or may be an adaptation of an existing GPL-compatible fluid simulation engine (i.e. Blender). The resulting module should at least be able to reproduce a moving liquid under the influence of gravity that can interact with other K-3D meshes. The resulting output must be visible in the OpenGL viewport for preview purposes and must render in the RenderMan engine for the final animation.

Goal: Implement a method for simulating fluids, and define a clear interface for future fluid simulation engines.

Requirements: Experience with C++, basic fluid dynamics knowledge, and optionally experience with numerical methods for PDEs.

References: The two most popular methods for fluid simulation in Computer Graphics are:


Near-Realtime Rendering Engine Using GPU

Mentor: Timothy M.Shead, tshead@k-3d.com who?


Description: Most hobbyists and semi-professionals frequently need to render projects fast rather than picture-perfect. Examples are visualizations of crime events and accidents, educational animations and architectural fly-throughs. In such cases, the quality level of a fast GPU based 3D engine often suffices. It is an annoying break in the modify-and-review approach to making animations, that a normal rendering of a one-minute animation can take hours if using shadows, bumpmaps, displacement maps and other common modern features, especially since a lot of those features are already being deployed in GPU-intensive computer games.

The project would consist of three parts.

  • Make a render-engine that uses the GPU to create pictures using all the necessary techniques available to achieve a pretty result, but that is otherwise under no obligation to be mathematical correct. For instance if it increases render timer from 0.1s to 10s to get mathematically correct depth-of-field, it would be much better to default to a common technique of using Z-based blurring in a post process phase to keep render time down to, say 0.15s.
  • Implement this engine into the engine plugin architecture of K-3D in a similar way that YafRay and Aqsis currently is, i.e. by implementing the k3d::icamera_preview_render_engine, k3d::icamera_still_render_engine, or k3d::icamera_animation_render_engine interfaces.
  • Implement a set of nodes/plugins which are specific to this engine for handling materials and lights. For simplicity it would probably be easier to create new nodes which can more easily be molded into the particular (and rather hack'ish) nature of typical GPU trickery.


Goals: Create a GPU-based renderer utilizing a broad selection of the many techniques in use for computer games today and implement it into K-3D. The goal is achieved, when the user can create a scene and adorn the elements with materials such that the final render shows signs of some form of the following techniques:

  • Lighting/shadowing. Using Z-based shadow-maps is a common technique, but others may be applied too.
  • Diffuse, specularity, bump mapping. A rather common way to simulate bump/displacement mapping is to use parallax scrolling.

The following nodes or a super- or sub-set thereof which embodies the same features set must be available to the user:

  • Lights:
    • Lamp - shining equally in all directions.
    • Spot - shining in a given direction. Angle-span of the cone must be adjustable, and a controllable soft edge would be preferrable.
  • Materials:
    • Material - Setting of diffuse, speculatity and bump maps plus the usual parameters.


Not goals, but wouldn't hurt:

  • Subdivision. Another more expensive - yet very acceptable in this almost-but-not-necessarily realtime context - is geometry shading or geometry instantiation using some form of render-to-vertex-buffer to subdivide the object
  • Post processing pipeline. Edge-enhancements, blurring, color-adjustments etc. Making a compositing pipeline like Blender has would not be hard, given that GLSL is very flexible and is realtime compiled.


Requirements: Good C++ experience. Very solid GPU-effect programming experience encompassing render-to-FBO, render-to-VBO, usage of floating point textures and particularly GL Shading Language


References:

Generic CAD System

Mentor: Timothy M. Shead, tshead@k-3d.com

Description: In generic CAD development, the modeller constructs parts which is glued together in assemblies by drawing basic primitives onto a 2D sketch, applying procedural modelling features to get 3D bodies and furnishes the CAD program with geometric constraints that must be solved automatically. S/he uses these techniques almost in every aspect of the work.

The sketching is done with a few very ordinary primitives: Lines, circles, arcs, rectangles. Any flat surface in the scene can become a sketch plane for further sketching.

The features mirrors the physical aspects of how the item will be constructed afterwards. Examples are filleting, which removes sharp edges so plastic parts will not stick to their molds, utilities for sheet bending of a metal sheet which must match what you get, if an iron worker is asked to manually follow the blueprint from the CAD program.

The constraints alleviates the modeller the burden of aligning and glueing elements together. A small set of elementary constraints is available. It is up to the modeller to supply enough constraints so that the computer can solve the final appearance of the item unambiguously but not so many as to give rise to conflicts.

An example of how to make a house with a door-frame and a door:

HOUSE-PART:

  • Make a Rectangle on the base XY-plane.
  • Apply an Extrude. You now have a 3D spaceous body. This body will have faces, which themselves (if they are flat, such as the sides of a rectangle extruded into a box) can become the drawing canvas of a new sketch.
  • Apply a Hollow-Out/Shell-Out feature leaving a box which is not a solid thing, but rather six thin plates of iron.
  • Select a face on the house and use it as a sketch-base where you can draw a Rectangle the size of your door.
  • Apply a Cut feature to that sketch, and tell it to cut all the way through to infinity in both

directions just to be sure.

DOOR-PART:

  • Make a Rectangle and Extrude it

HOUSE-ASSEMBLY:

  • The door must be able to swing back and forth on an axis. The quickest way to do that is to add a constraint that says that the pivoting edge of the door must remain coincident with an edge on the door frame around which the pivoting takes place. First select the edge on the door-part. Then select the edge on the house-part. Then add a Coincident-constraint.

Duly notice that the nature of the given constraints can be very advanced and will in some cases take hours to evaluate! In the example above, the modeller has constrained the ability of the door to move. This shows when manually trying to move and rotate the door. Since the edge of the door is fixed to another edge of the house, the degrees of freedom has been reduced, and the door can no longer hurl around in space freely.

Image:cad-example-build-house.jpg


Goals:

  • A CAD sketch canvas interface must be added to the system, icad_sketch_plane, as well as an interface that provides information about an objects available sketch planes, icad_sketch_plane_provider. All the nodes and filters which produce spaceous bodies with faces eligible for sketching must implement the provider interface, which has functions for querying sketch planes. Asking for a sketch plane returns a logical object, which implements the plane interface. It has functions for adding rectangles, lines etc.

These objects must be added to the system.

Sketch objects must be made:

  • Rectangle
  • Line
  • Circle

Feature objects must be made:

  • Extrude (can extrude both backward and forward)
  • Cut (can cut through the body both backwards and forward a given length)
  • Revolve (like the usual spin or sweep modifier)

Notice that is is a requirement that a feature does not split faces unnecessarily. If a CutHole feature cuts a square hole in a cube with 6 faces, then the new object will contain 6 + 4 faces, of which 2 of them now have a hole. The concept of a face in typical CAD use ordinarily is built around bezier patches which is silently stitched together to form a coherent face.

Image:cad-face-coherence-principle.jpg

Constraint objects must be made. It is undefined yet whether the constraint limits one or the other part. Probably a "father-child" relationship will be formed, since most parts are add-ons to a base part.

  • EdgeCoincidentToEdge - keeps two edges onto each other, but they can slide along each other. Constrains rotation to 1 dimension and movement to 1 dimension.
  • EdgeParallelToEdge - keeps two edges parallel. Constrains rotation to 1 dimension. Movement remains possible in all three dimensions.
  • FaceTangentToFace - keeps two faces tangent to each other. Notice that both can be curved! Applied to two balls, they will remain together like magnets, but can be slided along each other. Rotation remains possible in all 3 dimensions, but movement is constrained to 2 dimensions.
  • A solver which can be applied with the click of a button or continuously, and which will move parts around once a solution to all the constraints have been found.

NOTE: Making a CAD system is a great challenge. Some mildness in judging the result given the time window available seems to be in order.


Not goals, but nice to have:

Features

  • Fillet (Removes sharp corners by adding a round edge of controlled length)


Requirements:

A very solid understanding of vector algebra and probably also calculus. Some research must be done on the students own behalf, as we have not yet encountered a book entitled "How to make your own CAD system - the math behind". The mentors have a basic idea of how to apply matrix based equation solving to handle some of the problems. Besides that, adequate C++ knowledge.


References:

None yet.

Architecture CAD System

Mentor:


Description: At least two large architectural tools are know to the public today, ArchiCAD and SketchUp. Such tools are the architect's counterpart to rapid application development in programming. A mock-up of a building can easily be constructed and modified using terms and methods particular to architecture.

A part of the project is to invent a methodology for how to build a house, ruin, temple, pyramid and so on using the most intuitive techniques imaginable. Besides single objects, there will be a notable need for other uses: Landscapes, cities, harbours...

A lot of ideas are quite obvious (so much in fact, that one should be consider whether naive patents on the subject already exists). A workflow such as this is a good starting point:

  • Mold a landscape using a paint brush that draws rocks, grass and other features
  • Flatten an area and add a Foundation. This foundation will be leveled on top, but will also reach down into the ground as long as is needed. A small strip of faces looking like rubbles around the house must be stitched together with the rest of the soil mesh.
  • Right-click on the foundation, and choose BuildLevel to build the first (floor) level of the house. Extrude until the necessary height is reached.
  • Open the floor-plan editor. This is a 2D view, where inner walls can be drawn.
  • Each wall acts as a basis for drawing doors and windows.
  • Another level can be constructed by clicking on the top of the box which constitutes the current outer hull. Choosing BuildAnotherLevel will make another level. BuildRoofLevel will make a roof and a hollow attic. Inner beams must be constructed too.

Image:cadarchi-example-house-blueprint.jpg

The idea of using surfaces of 3D bodies as a canvas for 2D drawing is something that is shared between this project and the generic CAD project. In many ways, this project is a theoretically simpler and more narrow version of the generic one. Doors and windows can only be part of walls and always consists of door frame and door.

This project can be constructed separately from the generic CAD project in which case the resulting architecture CAD system doesn't have the constraint-facility, or it can be developed together with that project. In any event, interfaces between the two kinds of functionality must be defined.


Goals: Since the project does not necessarily require a lot of theoretical work, the completeness is measured according to how many libraries have been added.

At least the following should be provided:

  • Basic tools for construction of houses, both rectangular and other ground shapes. Foundation, BuildLevel (which builds a separate floor on top of a face) and BuildRoof
  • A large set of doors and windows representing important styled epochs and countries
  • Tools for making cityscapes: Generation algorithms for making a city-blueprint which will be populated with suitable buildings using random parametric variations (hint: The measurements of a house must be something that can be modified by a script)


Requirements: C++ knowledge and a good sense of how architecture works throughout history.


References: