<div dir="ltr">Hi Sergey, sorry for missing this reply! I had some time off from the internet over christmas and am catching up. <div><br></div><div>I think I understand what you are saying with regards to subclassing the render engine class vs closer integration. </div><div><br></div><div>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;</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>Kind Regards</div><div><br>James :)</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 25, 2015 at 10:00 PM, <span dir="ltr"><<a href="mailto:bf-cycles-request@blender.org" target="_blank">bf-cycles-request@blender.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Bf-cycles mailing list submissions to<br>
<a href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bf-cycles-request@blender.org">bf-cycles-request@blender.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bf-cycles-owner@blender.org">bf-cycles-owner@blender.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Bf-cycles digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Bf-cycles Digest, Vol 56, Issue 13 (Sergey Sharybin)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 24 Dec 2015 21:42:02 +0500<br>
From: Sergey Sharybin <<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>><br>
Subject: Re: [Bf-cycles] Bf-cycles Digest, Vol 56, Issue 13<br>
To: Discussion list to assist Cycles render engine developers<br>
<<a href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>><br>
Message-ID:<br>
<CAErtv247zp=RsVyQf=<a href="mailto:FScoiOGVWXuBEcqdrvaRFPcsJ_dAvrcg@mail.gmail.com">FScoiOGVWXuBEcqdrvaRFPcsJ_dAvrcg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
As i understood, you're writing a RenderEngine subclass to implement render<br>
scheduling layer, is it correct?<br>
<br>
If it's an addon which does all the scheduling job then not sure how much<br>
we can help from Cycles. You'll be mainly limited by what Blender Py API<br>
allows to do and it's already sort of comprehensive enough.<br>
<br>
For closer integration with Cycles you'll likely need to move forward with<br>
existing device_network.cpp and do all the jobs distribution totally<br>
transparent for artists (they'll simply choose "Renderfarm" device in the<br>
user settings and keep using blender as if they're using Cycles directly).<br>
This, however, is not really aligned with your plans of supporting physics<br>
types of jobs.<br>
<br>
So at this point we all be happy to help, but it's not really clear what's<br>
really needed and what are the questions are?<br>
<br>
On Wed, Dec 23, 2015 at 3:38 PM, James Crowther <<br>
<a href="mailto:jamesharrycrowther@gmail.com">jamesharrycrowther@gmail.com</a>> wrote:<br>
<br>
> Hello Sergey, nice to meet you (sort of!) :).<br>
><br>
> Hmmm, I don't have any diagrams or code I can show you right now I'm<br>
> afraid. However, I can describe what the api does more or less if that<br>
> would help? The addon started life as just that, an addon, but the we<br>
> realised that we couldn't justify writing a whole new render engine. So we<br>
> are now focussing on turning our code into an api that can be used to<br>
> distribute and accelerate different tasks.<br>
><br>
> So that is what our planned api does, takes data from a client machine and<br>
> then distributes it in real time to a number of nodes which then perform a<br>
> commanded task (such as rendering the scene in this case) and then combine<br>
> and return the results.<br>
><br>
> However it is planned that the 'data' and 'task' I speak of can be<br>
> generic, at least to a point. For example, I'm currently talking to a<br>
> researcher in Portugal (specialist in fluid simulation and also part of<br>
> Problender, the Portuguese Blender assoc) about how I could accelerate the<br>
> Blender physics engine using our same api.<br>
><br>
> Essentially what we have built and will continue to build is a method by<br>
> which data can be streamed out to nodes on a network in real time, and then<br>
> the results of some process that acts on that data, streamed back again.<br>
><br>
> As the prototype clearly shows, we have done a crude version of this and<br>
> we chose the cycles render engine as a particular use case.<br>
><br>
> Why I am wanting to work more closely with the cycles group is that at the<br>
> moment I am finding it time consuming to integrate with cycles from the<br>
> 'outside'. Essentially I am doing two tasks, developing our API and at the<br>
> same time, attempting to integrate it with cycles. I am fast realising that<br>
> it might be better to work with you all on the integration part. I am still<br>
> happy to do that work, but I need to ask a lot of questions about the best<br>
> way to do it.<br>
><br>
> So that is my proposal, I am happy to share my progress and any<br>
> information necessary for others to understand what I am doing with the<br>
> group if I might be allowed to ask about how certain things are done.<br>
><br>
> One example of this is the node editor, with cycles and blender internal,<br>
> the node editor will display the material node tree, but not when I enable<br>
> my addon and use it as a 'render engine'. It seems that Blender does not<br>
> recognise my addon as being able to support the ShaderNodeTree tree-type<br>
> and so won't display the material node-tree.<br>
><br>
> I could spend a lot more time trying to figure this out by trial and error<br>
> and hacking, but this seems inefficient when I could reach out and<br>
> collaborate.<br>
><br>
> Kind Regards<br>
><br>
> James :)<br>
><br>
<br>
<br>
--<br>
With best regards, Sergey Sharybin<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.blender.org/pipermail/bf-cycles/attachments/20151224/f5ce13ce/attachment-0001.htm" rel="noreferrer" target="_blank">http://lists.blender.org/pipermail/bf-cycles/attachments/20151224/f5ce13ce/attachment-0001.htm</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br>
<br>
End of Bf-cycles Digest, Vol 56, Issue 16<br>
*****************************************<br>
</blockquote></div><br></div>