[Soc-2007-dev] Status Report

Aaron Moore two.a.ron at gmail.com
Sat Jun 2 00:21:32 CEST 2007


Sorry if this is a bit verbose, I didn't realized I was writing a
status report until I got to the end and realized that I had just
written a status report... The next one will be more concise.

Progress Report 1

I've just had a chance to step back, take a breather, and look at what
I've done so far. It may not look like much, but I think I've made
some steps in the right direction, and also begun working out what
directions arn't the right one...

Here are a few of the ways I've attempted to break down the project so
far: Workflow: Determine requirements, design, implement. Research:
existing APIs, existing renderers, blender source. Existing APIs are
important because they show how others have broken this problem down
and created a proven working solution. Also, if my API was similar it
would be easier to port exporters. Existing renderers are important
because they are who I'm trying to give data to. And finally, the
blender source, of course, tells me what data I have to export and how
that's currently being done.

A few days before SOC started I began madly working through the
blender source. I tried to figure out the UI in an attempt to setup a
system for running test code, but failed at that. I searched with grep
and ctags. Finally, I had the idea of running the current source in a
debugger and following execution and examining the memory. These
methods have helped me start to produce a grasp of the source, but
talking with developers I'm sure will help much more. This was
research in the "blender source" area.

Just before summer of code started, I attended the developer meeting
on #blendercoders and got some very helpful suggestions, such as the
idea of examining the existing XSI API among others. The XSI API seems
well designed, so I have been reducing my work by taking it as
representative. I examined how XSI setup external renderers through a
system of callbacks, an internal plugin registrar, and a 'rendering
context' object which contains links to all the necessary data.
However the XSI scene description is a massive class hierarchy which I
soon got bogged down in and lost some time. This was my research in
the "existing APIs" area.

Next I turned from XSI to the Renderman Specification. I discussed
renderman and rendering in passes with Akhil, which was helpful, but
also got me thinking that I have some significant things to learn
before I create this design. I decided that in order to write an API
that will be used to write exporters I should have some knowledge of
what an exporters concerns are, so I merged these two ideas and
started working through the RISpec again, but this time writing test
RIBs along the way to verify that I understood it. This was very
aggravating, but I did get somewhere. I learned to read the specs more
carefully, and came to a better understanding of the parts that I did
work out in test RIBs. I used aqsis and pixie for test renders. This
has bee the extent of my research in the "existing renderers" area in
the last week.

I felt like I needed to study a few 3D concepts a bit more in order to
do this project, so I pulled out "3D Computer Graphics" by Alan Watt,
and read about transformations, viewing systems, geometry, an overview
of the rendering process, and some about materials. I think this will
help me make sense of what's going on in the blender source more.

I have finally come full circle. I've realized that where the question
"how does a given renderer want it's data?" certainly influences
design decisions in an API, the first question must be "what data do I
have to export and how is it structured?" So, short of a possible read
through of the Renderman shading language, which I have yet to do, I'm
headed back into the blender source. I will begin by examining the
data structures. My focus will be extracting the information I need to
create the design.

Finally concerning the workflow. I have been focusing on research
thus-far, that is, determining the requirements of my API. But in all
this research I have somewhat lost the goal of creating a full design
of an API. Tonight I have had a chance to sit down an think about how
I see the design at this point, and I feel more capable than I did
Monday. So my goal for the next week is to get the design document
written and begin discussing it on #blendercoders. My research of the
blender source should help me write the document, but I can't afford
to do research any more without making progress in producing a design.

Here are the things I want to get done in the next week:

   1. Finish reading about renderman shader language
   2. Write, peer-review, and finalize a framework for the API. Once I
have a general framework to work in, I'll be able to set it up in the
code. Having a foothold on the code would be good for making further
progress when the design is complete.
   3. Look over blender data-structures, current blender
implementation, and existing blender exporters.
   4. Block out the main sections of the API and design a first draft.
Use blender data-structures, XSI docs, and renderman spec as reference
/ inspiration.
   5. Discuss this with blender community on #blendercoders.

Aaron


More information about the Soc-2007-dev mailing list