- 1 GSoC Project Proposal (the one I submitted on April 9th)
GSoC Project Proposal (the one I submitted on April 9th)
- Name: Guilherme Kunigami
- E-mail address: kunigamigmail.com (also firstname.lastname@example.org)
- IRC username: kunigami
Brief background info:
I'm a computer engineer, MSc. student at UNICAMP. I've experience in C/C++ (4+ years), design of algorithms (ACM-ICPC and Topcoder contestant). Relevant graduate courses I've taken are computational geometry, computer graphics and image processing. Although my research area is essentialy combinatorial optimization and computational geometry, I have a great interest in computer graphics, specially ray tracing.
I've never participated in big projects or Google Summer of Code but already contributed to Scilab translation and bug fixing. I also developed some personal projects like a visualization to computational geometry algorithms (http://www.loco.ic.unicamp.br/~kunigami/projects/geometria/).
Tasks performed so far:
- Submtted a patch: http://sourceforge.net/tracker/?func=detail&atid=640804&aid=3250116&group_id=105292 - Read development guideline: http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/HACKING
About my time: I'm finishing my master thesis and I think the timing is quite suitable for dedicating to the project. Until middle of May, I need to send a final version of my thesis to my advisor. After that will begin a period of reviews and small changes that will take me little time. So, from middle of May to August 15th, I can surely spend +40h/week. Before that, I'll have to check final details of my thesis and thus I'm not sure if I can spend more than 20h/week. To raise the chances that the project will be done, I'm declaring that I'll take priority on Google Summer of Code over my thesis from May 23th until August 15th. I'll be able to postpone a month or two of my thesis if I successfully complete the program.
I'm enrolled with my University until the end of July, so I'm eligible according to GSoC rules.
Brief project summary
Shaders in BRL-CAD are implemented using C language. Recently Sony released its shading language as open source, now called OSL. This is a C-like language that works like a framework to write shaders. It was specially developed to work with raytracers, which is also the application of BRL-CAD shaders. To this end, an idea is to implement BRL-CAD shaders using OSL. In this proposal I provide a brief description of BRL-CAD shader system and OSL specification. Then I describe a top-level approach to accomplish this task.
Detailed project description
I've little (if none) experience with shaders, but I really want to learn about them and this project is an opportunity to both learn and contribute to open source. To this end, I'm declaring this project to have the greatest priority among the others I'm applying. In the past weeks, I've been researching BRL-CAD code and OSL to better understand how shaders sytems work. I can now devise how BRL-CAD could benefit in using OSL language to implement their shaders.
BRL-CAD Shader System
A shader is implemented at liboptical with the name sh_<shader name>.c. It may have several particular functions, but one of them is always required and is named <shader name>_render. It returns the color of the light that will be seen when a ray shot by the raytracer hits the surface of an object using this shader. In general, shaders models properties like color, transparency, reflection and diffraction. The default shader of an object is the plastic texture, modeled by the phong shader. There are several other types of material such as cloud, wood, fire, etc. Lights in BRL-CAD are treated as a special type of shader that emits light .
BRL-CAD shaders are currently written in plain C. They're mainly used by the raytracer system, both in the stand-alone rt application or through mged application using librt. Shaders are compiled as shared libraries and are loaded dynamically at runtime.
Recently Sony opened the code of their shader language . Chatting at IRC and from the project description, it's clear that this language is to be carefully analyzed in order to benefit BRL-CAD shader system, specially because it is developed for raytracers, which is the same use BRL-CAD current system has. OSL is a C-like language that can be used to write shaders.
One can write individual shaders using OSL and integrate them afterwards using shaders groups. These groups are basically a network (more specifically, a directed acyclic graph, also known as DAG) of individual shaders, called layers, and they're connected like UNIX pipes: the output of one is the input of the other. Using OSL, setting up this network is simple as coding the individual shaders and defining a set of pairs of (ouput shader, input shader). This is like the stacking of shaders present in BRL-CAD.
In general, the output of a shader is not a final color but instead it's a structure called closure. It stores parametrized formulas that would be used to evaluate the final color but the variables are maintained. This has several advantages such as:
We can recompute colors more quickly when there are changes only in the lights We can compute the final color for given only a direction. Given an input and output direction, it's possible to get the amount of light propagated from the input to the output. The last two items are quite interesting for raytracers.
The OSL represents a interesting framework to develop shaders. BRL-CAD shaders could benefit from it by improving performance with the concept of closures. Also, we could take advantage of already implemented shaders for OSL and when developing new shaders for BRL-CAD we would be contributing to OSL database, which is, according to  (may be outdated) quite sparse.
There are some issues to solve first. In the OSL specification document from January 2010, it's said that some components are assumed to exist in order to implement shaders using OSL. One of them is the integrator, which combines the color closure, lights and view-dependent variables. They say in the future they would provide a way to implement them through OSL, though I'm not sure what is the current state. If not, it would need to be included in the project.
Here is how I plan to execute this project: study the details of BRL-CAD and OSL shaders. Change the shader system of BRL-CAD to adapt to shaders implemented with OSL (this is important so we can use any shader developed with OSL). Reuse shaders that are already implemented with OSL and that fits the current shaders of BRL-CAD. Then, implement possibly missing shaders. After implementing/porting the first shader, we must check consistency of the new shader system, testing if it works well with the raytracers. Also, after each shader is added, we need to check if the result is similar to the replaced one. An extra task that can be done, if time allows it, is to implement new shaders with this language. Another good thing that can be done is to write a small tutorial on how to implement shaders using OSL.
Community Bonding: Study in depth details OSL and BRL-CAD shaders. Possibliy take a look at other shaders like yafaray and pixie.
- May 23 to June 20 (4 weeks):
Evaluate which changes need to be done in order that BRL-CAD shader system can accept OSL language-based shaders. Design and start implementing these changes. Report advances to mentor.
- June 20 to July 18 (4 weeks):
Research any shader that can be reused for BRL-CAD or implement one. Test it against the new system. Perform tests over the new shader system.
- June 18 to July 1 (4 weeks):
Port or implement missing shaders, always performing tests after each one and checking with mentors if the shaders are being rendered as expected.
If time allows it, implement additional shaders and/or write tutorial on how to develop a shader using OSL.