[Bf-cycles] Cycles contributor meeting notes

[Nathan Letwory]

Hi,

Thanks for writing this up. It would have been great to attend, but this
year was not that year.

Comments inline where necessary.

On 11/05/2016 03:04, Brecht Van Lommel wrote:
> https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Roadmap

Cool. Shadow catcher and Cycles Disney BSDF are currently in one form or
another in use. Both still need work to be as we want them. I'll be
revisiting the patches when I finally get back to them. Here a small
test with the Cycles Disney BSDF patch, augmented with a configurable
specular color:

https://twitter.com/nathanletwory/status/794538887108497408

> CONTRIBUTING

> Code documentation and wiki is lacking, we'll try to update it in the
> coming weeks. Stefan Werner reports that lack of documentation was not
> a real problem for him in integration. This may not be true for
> everyone though.

In general not a problem no. I'd liked code documentation on several
occasions, i.e. that shader ID gets overloaden with some extra
information at some point, member and class documentation and so on.
Sure, one can find out by reading code, but that can mean jumping around
a lot before the picture becomes clear.

> 
> CONTINUOUS INTEGRATION

Perhaos this could be used also to automatically sync the stand-alone
repository. Yes, there is the script by Sergey, but that works on linux.
And still is manual. CI can be used to automate that.

> XML FILE FORMAT
> 
> Poser integration is using this already, with some modifications, no
> one else seems to be using it in production. They might be able to
> contribute back changes to Cycles master to make this more complete.
> Would like to be able to write out scenes exported from host
> application, and then read them back, in a way that's mostly
> automated.

For Rhinoceros 3D we use this extensively also. This is also used for
Grasshopper 3D, and we'll be continuing to do so.

That said, we currently use a C# implementation of the XML API, but we'd
be really happy if this can be retained.

> File format itself doesn't matter too much, might switch to something
> else than XML if needed. But as long as the Cycles API can read/write
> it, it's not a big deal.

I'd like to stick with XML, because currently a switch away from that
would mean re-implementing the parser.

> MATERIAL EXCHANGE
> 
> File format for exchanging materials would be useful. Some possibilities are:
> 
> Cycles XML: covers all data we need with no conversions, easiest if we
> only need it for Cycles.
> NVidia MDL: already mature and comes with a material library, but no
> open source implementation.
> MaterialX: will be open source, but is still being developed.

Again, XML is already up and running. We use the XML format especially
for materials.


> BIDIRECTIONAL RENDERING

I'm pretty sure that most of our users would love to see something like
this.

> TEXTURE MIPMAPS AND CACHE

> Motivation: users have very high resolution textures and don't want to
> have to worry about scaling them down, with a texture cache that's
> automatic.

Automation we love.


> UDIM / PTEX
> OPENVDB AND VOLUME RENDERING

Not of very much importance to us at the moment. I guess this will stay
optional when building Cycles code...

> STATISTICS AND DEBUGGING
> 
> For production there is a real need to be able to analyze performance.
> Lots of things we could do here:
> * Memory usage stats
> * Performance counters
> * Time based sampling (but how to scale it for a long running render?)
> * HTML reports or display in Blender
> * In principle can all be done with lower overhead compared to total
> render time so it can be always on

Especially interesting if there is a good API to retrieve this
information instead of putting everything into printf's.

> SPLIT KERNEL
> EMBREE, RADEONRAYS
> GPU FEATURES
> METAL
> ANYDSL

Whatever makes Cycles faster and better - and with the possibility to
turn of such features on compile time :)

> SHADER CODE DUPLICATION

> Adding a shader requires changes to too many files and code is
> duplicated for SVM, OSL, GLSL. There is some code reorganization we
> could do to reduce the number of files to modify. However to solve the
> duplication entirely we'd need some major macro magic or a custom
> intermediate compiler or code generator that abstracts the different
> systems.
> 
> Unclear how to tackle this in the near term, maybe some incremental
> improvements are possible.

Without having any proposal (it seems unclear to everybody at this point
anyway), I'd hope macros won't be considered. Debugging that kinda code
is awkward and annoying.

> VIEWPORT
> The Blender viewport project also has some implications for Cycles,
> Dalai will make a proposal for that.

Not really important to us, as long as the implications don't result
into big integration problems for us :)

I am sad I wasn't able to join, by the looks of the notes it must have
been a great meeting.

Did the meeting talk about C++1x usage in an effort to drop boost
dependency? For our usage we have also essentially dropped OpenImageIO,
since Rhino already has image reading code etc. Only the ustring part is
really in use, so there is a heavily cut-down version of OIIO (just that
what is needed minus all image reading code). Ideally we'd want a Cycles
that has as few dependencies as possible, but I understand that isn't
necessarily the main focus :)

/Nathan

-- 
Nathan Letwory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20161105/ef568797/attachment.pgp