Page Comparison

Table of Contents

Introduction

...

• depth (how far away from pinhole camera this plane should exist in space) 
• alpha gain or other "image attributes"
• more attributes to fine tune fit

...

Pinhole Camera Diagram

This proposal will follow the same nomenclature from the Cooke site. Here is a reproduced CG Camera diagram. (from https://cookeoptics.com/i-technology/ > "Cooke Camera Lens Definitions for VFX" > CG Camera diagram 2.1.)

Image Added

UsdGeomImagePlaneAPI Schema

The UsdImagePlane UsdGeomImagePlaneAPI  schema defines basic properties for rendering an image plane. The UsdImagePlane UsdGeomImagePlaneAPI  schema derives from UsdSchemaBase  and will be a Multi-Apply Schema that would be restricted to UsdGeomCamera prim types.

Properties

• asset image = @@
  • Path to image file,
    • can be time sampled per frame
    • This will have to be per frame, as USD/Hydra do not at this time support a $F substitution for image/texture asset paths.
• double depth = 0
  • distance, in scene units, 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"above pinhole camera diagram

    • 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, but maybe this behavior is too ambiguous
    • "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
• token visibilitybool enabled
  • Control image plane visibility. Possible values: 
    • "inherited"
    • "visible"
    "invisible"
    • alternate name: "visible"
    • regardless of this value, if the (camera) prim itself is invisible, the image plane will not be visible in the viewport/render

Why a Multi-Apply API Schema?

If we implement a Multi-Apply API Schema for Image Planes we can:

• author attributes directly to camera
• author multiple image planes to camera, since multi-apply schemas can be applied several times to the same prim    
  • This multiple image planes could be used to view CG elements in context with foreground or and background plates.

API Methods

TODO:

• CreateImagePlane(imagePlaneName)
• SetImagePlane*Attr(imagePlaneName, value)
• GetImagePlane*Attr(imagePlaneName, attribute)
• SetImagePlanes([])
• GetImagePlanes()

...

camera = stage.GetPrimAtPath('/world/cam')
imagePlaneApi = UsdImagePlaneAPIUsdGeomImagePlaneAPI(camera)
imagePlaneApi.CreateImagePlane("imagePlane1")
framesToImages = [(f, fileSequence.frameAt(i) for f in fileSequence.frames()]
imagePlaneApi.SetImagePlaneImageAttr(framesToImages, "imagePlane1")

...

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

Hydra Implementation

TODO: Flesh out and discuss with Hydra team.

• Use UsdPreviewSurface textures in a way similar to GeomModel texture cards.
• Do the compositing in an Hdx post task

Open Questions

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

...

• Requires relationships between camera + plane primsWould have to traverse below camera to find whether has any image planes 
• Requires an extra API schema to encode the relationship on the Camera.
• There's the possibility that someone targets something other than an ImagePlane with the relationship, so there are more ways to "get stuff wrong".

Using existing USD types (Plane + material + camera + expressions)

...