Now that Cycles is in a Blender release, the next step is to extend it further and improve performance. Remember that Cycles is intended to be a render engine for individuals / small studios, aimed primarily at rendering animations, and this goal is what we evaluate priorities of features by.
For the next few months, the main priorities are:
- Render layers, passes, full sample, compositing layer, ..
- Performance improvements / noise reduction for typical two bounce animation scenes
- Some smaller things for completeness (blender integration stuff, ramps, multi GPU, ..)
After that, we should get to some more exciting features, which ones are a bit unclear, but this will be influenced by project Mango. Volume rendering and motion blur seem like good candidates, but we’ll see. Performance work will be ongoing during Mango of course, and we see that quite broadly, it’s about low level performance tuning, better algorithms and better user control.
Beyond that, there is a feature list which contains roughly what we’d like to see added over the next 2 years.
Contributing
If you’re a developer and would like to help out, you can look in these places:
If you need more details about how features should work, how to implement things or just to announce that you’re working on something, contact the bf-cycles mailing list. Another way to help is to improve our documentation in the manual.
Not Priorities
There are some things obviously missing that people would like to see added. Bidirectional path tracing, photon mapping, MLT and similar algorithm are not a priority for me, since we do not believe they are the main possible performance improvements for animation frames. Shading language support, resumable rendering, is another one that we do not think should get very high priority.
GPU Rendering
Lastly, GPU rendering can be somewhat of a bottleneck to development. It seems that with older cards and current OpenCL support in the drivers, we’d have to considerably complicate the code to get Cycles working fully, to the point where it would be too hard to add new features. This also means we’re dependent on improving driver implementations or language features. We’ll keep track of this, but also can’t justify spending too much time on this, to try to work around issues with every possible card / driver combination.
Another vote here for texture lightmap baking, a massive quality win in gaming and similar scenarios, although I appreciate it is probably not the easiest thing to implement (I can imagine the default renderer is probably itself very much “baked in” to the lightmap generation code)
Love the additions to Cycles, but I’m also curious about volumetric rendering and its place on the current roadmap.
It’s seem really simple to code. The texture baking is also good to implement.
why arent anyone talking about volumetric renders for cycles? its not in blender as far as i can see or is it there? o.o
http://www.openacc-standard.org/Frequently-Asked-Questions
“OpenACC API allows parallel programmers to provide simple hints, known as “directives,” to the compiler, identifying which areas of code to accelerate, without requiring programmers to modify or adapt the underlying code itself. By exposing parallelism to the compiler, dir”
Jeremy
By what im reading, seems that there is a problem implementing OpenCL.
Im not too familiar with it, but what about OpenACC/CAPS?
http://www.openacc-standard.org/node/51
Check out the pdf
Texture baking would be great. Unless you are rich enough to buy super SLI systems, baking would allow amazing quality to come from small studios. Blender in my eyes have always helped the little guy so baking would be a huge step! Cycles itself is a huge step for all though and I am extremely grateful for it. Baking seems like an important feature to complete the possibilities. Render super GI image for hours, bake textures, apply shadeless to BI render. Now you have photo-realistic animation in seconds =)
Thanks for all the improvements recently, they have helped me a ton!
+ 3 For the baking system.
I love Cycles so far, and i wish i could use Texture Baking on it.
You should definitely consider it !
New roadmap? Thx.
schedule got outdated :( badly
I also am greatly interested in hair with cycles. I have previously converted the hair particle systems to mesh then curve, however with more recent project this is not possible. I look forward to cycles with hair.
Particle Hair would be so great. Anyways – superb great work. With your help Blender may surpass Maya in no time.
One thing that Maya does well is: it only calculates Pixels or Rays, that are really >in the Camera< and everything else will not be considered to be rendered, which frees a lot of RAMs and power of the GPU/CPU. Just wanted to mention it. ;)
When will be ready the hair particle in cycles??
+1 for baking system, norml map baking with cage and ability to bake hard surface without seams. Many ppl vote here for remake baking system, so please mark it on road map please.
Thank you so much, Brecht! I really love cycles.
What I really hope to see is texture-baking support. (maybe somewhere between v2.70-2.80?)
when can we expect nvidia 600 series support?
hello and thank you for your great work :)
I have a proposal for cycles: Is it possible to have the selection visible in render mode? in fact it corresponds to a layer with the wireframe mode above the rendering. May be we could switch the display of the selection. I hope that the cycles mode will be the main mode and we will work directly on it …
ps: sorry for my English :)
Thanks!!
Nico
The new GeForce cards should be enough indication that CUDA is NOT the way to go. While pre-600 series had just its double precision at 1/8 the single precision performance, the new ones have been capped at 1/24 SP. Check the latest reviews of the new Nvidia cards to find out its truly poor compute performance (the SmallLuxGPU tests are appalling). On AMD’s side, consumer cards have a relatively small cap of 1/4 SP, which makes them much more useful for rendering.
Workstation cards -the only non-capped ones- are just too expensive. Please go OpenCL and make Cycles shine in GPU rendering.
Sorry, my post wasn’t intended as a reply to Matthew’s. I don’t find a way to edit it.
i have a suggestion for cycles or any other rendered
i don’t know if your familiar with renderproxys in maya but
anyway they make it so your seane size can be almost unlimited
and to tell you the truth i love blender but i get very fed up when
it crashes on large renders
and i have 24Gb ram windows64bit and a high end nvidia quadro card
so if i am complaining you should be too
don’t view this as an insult i am almost ready to make the complete
swithc to blender you have all come so far
Thx Brecht
i hope you plan animated textures too ! ( video maps ).
I’m waiting a lot with NOISE REDUCTION and Motion blur !
IES/photometric lights support would be essential too.
Thanks a lot Brecht.
I tested 4xGTX580, and it worked well.
And, I tested 8xGTX580, but it did not work well.
Does Cycles have any limitation on number of GPUs?
haven’t seen bake in the todo list, but the drop down category is missing from the properties pane. Is it done in another way?
Thanks Brecht for all your hard work. I used to use Mental Ray and Vray, they are very good renderers but Cycles is just something else. Cycles really cruises on my gtx580.
I can’t wait for sss, hair, volume, motion blur, well… everything that is planned.
Thanks!!
Hi,
in my little opinion the direction of blender development
should always follow the opensource way, therefore OpenCL.
From an implementation point o view, I’d like that developers
have focus on the OpenCL framework and not, for example,
making work-arounds to let AMD products to work well.
Then, each hardware producer can (or not) implement Opencl
for its driver… Is it possible that no one have interest
developing opencl drivers?
There could be free opensource (like blender) and commercial software that can use OpenCL, isn’t it?
Thanks for your attention.
I do hope that OpenCL support comes. To me it would have made more sense to go the OpenCL route for GPU accelerated rendering in the first place, since nvidia apparently does support OpenCL as well. Of course, some sort of limitation may exist that I’m not aware of…
Impressive list..if you need coffee or tea support – let me know :-P
thanks brecht
any chance of light cache or photon mapping like thingy?
“Bidirectional path tracing.. MLT” etc <– I thought these provide speed benefits for unbiased renderers as well?
One thing I would love added to the ToDo list is some sort of volume precedence system – something that detects boundaries between dynamic objects – to allow rendering of fluid simulation interacting with glass objects.
The render layers and passes are going to be like the blender internal system or it will be something more similar to xsi or maybe maya??
Has anyone tested to see if the ne 12.1a preview Drivers with OpenCL 1.2
has helped any?
and the baked normal maps will be supported?well as the typical textures used in game design?, it would be interesting to stop using 3dsmax or Maya
Why not hybrid rendering (CPU+GPU)? I have 2 GTX 580 SLI but also an i7 that can be put to good use.
The render layers and passes are going to be like the blender internal system or it will be something more similar to xsi or maybe maya??
Everyone who wants OpenCL, guys it’s the AMD OpenCL driver which has issues and stops us from proper support for it. I guess there are possibilities for workarounds, but that is very time intensive and does not fix the error source (again: the AMD drivers!)
Write mails to AMD ;-)
Overall I’m very happy with this development.
My worry is the OpenCL part. I understand the difficulties, but going into CUDA goes agains OpenSource in nature. Plus it forces us to get Nvidia equipment if we want to have GPU acceleration.
I do agree about supporting older hardware, and maybe you should simply not support it. Just like the steps made to not support older versions of CUDA in released drivers.
Still I do hope that OpenCL does get its proper attention.
Hi,
all my thanks and support to that fantastic project that adds modern GI right into Blender, which was much needed (at least by me :P) !
I join Emmanuel’s remark that baking cycles diffuse GI to textures would be a huge plus, not only for game but also animation projects.
Is that somewhere in the plan ?
Cheers,
______
JG
Is it possible to have an alpha channel to all material nodes?
Adding a textured alpha is very difficult now.
Thank you!
thank you Brecht! I cant wait to see the new features in action! Cycles is becoming my favorite render engine. Would it be possible to implement a “sobel-style” edge node in cycles, similar(or better yet identical) to the Edge render effect from Blender Internal Renderer?
OpenMP is likely going to have extensions for GPUs and other accelerators eventually (OpenACC). Lets see if AMD and Intel get on board with this one. OpenACC might sufficiently lessen the technology coupling of the system, removing the development bottleneck.
What about baking to texture? We at the WebGL would love having fabulous pre-baked textures :)
congratulations.
I’m very interested in the motor under the hood. Could you tell me which books/thesis you read ?
Really, thanks a lot, you move the open source cg to the next step :P
Thx.
nooooooooooooooooooooooooooo
it’s too much
i can’t wait all that
Thanks a lot Brecht
There’s a vivid discussion on normal maps right now on BlenderArtists, so if you ever read this Brecht, could you put them somewhere on the roadmap for us please? It’s quite frustrating to not see them mentioned anywhere. And thanks for all the hard work! Cycles is fast becoming my favorite render engine. :-)
Great work ! In my opinion a cycles based – bake system useful for game creation could be a very boost to the adoption of blender; an automatic system to UVunwrap + create image + bake starting from cycles materials and throught cycles engine would be a definitive tool !! Am I a dreamer ?!
Thank for your great work !!
I posted something here about adaptive sampling
http://blenderartists.org/forum/showthread.php?236453-Measuring-Noise-in-Cycles-Renders&p=2024665#post2024665
I think it would be good if the render API could somehow bring a long with it a generic option to set up multiple layers / passes which are independent of engines.
An example would be to have a generic render layer set-up, with a select-able engine from the add-ons enabled under the layer name, then depending on the engine selected, the required render options / settings / passes would be shown in the render panel.
The generic render layers could then be set up across many different engines to use each to it’s own strength i.e. Blender for hair, Cycles for beauty passes and clicking on each render layer would automatically switch between the active engines.
I think this would probably quite difficult to coordinate as there are several other engines with add-ons for Blender but I really do think it would make Blender such a powerful tool, sort of like Katana for bring everything together in the rendering, except of course you’d use Blender for everything else as well ;)
On-topic:
Brecht, you are making amazing progress and with Cycles improving each day, the future really is looking exceptionally bright.
Thanks! :)
Once Cycles can handle render layers, something I’ve been wondering about is if the compositor could use a render layer with Cycles, and another render layer with Blender Internal. In my mind, certain passes don’t necessarily need the complex treatment Cycles provides. You could also consider that Freestyle could be combined with Cycles that way.
…oh. Sorry. DId I start dreaming too much again?
Nice post Brecht! Keep it up. We’re all rooting for you. :)
Currently, that’s possible, as long as you use the different renderers in separate scenes. It’s a little more annoying than having renderlayers, but it works.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.