[Bf-cycles] Cycles contributor meeting at Blender Conference

[Wolfgang Fähnle]

Hi, some "features" often spoken about:

Settings for multiple GPU, now only one or all
Reduce CPU usage during render, now one CPU core 100% per GPU
Netrender
Async Cuda GPU, reduce render priority for better system response

Some was allready worked on but not finished or reverted.

Cheers, mib



Am 07.10.2016, 09:14 Uhr, schrieb Thomas Volkmann  
<lists at thomasvolkmann.com>:

> Just want to add:
> - support for getting vertex-group information (maybe just an ID?). At  
> the moment I >give each vertex group a different Vertex-color that I can  
> read with cycles nodes, >but it is tedious and very hard to manage with  
> a custom OCIO because the values seem >a bit messed up (e.g. vertex  
> color rgb(0.2) seems to be something different when >using an ACES  
> config)...
>sorry for the noise, please continue ....
>/Thomas
>
>> Lukas Stockner <lukas.stockner at freenet.de> hat am 6. Oktober 2016 um  
>> 20:12 >geschrieben:
>>Hi all,
>>I think Brecht's mail covers the most important points, but here are  
>> some more >specific topics I'd like to address:
>>- Animation rendering: Currently, Cycles only cares about single  
>> frames, but more >and more papers are based on information from  
>> multiple frames (including most >denoising papers). Can and should this  
>> be considered in Cycles?
>> - Render Passes: The current system is pretty much based on the legacy  
>> Blender >systems, but for the future a better system will be needed for  
>> a lot of features >(AOVs, light groups, possibly Cryptomatte...).
>> - Light Transport: Currently, Cycles is based on straightforward  
>> unidirectional >path tracing with next event estimation, but there are  
>> a lot of approaches to improve >upon that. Questions there are:
>> - What limitations does the current system have (that matter in actual  
>> use)?
>> - Is it desirable or even possible to go towards (optional)  
>> bidirectional methods? >Is it viable to limit the feature set for some  
>> methods (e.g. no ray visibility) if >they're not compatible with some  
>> options?
>> - If not, what else can be improved (candidates are e.g. caching the  
>> spatial light >distribution or gradient-domain path tracing)?
>> - Network Rendering
>>Am 02.10.2016 um 21:19 schrieb Thomas Dinges:
>> > Hi all,
>> >> Blender Conference is getting closer and I was asked to coordinate  
>> the
>> > Cycles meeting a bit. (See Tons original mail below for details about
>> > the meeting).
>> >> I would like Cycles contributors, who attend the conference to mail  
>> back
>> > topic suggestions and wishes. What shall be discussed during the
>> > meeting, is there anything in particular we should focus on?
>> >> Apart from a brief introduction round, discussing a roadmap for the  
>> next
>> > year, there should be plenty of time for other topics.
>> >> Best regards,
>> >> Thomas
>> >>> Am 10.08.2016 um 12:33 schrieb Ton Roosendaal:
>> >> Hi all,
>> >>
>> >> During the Blender Conference I would like to reserve a meeting room  
>> with 16-20 >seats (around a table) for a couple of more focused Cycles  
>> developers/contributor >meetings. This would be open for anyone who  
>> contributes to Cycles in one or another >way (cycles coders, 3rd party  
>> product integrators, studio pipeline engineers).
>> >>
>> >> Access to the sessions would be based on reservation, I will  
>> maintain a list of >participants, which I'll verify with Brecht and  
>> Sergey. I'll give priority to active >contributors and coders. One or  
>> two artists who are closely involved could be added >on the list too.
>> >>
>> >> Goal is to have quality time together, on high technical level, to  
>> discuss the >current projects and agree on a roadmap. No streaming or  
>> recording would happen here.
>> >>
>> >> Special attention could go to companies/developers who integrate  
>> Cycles in their >own products or studio pipelines, to make sure they  
>> can keep using Cycles and that >they feel welcome to contribute back.  
>> Finally the need for an 'architecture review >board' could be checked  
>> on.
>> >>
>> >> The main topics and outcome of the meeting can be presented the day  
>> after in an >open feedback session in the Salon.
>> >>
>> >> I suggest to schedule as follows:
>> >>
>> >> Saturday 29 October: Room available from 13:30 - 17:00>> Sunday 30  
>> October: Salon presentation in afternoon.
>> >>
>> >> Thanks,
>> >>
>> >> -Ton-
>> >>
>> >> --------------------------------------------------------
>> >> Ton Roosendaal - ton at blender.org - www.blender.org
>> >> Chairman Blender Foundation, Producer Blender Institute
>> >> Support us - join blender.cloud or Blender Dev Fund.
>> >>
>> >> _______________________________________________
>> >> Bf-cycles mailing list
>> >> Bf-cycles at blender.org
>> >> https://lists.blender.org/mailman/listinfo/bf-cycles
>> >> _______________________________________________
>> > Bf-cycles mailing list
>> > Bf-cycles at blender.org
>> > https://lists.blender.org/mailman/listinfo/bf-cycles
>> >_______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles



-- 
Erstellt mit Operas E-Mail-Modul: http://www.opera.com/mail/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20161008/810cf7c9/attachment.htm