Potential crash when toggling shadows?

[Paul Molodowitch]

A bit back, I ran into a crash when toggling shadows.

I thought it was due to usage of invalid iterators, and made this PR, which seemed to fix it:

PixarAnimationStudios/OpenUSD#565

...however, on discussion with Pixar, realized the problem may be in our scene delegate. Need to remove this change to USD, then re-test to see if crash still exists, and if so, fix (possibly by adding check for double extract).

Original reproduction code was:

import maya.cmds as cmds
import maya.mel as mel

def loadPlug(plug):
    if not cmds.pluginInfo(plug, q=1, loaded=1):
        cmds.loadPlugin(plug)
loadPlug("AL_USDMayaPlugin")
#cmds.file('/Volumes/sv-dev01/devRepo/paulm/usd_samples/cube_proxy.ma', open=1, f=1)
cmds.file('/Volumes/sv-dev01/devRepo/paulm/usd_samples/Kitchen_set/Kitchen_set_proxy_camera.ma', open=1, f=1)


loadPlug("mtoh")
mel.eval('setRendererAndOverrideInModelPanel $gViewport2 hydraViewportOverride modelPanel4;')
light = cmds.createNode('spotLight')
lightXform = cmds.listRelatives(light, parent=1)[0]
cmds.setAttr("{}.tz".format(lightXform), 500)
cmds.setAttr("{}.useDepthMapShadows".format(light), 1)

[Paul Molodowitch]

Fixed here: d7b3f64

[Paul Molodowitch]

This fix was a red herring - maybe I just got lucky the few times I tried this,
and it seemed to fix things. Real issue is that we are doing double extracts
from UsdImagingValueCache on transform and extent values; this happens because
HdMayaDelegateCtx::FitFrustumToRprims queries transform values to calculate a
good frustrum for it's shadow projection matrix; this means that
UsdImagingDelegate.GetTransform / GetExtent may be called both here, and when
rendering the transform itself.

However, it seems odd that you're not allowed to call GetTransform / GetExtent
more than once - especially since this is a publically exposed override of
HdSceneDelegate::GetTransform. Made a post on usd-interest here about this:

https://groups.google.com/forum/#!topic/usd-interest/tIEp5UyDpxs

Seems like the fix should be in usd itself, as there doesn't seem to be a "safe"
/ non-destructive way to get at this information currently...