Page Comparison

Table of Contents

Introduction

...

Applications outside of VFX:

• TODO:

High Level Anatomy of an Image Plane

An Conceptually, an Image plane must provide the following information:

• link to associated camera
• filepath of image (can be animated per frame)
• fit to filmback (how image is positioned in relation to cameras filmback)     
• visibility (should be hide-able for different workflows)

And should probably also provide:

• depth (how far away from pinhole camera this plane should be)    
  • This will also be important for resolving which pixels to render for cases where you have multiple image planes.
• fit to filmback (how should image fit to cameras filmback)     
  • fill/stretch, best, horizontal, vertical, to size
• offset to filmback     x,y (exist in space) 
• alpha gain or other "image attributes"
• more attributes to fine tune fit

UsdImagePlane API Schema

The UsdImagePlane schema defines basic properties for rendering an image plane. The UsdImagePlane schema derives from UsdSchemaBase. TODO: Verify best base class.

TODO: Continue fleshing out 

Properties

• asset image = @@
  • Path to image file, can be time sampled per frame
• double depth = 0
  • distance from the pinhole to the point on the optical axis where the image plane sits

    • l_o in CG Camera diagram 2.1 in https://cookeoptics.com/i-technology/ > "Cooke Camera Lens Definitions for VFX"

    • alternative name: "distance" (Autodesk Maya used "depth")
    • A nice default could be -1 or "infinite" so that it would always be behind CG. That might be hard to coexist with a physically placed in scene camera depth that exists in front of and behind cg elements.
• uniform token fit = "vertical"
  • How the image plane is fit to the filmback. Possible values:
    • "horizontal" - fit image width to filmback and keep image aspect ratio
    • "vertical"- fit image height to filmback and keep image aspect ratio
    • "best" - from Maya, maybe too ambiguos
    • "fill" - stretched to filmback
    • "to size" - constant size, centered on filmback, and requiring more data to define "image size"
• float[2] offset
  • in same units as camera filmback - tenth of scene unit)
• visibility (should be hideable for different workflows)

And should probably also provide:

• alpha gain or "texture like attributes"token visibility
  • Control image plane visibility. Possible values: 
    • "inherited"
    • "visible"
    • "invisible"

Open Questions

Should you have the ability to define multiple Image planes per camera? YES

...

Which would generate this .usda:

 def Xform "world" {
    def Camera "cam" {
        ...
        string[] imagePlanes = ["imagePlane1"]
        asset imagePlane1:image = {
            1001: @/path/to/image.1001.exr@, 
            1002:...
            }
        float imagePlane1:depth = 1000.0
    }
}

Schema Data

The nuts and bolts of the data types proposed are:

TODO:

• image: asset
• depth: float
• fit: token
• offset: (float, float)
• visibility: token

Alternative Strategies 

As a concrete prim type

...