Page 1 of 26 12311 ... LastLast
Results 1 to 20 of 511

Thread: Bidirectional Path Tracing and other speed improvements on Cycles

  1. #1
    Member tuqueque's Avatar
    Join Date
    Sep 2007
    Location
    Maracaibo, Venezuela
    Posts
    439

    Bidirectional Path Tracing and other speed improvements on Cycles

    ---------------------------------------------------------------------------------------

    Update:
    For those interested, Mike Farnsworth has stepped in and started coding features for Cycles, he has already contributed coding Environment Importance Sampling.

    He also created a blog: http://morecycles.blogspot.com/ where you can find development updates and you can also donate to support his great work.

    ---------------------------------------------------------------------------------------

    Ok, This isn't really news, but hopefully will become one ...

    Long post but please, keep reading...

    First of all, I apologize if there's any mistake on the technical stuff of this post, I have a fairly good understanding about the subject but if any hardcore programmer or Blender developer find something odd, feel free to point it out.

    Most Blender users are familiar with the Blender Internal Render... Well, this engine belongs to an old breed of rendering engines (no matter how this hurts)...

    There's now a "new" (not so new... Rather old to be fair) generation of renderers called Path Tracers... And Cycles belongs to this type or render engine...

    The big, huge, enormous advantage of these renderers is their simplicity, this allows them to easily solve realistic materials and light interactions... Also, Cycles algorithms can be implemented on the GPU. That's why we have already GPU support on Cycles even at this sort of pre-alpha state...

    But there's a problem with simple Path Tracers and is the speed... For Suzanne on a plane, or to be more production oriented, for fairly well lit scenes (day exteriors, few light sources, big sized lights and generally "easy to solve" scenarios), plain Path Tracers hold very well. But for not so well lit scenes (interiors with light coming from a window, lots of indirect lighting, small sized light sources and so on), plain Path Tracers fail miserably to deliver noise free images in reasonable times. And let's face it, in production, the second case scenarios are present half the times, so we can't really avoid them.

    Fortunately, today there are already a lot of well known improvements that can be implemented to the plain Path Tracing code that make it more "intelligent" and this algorithms "find" relevant light contributions in the scene and dedicate the processing power where is really needed, ergo, the scene is finished much faster... How much?... 2, 3... 10 and more times faster depending on the case...

    Those algorithms are not as easy to implement as the current plain Path Tracer present in Cycles, but there are already a good number of sources of information to implement them, and even better, those improvements are still "simple" enough to be implemented for CPU and also GPU, just like Cycles currently does with its plain Path Tracing.

    Some names you could have heard are "Importance sampling", "Bidirectional Path Tracing", "Metropolis Light Transport" (MLT for short), "Energy Redistribution Path Tracing" (ERPT for short)... And a lot of variations or different methods with even fancier names.

    In case you are not sure, Cycles today is just a plain Path Tracer, It does not have any optimization mentioned (Not sure if it has some Importance Sampling implementation though).

    Cycles has a good number of tricks under the sleeve to let the user optimize the scene, things like the great Light Path node and the Ray Visibility Panel are among the coolest... But there's just so much you can do with this tricks. We need some optimizations at the Path tracing level.

    A few days ago I asked in the Cycles mailing list about Brecht's plan and timeline to implement Bidirectional Path Tracing on Cycles... And his response was:

    Actually there is no concrete plan to implement these things soon. (...) Higher priority are things like render passes and layers, more detailed scenes (displacement, subdivision, caching), adaptive sampling, motion blur, ... (...) More advanced algorithms may get added at some point of course, and perhaps someone other than me wants to work on them soon...
    Brecht is really busy working hard on those cool features, so speed improvements at the Path Tracer level are not in the near or even mid future plans... And this is where comes the purpose of this thread...

    Cycles is already being used for production and professional work (me included) and we could benefit immensely from speed gains.

    IMHO, we should have at least some of the above mentioned improvements in the short term... And more than that... Brecht is receiving help from some cool developers porting nodes, applying patches and doing general stuff on Cycles... But Brecht needs more help on the hardcore stuff...

    Implementing BiDir (Bidirectional Path Tracing) on Cycles is not a trivial task, not to mention MLT or ERPT on top of that... Maybe I'm wrong, but very few developers from the Blender headquarters are able to work on that, so finding a hardcore developer that can implement a high quality BiDir + MLT/ERPT (or whatever other pertinent algorithm) on CPU and GPU can require a little bit of digging. And more important, I think this should be an user initiative, Blender Foundation is busy with regular Blender development and Mango pre-production... So:

    We should create a funding or something similar to hire a good programmer to help Brecht and implement the mentioned stuff... If we do a good job, we would actually alleviate BF guys from thinking about that... This could be a great retribution to their hard work.

    Depending on your feedback about this idea, I could get in contact with Brecht to gather the necessary information and start the search for a good programmer that can work on this and of course, meets Blender Foundation's and our requirements.

    We basically need a programmer that can work on maybe further optimizing the Raytracer (make BVH building threaded?), other optimizations on the plain Path Tracer (Multiple Importance Sampling?)... And Finally BiDir + whatever algorithms are decided (Of course, for CPU and GPU).

    And finally... In case you are skeptic and don't think there's enough speed improvement that worth implementing all this... Well, here's a short video of what can be achieved with BiDir + ERPT compared to plain Path Tracing:



    So let's start the feedback
    Last edited by tuqueque; 19-Jan-12 at 13:42.



  2. #2
    My personal wish list:
    - OpenCL first, (1/2 of hardware cannot work, it really a pain and NVIDIA vendor lock)
    - on-fly memory management to avoid hardware memory size restriction (no idea how to do it, pure randomness restrict to use caching, maybe simple texture paging system ?)
    - motion blur (very hard to do, need new BVH code, then rewrite core Blender to efficiently pass motion vector to Cycles, avoid huge 3x-4x memory increase for data)
    - network friendly real time preview for happy render farm owners (isn't it will be cool to make live tiled screen where all tiles are single network nodes?).

    Bi-dir, shaders, etc are less important, but more easy and fun, that is the reason i playing with them. So, my vote to pass money to Brecht to finish more important, not fun, boring for average programmer features.



  3. #3
    Member fahr's Avatar
    Join Date
    Apr 2009
    Posts
    1,237
    Well, it's all got to get done. And we want it all now, so passing the money to Brecht isn't going to get it done any faster. Brecht would just take the money and hire a developer to help him write Bidirectional Path Tracing, I imagine.

    Since Brecht's todo list consists of the biggest, most important elements, I have no problem at all donating to help pay someone to help code optimizations. Cycles will remain useless in production if we can't get our renders done in time, no matter what the features are.

    For the record storm_st, I agree your list is high priority, especially MOTION BLUR! I'm only interested in OpenCL (or CUDA) if the devs can make it not be limited by the amount of VRAM in your system. Talk about a bottleneck, it makes the GPU useless for any large scene.

    Oh, and since we are talking wish lists... I agree with Brecht's entire todo list, but one thing that has never been mentioned up until now is BAKING! If cycles could light bake, we could use cycles to generate light maps for environments that could be rendered in blender internal, or exported to a game engine. That would make cycles an incredibly useful tool NOW.

    Anyway, to reiterate, if someone wants to code optimizations into cycles, I'm in favor of supporting it. If someone wants to code just about anything on the todo list for cycles, I'm in favor of supporting it. We cycles up and running NOW!!!
    Chad Gleason
    Cinematic Animator / Deck Nine Games
    http://www.chadgleason.com



  4. #4
    Member tuqueque's Avatar
    Join Date
    Sep 2007
    Location
    Maracaibo, Venezuela
    Posts
    439
    This was the kind of feedback I was expecting

    Some of you want Motion Blur first, some of you SSS, some of you Hair, some of you Displacement... Some of you want to render CUDA on your ATi card and some of you want a pretty girlfriend and a yacht.

    Let's not debate then in what we need first (this can be discussed in a poll later if we are organized enough to create this funding or whatever we decide)... The important thing is that Brecht needs help!... The more help he gets, the earlier we have whatever we want (Disclaimer: I don't think Brecht can get you a pretty girlfriend and a yacht though)...

    And is important to stress the fact that is not about paying Brecht to do what we want... He has his own schedule and he has his hands full already... What he needs is more brains and hands to code.

    Greets.
    tuqueque.



  5. #5
    Member fahr's Avatar
    Join Date
    Apr 2009
    Posts
    1,237
    Then we agree. Sign me up!
    Chad Gleason
    Cinematic Animator / Deck Nine Games
    http://www.chadgleason.com



  6. #6
    Member m9105826's Avatar
    Join Date
    Dec 2007
    Location
    Fairfax, VA
    Posts
    4,183
    I'd love to see some photon mapping with FG added at some point, but I have Yafaray to tide me over for the time being. My wish list for Cycles includes anything that can make it more adapted to animation, which I'm sure is on the minds of those working on Mango as well.



  7. #7
    My brain is to small to help coding but I can do donations if needed :-)

    I've done some tests for outdoor architecture visualization renderings and Cycles does a very good job there yet. For example the Instancing-Support is for grass very usable and gives very realistic grass results almost like you can do with Multiscatter for 3dsmax and Vray (other commercial GPU-based Renderes do not support Instancing yet or hard light through windows in interiors mostly is a problem and so on...).
    I love Cycles it for the ease of use and it's very realistic and fast renderresults.
    Blender itself is pretty easy and smooth to use as well (I need to work with 3d max but I hate it's Userinterface and slow Viewport every day).

    From my point of view noiseless and fast Interiorrenderings and breaking the (V)RAM-limits would be my first two things to improve. Renderlayers are also very importand to do fast Colorcorrection on facadematerials in architecturebuildings for example.
    I'm also very curious about the Volume-Shaders to do reastic water or frosted glass (the things I've seen in the forum are not perfect enough for me :-)).

    So please help make Cycles to grow as smart, fast, usable, stable and productionusable like it has startet.

    Kind regards
    Alain



  8. #8
    Originally Posted by m9105826 View Post
    I'd love to see some photon mapping with FG added at some point, but I have Yafaray to tide me over for the time being. My wish list for Cycles includes anything that can make it more adapted to animation, which I'm sure is on the minds of those working on Mango as well.
    photon mapping is outdated in 2011.



  9. #9
    Member lsscpp's Avatar
    Join Date
    May 2006
    Location
    Firenze
    Posts
    2,031
    From what i understood by watching blender conference's cycles video, pathtracing is an easy to implement algorithm needed to have realtime GI, and as far as i understand also MLT or ERPT and the like, allow for realtime rendering.
    but talking about render speed, what about biased techniques? Maybe, they cannot be implemented on gpu, neither they can render realtime, but if the cycles motto is true (shaders are how materials and light look anyway, integrator is how you render them), one should be able to preview realtime with pathtracing, and hit F12 for the final render with, let's say, irradiance cache. Am I right?
    Well, i'm slighlty off topic, i know...
    back on topic: besides all the well known pathtracing evolutions out there, on the blender-wiki itself there's this proposal: http://wiki.blender.org/index.php/De.../ReducingNoise
    here too (http://blenderartists.org/forum/show...Cycles-Renders)
    I'm no coder, so i can't say if it's something easy to stuff on the GPU, but the technique sounds really smart and also intoduces the nice paradigm of "final render quality" (no number of passes, no time-limit)
    Last edited by lsscpp; 07-Dec-11 at 12:51. Reason: typos
    Everything's relative. Even saying "Everything's relative".



  10. #10
    Member DingTo's Avatar
    Join Date
    Mar 2008
    Location
    Southern Germany
    Posts
    1,626
    Hey,
    this thread sounds very promising!
    If this gets coordinated well, and we find a good developer for it, I am in to support this.
    Blender developer (Cycles / User Interface)
    Blog -- Blender Podcast -- OpenShading -- BlenderDay -- Blender Network profile



  11. #11
    Donating Member arexma's Avatar
    Join Date
    Jul 2008
    Location
    Austria
    Posts
    4,814
    Iīd most certainly donate.

    However for me personally it would be more important to enlarge the Cycles team to get Cylces up to full functionality with the current render kernel. Once Cycles is to Blender in functionality what BI currently is to Blender the whole team can start to implement new kernels and start optimizing.
    I think if a team finishes the functionality with the thought on optimizations in the back of their head already weīll have a result sooner, the devs can work more relaxed and donīt dance around each others code all the time.
    Letīs face it, Cycles can already render nice images, but is not really feature complete with Blender.

    As for the speed of development, itīs ridiculously fast. I just can say, look over at Octane. Theyīre on it for a while now, a whole team of coders, and so far they got a direct lighting, a pathtracing and a pmc kernel, where latter is a RefractiveSoftware alternative to MLT. Currently they are working on SSS among other things.
    Or take a look at Indigos half baked OpenCL implementation or at Luxray. Took them forever and itīs not really optimized.
    So optimizing and developing is beyond trivial and one can only wonder about Brechts dark magic.

    On top of that Iīd ask Brecht and Ton if they even want someone for the task, else the fundraiser here might fork Cycles, create a new branch and who knows whatīll happen to it. A render engine is rather delicate who knows if you'll ever be able to merge it
    Dead branch anyone?
    And if they think itīs a good idea to get more manpower for Cycles ask if they think itīs smarter to finish implementing functionality with Blender or to work on 2 things at once.

    PS: And I donīt really want to have "noise-reduction". Remove the cause, donīt try to fix the effect.
    Iīd rather have a solid MLT implementation of any kind to solve difficult lighting setups, especially for interiors or low light emmision scenes correctly in the first place.
    My superpower? Common sense. It seems so rare these days, it has to be a superpower..
    "Computers are like Old Testament gods; lots of rules and no mercy.” - Joseph Campbell



  12. #12
    Member NinthJake's Avatar
    Join Date
    May 2009
    Location
    Sweden
    Posts
    2,294
    Well if we are just throwing out potential coders here I would nominate Wenzel Jacob (the Mitsuba developer), he could probably come up with some entirely new algorithms that would work with realtime previews, I know that he is researching new rendering algorithms and that he probably don't want to work on something else before he has completed that research but nothing to loose by asking him right?



  13. #13
    Member Agus3D's Avatar
    Join Date
    Jan 2009
    Location
    Buenos Aires
    Posts
    249
    MTL, bidir, ERPT are not speed improvements always, in a outdoor scene, except you want caustics, they are actually slower than path tracing, and interior rendering is something that most animation productions always try to avoid, no matter what rendering algorithm you can use.

    Arnold render is an example of a raytracing animation production render, and in its years of high level productions they never find a justification to implement such algorithms.
    Cycles is a render born to follow that direction, it is not intended to satisfy all needs. And i would prefer that all the efforts go to make it very strong in that direction.

    My personal wish list could be:
    - Backgraound importance sampling
    - Irradiance cache!!! at least for final render!
    - Adaptative subdivision
    - SSS

    Cheers,



  14. #14
    Member ejnaren's Avatar
    Join Date
    Nov 2009
    Location
    Denmark
    Posts
    740
    If this can indeed be coordinated along with all the other developments it would be great.
    Irradiance Cache +1
    ... hmm, +1 to anything that helps the team actually...



  15. #15
    Member fahr's Avatar
    Join Date
    Apr 2009
    Posts
    1,237
    Caching in just about any form is bad for animation isnt it? Great for arch walkthroughs, a flickering mess for anything animated. Cycles is designed for animation, so with that in mind, things like final gather and irradiance caching goes against that philosophy. The improvements to the api should allow renderers like yafaray, lux and vray to integrate better for arch users.

    Bidirectional path tracing sounds like a terrific speed up for interior scenes and is animation friendly. This is the direction cycles should go and this is what is proposed.

    I'm in.
    Chad Gleason
    Cinematic Animator / Deck Nine Games
    http://www.chadgleason.com



  16. #16
    Member tuqueque's Avatar
    Join Date
    Sep 2007
    Location
    Maracaibo, Venezuela
    Posts
    439
    Great to see a positive response from all of you!

    Originally Posted by arexma
    Iīd ask Brecht and Ton if they even want someone for the task, else the fundraiser here might fork Cycles, create a new branch and who knows whatīll happen to it. A render engine is rather delicate who knows if you'll ever be able to merge it
    Also great you said that, there's probably more people concerned about this... OF COURSE there's a plan to contact Brecht to coordinate before even thinking on contacting a possible developer...

    Originally Posted by Agus3D
    MTL, bidir, ERPT are not speed improvements always, in a outdoor scene, except you want caustics, they are actually slower than path tracing...
    Sure, but BDPT is barely slower than PT in those scenarios if I'm not mistaken... And anyway, theoretically, the user could have options to decide between plain PT or other Sampler so I don't see any issue here.

    (...)and interior rendering is something that most animation productions always try to avoid, no matter what rendering algorithm you can use.
    I work on productions, I work on animations... And 75% of it consists in interior rendering with dificult lighting (client directions, not my decision)... So no, it can't be avoided always... And I'm sure I'm not the only one who works on interior renderings and wants to make fair use of Cycles just as anyone else.

    That being said, tonight I'll contact Brecht and fill him in with this initiative, explain ideas and of course, make clear there's not a "wishlist" for features... We just want another talented developer to help him coding features for Cycles. I'll even ask him for possible names/contacts of developers he thinks can do the job!...

    Depending on your feedback and how good we organize this, I'll try to organize with Brecht a more concrete timeline for features HE considers to be priorities... So we know what to expect and when .

    I'll keep you updated.



  17. #17
    But i agree with this that first let Brecht finish important things like OpenCL (i have 6850 prepared), easy bumpmapping like BI, ,multithread BVH and more speed speed speed... I know if there would be second developer then there will be beginning of MLT, ERPT etc greatness.



  18. #18
    Member lsscpp's Avatar
    Join Date
    May 2006
    Location
    Firenze
    Posts
    2,031
    Originally Posted by arexma View Post
    And I donīt really want to have "noise-reduction". Remove the cause, donīt try to fix the effect.
    If this is related to my post, it's wrong, since that proposal is not a trick to "reduce noise" but a method to have smarter *real* sampling, so: same results as path tracing but in less time
    Last edited by lsscpp; 07-Dec-11 at 16:53.
    Everything's relative. Even saying "Everything's relative".



  19. #19
    Member Agus3D's Avatar
    Join Date
    Jan 2009
    Location
    Buenos Aires
    Posts
    249
    Originally Posted by fahr View Post
    Caching in just about any form is bad for animation isnt it? Great for arch walkthroughs, a flickering mess for anything animated. Cycles is designed for animation, so with that in mind, things like final gather and irradiance caching goes against that philosophy. The improvements to the api should allow renderers like yafaray, lux and vray to integrate better for arch users.

    Bidirectional path tracing sounds like a terrific speed up for interior scenes and is animation friendly. This is the direction cycles should go and this is what is proposed.

    I'm in.
    Nop, caching is indeed good for animations, Renderman is the caching king , but caching introduces latency in the workflow so is not nice for interactive rendering, thats why i'll activate it in the final render, besides Brecht also implemented Irradiance cache for Durian but it nevers gets in trunk.
    Flickering will occur if you don't sample enough, but obviously the amount of samples is generally way less with IC.


    @tuqueque
    It seems your have very particular needs which are not common in classical cgi animations productions, is the feedback i can give you in these years that i have been working in the industry. Do you make archviz ?

    Don't misunderstand me, is really nice your initiative, but for most guys that make animation in blender, we don't have yet a really nice global illumination/ tight integrated and shader consistent render, and cycles is the only hope we have right now. And i repeat you, rendering interiors in animations is not common in the industry, and if they have to, its quite common to cheat, for example with AO ray lenght, some light sources to fake indirect light etc...

    If we are talking about conventional cgi animations (not archivz) is way more important to have right now Motion blur, render passes, I-Sampling, detailed scenes with subdivision, and more optimization of the things that are working now.

    So thats why makes me sad to see this effort is not taking care of the conventional animations needs, thats it.

    cheers!
    Last edited by Agus3D; 07-Dec-11 at 15:46.



  20. #20
    Member Ace Dragon's Avatar
    Join Date
    Feb 2006
    Location
    Wichita Kansas (USA)
    Posts
    28,150
    Originally Posted by lsscpp View Post
    Is this is related to my post, it's wrong, since that proposal is not a trick to "reduce noise" but a method to have smarter *real* sampling, so: same results as path tracing but in less time
    And I think this post here has some reference to this thread here
    http://blenderartists.org/forum/show...Cycles-Renders

    In this case it's not using a 'noise reduction' algorithm to mask the noisiness of undersampled areas, but using a noise-aware sampling strategy to identify areas that need more sampling as well as areas where the sampling can be stopped. So in effect it would be like the render region is broken down into tiles and if the maximum discrepancy between samples is below a certain threshold (after taking in other factors like the normal data from bumpmaps and geometry as well as the z-buffer data), than the sampling for that area stops meaning all future samples are concentrated in the remaining regions.

    In some sense, this would mean the total area of regions being sampled would get smaller and smaller and thus you would see areas being sampled more densely with each pass, and the process would continue until the noise level is low enough that the rendering would either just stop or go on to render the next frame (for animations). This combined with adaptive sampling and bidirectional/metropolis sampling could actually go a ways to bring about making the engine usable for animators without sacrificing the ability for stills artists to use high quality GI like seen in engines such as Indigo, Thea, and Luxrender (also noting that Cycles will probably have techniques for faking effects as well for animators and artists who want to speed up render times or add certain artistic touches that isn't easily done with GI).

    And to note, this would also be a boon for animators because it would attempt to take the guess work of how many samples you would need for each frame, as it would try to ensure that the correct amount is taken depending on what is being rendered in the frame.
    --------------------

    As for easy bumpmapping like BI, someone could create an addon or node group that does that, from my use of the Cycles engine I have seen firsthand the advantages of using the node system to create bumpmaps and I wouldn't be one wanting to trade it in for a BI-style texture stack. The advantage of using an addon for something like this is that you could use an alternative interface that constructs the node tree for you, the advantage of a group node is that you have an entire tree wrapped in one big node and all you would need to do is plug in textures to the outputs and dial in the amount of bump each one gives.
    Last edited by Ace Dragon; 07-Dec-11 at 16:15.
    Sweet Dragon dreams, lovely Dragon kisses, gorgeous Dragon hugs. How sweet would life be to romp with Dragons, teasing you with their fire and you being in their games, perhaps they can even turn you into one as well.
    Adventures in Cycles; My official sketchbook



Page 1 of 26 12311 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •