利用者:Nazg-gul/GSoC-2013/RejectedProposals

Google Summer of Code: Rejected Proposals

Just for the history, and maybe someone else could pick up something useful from this :)

Motion Tracking Improvements

Bigger tasks:

• Weighted tracks support

First step here is to support zero-weighted tracks which does not affect on camera motion. but which produces points in 3D space which are used as reference for modeling/orientation.

Next step is to support variable wight, which defines how much track affects on camera motion. This is useful to reduce camera jumps at frames where track appears or disappears. To do so track weight is simply setting to fade down to zero at the ends of tracked segment.

• Survey data support

It is an essential thing for rigid object motion tracking. Survey data in this case is a footage, where you shoot your object from all the sides, solve it and use this as an additional information for motion solver. It makes it possible to find a reasonable solution in cases when there's no enough depth information in main footage you need for VFX.

For example if having survey shot of Celia's hand would have made it possible to solve it's motion at breakage shot.

There could be some other types of survey data, such as manual declaration of feature points relationship and so on.

• Multicamera reconstruction

Support reconstruction of a scene using several cameras (witness camera approach). Goal of using multiple cameras is also to give it more depth information and have decent quality solution.

Witness camera approach is a cheap thing, does not require special equipment and could even use cheaper camera than main footage uses. Do not be confused by “this is thing only for expensive motion capture setup”.

• Overscan rendering

Basically, it says it all - render more pixels than final resolution so you'll be able to distort scene in compositor. This will bring some pipeline decisions - transparent dealing with overscan in compositor/image IO and so on (as in, make it so user doesn't spend lots of energy on figuring out whether he works with overscanned image or not, also EXR support this thing out of a box, so would be nice to have all this). Probably would require some improvements in compositor to support canvas things better.

• Distorted rendering

Would only work for Cycles (BI is heck of damn rasterizer where it's not possible to support such thing). But this is basically a feature, which allows to have a distorted image came straight out from the renderer - you save time on postprocessing-time distoriton.

Currently thinking of some general camera node to affect on rays going to it. This way more VFX things could be supported. For motion tracker it'll also mean different camera models are supported (projective, pinholes and so on).

Smaller tasks:

• Use GLSL for footage display

Currently it's only used for display-space conversion, but clip editor could benefit more of it: using GLSL for undistortion, gray-scale view and so. Would require implementing some general way to define image-display shaders which wil lstack on top of each other in a way like:

BeginGLSLImageDisplay();
UseUndistortionGLSLShader();
UseDisplaySpaceGLSLShader();
DrawImage();
FinishGLSLImageDisplay();

This way other areas in Blender could benefit as well - like GLSL-based strip modifiers in sequencer, realtime grading!

• Improving scene orientation operators

For easier scene orientation and making it so you don't need to re-orient scene after every solution.

Idea is store tracks used as floor and X-axis orientation in tracking DNA, which will be used after solution. Same goes to scale factor.

There're lots of other things to be done here, if there'll be time we've got Sebastian to provide more feature requests :)

Baking for Cycles

A bit of ambitious project since don't have much experience writing new core features to Cycles, but worked on other bakes before so guess i'll get into Cycles baking pretty easily.

Baking itself is questionable technique, but it's something what was requested by Mango artists for artistic things (like dirt maps baking). It'll also make Cycles renderer more attractive to those who works on games.

And as i understand recent discussion, some approach (but more transparent for artists) could speed up rendering as well (with some limitations for sure).

But anyway, having baking as a tool is useful anyway. Think goals of this project would be:

• Have baking tools working similar to current blender's internal renderer (applying on a textures using UV maps). Some bake methods will easily re-use existing path-trace things (like AO baker), but others (like displacement baking) seems to be more "stand-alone" thing comparing to Cycles render kernel. Architecture details could be discussed later.
• Looking into PTex, so that wouldn't be necessarily needed to unwrap objects and also brings features like more efficient image storage, cached input-output and others. However, think cache things is a bit deeper topic and would need to be checked with non-bake/ptex pipeline, implementing tile cache (probably using OIIO).

As an additional thing to be mentioned in context of tile cache, it could help implementing tile cache in ImBuf and using ImBuf instead of OIIO in Cycles (actually, make it plugin-like system, so it'll be easy to switch between ImBuf and OIIO). And as a continue, getting rid of Boost dependency in Cycles code :) (Just smaller possible changes in context of Cycles)