<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<style type="text/css">.mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: .5;z-index: 10000}
</style></head><body style=""><div>Just want to add:</div>
<div>- 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)...</div>
<div> </div>
<div>sorry for the noise, please continue ....</div>
<div> </div>
<div>/Thomas</div>
<div> </div>
<div><br>> Lukas Stockner <lukas.stockner@freenet.de> hat am 6. Oktober 2016 um 20:12 geschrieben:<br>> <br>> <br>> Hi all,<br>> <br>> I think Brecht's mail covers the most important points, but here are some more specific topics I'd like to address:<br>> <br>> - 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?<br>> - 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...).<br>> - 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:<br>> - What limitations does the current system have (that matter in actual use)?<br>> - 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?<br>> - If not, what else can be improved (candidates are e.g. caching the spatial light distribution or gradient-domain path tracing)?<br>> - Network Rendering<br>> <br>> Am 02.10.2016 um 21:19 schrieb Thomas Dinges:<br>> > Hi all,<br>> > <br>> > Blender Conference is getting closer and I was asked to coordinate the<br>> > Cycles meeting a bit. (See Tons original mail below for details about<br>> > the meeting).<br>> > <br>> > I would like Cycles contributors, who attend the conference to mail back<br>> > topic suggestions and wishes. What shall be discussed during the<br>> > meeting, is there anything in particular we should focus on?<br>> > <br>> > Apart from a brief introduction round, discussing a roadmap for the next<br>> > year, there should be plenty of time for other topics.<br>> > <br>> > Best regards,<br>> > <br>> > Thomas<br>> > <br>> > <br>> > Am 10.08.2016 um 12:33 schrieb Ton Roosendaal:<br>> >> Hi all,<br>> >><br>> >> 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).<br>> >><br>> >> 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.<br>> >><br>> >> 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.<br>> >><br>> >> 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.<br>> >><br>> >> The main topics and outcome of the meeting can be presented the day after in an open feedback session in the Salon.<br>> >><br>> >> I suggest to schedule as follows:<br>> >><br>> >> Saturday 29 October: Room available from 13:30 - 17:00 <br>> >> Sunday 30 October: Salon presentation in afternoon.<br>> >><br>> >> Thanks,<br>> >><br>> >> -Ton-<br>> >><br>> >> --------------------------------------------------------<br>> >> Ton Roosendaal - ton@blender.org - www.blender.org<br>> >> Chairman Blender Foundation, Producer Blender Institute<br>> >> Support us - join blender.cloud or Blender Dev Fund.<br>> >><br>> >> _______________________________________________<br>> >> Bf-cycles mailing list<br>> >> Bf-cycles@blender.org<br>> >> https://lists.blender.org/mailman/listinfo/bf-cycles<br>> > <br>> > _______________________________________________<br>> > Bf-cycles mailing list<br>> > Bf-cycles@blender.org<br>> > https://lists.blender.org/mailman/listinfo/bf-cycles<br>> > <br>> <br>> _______________________________________________<br>> Bf-cycles mailing list<br>> Bf-cycles@blender.org<br>> https://lists.blender.org/mailman/listinfo/bf-cycles</div></body></html>