academysoftwarefoundation / openvdb Goto Github PK
View Code? Open in Web Editor NEWOpenVDB - Sparse volume data structure and tools
Home Page: http://www.openvdb.org/
License: Mozilla Public License 2.0
OpenVDB - Sparse volume data structure and tools
Home Page: http://www.openvdb.org/
License: Mozilla Public License 2.0
Should I ask a question here meanwhile?
Whoops, just did. [/clever]
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'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?
/// 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); }
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
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
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?
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
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?
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()
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
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
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
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.
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
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.
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?
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.
/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
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)
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
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 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....
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.
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?
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.
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).
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
Math.h I mean inclusive/exclusive in terms of tolerance bounds. Is this intended?
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.
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?
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?
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
Also something I can do.
where is this script ?
(Source the houdini_setup script to set those two environment variables.)
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
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. :)
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
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?
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
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.
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 ?
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.
What is "if closely related" supposed to be?
I don't have a CLA but here is a tip for fixing the unittest for Windows builds...
small is defined in 'rpcndr.h' as...
#define small char
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 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.
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.