[Bf-committers] qdune and the render api

[Jonathan Merritt]

Hi Brecht,

That interface is still a great improvement over the previous  
situation! :-)  Will materials and lights (etc.) eventually be part of  
the push model as well, or will they be pulled by the plugin somehow?

One thing that I notice is that you only provide a single  
transformation matrix with RenderObject.  In RenderMan, ideally you  
want at least two transformation matrices, so that you can set up  
transformation motion blur.  Is there an easy way to access additional  
transformation matrices for each object?  How about complete mesh data  
from multiple frames, for deformation motion blur?

To "properly" implement a RenderMan exporter on top of your API will  
require an initial run of data marshaling, during which your API will  
execute all of its calls and the RenderMan exporter will build its own  
scene graph.  Following this, the exporter will have to output all of  
the required passes for each frame (shadow maps, reflections, etc.).    
If this marshaling task can be kept to a single frame then it is  
probably achievable, but if we need somehow to wait for multiple  
frames in order to pick up the full set of object transformation  
matrices and states then it will probably still be a nearly impossible  
task to implement.  Consequently, it would be good to set things up so  
that all required data is available for each frame.

Jonathan Merritt.

On 10/11/2007, at 5:39 AM, Brecht Van Lommel wrote:

>
> Hi,
>
> There would still need to be plug-ins of course. The difference is  
> that this one is based on callbacks, see this file for the current  
> interface:
> https://svn.blender.org/svnroot/bf-blender/branches/qdune/blender/source/blender/render/intern/include/renderinterface.h
>
> Each renderer plug-in would need to fill in those callback functions  
> with their own code still.
>
> Brecht.
>
>> ----- Oorspronkelijk bericht -----
>> Van: Shaul Kedem [mailto:shaul.kedem at gmail.com]
>> Verzonden: vrijdag, november 9, 2007 06:22 PM
>> Aan: 'bf-blender developers'
>> Onderwerp: Re: [Bf-committers] qdune and the render api
>>
>> Brecht,
>> - how does the mini render API work as an API? doesn't it require  
>> all of the
>> transformations from blender to renderer <X> to be in blender side?
>>
>> What I mean is, creating an API which calls the target renderer
>> requires knowledge of the particular renderer's work in blender (or  
>> as
>> a plug in), doesn't it?
>>
>> Thanks,
>> Shaul
>>
>> On 11/8/07, Shaul Kedem <shaul.kedem at gmail.com> wrote:
>>> "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."
>>>
>>> - how does that work for an API? doesn't it requires all of the
>>> transformations from blender to renderer <X> to be in blender side?
>>>
>>> On Nov 8, 2007 3:36 PM, Shaul Kedem <shaul.kedem at gmail.com> wrote:
>>>> Thank you for the detailed answer.
>>>>
>>>> I think that if you are to pause your work on this a detailed  
>>>> page is
>>>> a very good idea.
>>>>
>>>> Where is your mini API code ? BF-blender?
>>>>
>>>>
>>>> On Nov 8, 2007 3:29 PM, Brecht Van Lommel <brechtvanlommel at pandora.be 
>>>> > wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>>
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers