ID 397796 - Geolib CookInterface/CookInterfaceUtils discrepancy in handling of relative input location paths for newly created locations

Problem summary:

FnGeolibCookInterface functions such as getAttr(), when called at newly created (or re-created) locations, are able to query existing input scene graph locations given a relative path (such as '..') from their would-be input location path (which may or may not exist on the input scene, and as distinct from the natural input location path given by getInputLocationPath()), while FnGeolibCookInterfaceUtils functions (such GetAbsInputLocationPath() and GetGlobalXFormGroup()) are not.

Steps to reproduce:

1. Using an OpScript that creates a new location beneath an existing location, check the results of Interface.GetAttr('', '..') (get all attributes at the parent of the input location path), and Interface.GetAbsInputLocationPath('..') at the newly created location.

Expected behaviour:

Either both return valid results (a valid GroupAttribute and a valid scene graph location path respectively), or neither do.

Actual behaviour:

GetAttr() returns a valid result, GetAbsInputLocationPath() does not.

Workaround:

Avoid using relative input location paths at locations on which Interface.GetInputLocationPath() returns the empty string (i.e. newly created or re-created locations). This is a sensible choice in any case, as it can be considered problematic to make queries relative to a disjunct and/or non-existent location in the input scene.

Tested versions/platforms:

• All versions (2.0+) - Affected