Development update: Cycles & S-curves!

by - 2012/03/15 41 Comments Development

We didn’t forget what Mango is really about; which is of course to help improving Blender!

Last Monday we had two meetings with the devs & artists, on cycles and general issues. Yesterday we discussed pipeline designs. This morning we worked out a design idea for curve editing for masks. Time for an update :)

Cycles topics

  • Number one missing feature: Motion blur! It will (can) be added in three ways: 1) Camera motion blur (almost free) 2) Object motion blur (an extra matrix per ray) 3) Deformation motion blur (requires pre-proces as current vector blur in Blender.
  • Cycles will then also deliver vector pass in render-layers, for vector blur node.
  • For rendered masks, cycles should support Index passes (Object, Material index numbers). Also the old Z-mask option should be brought back, but hopefully can be combined with better visualization (in 3d window)
  • Shadow passes! This took a while to get pinned down precisely, mostly because from Cycles point of view the idea of “shadow” doesn’t really exist. It’s light bouncing around :). A good definition we found is to add two Shadow pass types. 1) Direct shadow (shadow caused directly by area or point/spot/sun lights) and 2) Indirect shadow (shadow which includes bounced light, GI, contributions from environment.
  • Anti-aliasing: Brecht will investigate to implement FSA for cycles. That method (1 full composite per sample, then merge samples) is still the way to deliver optimal quality AA. Alternative ways could just be to internally render things bigger, composite once, and merge down. Under investigation.
  • Mixing render engines in 1 scene: Since the ‘render database’ of Blender Internal and Cycles is not shared, individual render-layers of a Scene can also not use different render engines. For this it’s adviced to set up multiple scenes to render (which can be used in 1 composite anyway).
  • Volumetric render: will be possible in Cycles eventually, but we can fall back on Internal if needed.
  • Ramp shaders & Curve nodes: being worked on.
  • Biggest challenge for Cycles the next months is render speed. It’s still on the slow side for production scenes. Some shaders (caustics) can be avoided, other slow shaders (soft glossy) not so easily.
  • Sergey will research the topic “methods to attract lighting circumstances from footage, using 3d reconstruction”.

Other Blender topics, lessons from past week

  •  Blender’s library system is far too static with paths (relative, non relative, moving stuff). Needs a good tool & UI to manage.
  • Asset pre-viewing and browsing (in other files too) would be cool
  • Compositor is too slow! We need Jeroen Bakker’s new OpenCL compo!
  • Check on Alembic style baking for for animation playback.
  • Smoke sim should really allow objects to animate and interact with the smoke.
  • Bullet physics/fracture goes via game engine, can this be unified now? How is Joshua Leung’s Bullet branch going?
  • We need efficient ways to share animation data (like control 1 modifier property curve on 50+ objects).
  • Mesh modeling: bevel needs fix, “Inset” tool would be great. And are we getting realtime AO or Cavety shader for modeler now?

Pipeline meeting

Sebastian presented a cool diagram showing the data and workflow. Jeremy explained the data structure has we used in past (for sintel). Agreed is that Sebastian will become our “pipeline manager” and report and design issues further, he will pick this up next week when his tracking dvd training is done.

Mask curve editing: S-curves!

This morning we had a fun session together (Sergey, Sebastian, Francesco, Ton) on efficient ways to draw and edit masks, with efficient but advanced control over local feathering. This lead to a design proposal I nicked S-curve (Sharybin curve :)

  • Curve shape and curvature gets edited using 1 perpendicular handle (like X-splines).
  • Curve feather shape can be controlled using additional points (as many you like on a curve), which will have a user-defined distance from the original curve shape – but always remain perpendicular.
  • That means that feather–points can be dragged out of curve to define a soft area, but also can get ‘slided’ over the curve shape to position it.
  • Technically: the feather point is based on the U coordinate on curve, plus a Dist (or weight factor) to define distance.
  • Bonus: non-closed curves will always draw as a two-sided feathered string.

If this S-curve idea works will be figured out later, but the theory & design is promising. Back to coding! :)

  1. Gianmichele says:

    Scary and exciting at the same time…

  2. matthew/mofx says:

    Some very exciting stuff discussed here.

  3. 3duaun says:

    OpenCL Compo & Mixing render engines gets my +1

    The s-curves sound like a very nice solution to curve-based masking of footage(as long as it can all be keyed). thanks for sharing the updates!

  4. Psy-Fi says:

    Good luck to your coding endeavours!

  5. blenderguy says:

    What about particle hair in Cycles? Is it going to be implemented during Mango?

    • postrock says:

      If i’m not mistaken, they said its going to be implemented, but not during the Mango timeframe..

  6. mangojambo says:

    Very exciting features!!! But Ton, what about VSE? Still the same?
    Would be great to transform (Scale, Translate and Rotate) Strips straight in the preview(or a new proper space for that, like the Movie Editor has it own), transform using handles or something like that. Or even multiple VSE “timeline” data (not only multiple scenes), like AFx. Same for multiple NLA, remember? ;)

    Anyway, can´t wait for the new features. Cheerios.

    • ton says:

      Ian is an experienced Afx user, I bet he’ll come up with a list sooner or later too. Currently he’s doing crazy modeling :)

  7. blendercomp says:

    *Fascinating* stuff!

    Question regarding s-curves: are they going to be directly available in the VSE for masking or will they have to be created in the 3d viewport, rendered, and then become accessible in the VSE?
    Just curious.

  8. postrock says:

    All of this is spellbinding…yet one thing that seems to be missing is the ability to use movies or sequences as textures in Cycles..

    • ton says:

      Is on the list, was too small to mention :)

      • postrock says:

        That’s great, what you guys are doing is very inspiring.

      • PhysicsGuy says:

        Great news that it’s on the list. I’m waiting anxiously.

        Just out of interest: is this a specifically hard problem to solve? I can imagine it is, as one would have to resend the texture to the GPU for every frame, as opposed to just the geometry. Or is is just a matter of there being to much to do and not enough time to do it?

  9. PhysicsGuy says:

    Holy crap, you guys really know how to brainstorm. So many ideas in such a short time. I guess doing the short really paid off!

  10. Gill says:

    As Gianmichele said, exciting and scary in the same time.
    It’s fantastic to see how nìmany things you got discussed in two days, I wish you the best to accomplish them the best way.

    But it is also a bit scary that cycles hasn’t been used in the kickoff movie, is it in an unusable stage as it is now, or it’s simply too slow for a one-week project a the moment?

    Motion blur, volumetric, render speed improvements are all highest priority for the imminent mango project I suspect, I hope they can be properly addressed and in time for production!

  11. Daniel Wray says:

    Any chance of having Sebastian (If he wants to, and has time) to post a small post about the pipeline + diagram, it’d be interesting to see how the team is taking this project on after their experience with ‘Quit Blender, or Die’! :)

  12. ton says:

    Oh… the correct name is X-spline, google for it!

  13. Tungee says:

    I believe in Sergey!
    Nice to see Sergey and König on one boat!
    Results will be boombastic!

  14. Ace Dragon says:

    Hi, my first time replying in any thread on any of the Institute’s open movie sites. Reading the brainstorming ideas, I do have one thing to say which is somewhat copied by my reaction on Blenderartists.

    Personally, I am hoping that the optimizations will also go into the areas of smarter sampling and faster raytree types(like QBVH) and not just into implementing more ways to cheat and disable effects.

    If Brecht for example can get the QBVH implementation done and make the sampling a bit smarter, the Mango team won’t need to cheat near as much which would allow for higher quality scenes with reflecting and refracting surfaces as well as interior scenes. This in part is also a hope that the dev. team faces these challenges head on instead of designing the project in a way that tries to avoid them (which I feel was part of the case with Sintel)

    • PhysicsGuy says:

      I seem to recall that Brecht somewhere said that he was already looking into faster ways of building the BVH. Also, there has been some impressive work already on importance sampling in Cycles. So I guess in that respect, what you are asking for is already being done.

      Looking at the storyboards, I think the team is not planning on cutting corners during Mango. I don’t think we have to worry about this. Btw, in what sense do you think Sintel was about avoiding problems instead of solving them?

  15. Karlis says:

    Good to hear some points I have wodered about!

    “Mixing render engines in 1 scene…..render (which can be used in 1 composite anyway).”

    I think we really should somehow make Blender use diferent render engines at the same time. Really. In real life situation I want to setup my project to render.. and go home, so in the morning I would have everything rendered, but I can’t, because I must render something in cycles.. and then something in internal.. And I must choose wich I will render today and what tomorrow. I don’t have time for that. And what if I make changes in one scene.. I must think all the time not to forget to check if in other scene changes are made too.

    I know people hate when someone mentions other software, but maya allows to render both.. mental ray and standart render at the same time.

    Talking about rendering.. I want to setup more than only one camera to render! Maybe I have 3 in my scene.. and I want to render them all till morning + I want different render dimentions for every camera.. can I do it? No! I must set everything manually after every render.. and I can have only one setting for dimentions too.. that is not very cool..

    “Smoke sim should really allow objects to animate and interact with the smoke.”
    Definetly! :)

    “We need efficient ways to share animation data (like control 1 modifier property curve on 50+ objects).”
    I think we need more efficient way to not only share animation data, but also modifiers, materials and other things.. Wouldn’t it be much more logical to go in modifier properties.. select modifiers you want.. copy with Ctrl+C, select another object or hundred and paste it on? With Ctrl+L you can’t copy only one modifier from 3 for example.

    About camera projection.. when looking from camera and unwrapping with “Project from view” the UVs are streched, because output dimention is not square.. If don’t look through camera or I am in ortographic mode.. everything works fine.. but usually I want to project something from camera and I think most of us too.

    Sorry and thank you for listening! I love Blender and I like your ideas.

    • belich says:


      have you tryed the oscurartools add on, for batch rendering?
      its a bit tricki at the beggining but works quite well when you have to render several scenes with diferent engines from a single blender file

      by the way i totally agree about the Ctrl+C, but i guess is not to easy to get working. . . if it would be great to copy this way even objects from diferents blenders. .

      • Karlis says:

        Hmm.. I didn’t know it existed.. will try!
        But I think we should have these controls in Blender by default.. without some tricks.
        It’s very easy to make mistakes, if you have to use tricks all the time and af things are not intuitive.

  16. Big Fan says:

    I worried after seeing the concept artwork about the actual movie ambitions. Like previous endeavours I thought it was larger than the resources. I think though Ton keeps a good eye on things this time around. Having said about my concerns I like how this team has come together and been very productive in a short time. Early indications are that this project will be the most successful yet. Nice list of new code too. Keep it up guys. :D

  17. Rob says:

    That’s a lot of stuff to work on! It will be amazing if even half of that gets finished in time!

  18. Nabil Stendardo says:

    About the S-curve idea, publish a paper on it quick, before some troll even thinks of patenting it. PS: It’s a great idea.

  19. Ben Dansie says:

    You all know how little of a coder I am, so take this with that in mind…

    “Check on Alembic style baking for for animation playback.”

    Are there plans (within the Mango timeframe or not) to actually include Alembic support? To early to say? Waiting to see how Alembic pans out? etc.

    Some news would be good.

    Enjoying the blog, best wishes to the team!

  20. ZanQdo says:

    le masking tools of ye gods! keep it up!

    question, for motion blur point 3 does that mean deformation motion blur will also work realtime?

  21. LswaN says:

    Cool stuff, I am looking forward to the improvements that are coming through this project! Just out of curiosity, will there ever be viewer nodes added to cycles material nodes? I know you can use the rendered view in a 3d window, but sometimes I just want to see what my procedural texture looks like, especially when I’m making a lot of changes to the settings, without having to wait for the viewport render to catch up… But anyway, I don’t want to start sounding like a whiner, the proposals here sound great, and like I said I’m really looking forward to the results of the Mango development work!

  22. Ace Dragon says:

    Hi, me again, has Brecht seen the implementations talked about in this blog yet (I just found it)?

    There’s some stuff in here that could potentially be useful for Brecht like a GPU-capable bidirectional path tracing implementation. (the alternative two-way pathtracing method is outlined there as well)

  23. Blendiac says:

    Volumetrics in Cycles? Adjustable width feathering of curves? Mixing Cycles with BI renderer? Drool. An enviable feature list, indeed?

    Like the poster above, I’m also really hoping that the VSE gets some real, AE-like upgrades.

  24. Niclas Åberg says:

    This sure looks great!

    “Mixing render engines in 1 scene”

    Have you ever thought about having the OpenGL-view as a render layer in the compositor? I think that this could potentially be very powerful when working with scenes that do not require any real 3d but positioned 2d sprites in 3d space (camera mapping etc). Also it would be very fast to work with.

    Keep up the great work!

  25. hetors says:

    More cool improvements to come!!, yeah!!.
    Greetings Mango Team!!!

  26. jake says:

    Feathered mask selections would be great, that way you wouldn’t have to do the feathering in Photoshop/Gimp.

  27. Luciano says:

    What about implementing OFX plugins for postproductions, many compositors have them like fusion and after effects, might be a good way of allowing not only for the community to make plugins it’d be easier to get plugins that are already working on other softwares inside blender.


    btw great work guys, i’m loving every minute i check the blog.

  28. Gianmichele says:

    Any plan to start working on the dependency graph or do you prefer working on it outside of the projects?

  29. Camote says:

    Since Joshua Leung’s working on the the Bullet physics/fracture, I think he need to collaborate with Phymec & KaiKostack. There presentation on Youtube are superb. I’m just making suggestion over here. Thank you.

  30. Brian says:

    Please unify the Bullet Physics engine. Or at least bring it out of it’s Game Engine box! Bullet is uber slow to calculate in the Game Engine (for me…) compared to other applications I’ve used which utilize Bullet. It’s usually near real-time in other applications.