Cycles developers and module members currently debate about development plan for 2.8 branch. Discussion on tracker concern mostly technical things and is only for those strictly involved in development. Reason for this is to avoid flood of random requests and comments, which is vital for good communication. I made this thread for us, cycles users to discuss about those plans, post ideas. Developers are welcome too, if they have time.
Developers discussion: http://developer.blender.org/T46258
(Please. Donāt post your ideas/request/feedback/questions there. That topic is dedicated only for them for purpose.)
CUDA kernel split and more love to built in procedural textures please me the most. Iām concerned about Bake status. For now nobody, even Dalai, mention anything about it.
Hadriscus- Kernel-split will bring better stability and faster rendering. Currently instructions to GPU are send in form of single complex CUDA program(Kernel). Because of todays GPUs parallel architecture its better to split this program to smaller parts (Kernels).
BrilliantApe- Actually when they finish kernel split both for OpenCL and CUDA we will see significant speedup on Nvidia cards.
I see thanks. As I understand it the OpenCL kernel split already happened (or is in progress) and allows Cycles to compile and work with AMD cards - now this is also happening for Nvidia cards (although they did work already) ? Does that mean they are maintaining two different āversionsā of cycles, one for AMD and another for Nvidia ?
I donāt know much about the technical aspect either, but that last comment by Brecth sounds pretty solid to me, I hope the devs take it into accountā¦
ā¦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.
Other than that, any speed improvement will always be a good thing
Iād like to see Adaptive Sampler again, in its current state or in an improved state (think current was fine)
Since tile renderer knows exactly what is to be rendered, ea having the 3D knowledge, i hope to see an image denoise function. which should work on a p object bases, not blending object, and keeping things sharp.
Besides denoising of 2D, how about smart morph, so every n-th frame can be a morph instead of a full render, to faster create an animation.
Or maybe some other way of improving animation speed (caching of resolved light ?). I think animations can be speeded up in otherways then single images can.
Also image denoise and smooth functions in post cycles (compositor), preferably working on object id bounderies. (so no blending).
layer output smoke
an option to have lights as layerouput too, so that light color can be changed after rendering.
This doesnt have to be for all lights, but just an option to promot a lightname to layer output.
maybe for the node system combine glossy and bsdf into one node.
Auto tile size by default. (with optimal dimensions in regard to output image, and optimal cpu/gpu size).
Maybe more NPR effects ?.
Metropolis or other methods, think those where amazing.
And anything that makes it faster
And maybe (not directly cycles) a simple way of joining PCās to help render an animation, which should work on the fly and where people could set their PCās on or off, but when on a service checks if the renderguy is working on something and so other people can help rendering if their CPU is not in use.
Combination node of glossy and bsdf (to make life easy).
A PBR real good version of fresnel ( it just should be fixed)
It looks to me this is becoming less of a thread about the development plans for Cycles and more of a thread for the posting of a laundry list of requested features.
Keep in mind that the long cycle being proposed is still not going to make it possible for them to satisfy dozens and dozens of requests so they will need to decide which ones are the most critical for the professional use of Cycles (they already have quite a list in the developer.blender.org thread).
A well made fully integrated materials database, so that many realistic materials are available at the click of a button, like other render engines, without having to carefully design complex material node setups. I think this would push Blender Cycles to the mainstream and make it more popular and accessible.
I also want more filters than just Gaussian, so we can get sharper renders without extra compositing.
There was an experimental patch that brought in the Mitchell filter for anti-aliasing, but the issue is that it is what you call a negative-lobe filter are infamous for ringing artifacts.
You canāt really reduce the bell curve any further without introducing numerous aliasing problems in various situations, so the only real way to go here is to have an adaptive filter that smartly determines the minimum lobe size needed on a per-pixel basis (which might be tricky to code).
Iād like to see Cycles compete with V-Ray to be honest. Mainly because V-ray has such a big user base, and is expensive, so it would be really fun to give V-Ray users a run for their money.
But i have no real idea what cycles would have to do in order to compete as i donāt use V-ray. All i hear is that V-ray is hard to use, so it would be nice to see cycles stay user friendly as well.
I looked at the developer threat and saw where they work on
So here is my post again, with a smile means, its under the eyes of development
So thats good news
I wonder if the idea of optimizing animations is possible too (ea maybe things can speedup by different rendering, since blender just did a previous movie frame. (morphing or something like that).
