academysoftwarefoundation / openvdb Goto Github PK

I'm using openvdb via the Homebrew package manager on MacOs (https://github.com/Homebrew/homebrew-core). Homebrew uses the source code release tarball SHA256 to identify the package and apparently, the SHA has changed on your server of the version 4.0.2 (Homebrew/homebrew-core#17757):

    url "https://github.com/dreamworksanimation/openvdb/archive/v4.0.2.tar.gz"

before

    sha256 "d86852dfff43251a3566f3a25e801591df498a9591558a39f237e935f15e138e"

after

    sha256 "7d995976cf124136b874d006496c37589f32de1b877ee7ccce626710823e8dbb" 

Could you please confirm that the later is the good one ?

Thanks in advance.

Is it intended to *_ALWAYS *_define OPENVDB_IMPORT as attribute((visibility("default"))) under non Windows platforms?

By including almost any openvdb header(openvdb.h is enough). My *.so files start to export all the header file declared/defined symbols. (Example is Maps.h)

I don't have a CLA but here is a tip for fixing the unittest for Windows builds...

https://github.com/caron/openvdb/blob/195735f531955119c9c4d57165dbdea3f34070d2/openvdb/unittest/TestTree.cc#L1662-L1680

small is defined in 'rpcndr.h' as...

#define small char

Hi

I am trying to build the whole openvdb package under windows.
The commandline tools incule a file named "openvdb/port/getopt.c", which is not in the repository.
Could somebody please add this file.

Cheers

Sebastian

I have a segmentation, A 3d array where every value is an integer that corresponds to an object.

Something like this, but in 3d:

I'm interested in either generating meshes for all objects in one pass thru the array, or generating the meshes of one object at the time by using some tree structure so it is fast enogh ( most objects occupies a very small volume, but have a very large bounding box).

Does OpenVDB has any implemantion that could be useful for this?

It seems like these two repos should be made into separate projects. There may be situations where we want to release patch versions of the openvdb code (or Houdini plugins) without revving the other side; keeping them separate makes this easier to manage.

I'm compiling on Arch Linux, and am getting dependencies from Arch's package manager. Headers are stored in /usr/include. I've configured all my header directories using the helpful instructions at the top of the Makefile.

However, I run into errors that stdlib.h cannot be found. I traced it to this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c1

So I've gone and commented out most of the *_INCL_DIR variables, since they end up in -isystem arguments. That works, for the most part, except when those variables are needed for other reasons, in which case I go and delete the -isystem line.

I've been able to get openvdb to compile, but am not sure how I'd fix the Makefile to handle more general cases, like people using gcc < 6

Any advice?

Hi, I have a problem that how can i convert points or particles attributes to a scalar/vector fields.

In Houdini have a sop node:vdb from particles,that can convert the attribute to a volume.

I can convert the particles to volume/sdf(density grid) that used the "MyParticleList" , but how can extract the "v" vector attribute to a openvdb::Vec3s grid(velocity grid) and other typed attribute to their typed grid

thanks.

Hi,

Since python3.5m is in a global space, why is there the ../ in front? Is this the cause of the error that I am getting? My understanding is that just having -lpython3.5m would search the global space first.

My compile options:

	local myprefix="${EPREFIX}"/usr/
	# Enable unit tests later in 4.0.1
	local mycmakeargs=(
		-DOPENVDB_BUILD_UNITTESTS=OFF
		-DOPENVDB_BUILD_DOCS=$(usex doc)
		-DOPENVDB_BUILD_PYTHON_MODULE=$(usex python)
		-DOPENVDB_ENABLE_3_ABI_COMPATIBLE=$(usex abi3-compat)
		-DBLOSC_LOCATION="${myprefix}"
		-DGLEW_LOCATION="${myprefix}"
		-DGLFW_LOCATION="${myprefix}"
		-DGLFW3_LOCATION="${myprefix}"
		-DILMBASE_LOCATION="${myprefix}"
		-DILMBASE_NAMESPACE_VERSIONING=OFF
		-DOPENEXR_LOCATION="${myprefix}"
		-DOPENEXR_NAMESPACE_VERSIONING=OFF
		-DTBB_LOCATION="${myprefix}"
	)

	if use python; then
		mycmakeargs+=(
			-DPYTHON_LIBRARY="$(python_get_LIBS)"
			-DPYTHON_INCLUDE_DIR="$(python_get_includedir)"
		)
	fi

The exact command line:

cd /var/tmp/portage/media-gfx/openvdb-4.0.0/work/openvdb-4.0.0_build/openvdb && /usr/bin/cmake -E cmake_link_script CMakeFiles/openvdb_shared.dir/link.txt --verbose=1
/usr/bin/x86_64-pc-linux-gnu-g++  -fPIC -march=native -O2 -w -pipe -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libopenvdb.so.4.0 -o libopenvdb.so.4.0.0 CMakeFiles/openvdb_shared.dir/Grid.cc.o CMakeFiles/openvdb_shared.dir/MetaMap.cc.o CMakeFiles/openvdb_shared.dir/Metadata.cc.o CMakeFiles/openvdb_shared.dir/Platform.cc.o CMakeFiles/openvdb_shared.dir/io/Archive.cc.o CMakeFiles/openvdb_shared.dir/io/Compression.cc.o CMakeFiles/openvdb_shared.dir/io/File.cc.o CMakeFiles/openvdb_shared.dir/io/GridDescriptor.cc.o CMakeFiles/openvdb_shared.dir/io/Queue.cc.o CMakeFiles/openvdb_shared.dir/io/Stream.cc.o CMakeFiles/openvdb_shared.dir/io/TempFile.cc.o CMakeFiles/openvdb_shared.dir/math/Maps.cc.o CMakeFiles/openvdb_shared.dir/math/Proximity.cc.o CMakeFiles/openvdb_shared.dir/math/QuantizedUnitVec.cc.o CMakeFiles/openvdb_shared.dir/math/Transform.cc.o CMakeFiles/openvdb_shared.dir/points/AttributeArray.cc.o CMakeFiles/openvdb_shared.dir/points/AttributeArrayString.cc.o CMakeFiles/openvdb_shared.dir/points/AttributeGroup.cc.o CMakeFiles/openvdb_shared.dir/points/AttributeSet.cc.o CMakeFiles/openvdb_shared.dir/points/StreamCompression.cc.o CMakeFiles/openvdb_shared.dir/openvdb.cc.o CMakeFiles/openvdb_shared.dir/util/Formats.cc.o CMakeFiles/openvdb_shared.dir/util/Util.cc.o -lboost_iostreams-mt -lboost_system-mt -lboost_thread-mt -lboost_python-3.5-mt -lboost_regex-mt -lboost_chrono-mt -lboost_date_time-mt -lboost_atomic-mt ../-lpython3.5m -ltbb -lHalf -lz -lblosc 
x86_64-pc-linux-gnu-g++: error: ../-lpython3.5m: No such file or directory
make[2]: *** [openvdb/CMakeFiles/openvdb_shared.dir/build.make:680: openvdb/libopenvdb.so.4.0.0] Error 1
make[2]: Leaving directory '/var/tmp/portage/media-gfx/openvdb-4.0.0/work/openvdb-4.0.0_build'
make[1]: *** [CMakeFiles/Makefile2:170: openvdb/CMakeFiles/openvdb_shared.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Thanks. :)

It would be great to be able to convert to Polygons at a different (lower) rate than the VDB resolution without using a VDB Resample SOP to do it. This would be convenient and more efficient, if possible.

Thanks,
Jason

When compiling with make, certain options are not properly used.

The full command line used is this:
make -j2 rpath=no shared=yes DESTDIR=/var/tmp/portage/media-gfx/openvdb-3.1.0/image/usr HFS=/usr HT=/usr HDSO=/usr/lib64 GLFW_INCL_DIR=/usr/lib64 GLFW_LIB_DIR=/usr/lib64 BLOSC_INCL_DIR=/usr/include BLOSC_LIB_DIR=/usr/lib64 EPYDOC= DOXYGEN= LIBOPENVDB_RPATH= CPPUNIT_INCL_DIR=/usr/include/cppunit CPPUNIT_LIB_DIR=/usr/lib64 LOG4CPLUS_INCL_DIR=/usr/include/log4cplus LOG4CPLUS_LIB_DIR=/usr/lib64 PYTHON_VERSION=3.5 PYTHON_INCL_DIR=/usr/include/python3.5m PYCONFIG_INCL_DIR=/usr/include/python3.5m PYTHON_LIB_DIR=/usr/lib64/libpython3.5m.so PYTHON_LIB=-lpython3.5m NUMPY_INCL_DIR=/usr/lib64/python3.5/site-packages/numpy/core/include/numpy BOOST_PYTHON_LIB_DIR=/usr/lib64 BOOST_PYTHON_LIB=-lboost_python-3.5

However, DESTDIR, EPYDOC, and DOXYGEN revert back to the default settings in Makefile. The other options seem to work, as the respected libraries are found. How do I get the Make file to properly respect the options passed to it on the make line?

Thanks,
Jon

Hi,

I don't know if this is a OpenVDB or Blender 2.78a issue. I compiled OpenVDB4 with ABI 3 Compatibility, yet when trying to compile Blender 2.78a with OpenVDB support, I received the error in the title. This only happened when trying to compile the openvdb writer part, whereas the reader part compiled fine.

The full error is:

[ 11%] Building CXX object intern/openvdb/CMakeFiles/bf_intern_openvdb.dir/intern/openvdb_writer.cc.o
cd /var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a_build/intern/openvdb && /usr/bin/x86_64-pc-linux-gnu-g++  -DWITH_OPENVDB -DWITH_OPENVDB_BLOSC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__LITTLE_ENDIAN__ -D__MMX__ -D__SSE2__ -D__SSE__ -I/var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb -I/var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb/intern -isystem /usr/include/OpenEXR   -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -Wredundant-decls -Wall -Wno-invalid-offsetof -Wno-sign-compare -Wlogical-op -Winit-self -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Werror=return-type -Werror=implicit-function-declaration -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith -Wunused-parameter -Wwrite-strings -Wundef -Wformat-signedness -Wuninitialized -Wundef -Wmissing-declarations -march=native -O2 -w -pipe -funsigned-char -fuse-ld=gold -fopenmp -std=c++11   -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing -msse2   -o CMakeFiles/bf_intern_openvdb.dir/intern/openvdb_writer.cc.o -c /var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb/intern/openvdb_writer.cc
/var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb/intern/openvdb_writer.cc: In member function ‘void OpenVDBWriter::insert(const openvdb::v4_0_0::GridBase&)’:
/var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb/intern/openvdb_writer.cc:48:36: error: no matching function for call to ‘std::vector<std::shared_ptr<openvdb::v4_0_0::GridBase> >::push_back(openvdb::v4_0_0::GridBase::ConstPtr)’
  m_grids->push_back(grid.copyGrid());
                                    ^
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/g++-v6/vector:64:0,
                 from /usr/include/boost/random/detail/polynomial.hpp:18,
                 from /usr/include/boost/random/mersenne_twister.hpp:32,
                 from /usr/include/openvdb/math/Math.h:48,
                 from /usr/include/openvdb/Types.h:37,
                 from /usr/include/openvdb/openvdb.h:35,
                 from /var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb/intern/openvdb_writer.h:29,
                 from /var/tmp/portage/media-gfx/blender-2.78a/work/blender-2.78a/intern/openvdb/intern/openvdb_writer.cc:26:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/g++-v6/bits/stl_vector.h:914:7: note: candidate: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = std::shared_ptr<openvdb::v4_0_0::GridBase>; _Alloc = std::allocator<std::shared_ptr<openvdb::v4_0_0::GridBase> >; std::vector<_Tp, _Alloc>::value_type = std::shared_ptr<openvdb::v4_0_0::GridBase>]
       push_back(const value_type& __x)
       ^~~~~~~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/g++-v6/bits/stl_vector.h:914:7: note:   no known conversion for argument 1 from ‘openvdb::v4_0_0::GridBase::ConstPtr {aka std::shared_ptr<const openvdb::v4_0_0::GridBase>}’ to ‘const value_type& {aka const std::shared_ptr<openvdb::v4_0_0::GridBase>&}’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/g++-v6/bits/stl_vector.h:932:7: note: candidate: void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = std::shared_ptr<openvdb::v4_0_0::GridBase>; _Alloc = std::allocator<std::shared_ptr<openvdb::v4_0_0::GridBase> >; std::vector<_Tp, _Alloc>::value_type = std::shared_ptr<openvdb::v4_0_0::GridBase>]
       push_back(value_type&& __x)
       ^~~~~~~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/g++-v6/bits/stl_vector.h:932:7: note:   no known conversion for argument 1 from ‘openvdb::v4_0_0::GridBase::ConstPtr {aka std::shared_ptr<const openvdb::v4_0_0::GridBase>}’ to ‘std::vector<std::shared_ptr<openvdb::v4_0_0::GridBase> >::value_type&& {aka std::shared_ptr<openvdb::v4_0_0::GridBase>&&}’
make[2]: *** [intern/openvdb/CMakeFiles/bf_intern_openvdb.dir/build.make:111: intern/openvdb/CMakeFiles/bf_intern_openvdb.dir/intern/openvdb_writer.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....

where is this script ?

(Source the houdini_setup script to set those two environment variables.)

I tried using meshToSignedDistanceField with a world to index transform that maps to
an anisotrop voxel size (e.g. 0.5, 0.25, 0.25). When reading the resulting distance field,
I noticed that the distances are wrong, because only the voxel size in X dimension is taken into account:

const ValueType voxelSize = ValueType(transform.voxelSize()[0]);
Could you maybe support anisotropic voxel sizes in a future version?

i am not so used to using the scroll wheel for zooming, i dont mind using the scroll wheel for shifting the cut planes but not for navigation. maybe add support both?

This could be an intro refactor exercise for me, but I want to check first. Metadata.h does nothing but expose part of the metadata folder namespace-free for convenience, but it's used internally too. Platform.cc is similar (wherever Platform.h is used).

Example:
openvdb::io::File input_file("files_that_doesnt_exist.vdb");
input_file.open();
There is no warning at all, and it just die.
Is it possible to add at least some warning, so people can debug it?

I am trying to compile openVDB4.0 houdini toolkit on houdini 15.5. I have sourced the houdini setup script and managed to compile the library, the unit tests also run. The new openVDB nodes show up in houdini, but when I use the createVDB node, houdini crashes with a memory usage error. I am able to compile and execute the examples in the openVDB cookbook with version 4. The versions of the dependencies I have used are : gnu make 3.81, and cppunit version 1.13, the rest of the libraries are as specified in the houdini HDK.

/var/tmp/portage/media-gfx/openvdb-4.0.2/work/openvdb-4.0.2/openvdb/python/pyFloatGrid.cc: In function ‘void exportFloatGrid()’:
/var/tmp/portage/media-gfx/openvdb-4.0.2/work/openvdb-4.0.2/openvdb/python/pyFloatGrid.cc:50:9: error: ‘py::numeric’ has not been declared
py::numeric::array::set_module_and_type("numpy", "ndarray");
^~~~~~~

python/numeric.hpp removed from boost
boostorg/python@2d1f66f

Reference to older issue : #126
I have installed the vdb 4.0.0 version with abi=3, when I compile the example code, I run into the similar error, undefined reference to openvdb::v4_0_0::math::simplify(std::shared_ptropenvdb::v4_0_0::math::AffineMap) .
openvdb::v4_0_0::io::setStreamMetadataPtr(std::ios_base&,std::shared_ptropenvdb::v4_0_0::io::StreamMetadata&, bool)
I am not sure how to set the ABI during compilation. Is it a flag that needs to be set during compilation?

What is "if closely related" supposed to be?

Hi,

Having created some OpenVDB 4.0 point data and writing them out to disk, I don't see them when I view them in vdb_view

I tried using Houdini "OpenVDB Read" SOP node, still without success.

What is the work flow utilizing point data in OpenVDB 4.0 ?

Cheers

There seems to be a memory leak in tools::mesh_to_volume_internal::ExpandNarrowband::operator().

Notice while using the new Platonic ops with the latest development version.

Here's (a cleaned up) part of a report from GCC 5.3's leak sanitizer:

Indirect leak of 10240 byte(s) in 5 object(s) allocated from:
    #0 0x7fc9125a530a in operator new[](unsigned long)
    #1 0x7fc8f085f73d in tree::LeafNode<int, 3u>::Buffer::Buffer(int const&)
    #2 0x7fc8f085a6f4 in tree::LeafNode<int, 3u>::LeafNode(math::Coord const&, int const&, bool)
    #3 0x7fc8f08d128b in tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >::operator()(tbb::blocked_range<unsigned long> const&)
    #4 0x7fc8f08c2b48 in tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>::run_body(tbb::blocked_range<unsigned long>&)
    #5 0x7fc8f08b05a8 in void tbb::partition_type_base<tbb::auto_partition_type>::execute<tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>, tbb::blocked_range<unsigned long> >(tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>&, tbb::blocked_range<unsigned long>&)
    #6 0x7fc8f08a047b in tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>::execute()

Full report

Hi,
I'm using OpenVDB and the Eigen library together and the B2 macro in openvdb/util/NodeMasks.h conflicts with an object in the Eigen library. Would it be possibly for you to rename the B2, B4, B6 macros in such a way as to be unlikely to conflict with other code? Or possibly not use #define at all?
Thanks!

Eigen/src/SVD/BDCSVD.h:350:48: error: too many arguments provided to function-like macro invocation
Map B2(m_workspace.data()+2nn, n, n);
^
openvdb/util/NodeMasks.h:60:12: note: macro 'B2' defined here
# define B2(n) n, n+1, n+1, n+2
^
1 error generated.

I have compiled and installed the openvdb latest commit in Ubuntu 16.04 with boost 1.58 successfully.
During the compilation of any cookbook examples, i get the following error:

In function openvdb::v4_0_1::math::AffineMap::postRotate(double, openvdb::v4_0_1::math::Axis) const': /usr/local/include/openvdb/math/Maps.h:619: undefined reference to openvdb::v4_0_1::math::simplify(std::shared_ptropenvdb::v4_0_1::math::AffineMap)'

The simplify function in OpenVDB library is defined as:
openvdb::v4_0_1::math::simplify(boost::shared_ptropenvdb::v4_0_1::math::AffineMap)

But in the Maps.h it is defined as
OPENVDB_API SharedPtr simplify(SharedPtr affine);

where
template using SharedPtr = std::shared_ptr;

I think that, it shall be declared as boost::shared_ptr instead of std::shared_ptr.

Hi,

Using the source from master, at the date in the title, the python module fails with this message:

In file included from /usr/include/sched.h:28:0,
                 from /usr/include/pthread.h:23,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/x86_64-pc-linux-gnu/bits/gthr-default.h:35,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/x86_64-pc-linux-gnu/bits/gthr.h:148,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/ext/atomicity.h:35,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/basic_string.h:39,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/string:52,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/stdexcept:39,
                 from /usr/include/boost/function/function_base.hpp:14,
                 from /usr/include/boost/function/detail/prologue.hpp:17,
                 from /usr/include/boost/function/function_template.hpp:13,
                 from /usr/include/boost/function/detail/maybe_include.hpp:13,
                 from /usr/include/boost/function/function0.hpp:11,
                 from /usr/include/boost/python/errors.hpp:13,
                 from /usr/include/boost/python/handle.hpp:11,
                 from /usr/include/boost/python/args_fwd.hpp:10,
                 from /usr/include/boost/python/args.hpp:10,
                 from /usr/include/boost/python.hpp:11,
                 from python/pyOpenVDBModule.cc:33:
python/pyOpenVDBModule.cc: In function ‘void init_module_pyopenvdb()’:
python/pyOpenVDBModule.cc:595:5: error: return-statement with a value, in function returning 'void' [-fpermissive]
     import_array();

However, Python v2.7.x will compile the module. If you need more details, please let me know.

Thanks,
Jon

Appendix: The compile settings:
make -j2 python rpath=no shared=yes LIBOPENVDB_RPATH= DESTDIR=/var/tmp/portage/media-gfx/openvdb-3.2.0_pre20160604/work/install/usr HFS=/usr HT=/usr HDSO=/usr/lib64 CPPUNIT_INCL_DIR=/usr/include/cppunit CPPUNIT_LIB_DIR=/usr/lib64 LOG4CPLUS_INCL_DIR=/usr/include/log4cplus LOG4CPLUS_LIB_DIR=/usr/lib64 GLFW_INCL_DIR=/usr/lib64 GLFW_LIB_DIR=/usr/lib64 BLOSC_INCL_DIR=/usr/include BLOSC_LIB_DIR=/usr/lib64 DOXYGEN= PYTHON_VERSION=3.4 PYTHON_INCL_DIR=/usr/include/python3.4m PYCONFIG_INCL_DIR=/usr/include/python3.4m PYTHON_LIB_DIR=/usr/lib64/libpython3.4m.so PYTHON_LIB=-lpython3.4m PYTHON_INSTALL_INCL_DIR=/var/tmp/portage/media-gfx/openvdb-3.2.0_pre20160604/work/install/usr/include/python3.4m PYTHON_INSTALL_LIB_DIR=/var/tmp/portage/media-gfx/openvdb-3.2.0_pre20160604/work/install/usr/lib64/python3.4/site-packages NUMPY_INCL_DIR=/usr/lib64/python3.4/site-packages/numpy/core/include/numpy BOOST_PYTHON_LIB_DIR=/usr/lib64 BOOST_PYTHON_LIB=-lboost_python-3.4 EPYDOC=
Building python/pyFloatGrid.o because of pyFloatGrid.cc and others
g++ -c -march=native -O2 -w -pipe -pthread -O3 -DNDEBUG -I . -I .. -isystem /usr/include -isystem /usr/include -isystem /usr/include -isystem /usr/include -isystem /usr/include/log4cplus -DOPENVDB_USE_BLOSC -DOPENVDB_USE_LOG4CPLUS -DOPENVDB_USE_GLFW_3 -I . -fPIC -isystem python -isystem /usr/include/python3.4m -isystem /usr/include/python3.4m -isystem /usr/lib64/python3.4/site-packages/numpy/core/include/numpy -DPY_OPENVDB_USE_NUMPY -o python/pyFloatGrid.o python/pyFloatGrid.cc
Building python/pyIntGrid.o because of pyIntGrid.cc and others
g++ -c -march=native -O2 -w -pipe -pthread -O3 -DNDEBUG -I . -I .. -isystem /usr/include -isystem /usr/include -isystem /usr/include -isystem /usr/include -isystem /usr/include/log4cplus -DOPENVDB_USE_BLOSC -DOPENVDB_USE_LOG4CPLUS -DOPENVDB_USE_GLFW_3 -I . -fPIC -isystem python -isystem /usr/include/python3.4m -isystem /usr/include/python3.4m -isystem /usr/lib64/python3.4/site-packages/numpy/core/include/numpy -DPY_OPENVDB_USE_NUMPY -o python/pyIntGrid.o python/pyIntGrid.cc

The grid.deepCopy() call produces this error:

c = g.deepCopy() TypeError: No to_python (by-value) converter found for C++ type: boost::shared_ptr<openvdb::v3_2_0::Grid<openvdb::v3_2_0::tree::Tree<openvdb::v3_2_0::tree::RootNode<openvdb::v3_2_0::tree::InternalNode<openvdb::v3_2_0::tree::InternalNode<openvdb::v3_2_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > > >

Demo script:

`
import sys
import pyopenvdb as vdb

g = vdb.FloatGrid()
g.fill(min=(0, 0, 0), max=(100, 100, 100), value=1.0)

c = g.deepCopy()
`

Reverting to boost 1.59 works around this.

In my attempts to sort out where the issue was coming from, I also tried building openvdb 3.1 and 3.0 against boost 1.60 and they fail in the same way. This happens with both python 2 and 3.

Math.h I mean inclusive/exclusive in terms of tolerance bounds. Is this intended?

Also something I can do.

Hi there,

it might be too early for reporting this as the VolumeRayIntersectors is not part of an official release yet, but I thought getting it out might help with the development. There seems to be a bug in the VolumeHDDA. In some cases, the DDA seems to get stuck in a tile or a voxel not advancing to the next one. I tried to create a minimal code that reproduces the error. It is a variation of the last test in the TestVolumeRayIntersector.cc. In the second block, the ray is reversed, other than that the blocks are identical.

    FloatGrid grid(0.0f);

    grid.tree().setValue(Coord(0*8,0,0), 1.0f);
    grid.tree().setValue(Coord(1*8,0,0), 1.0f);
    grid.tree().setValue(Coord(3*8,0,0), 1.0f);
    // grid.fill(CoordBBox(Coord(4*8,0,0), Coord(4*8+7,7,7)), 2.0f, true);

    tools::VolumeRayIntersector<FloatGrid> inter(grid);
    {
        const Vec3T dir( 1.0, 0.0, 0.0);
        const Vec3T eye(-1.0, 0.0, 0.0);
        const RayT ray(eye, dir);
        int hit = inter.setIndexRay(ray);
        printf("setIndexRay(): %d\n", hit);
        double t0=0, t1=0;
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
    }

    {
        // Flip and offset the ray
        const Vec3T dir(-1.0, 0.0, 0.0);
        const Vec3T eye(50.0, 0.0, 0.0);
        const RayT ray(eye, dir);
        int hit = inter.setIndexRay(ray);
        printf("setIndexRay(): %d\n", hit);
        double t0=0, t1=0;
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
        hit = inter.march(t0, t1);
        printf("march(): %d, t0: %f t1: %f\n", hit, t0, t1);
    }

This produces the following output:

setIndexRay(): 1
march(): 2, t0: 1.000000 t1: 9.000000
march(): 2, t0: 9.000000 t1: 17.000000
march(): 2, t0: 25.000000 t1: 33.000000
march(): 1, t0: 33.000000 t1: 41.000000
march(): 0, t0: 33.000000 t1: 41.000000
setIndexRay(): 1
march(): 1, t0: 10.000000 t1: 18.000000
march(): 1, t0: 18.000000 t1: 18.000000
march(): 1, t0: 18.000000 t1: 18.000000
march(): 1, t0: 18.000000 t1: 18.000000
march(): 1, t0: 18.000000 t1: 18.000000

For the reverted ray, the march() method steps only ones and then gets stuck with the current region (tile). The problem occurs even if I remove the tile; it gets stuck in a leaf node.As long as I'm not doing something stupid, I believe this is a bug.

Can you please confirm and let me know when do you expect to release the VolumeRayIntersector in an official release?

Thanks!
--jan

The i386 build of openvdb failed with errors indicating that it was
trying to use templates specialized on unsigned int whereas it needed
variants specialized on unsigned long long:

In file included from ./openvdb/tree/LeafNode.h:41:0,
from ./openvdb/tree/Tree.h:52,
from ./openvdb/Grid.h:43,
from ./openvdb/openvdb.h:39,
from viewer/RenderModules.h:34,
from viewer/RenderModules.cc:31:
/usr/include/tbb/parallel_for.h: In instantiation of 'void tbb::interface6::internal::start_for<Range, Body, Partitioner>::run_body(Range&) [with Range = tbb::blocked_range; Body = openvdb_viewer::PointGenerator<const openvdb::v1_2::tree::Tree<openvdb::v1_2::tree::RootNode<openvdb::v1_2::tree::InternalNode<openvdb::v1_2::tree::InternalNode<openvdb::v1_2::tree::LeafNode<long long int, 3u>, 4u>, 5u> > > >; Partitioner = tbb::auto_partitioner]':
/usr/include/tbb/partitioner.h:247:13: required from 'void tbb::interface6::internal::partition_type_base::execute(StartType&, Range&) [with StartType = tbb::interface6::internal::start_for<tbb::blocked_range, openvdb_viewer::PointGenerator<const openvdb::v1_2::tree::Tree<openvdb::v1_2::tree::RootNode<openvdb::v1_2::tree::InternalNode<openvdb::v1_2::tree::InternalNode<openvdb::v1_2::tree::LeafNode<long long int, 3u>, 4u>, 5u> > > >, tbb::auto_partitioner>; Range = tbb::blocked_range; Partition = tbb::interface6::internal::auto_partition_type]'
/usr/include/tbb/parallel_for.h:116:9: required from 'tbb::task* tbb::interface6::internal::start_for<Range, Body, Partitioner>::execute() [with Range = tbb::blocked_range; Body = openvdb_viewer::PointGenerator<const openvdb::v1_2::tree::Tree<openvdb::v1_2::tree::RootNode<openvdb::v1_2::tree::InternalNode<openvdb::v1_2::tree::InternalNode<openvdb::v1_2::tree::LeafNode<long long int, 3u>, 4u>, 5u> > > >; Partitioner = tbb::auto_partitioner]'
viewer/RenderModules.cc:600:1: required from here
[...]

It's not clear what actually needs these specific instantiations, or
for that matter why they're not a problem elsewhere, as the only
requirer cited that isn't itself a template is the brace closing
RenderModules.cc's namespace openvdb_viewer { ... } construct.

ref:
http://bugs.debian.org/715427

Math.h

/// Return @a x if it is greater in magnitude than @a delta.  Otherwise, return zero.
template<typename Type>
inline Type Chop(Type x, Type delta) { return (Abs(x) < delta ? zeroVal<Type>() : x); }

Hi there,

We generally find it far more robust and useful to be able to specify distances (like those in Reshape SDF) in units rather than in voxels. It makes it easier to up-res things in production without having to adjust values in concert with the voxel resolution. Would it be possible to add support for this?

Thanks,
Jason Iversen

I noticed that the new CMake files don't have support for building the python module, unless I missed that.

Anyways, I would like to request that the build system should somehow take a list of all versions to build the python module for, like 2.7, 3.4, 3.5... I use Gentoo where we can have multiple versions installed to support various packages.

This should also mean that auto-finding the python implementations should be overrided since there is a default that /usr/bin/python, /usr/bin/python2, /usr/bin/python3 link to, so I need to set the path to the correct version which our build system does for us.

Thanks,
Jon

I feel like there should be a straightforward way to write compressed VDB's, however I am not able to get the compressed files from houdini 15 (a VDB points grid, using the openVDB write node). I am however able to get gzipped VDB's from houdini 16 file write node.
How do I write out a compressed VDB in houdini 15? Also I notice that there is a small difference (about 0.2 KB ) between the files written from houdini 15 vs 16, why does this happen?

Hello there,

I've build OpenVDB 4.0.1 with the instruction provide by 'BuildingWithCMake.md' in the package.
I'm using this configuration for cmake and all want fine:

export ILMBASE_ROOT=/prod/softprod/libs/openexr/2.2.0
export OPENEXR_ROOT=/prod/softprod/libs/openexr/2.2.0
export GLFW3_LOCATION=/prod/softprod/libs/glfw/3.2.1
export MAYA_LOCATION=/prod/softprod/apps/maya/2016.sp6/linux
export BLOSC_LOCATION=/prod/softprod/libs/c-blosc/1.7.1
export TBB_ROOT=$MAYA_LOCATION
export BOOST_ROOT=/prod/softprod/libs/boost/1.61.0
export LD_LIBRARY_PATH=$BOOST_ROOT/lib:$ILMBASE_ROOT/lib:$OPENEXR_ROOT/lib:$GLFW3_ROOT/lib:$BLOSC_ROOT/lib
cmake \
-D CMAKE_BUILD_TYPE=Release \
-D CMAKE_CXX_COMPILER=/opt/rh/devtoolset-2/root/usr/bin/g++ \
-D CMAKE_C_COMPILER=/opt/rh/devtoolset-2/root/usr/bin/gcc \
-D CMAKE_CXX_FLAGS=-std=c++11 \
-D BLOSC_LOCATION=/prod/softprod/libs/c-blosc/1.7.1 \
-D Tbb_TBB_LIBRARY=$MAYA_LOCATION/lib/libtbb.so \
-D Tbb_TBBMALLOC_LIBRARY=$MAYA_LOCATION/lib/libtbbmalloc.so \
-D OPENVDB_ENABLE_3_ABI_COMPATIBLE=ON \
-D OPENVDB_BUILD_UNITTESTS=OFF \
-D OPENVDB_BUILD_DOCS=OFF \
-D OPENVDB_BUILD_MAYA_PLUGIN=ON \
-D OPENVDB_ENABLE_RPATH=ON \
-D ILMBASE_NAMESPACE_VERSIONING=OFF \
-D OPENEXR_NAMESPACE_VERSIONING=OFF \
-D USE_GLFW3=ON \
-D GLFW3_LOCATION=/prod/softprod/libs/glfw/3.2.1 \
-D Boost_USE_STATIC_LIBS=ON \
-D Blosc_USE_STATIC_LIBS=ON \
-D CPPUnit_USE_STATIC_LIBS=ON \
-D CMAKE_INSTALL_PREFIX=/prod/softprod/libs/openvdb/4.0.1 \
../
 
make
make install

But when i try to load the OpenVDB.so plugin, it failed with an error:
/prod/softprod/libs/openvdb/4.0.1/maya2016/plug-ins/OpenVDB.so: undefined symbol: _ZNK7MPxNode9dependsOnERK5MPlugS2_Rb //
// Error: line 1: /prod/softprod/libs/openvdb/4.0.1/maya2016/plug-ins/OpenVDB.so: undefined symbol: _ZNK7MPxNode9dependsOnEdevRK5MPlugS2_Rb (OpenVDB) //

I'm on Centos 6.8. I'm using devtoolset-2 (gcc 4.8.2).

I don't know where to search for resolving this error...
Can you help me please.

Thanks

Should I ask a question here meanwhile?

Whoops, just did. [/clever]

It seems to me that the new openvdb version is not working with boost 1.54 and above.
The reason is the usage of the iostrems::filedescriptor method in boost.
I guess this is a boost bug, which was reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739908

So, compiling openvdb lib with the command

g++ -pthread -O3 -DNDEBUG -I . -I .. -isystem /include -isystem /usr/include/OpenEXR -isystem /usr/include/tbb -isystem /rel/folio/log4cplus/log4cplus-1.0.3-latest/sys_include -DOPENVDB_USE_LOG4CPLUS -DOPENVDB_USE_GLFW_3 -o vdb_print cmd/openvdb_print/main.cc -I . \
        -ldl -lm -lz -Wl,-rpath,/usr/lib/x86_64-linux-gnu/ -L/usr/lib/x86_64-linux-gnu/ -lHalf -Wl,-rpath,/usr/lib/x86_64-linux-gnu/ -L/usr/lib/x86_64-linux-gnu/ -ltbb -Wl,-rpath,/usr/lib/x86_64-linux-gnu/ -L/usr/lib/x86_64-linux-gnu/ -lboost_iostreams -lboost_system  -Wl,-rpath,/rel/folio/log4cplus/log4cplus-1.0.3-latest/library -L/rel/folio/log4cplus/log4cplus-1.0.3-latest/library -llog4cplus -lrt -ljemalloc \
        -Wl,-rpath,/tmp/OpenVDB/lib -L/home/user/projects/cpp/openvdb_github/openvdb libopenvdb.so.3.0.0

fails with

libopenvdb.so.3.0.0: undefined reference to `boost::iostreams::file_descriptor::seek(long, std::_Ios_Seekdir)'
libopenvdb.so.3.0.0: undefined reference to `boost::iostreams::file_descriptor::close()'
libopenvdb.so.3.0.0: undefined reference to `boost::iostreams::file_descriptor_sink::file_descriptor_sink(int, boost::iostreams::file_descriptor_flags)'
libopenvdb.so.3.0.0: undefined reference to `boost::iostreams::file_descriptor_sink::file_descriptor_sink(boost::iostreams::file_descriptor_sink const&)'
libopenvdb.so.3.0.0: undefined reference to `boost::iostreams::file_descriptor::write(char const*, long)'
libopenvdb.so.3.0.0: undefined reference to `boost::iostreams::file_descriptor::file_descriptor()'

When compiling to static libraries (setting make shared=no)
the error is

libopenvdb.a(Archive.o): In function `openvdb::v3_0_0::io::getErrorString(int)':
Archive.cc:(.text+0xf0c): undefined reference to `boost::system::generic_category()'

As for the linker libraries

/usr/lib/x86_64-linux-gnu/

in my case,
this contains the required libraries:

libboost_iostreams.a
libboost_iostreams.so
libboost_iostreams.so.1.54.0
libboost_iostreams.so.1.55.0

Hello! I'm very excited about using OpenVDB, but I'm looking for a cross-platform, easy-to-install way of interacting with it. I have successfully compiled but it would be great to be able to install the python library like pip install pyopenvdb. I'm not sure of the challenges to do that, but I thought I would bring it up because having python packages available via pip decreases the startup cost by an order of magnitude, easily. Thoughts?

When I try to display the surface in the vdb view tool, I receive this error in the console:

log4cplus:ERROR No appenders could be found for logger (main). log4cplus:ERROR Please initialize the log4cplus system properly.

Hi guys I just wanted to ask if calling file.close() in File::writeGrids is intended, as the name of the function does not suggest it, and it may cause problems to someone?

Hi,

After reading in an OpenVDB 4 file with point data, how does one create a partitioner ?

I am looking to the partitioner to provide indices to actual points (per bucket?) and query additional information like position, velocity and other attributes.

So far, I don't know what method in PointDataGrid returns object that can be use for the construction of the Partitioner, here is my current attempt, ::create() fails to compile as I am not providing what it needs

I see the example creating a struct call PointList within an anonymous namespace

`
openvdb::io::File fileIn(vdb_file);
fileIn.open();

    openvdb::GridPtrVecPtr grids = fileIn.getGrids();

    fileIn.close();

	std::cout << boost::format("Grid size = %1%") % grids->size() << std::endl;

	if (!grids->empty())
	{
		openvdb::points::PointDataGrid::Ptr inputPointDataGrid = openvdb::GridBase::grid<openvdb::points::PointDataGrid>((*grids)[0]);
		if (inputPointDataGrid)
		{
			if (!inputPointDataGrid->empty())
			{
			    const float voxelSize = 0.1f;
			    const openvdb::math::Transform::Ptr transform =
			            openvdb::math::Transform::createLinearTransform(voxelSize);

			    typedef openvdb::tools::UInt32PointPartitioner PointPartitioner;

			    PointPartitioner::Ptr partitioner =
			                PointPartitioner::create(pointList, *transform);

`

Cheers

Relevant log:

Relevant part (hopefully):

g++ -c -DOPENVDB_PRIVATE -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-inlines-hidden -pthread -g -I . -I .. -isystem /usr/include -isystem /usr/include/OpenEXR -isystem /usr/include -isystem /usr/include -isystem /usr/include -DOPENVDB_USE_BLOSC -DOPENVDB_USE_LOG4CPLUS -DOPENVDB_USE_GLFW_3 -fPIC -o Grid.o Grid.cc
In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
from /usr/include/c++/6/bits/basic_string.h:5402,
from /usr/include/c++/6/string:52,
from /usr/include/c++/6/bits/locale_classes.h:40,
from /usr/include/c++/6/bits/ios_base.h:41,
from /usr/include/c++/6/ios:42,
from /usr/include/c++/6/ostream:38,
from /usr/include/c++/6/iostream:39,
from Grid.h:34,
from Grid.cc:31:
/usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^
compilation terminated.
make[2]: *** [Grid.o] Error 1

Hello,

I am having some trouble converting a mesh with nested shells in the MeshToVolume conversion function. I am getting a grid that shows the entire volume as filled rather than just the skin. Please see:
nestedShell.zip

for a sample file.

It does say that the normals are not taken into account during the conversion, so I'm not sure than how else to handle this -- maybe do a csgSubtract of the inner shell from the outer shell? Thanks!

Brad

We're using OpenVDB 3.0.0 on Linux.
I'm trying to update our TBB implementation to 2017 update 5, but there is one pretty bad crash when we try to open a vdb and read its content.

If I revert the version of TBB the problem disappears.
Below you can find the backtrace printed by valgrind:

==26566== Process terminating with default action of signal 11 (SIGSEGV)
==26566== Access not within mapped region at address 0x10
==26566== at 0x114E587A: load_with_acquire (tbb_machine.h:611)
==26566== by 0x114E587A: __TBB_load_with_acquiretbb::interface5::internal::hash_map_base::node_base* (tbb_machine.h:706)
==26566== by 0x114E587A: itt_load_word_with_acquiretbb::interface5::internal::hash_map_base::node_base* (tbb_profiling.h:209)
==26566== by 0x114E587A: acquire (concurrent_hash_map.h:647)
==26566== by 0x114E587A: bucket_accessor (concurrent_hash_map.h:642)
==26566== by 0x114E587A: tbb::interface5::concurrent_hash_map<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool, tbb::tbb_hash_compare<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>>, tbb::tbb_allocator<std::pair<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool> > >::lookup(bool, openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const> const&, bool const*, tbb::interface5::concurrent_hash_map<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool, tbb::tbb_hash_compare<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>>, tbb::tbb_allocator<std::pair<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool> > >::const_accessor, bool, tbb::interface5::concurrent_hash_map<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool, tbb::tbb_hash_compare<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>>, tbb::tbb_allocator<std::pair<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool> > >::node ()(tbb::tbb_allocator<tbb::interface5::concurrent_hash_map<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool, tbb::tbb_hash_compare<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>>, tbb::tbb_allocator<std::pair<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool> > >::node>&, openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>* const&, bool const*), tbb::interface5::concurrent_hash_map<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool, tbb::tbb_hash_compare<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>>, tbb::tbb_allocator<std::pair<openvdb::v3_0_0::tree::ValueAccessorBase<openvdb::v3_0_0::tree::Tree<openvdb::v3_0_0::tree::RootNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::InternalNode<openvdb::v3_0_0::tree::LeafNode<float, 3u>, 4u>, 5u> > > const>, bool> > >::node) (concurrent_hash_map.h:1132)
==26566== by 0x114E61E4: insert (concurrent_hash_map.h:951)
==26566== by 0x114E61E4: attachAccessor (Tree.h:1413)
==26566== by 0x114E61E4: ValueAccessorBase (ValueAccessor.h:107)
==26566== by 0x114E61E4: ValueAccessor3 (ValueAccessor.h:2089)
==26566== by 0x114E61E4: ValueAccessor (ValueAccessor.h:479)
==26566== by 0x114E61E4: getConstAccessor (Grid.h:593)

Hi,

I have the following code which works for "P" but not for "Cd", is retrieving attribute data other than "P" very different ?

`
for (openvdb::points::PointDataTree::LeafCIter leafIter = inputPointDataGrid->tree().cbeginLeaf(); leafIter; ++leafIter)
{
const openvdb::Name attribute_name("Cd");
openvdb::points::AttributeHandleopenvdb::Vec3s::Ptr handle = openvdb::points::AttributeHandleopenvdb::Vec3s::create(leafIter->constAttributeArray(attribute_name));

for (openvdb::points::PointDataTree::LeafNodeType::IndexOnIter iter = leafIter->beginIndexOn(); iter; ++iter)
{
if (attribute_name.compare("P")==0)
{

   const openvdb::Vec3s voxelCoord = iter.getCoord().asVec3d();
   const openvdb::Vec3s positionVoxelSpace = handle->get(*iter);
   const openvdb::Vec3s positionWorldSpace = inputPointDataGrid->transform().indexToWorld(positionVoxelSpace + voxelCoord);
   std::cout << boost::format("%1%: %2%") % attribute_name % positionWorldSpace << std::endl;
 }
 else
 {
   const openvdb::Vec3s positionVoxelSpace = handle->get(*iter);
   std::cout << boost::format("%1%: %2%") % attribute_name % positionVoxelSpace << std::endl;
 }

}
}
`

Cheers

Hello, I'm trying to build OpenVDB on OS X 10.8.5 and it doesn't compile.

I have this output with Apple LLVM version 5.0 (clang-500.2.76):

In file included from viewer/RenderModules.cc:31:
In file included from viewer/RenderModules.h:34:
In file included from ../openvdb/openvdb.h:39:
In file included from ./Grid.h:43:
In file included from ../openvdb/tree/Tree.h:52:
In file included from ../openvdb/tree/LeafNode.h:41:
/Library/Frameworks/Houdini.framework/Versions/12.5.469/Resources/toolkit/include/tbb/parallel_for.h:110:37: error: no matching function for call to object of type 'const openvdb_viewer::PointGenerator<const
      openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > >'
        void run_body( Range &r ) { my_body( r ); }
                                    ^~~~~~~
/Library/Frameworks/Houdini.framework/Versions/12.5.469/Resources/toolkit/include/tbb/partitioner.h:247:19: note: in instantiation of member function 'tbb::interface6::internal::start_for<tbb::blocked_range<unsigned long>, openvdb_viewer::PointGenerator<const
      openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > >, tbb::auto_partitioner>::run_body' requested here
            start.run_body( range ); // simple partitioner goes always here
                  ^
/Library/Frameworks/Houdini.framework/Versions/12.5.469/Resources/toolkit/include/tbb/parallel_for.h:116:22: note: in instantiation of function template specialization
      'tbb::interface6::internal::partition_type_base<tbb::interface6::internal::auto_partition_type>::execute<tbb::interface6::internal::start_for<tbb::blocked_range<unsigned long>, openvdb_viewer::PointGenerator<const
      openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > >, tbb::auto_partitioner>, tbb::blocked_range<unsigned long> >' requested here
        my_partition.execute(*this, my_range);
                     ^
/Library/Frameworks/Houdini.framework/Versions/12.5.469/Resources/toolkit/include/tbb/parallel_for.h:92:67: note: in instantiation of member function 'tbb::interface6::internal::start_for<tbb::blocked_range<unsigned long>, openvdb_viewer::PointGenerator<const
      openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > >, tbb::auto_partitioner>::execute' requested here
                start_for& a = *new(task::allocate_root(context)) start_for(range,body,const_cast<Partitioner&>(partitioner));
                                                                  ^
/Library/Frameworks/Houdini.framework/Versions/12.5.469/Resources/toolkit/include/tbb/parallel_for.h:162:5: note: in instantiation of member function 'tbb::interface6::internal::start_for<tbb::blocked_range<unsigned long>, openvdb_viewer::PointGenerator<const
      openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > >, tbb::auto_partitioner>::run' requested here
    internal::start_for<Range,Body,__TBB_DEFAULT_PARTITIONER>::run(range,body,__TBB_DEFAULT_PARTITIONER());
    ^
viewer/RenderModules.h:380:9: note: in instantiation of function template specialization 'tbb::parallel_for<tbb::blocked_range<unsigned long>, openvdb_viewer::PointGenerator<const
      openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > > >' requested here
        tbb::parallel_for(mLeafs.getRange(), *this);
        ^
viewer/RenderModules.h:764:18: note: in instantiation of member function 'openvdb_viewer::PointGenerator<const openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > >
      >::runParallel' requested here
        pointGen.runParallel();
                 ^
viewer/RenderModules.h:987:21: note: in instantiation of function template specialization
      'openvdb_viewer::ActiveScalarValuesOp::operator()<openvdb::v2_0_0::Grid<openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > > >' requested here
        op.template operator()<GridType>(openvdb::gridConstPtrCast<GridType>(grid));
                    ^
viewer/RenderModules.h:999:70: note: in instantiation of member function 'openvdb_viewer::util::GridProcessor<openvdb::v2_0_0::Grid<openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long
      long, 3>, 4>, 5> > > >, openvdb_viewer::ActiveScalarValuesOp, true>::call' requested here
        boost::is_const<typename GridPtrType::element_type>::value>::call(op, grid);
                                                                     ^
viewer/RenderModules.h:1061:51: note: in instantiation of function template specialization
      'openvdb_viewer::util::doProcessTypedGrid<openvdb::v2_0_0::Grid<openvdb::v2_0_0::tree::Tree<openvdb::v2_0_0::tree::RootNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::InternalNode<openvdb::v2_0_0::tree::LeafNode<long long, 3>, 4>, 5> > > >, openvdb_viewer::ActiveScalarValuesOp,
      boost::shared_ptr<const openvdb::v2_0_0::GridBase> >' requested here
    else if (grid->template isType<Int64Grid>())  doProcessTypedGrid<Int64Grid>(grid, op);
                                                  ^
viewer/RenderModules.cc:511:10: note: in instantiation of function template specialization 'openvdb_viewer::util::processTypedScalarGrid<boost::shared_ptr<const openvdb::v2_0_0::GridBase>, openvdb_viewer::ActiveScalarValuesOp>' requested here
    if (!util::processTypedScalarGrid(mGrid, drawScalars)) {
         ^
viewer/RenderModules.h:384:17: note: candidate function not viable: no known conversion from 'blocked_range<unsigned long>' to 'const blocked_range<openvdb::Index64>' for 1st argument
    inline void operator()(const tbb::blocked_range<openvdb::Index64>& range) const
                ^

And I have the same error with GCC 4.8.2:

viewer/RenderModules.h:384:17: note:   no known conversion for argument 1 from ‘tbb::blocked_range<long unsigned int>’ to ‘const tbb::blocked_range<unsigned int>&’

I tried to compile version 1.2 from the official site and the last version from here, every time I have the same error.

Changing "openvdb::Index64" to "unsigned long" in viewer/RenderModules.h:384:53 fixes the problem.

I use Archive::getUniqueTag() to validate the identity of archives in an application and I noticed that under some circumstances different archives can have the same UUID as returned from getUniqueTag(). I looked at the code and it appears that when writing an archive, Archive::writeHeader() uses the time in seconds since the Unix epoch as the seed to the random number generator used to generate the UUIDs (https://github.com/dreamworksanimation/openvdb/blob/master/openvdb/io/Archive.cc#L978).

I think this causes multiple archives to receive the same UUID if a program writes out the archives within the same second. Perhaps the generator could be seeded only once or a different seed mechanism could be used?

I tried to compile the openvdb with maya and met the errors. [ As I want to use it in the Maya2016,Maya2014]

E1. openvdb\Exception.h
... \Exceptions.h(46): error C2065: 'default' : undeclared identifier

E2. '(' errror at template
Vec3.h(92): error C2958: the left parenthesis '(' found at .....\openvdb\math\vec3.h(92)'

I searched and found one way to solve the E1 with wrting some precompiled instructions, but was so confused the E2 template . I had these questions.

• Is it possible to compile openvdb4.x.x with vs2012 or vs2010 [some compilers not fully support c++11]?

• Is there any tips to sovle these problems ?