[Bf-cycles] Bf-cycles Digest, Vol 56, Issue 13

Sergey Sharybin sergey.vfx at gmail.com
Thu Dec 24 17:42:02 CET 2015


Hi,

As i understood, you're writing a RenderEngine subclass to implement render
scheduling layer, is it correct?

If it's an addon which does all the scheduling job then not sure how much
we can help from Cycles. You'll be mainly limited by what Blender Py API
allows to do and it's already sort of comprehensive enough.

For closer integration with Cycles you'll likely need to move forward with
existing device_network.cpp and do all the jobs distribution totally
transparent for artists (they'll simply choose "Renderfarm" device in the
user settings and keep using blender as if they're using Cycles directly).
This, however, is not really aligned with your plans of supporting physics
types of jobs.

So at this point we all be happy to help, but it's not really clear what's
really needed and what are the questions are?

On Wed, Dec 23, 2015 at 3:38 PM, James Crowther <
jamesharrycrowther at gmail.com> wrote:

> Hello Sergey, nice to meet you (sort of!) :).
>
> Hmmm, I don't have any diagrams or code I can show you right now I'm
> afraid. However, I can describe what the api does more or less if that
> would help? The addon started life as just that, an addon, but the we
> realised that we couldn't justify writing a whole new render engine. So we
> are now focussing on turning our code into an api that can be used to
> distribute and accelerate different tasks.
>
> So that is what our planned api does, takes data from a client machine and
> then distributes it in real time to a number of nodes which then perform a
> commanded task (such as rendering the scene in this case) and then combine
> and return the results.
>
> However it is planned that the 'data' and 'task' I speak of can be
> generic, at least to a point. For example, I'm currently talking to a
> researcher in Portugal (specialist in fluid simulation and also part of
> Problender, the Portuguese Blender assoc)  about how I could accelerate the
> Blender physics engine using our same api.
>
> Essentially what we have built and will continue to build is a method by
> which data can be streamed out to nodes on a network in real time, and then
> the results of some process that acts on that data, streamed back again.
>
> As the prototype clearly shows, we have done a crude version of this and
> we chose the cycles render engine as a particular use case.
>
> Why I am wanting to work more closely with the cycles group is that at the
> moment I am finding it time consuming to integrate with cycles from the
> 'outside'. Essentially I am doing two tasks, developing our API and at the
> same time, attempting to integrate it with cycles. I am fast realising that
> it might be better to work with you all on the integration part. I am still
> happy to do that work, but I need to ask a lot of questions about the best
> way to do it.
>
> So that is my proposal, I am happy to share my progress and any
> information necessary for others to understand what I am doing with the
> group if I might be allowed to ask about how certain things are done.
>
> One example of this is the node editor, with cycles and blender internal,
> the node editor will display the material node tree, but not when I enable
> my addon and use it as a 'render engine'. It seems that Blender does not
> recognise my addon as being able to support the ShaderNodeTree tree-type
> and so won't display the material node-tree.
>
> I could spend a lot more time trying to figure this out by trial and error
> and hacking, but this seems inefficient when I could reach out and
> collaborate.
>
> Kind Regards
>
> James :)
>


-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20151224/f5ce13ce/attachment.htm 


More information about the Bf-cycles mailing list