[Bf-committers] qdune and the render api

[Brecht Van Lommel]

Hi,

> What is left to do in the SoC code? Was it stopped because of lack of
>time or due to other reasons?

The SoC code can only export meshes, without materials or texture coordinates. Also no metaballs, NURBS, etc. There was not enough time to finish it within the timeframe of the SoC project.

> Which of the routes would you take? your mini code or the SoC?

I would probably use my own code and enhance it with functionality and code from SoC, but part of the reason is of course that it is my own code. The difference between the two is that for SoC it was tried to build an API from the ground up, while I basically started changing the code, keeping all functionality working. That means the Render API is quite incomplete, while in my code there is a bunch of stuff not cleanly separated yet.

Also a difference is that in my code blender pushes the data to the renderer, while in the SoC code the renderer pulls the data from blender. The former was much easier to implement, because it did not require rewriting as much code.

> How much knowledge of the Renderer would one need in order to help on this?

It is not necessary to know the inner workings of the internal renderer, mostly general knowledge of Blender code helps I think. Though of course anyone working on this needs to become somewhat familiar with part of the render code, I didn't know much about it either up to a few months ago.

> How big is this project?

It's quite a lot of work to get a full render api that does everything we want, but I think it is feasible to get a basic, generic render api working fairly quick, based on my code. But that depends on how familiar with the code the person working on this is.

If someone is interested in working on this, I can make a detailed page on the current state, what should be done, and how I think it should be implemented.

Brecht.