It all sounds good to me.

Personally I think implementing something like the Disney principled BSDF is important. As I understand it this shader was used for everything in Big Hero 6 (except for hair and volumes), and it doesn't have that many parameters, so that seems quite powerful and simple for users.

I would also enable multiple importance sampling by default for lights, volumes and world. Probably filter glossy as well.

For the GPU it would be nice to let a single GPU render multiple tiles at once, to get rid of the tile size problem. For the CPU multiple cores could also cooperate on the same tile too.

Basically I think being simple to use is one of Cycles' strengths, and it would great to make it even simpler. But it's entirely up to you guys to decide what to work on of course.

Wouldn't really call it "Cycles for Blender 2.8x", more like "Cycles roadmap" or so.

There's numerous of patches which are to be finished here and which could be applied for whatever our next release will be:

New features:

• Self-shadowing option
• Shadow catcher
• Denoising (combined with variance estimation which should be also aligned with adaptive sampling). This also actually touches render pipeline and compositing, but some extra info is to be provided by Cycles.
• Motion blur center (basically, which frame corresponds to fully opened shutter), D1380
• Sample offset option for the renderfarms

Optimization:

• Merge remaining optimizations from the Gooseberry branch
• Theraded object export, D618
• Fallback to simplier area light samling for small area lights being far away from the shading point
• Low light threshold, D832

Experiments:

• Camera lens nodes
• Use new Perlin noise

But this is surely only stuff i've been working on, bigger plan will include work like:

• Finishing work with OpenVDB and Alembic (main problem currently is the pipeline)
• Switching to texture definition objects (or whatever their official name is) to overcome texture limit for CUDA cards with compute capability 3.5 and above.
• Switching to non-packed image textures for OpenCL (will mean OpenCL 2.x bump)
• Improvements in subdivision surfaces, real bump mapping

And surely feedback from @Brecht Van Lommel (brecht) is also good here.. So the list could actually become much-much longer.

I'm not sure opening a design task is the best way to communicate this. We've got handful developers in the area, we can just agree on the roadmap and do a code.blender.org post. Otherwise i'm afraid this task will get flooded with feature requests, requests to change priorities and so on.

Hi,
I mainly opened this to collect some feedback from Cycles developers, which can be used as a basis for further discussion at e.g. the Blender conference in Amsterdam.

@Brecht Van Lommel (brecht): Nice ideas. I agree that we should rethink some defaults in Cycles and as you said, enable MIS for example.

@Sergey Sharybin (sergey): Good list! Just one question, I thought OpenCL 1.2 is required for the non-packed image textures, sure it's 2.0? We sure want to jump to OpenCL 2.0 at some point, but I am afraid it will take some time before all vendors support that.

One other thing that I would like to tackle are the various "todo" comments in the code. We have 202 "todo" comments in the cycles code base, maybe it wouldn't be a bad thing to spend a few days on these, and try to solve some of them or make sure they are still valid.

Please read the original message here which says "NOTE: For now this task is only meant for Cycles developers and module members!" Thanks.

@Thomas Dinges (dingto), well ok, two things got mixed here. For packed textures 1.2 is indeed the bare minimum. With 2.0 we can get rid of CPU roundtrip for the split kernel. But either my brain mixing some stuff in now (crunchtime with thesis eeh) but it could also be some neato stuff for textures support arrived in 2.0.

One more thing which will be handy in 2.0: workaround we did for global/private address space function arguments. In new OpenCL it's possible to skip doing manual tricks and benefit from some sort of c++-ish polymorphism.

And i agree that re-evaluating TODOs in the code is a good thing. Maybe even mention all relevant ones in the Cycles TODO Wiki page.

P.S. One more major thing (not directly Cycles-related) -- node/shaders graphs presets! This issue appears every so often now, really need to be addressed. But that's more of a Blender side work (which might be not so sexy-looking).

Some stuff from my current list is:

• • Compressed encoding (LogLuv 32bit) for float textures to reduce memory usage of huge HDRs
• Grouping smaller textures into bigger ones to allow more textures on GPU (that might be obsolete with Sergey's post above)
• Cubemap output for the panorama camera
• Trying out the "Weighted Path Tracing idea" mentioned on BA: It's a mix of Pathtracing and Branched PT, where the user sets a number of secondary rays per sample and weights for the individual closure types

Regarding filtering, I'm currently working on a test implementation of Locally Weighted Regression filtering. LWR also has an extension for flicker-free animation filtering and adaptive sample distribution, so I think it would be a great approach for Cycles. However, the adaptive stuff means that it must be done directly in Cycles, not in the Compositor. Also, the current way in which Blender renders animations doesn't really allow for cross-frame filtering...

But IMHO the most important area is the handling of render passes, both in the Render API and in Cycles. A flexible system would allow many new features such as true AOVs (adding separate output nodes in the shader tree, maybe with Light Path Expressions to specify where they will be evaluated), "Light groups" (in the Luxrender sense, images passes that only contain the contribution of certain lights), many more Debug passes and Pass support for external renderers without having to modifying Blender...

Adding to the TODO tackling, I think time should be spent finishing some of the more half-baked features present before jumping into new things. Hair, hair shaders, volumes, and deformation blur still add much more to render time than should be acceptable, and proper displacements+autobump are a big part of a production pipeline that have been sitting on the table for years. Support for industry standards like UDIM and Ptex should also be high priority, even if Blender itself can't properly create them yet, especially considering that Cycles is now stretching its legs in other 3d packages. UDIM especially would likely take almost no time to implement, as everything we would need is already in the code.

I've played with the LWR patch. It is indeed very impressive. While not 100% accurate, I think it's a fantastic goal for Cycles considering the target audience and their likely limited access to render horsepower.

@Lukas Stockner (lukasstockner97):

Cubemap output for the panorama camera

I mentioned to @Sergey Sharybin (sergey) my interest in implement this, but he said he would prefer to have this supported via camera nodes instead.

In T46258#337677, @Matt Heimlich (m9105826) wrote:

Support for industry standards like UDIM and Ptex should also be high priority, even if Blender itself can't properly create them yet, especially considering that Cycles is now stretching its legs in other 3d packages. UDIM especially would likely take almost no time to implement, as everything we would need is already in the code.

For UDIM you really need to use something like the OIIO texture cache to avoid running out of memory, which is not easy to add to SVM. For OSL it's simple but in that case you can already write a simple OSL shader for UDIM. Even if you keep all textures in memory it's still a bunch of work to implement.

In my opinion UDIM is also a pretty terrible solution to the problem, but unfortunately seems to have become a standard so it may be unavoidable at some point. There's a bunch of undefined things regarding how to handle missing tiles, how to do wrap modes for texture filtering, how to filter across tiles, which tile to read metadata from, etc, and the large amount of image files is not very user friendly to work with.

I'd be curious to hear your thoughts on .tx support as well, Brecht (and Thomas and Sergey). The render time savings in Arnold and Renderman are pretty enormous in my own tests.

Interesting notes on the UDIM front. I've done some manual setups using the mapping node with decent results and figured that a basic implementation wouldn't take anything more than a couple of functions to parse the file name and automatically adjust the mapping accordingly.

.tx files currently should give good memory savings (and faster startup time) when using OSL, since that uses the OIIO texture cache to load just the necessary tiles and resolutions. For longer renders there won't be significant render time savings, unless you run out of memory.

For SVM it's more difficult because we'd need to add support for ray differentials for all nodes that manipulate texture coordinates, which OSL handles automatically. For CPU rendering that would be good that add. GPU support for a texture cache would be great but it's very challenging to implement.

Speaking of ray differencials.. We need to support mipmaps for SVM. It's quite straightforward to do on CPU, on GPU where we're limited in memory and can't really do on-demand scaling it's a bit tricky.

The idea i had in mind here is to exploit CPU roundtrip which currently happens in split kernel. Roughly speaking, kernel might detect missing data which then lead to CPU roundtrip and missing data will be uploaded to the GPU. A bit tricky to implement in a proper way so performance is not killed by the constant data transfer happening..

Hi gang, I have been a little silent lately.

For OpenVDB, currently it is using a node to get the volume from a file. This feels about right for just sampling the grid as a texture, but when it comes to ray intersection (accelerated ray marching/empty space skipping) it feels a bit hackish to me. Also I haven't really spent time to figure out which grid in a file to use for ray marching, or how to let the user choose it. Currently it is using the first grid with "density" in its name (case insensitive) or the first scalar grid otherwise. Then I'm not sure how to extend it to have, maybe, motion blur going on (how to choose the velocity grid if one or more are present, etc...).

I would rather see (make) a better integration where volumes are dealt with like objects, with some attributes to get what the user wants. The attributes don't really need to be passed through the attribute node, they could also be hidden in a convenient volume node or else. For that, I would also like to see some sort of volume primitive in Blender, which is then passed to Cycles. At first this will only be for gas simulations (maybe liquids too). This would also make it easier to deal with external VDB files as they don't have the same scale and orientation than Blender's (so first import in Blender, set proper scaling..., then pass to Cycles), and it will also make it easier to support level sets (or distance fields) rendering in Cycles.

Anyway, I haven't put much thoughts into this, and it deals with workflow/pipeline a lot, so this is open for discussion.

P.S. : there is also compilation with OSL/LLVM that needs to sorted. Initially DreamWorks had accepted my quick patch to replace the built-in C++ typeid system with boost's typeid system (easier and less painful than creating a home brew system for it's usage in OpenVDB), so it can be turned off, but then they reverted the change because... it's using boost and they want to get rid of it and switch to C++11 (good and bad news right there ;). Anyhow, I think it should be doable with my current implementation to isolate the OpenVDB code so there are no collisions with OSL during compilation. I'll check on that shortly.

@Kévin Dietrich (kevindietrich), I think it would indeed be best to have a built-in volume object in Blender, there's lots of awesome possibilities with the OpenVDB library.

If you want an intermediate solution for Cycles though I think it would be fine to have a mesh property that has an OpenVDB filepath. Then you don't need to add a new node and all attribute lookups can simply use that file. For ray intersection I would automatically use all attributes requested by the shader network. So that means you might intersect multiple grids and then merge the intersections (or you could try to merge the grids though that's trickier if they have different transforms).

The RTTI issue is annoying yes. It should indeed be possible to isolate either the OSL or OpenVDB code to use different RTTI flags, I think we were doing that for OSL at some point.

Please, this is not the place for feature requests, if you have ideas mail bf-cycles, post proposals on forums, on the wiki, etc.