dreamworksanimation / dwa_usd_plugins Goto Github PK

Switch out of preview mode, or change pixel samples > 1.

Hello,

When I run the build script:

python build_scripts/build_usd.py --nuke --nuke-location /workspace/install/Nuke11.3v4 build

I get:

-- Found Nuke: /workspace/install/Nuke11.3v4/include  
CMake Error at CMakeLists.txt:54 (include):
  include could not find load file:

    CXXDefaults


CMake Error at CMakeLists.txt:58 (include):
  include could not find load file:

    Public


CMake Error at CMakeLists.txt:60 (pxr_toplevel_prologue):
  Unknown CMake command "pxr_toplevel_prologue".

Searching the source directory I can't find anything that references CXXDefaults or Public or pxr_toplevel_prologue, are they required? are they missing?

Thanks.

Greetings!

It looks as though the "lock frame" function in the readgeo node isn't working as expected. Instead of locking to the frame number in the "set read frame" knob, it seems like it uses a static frame number (likely frame 1).

Also a minor note from some of our users. The verbiage used for the lock frame checkbox was a little confusing and makes it look as though frame locking is on by default when it isn't. I think either reversing the checkbox behavior (no check = read every frame, check = frame lock) or changing the label to something like "read each frame" might make that function a little more user friendly.

Please let me know if there are any questions or would like additional info.

Many Thanks!
Morgan

Hi, i try to dwa_usd compile.

but FindTBB.cmake occurt to compile error.
we using Pixar USD. so already compile to TBB.

Error :
CMAkeError.log
Determining if the pthread_create exist failed with the following output:
Change Dir: /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_06361/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_06361.dir/build.make CMakeFiles/cmTC_06361.dir/build
gmake[1]: Entering directory /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_06361.dir/CheckSymbolExists.c.o /usr/bin/cc -o CMakeFiles/cmTC_06361.dir/CheckSymbolExists.c.o -c /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp/CheckSymbolExists.c Linking C executable cmTC_06361 /netapp/backstage/pub/lib/extern/bin/cmake -E cmake_link_script CMakeFiles/cmTC_06361.dir/link.txt --verbose=1 /usr/bin/cc -rdynamic CMakeFiles/cmTC_06361.dir/CheckSymbolExists.c.o -o cmTC_06361 CMakeFiles/cmTC_06361.dir/CheckSymbolExists.c.o: In function main':
CheckSymbolExists.c:(.text+0x16): undefined reference to pthread_create' collect2: error: ld returned 1 exit status gmake[1]: *** [cmTC_06361] Error 1 gmake[1]: Leaving directory /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp'
gmake: *** [cmTC_06361/fast] Error 2

File /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
(void)argv;
#ifndef pthread_create
return ((int*)(&pthread_create))[argc];
#else
(void)argc;
return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_8904a/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_8904a.dir/build.make CMakeFiles/cmTC_8904a.dir/build
gmake[1]: Entering directory /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_8904a.dir/CheckFunctionExists.c.o /usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTC_8904a.dir/CheckFunctionExists.c.o -c /netapp/backstage/pub/lib/extern/share/cmake-3.9/Modules/CheckFunctionExists.c Linking C executable cmTC_8904a /netapp/backstage/pub/lib/extern/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8904a.dir/link.txt --verbose=1 /usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create -rdynamic CMakeFiles/cmTC_8904a.dir/CheckFunctionExists.c.o -o cmTC_8904a -lpthreads /usr/bin/ld: cannot find -lpthreads collect2: error: ld returned 1 exit status gmake[1]: *** [cmTC_8904a] Error 1 gmake[1]: Leaving directory /WORK_DATA/develop/lib/extern/nuke-usd/19.07/build/dwa_usd_plugins-master/CMakeFiles/CMakeTmp'
gmake: *** [cmTC_8904a/fast] Error 2

TBB Compiling error Message.
CMake Error at cmake/defaults/Packages.cmake:67 (find_package):
By not providing "FindTBB.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "TBB", but
CMake did not find one.

Could not find a package configuration file provided by "TBB" with any of
the following names:

TBBConfig.cmake
tbb-config.cmake

Add the installation prefix of "TBB" to CMAKE_PREFIX_PATH or set "TBB_DIR"
to a directory containing one of the above files. If "TBB" provides a
separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
CMakeLists.txt:34 (include)

ERROR: Failed to run 'cmake -DCMAKE_INSTALL_PREFIX="/WORK_DATA/develop/lib/extern/nuke-usd/19.07" -DCMAKE_PREFIX_PATH="/WORK_DATA/develop/lib/extern/nuke-usd/19.07" -DCMAKE_BUILD_TYPE=Release -DPXR_MALLOC_LIBRARY="/netapp/backstage/pub/lib/extern/lib/libjemalloc.so" -DPXR_ENABLE_PYTHON_SUPPORT=ON -DBUILD_SHARED_LIBS=ON -DTBB_USE_DEBUG_BUILD=OFF -DPXR_BUILD_DOCUMENTATION=OFF -DPXR_BUILD_TESTS=OFF -DPXR_BUILD_IMAGING=ON -DPXR_ENABLE_PTEX_SUPPORT=OFF -DPXR_BUILD_EMBREE_PLUGIN=OFF -DPXR_BUILD_PRMAN_PLUGIN=OFF -DPXR_BUILD_OPENIMAGEIO_PLUGIN=OFF -DPXR_BUILD_OPENCOLORIO_PLUGIN=OFF -DPXR_BUILD_USD_IMAGING=ON -DPXR_BUILD_USDVIEW=ON -DPXR_BUILD_ALEMBIC_PLUGIN=OFF -DPXR_BUILD_MATERIALX_PLUGIN=OFF -DPXR_BUILD_MAYA_PLUGIN=OFF -DPXR_BUILD_KATANA_PLUGIN=OFF -DPXR_BUILD_HOUDINI_PLUGIN=OFF -DNUKE_LOCATION="/usr/local/Nuke10.0v4" -DPXR_BUILD_NUKE_PLUGIN=ON "/WORK_DATA/INSTALL/DREAMWORKS/dwa_usd_plugins-master"'

we want use dwa nuke plugin. help please.

Our asset management system uses files paths that contain colons in them, and it appears that the USD reader cuts off the first part of the path up to the first use of a colon. In the example output below, the full path that was used in Nuke was: /p/show:shot:sq982:s8000-shot/shot.usda

GeoSceneGraphReader::getNodeDescriptions('shot:sq982:s8000-shot/shot.usda') error 'UsdIO: file does not exist'

It appears the new USD camera has lost its "Look" input functionality

The USD plugin for Nuke seems to not be properly reading the UVs on geometry exported out of Houdini.

This test was done using Nuke 12.0v4 and USD 19.11.

I've tried a few different combinations of attribute remapping with the included tab on the readGeo node, but no success.

Below is the debugging printout of the readgeo node for my test geometry.

Also maybe worth noting, I connected your ViewGeoAttributes node to the readGeo node, which showed that the geo only had normals and "Cf" attributes.

Please let me know if there is any additional info I can provided that would be helpful.

Thanks!
Morgan

FuserGeoReader::geometry_engine(0x8d7cd20): rebuild_mask=2b: reload_prims=1, reload_points=0, reload_attribs=1, frame=206
 file='test3.usd', fuserIOClass='UsdIO'
 reader_frame=206, output_frame=206, selected nodes=1 num_objects=1, num_threads=1
 '/Scene/Set/MuseumInterior/Hallway/geo/Banco_01': , type='Mesh', HasPayload=0, IsActive=1, IsDefined=1, IsAbstract=0, isModel=0, isGprim=1, isScope=0 attribs[ accelerations, cornerIndices, cornerSharpnesses, creaseIndices, creaseLengths, creaseSharpnesses, doubleSided, extent, faceVaryingLinearInterpolation, faceVertexCounts, faceVertexIndices, holeIndices, interpolateBoundary, normals, orientation, points, primvars:class, primvars:class:indices, primvars:displayColor, primvars:displayColor:indices, primvars:displayOpacity, primvars:displayOpacity:indices, primvars:st, primvars:st:indices, primvars:uv, primvars:uv:indices, purpose, subdivisionScheme, triangleSubdivisionRule, velocities, visibility, xformOpOrder ]
 FuserUsdMesh::ctor('/Scene/Set/MuseumInterior/Hallway/geo/Banco_01') topo_variance=0 (default Purpose)[ accelerations, cornerIndices, cornerSharpnesses, creaseIndices, creaseLengths, creaseSharpnesses, doubleSided, extent, faceVaryingLinearInterpolation, faceVertexCounts, faceVertexIndices, holeIndices, interpolateBoundary, normals, orientation, points, primvars:class, primvars:class:indices, primvars:displayColor, primvars:displayColor:indices, primvars:displayOpacity, primvars:displayOpacity:indices, primvars:st, primvars:st:indices, primvars:uv, primvars:uv:indices, purpose, subdivisionScheme, triangleSubdivisionRule, velocities, visibility, xformOpOrder ]
FuserUsdMesh::_validateState(0xb579b50): for_real=1, time=206, m_local_bbox=[-3.35058 0.318408 -1.83118, -2.99723 1.34921 2.16528](0.353342 1.0308 3.99647), m_have_xform=0
 FuserUsdMesh::_execute(0xb579b50) target='GeoOpGeometryEngine' Mesh '/Scene/Set/MuseumInterior/Hallway/geo/Banco_01', xform disabled
 ----------------------------------------------------------------
 FuserUsdMesh::initializeMeshSample(0xb579b50): time=206, name='Banco_01', 'test3.usd'
 nFaces=577, nVerts=2308, nPoints=612
 --------------------------------------------------------------------------------------
 FuserUsdMesh::geoOpGeometryEngine(0xb579b50): obj=0, time=206, name='Banco_01', path='/Scene/Set/MuseumInterior/Hallway/geo/Banco_01', 'test3.usd'
 rebuild_mask=0x2b: reload_prims=1, reload_points=1, reload_attribs=1, m_local_bbox=[-3.35058 0.318408 -1.83118, -2.99723 1.34921 2.16528](0.353342 1.0308 3.99647), m_have_xform=0, mesh.subd_level=0, subd_render_level=0
 args: 'scene:path'=[/Scene/Set/MuseumInterior/Hallway/geo/Banco_01], 'fsr:node:path'=[/Scene/Set/MuseumInterior/Hallway/geo/Banco_01], 'scene:file:archive:context:hash'=[5965e73fec6229b4], 'scene:file:archive:context:id'=[9223001], 'reader:fps'=[24], 'reader:velocity_scale'=[1], 'fsr:node:name'=[Banco_01], 'reader:creation_mode'=[immediate], 'reader:attribute_mappings'=[], 'geo:read_debug'=[1], 'scene:node:selection:hash'=[a4ce5f9ee3bf4295], 'output_frame'=[206], 'reader:subd_force_enable'=[0], 'reader:subd_snap_to_limit'=[0], 'fsr:node:debug'=[1], 'scene:node:filter:hash'=[9625395cec878e5c], 'frame'=[206], 'fps'=[24], 'reader:color_facesets'=[0], 'scene:file'=[test3.usd], 'reader:subd_import_level'=[off], 'reader:subd_render_level'=[off], 'reader:debug'=[1], 'reader:use_geometry_colors'=[0], 'reader:proxy_lod_mode'=[proxy], 'fsr:node:directive'=[geo:node:auto-detect], 'reader:color_objects'=[0], 'reader:apply_matrix'=[1], 'reader:point_render_mode'=[pointclouds-spheres], 'reader:debug_attribs'=[1]
 FuserUsdMesh::dtor(0xb579b50) '/Scene/Set/MuseumInterior/Hallway/geo/Banco_01'

Hi,

I've tested out building the Hydra plugin using Houdini 17.5.327 and I got pretty close but seems like there is a few things that I can't seem to figure out and just throwing it out there to see if you have solved this. Please feel free to reject this issue.

First off, houdini 17.5 now uses a USD that ships with Houdini, and building anything using anything other than it's inhouse USD will make it pretty sad. So for instance, building the OP_gusd that ships with Houdini is now done like this:

export HOME=/usr/local/USD.19
cmake3 /opt/hfs17.5.327/toolkit/usd_houdini_plugins -DCMAKE_C_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/gcc -DCMAKE_CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/g++ -DCMAKE_PREFIX_PATH=/opt/hfs17.5.327/toolkit
make -j12 install

I've looked at how that is setup and used that as a base to generate this CMakeLists.txt for the Hydra plugin. It compiles fine but segfaults om some missing functions that are not dynamically linked. First test it segfaults on startup with this:

/opt/hfs17.5.327/bin/houdinicore-bin: symbol lookup error: /usr/local/USD.19/houdini17.5/dso/Hydra.so: undefined symbol: _ZN32pxrInternal_v0_19__pxrReserved__16GusdGU_PackedUSD7installER19GA_PrimitiveFactory

That points to:
pxrInternal_v0_19__pxrReserved__::GusdGU_PackedUSD::install(GA_PrimitiveFactory&)
which by inspecting the .so file is undefined in the Hydra.so file. It does exists in the libHoudiniUSD.so though file, but it seems to fall off during dynamically linking it.

It fails here:
https://github.com/dreamworksanimation/dwa_usd_plugins/blob/master/third_party/houdini/plugin/Hydra/plugin.cpp#L34

Removing that line made it go further since that is done on startup in 17.5 and above when talking to sidefx, so no need to do that anymore. But there are still some functions that are missing and it now fails here:

/opt/hfs17.5.327/bin/houdinicore-bin: symbol lookup error: /usr/local/USD.19/houdini17.5/dso/Hydra.so: undefined symbol: _ZNK32pxrInternal_v0_19__pxrReserved__16GusdGU_PackedUSD10getUsdPrimE16UT_ErrorSeverity

looking at the libgusd.so file that is the lib it used before the libHoudiniUSD.so file, it does seem to have more dynamic functions exposed.

nm -D /usr/local/USD.19/houdini17.5/lib/libgusd.so | grep getUsdPrim
000000000014ab40 W _ZNK32pxrInternal_v0_19__pxrReserved__15GusdMeshWrapper10getUsdPrimEv
00000000002882b0 T _ZNK32pxrInternal_v0_19__pxrReserved__16GusdGU_PackedUSD10getUsdPrimE16UT_ErrorSeverity

vs libHoudiniUSD.so

nm -D /opt/hfs17.5.327/dsolib/libHoudiniUSD.so | grep getUsdPrim
0000000000460cf0 T _ZN32pxrInternal_v0_19__pxrReserved__23HUSDgetUsdPrimPredicateE25HUSD_PrimTraversalDemands

I'm not too familiar with what would make the ligbusd.so file have that function show up vs the libHoudiniUSD.so file not having it. I take it that if I were to add the USD_API to that function that it would make it to the dynamically linked functions, but that would require rebuilding libHoudiniUSD.so I think.

If you have any pointers or ideas of solving this they would be more than welcome.
Many thanks,
Dan

Greetings!
I wanted to log this issue on its own to continue discussion on adding support for instanced geometry to the Nuke USD plugin.

I checked into providing a test scene with examples of instancing and it does appear that the Kitchen test scene provided by Pixar has two versions with and without instancing. Here is the path to the kitchen set I tested: http://graphics.pixar.com/usd/downloads.html

Let me know your thoughts on adding basic support for instancing. I think starting with a deferred-loading option makes sense to me and will let us test to see how well Nuke's 3D system can handle (or can't handle as the case may be) an average scene we'll be using in production. Certainly of course, I'm open to other suggestions and ideas for first steps that we can try as well!

Cheers,
Morgan

While testing some of our USD camera setups in Nuke, we discovered that if the camera is nested below 4 or 5 xform nodes the plugin does not seem to correctly resolve the final concatenated xform and therefor the camera ends up being off.

Let me know if there is any additional information that would be helpful in troubleshooting and I'll be happy to try to provide that.

Thanks!
Morgan