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

[James Crowther]

Hi Sergey, sorry for missing this reply! I had some time off from the
internet over christmas and am catching up.

I think I understand what you are saying with regards to subclassing the
render engine class vs closer integration.

Currently we have created our own subclass of the render engine class in
order to build a proof of concept prototype. We did this just to get
something to work. It has its shortcomings as I'll briefly describe;

1. We want the user to choose 'cycles' or 'blender internal' as usual and
just use blender as normal as you suggested. Currently we have to use our
subclassed render engine which distracts the user from their normal user
experience.

2. When we select our render engine, we're missing parts of the user
interface for node materials, most likely because our subclass of the
render engine class isn't recognised by blender as supporting nodal
materials.

I like what you said about working with the existing device_network.cpp,
but I have no idea what this is, is there a source you could direct me to
so that I can familiarise my self with it?

Kind Regards

James :)



On Fri, Dec 25, 2015 at 10:00 PM, <bf-cycles-request at blender.org> wrote:

> Send Bf-cycles mailing list submissions to
>         bf-cycles at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.blender.org/mailman/listinfo/bf-cycles
> or, via email, send a message with subject or body 'help' to
>         bf-cycles-request at blender.org
>
> You can reach the person managing the list at
>         bf-cycles-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-cycles digest..."
>
>
> Today's Topics:
>
>    1. Re: Bf-cycles Digest, Vol 56, Issue 13 (Sergey Sharybin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 24 Dec 2015 21:42:02 +0500
> From: Sergey Sharybin <sergey.vfx at gmail.com>
> Subject: Re: [Bf-cycles] Bf-cycles Digest, Vol 56, Issue 13
> To: Discussion list to assist Cycles render engine developers
>         <bf-cycles at blender.org>
> Message-ID:
>         <CAErtv247zp=RsVyQf=
> FScoiOGVWXuBEcqdrvaRFPcsJ_dAvrcg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.htm
>
> ------------------------------
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> End of Bf-cycles Digest, Vol 56, Issue 16
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160101/8f7bed02/attachment.htm