Development update: Cycles & S-curves!

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! :)