bluebrain / livre Goto Github PK

View Code? Open in Web Editor NEW

31.0 31.0 21.0 8.79 MB

Large-scale Interactive Volume Rendering Engine

Home Page: https://bluebrain.github.io

License: GNU Lesser General Public License v3.0

CMake 2.19% C++ 92.04% GLSL 2.07% Python 1.34% QML 1.20% JavaScript 0.10% Roff 1.06%

livre's People

Contributors

Stargazers

Watchers

Forkers

eile rballester chevtche bilgili jafyvilla rdumusc egparedes l3m vr3d vmml favreau hernando guozanhua sunhanpt jameslinus nagyistge karrokdc malei-pku shugraphics ichild1994

livre's Issues

Caches are overcommitted

See stats:

This leads to a bad_alloc on the 32bit OS app.

Some blocks are not rendered with a volume of size (1140,800,1320)

This is reproducible with both bbic and mem datasources, the volume is cut; only 2 blocks instead 4 seem to be visible at --max-lod=0.

vglrun livre --volume bbic:///gpfs/bbp.cscs.ch/project/proj3/resources/volumes/bbic/allen_average_brain.h5 --max-lod 0
OR
vglrun livre --volume mem:///#1140,800,1320,56 --max-lod 0

The code in VolumeDataSourcePlugin.cpp -> fillRegularVolumeInfo() might be a good starting point for debugging, but the conflicting documentation in livre/core/data/NodeId.h between RootNode and NodeId constructors complicate the task.

The reported depth of 4 looks suspicious since the LOD structure is the following:

BBIC file v1 - 0 stacks, 1 volumes
Volume v2 [1140, 800, 1320], block size: 64, #blocks (18, 13, 21)
detailed structure:
Level 0: #blocks (18, 13, 21), size (1140, 800, 1320)
Level 1: #blocks (9, 7, 11), size (570, 400, 660)
Level 2: #blocks (5, 4, 6), size (285, 200, 330)
Level 3: #blocks (3, 2, 3), size (142, 100, 165)
Level 4: #blocks (2, 1, 2), size (71, 50, 82)

However increasing the depth to 5 in fillRegularVolumeInfo() breaks the behaviour in multiple places. This bugs needs further investigations as I couldn't find an easy fix.

Default samples per ray are too low

Not always possible to change the frame range from the GUI

If Livre is initialized with a specific frame range, e.g. --frames '200 300' and then the user wants to change this from the livreGUI, depending on the change the GUI animation component gets disabled.

For example, the initial frame range is [200, 300), and the user wants to change it to [200, 250). As soon as the first '2' in '250' is typed, the frame range [200, 2) is processed. Since '2' is not a valid frame in the initial frame range (it is outside the valid range of values), the whole animation component in the GUI is disabled, making it impossible to continue typing or changing frame-related parameters.

--animation disables async rendering

Well observable when running with --volume fivox://, interaction is impossible since redraw is linked to voxelization speed.

Implement dynamic near/far planes

Sample code at https://github.com/Eyescale/Equalizer/blob/master/examples/eqPly/channel.cpp#L769

This allows to approach closer to the object in immersive environments.

VRPN tracking does not trigger redraw

Clarify License

The C&P files from Equalizer carry the BSD license, new ones don't have any. Add a License.txt and proper headers. Not sure if we want BSD or LGPL.

SegFault on exit

Ubuntu 16.04 / Eq and Livre master:

gdb ../build/bin/livre
[...]
31430.Draw0     ../Collage/co/connection.cpp:111   10323 co::Connection 0x7fffa448ce40 state closed description NONE#0###0#default#: 0 MB out, 0 MB in
[Thread 0x7fffad162700 (LWP 31445) exited]
[Thread 0x7fff7dffb700 (LWP 31460) exited]
[Thread 0x7fff7e7fc700 (LWP 31459) exited]
31430.Draw0        ../Equalizer/eq/frame.cpp:40    10332 FrameData attached in frame destructor
[Thread 0x7fff7effd700 (LWP 31458) exited]

Thread 18 "Draw0" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff9cd79700 (LWP 31454)]
0x00007fffee8d497d in XQueryExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0  0x00007fffee8d497d in XQueryExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#1  0x00007fffee8c84f2 in XInitExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x00007fffee69bfdf in XextAddDisplay () from /usr/lib/x86_64-linux-gnu/libXext.so.6
#3  0x00007fffc49a7f57 in ?? () from /usr/lib/nvidia-361/libGLX_nvidia.so.0
#4  0x00007fffc49a93ca in ?? () from /usr/lib/nvidia-361/libGLX_nvidia.so.0
#5  0x00007fffc49a9bba in ?? () from /usr/lib/nvidia-361/libGLX_nvidia.so.0
#6  0x00007fffc49aa565 in ?? () from /usr/lib/nvidia-361/libGLX_nvidia.so.0
#7  0x00007fffeae85023 in ?? () from /usr/lib/nvidia-361/libGLX.so.0
#8  0x00007fffeae855c1 in ?? () from /usr/lib/nvidia-361/libGLX.so.0
#9  0x00007ffff657cc3e in eq::glx::Window::doneCurrent (this=0x7fff84001230) at ../Equalizer/eq/glx/window.cpp:802
#10 0x00007ffff7b822ce in livre::EqContext::doneCurrent (this=0x7fff84000ad0) at ../Livre/livre/eq/render/EqContext.cpp:99
#11 0x00007ffff72327da in livre::Workers::Impl::execute (this=0x7fffa41e7fc0) at ../Livre/livre/core/pipeline/Workers.cpp:65
#12 0x00007ffff72340d5 in boost::_mfi::mf0<void, livre::Workers::Impl>::operator() (this=0x7fffa41e8628, p=0x7fffa41e7fc0)
    at /usr/include/boost/bind/mem_fn_template.hpp:49
#13 0x00007ffff7234038 in boost::_bi::list1<boost::_bi::value<livre::Workers::Impl*> >::operator()<boost::_mfi::mf0<void, livre::Workers::Impl>, boost::_bi::list0> (this=0x7fffa41e8638, f=..., a=...) at /usr/include/boost/bind/bind.hpp:253
#14 0x00007ffff7233fd0 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, livre::Workers::Impl>, boost::_bi::list1<boost::_bi::value<livre::Workers::Impl*> > >::operator() (this=0x7fffa41e8628) at /usr/include/boost/bind/bind.hpp:893
#15 0x00007ffff7233f82 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, livre::Workers::Impl>, boost::_bi::list1<boost::_bi::value<livre::Workers::Impl*> > > >::run (this=0x7fffa41e8470) at /usr/include/boost/thread/detail/thread.hpp:116
#16 0x00007ffff470f5d5 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
#17 0x00007ffff33216fa in start_thread (arg=0x7fff9cd79700) at pthread_create.c:333
#18 0x00007ffff3057b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

Blocking during brick generation

I still get frame blocks, up to seamingly a deadlock when running:

bin/livre --volume 'fivoxSynapses://?resolution=1000'

and zooming into the data. It seems the tree traversal becomes to expensive:

Thread 12 (Thread 0x7fffb75fe700 (LWP 682)):
#0  0x00007fffefc5eabf in lunchbox::LFVector<boost::shared_ptr<lunchbox::Any>, 32>::LFVector (this=0x7ffdbb7ca3d8, n=10983, t=...)
    at ../Lunchbox/lunchbox/lfVector.ipp:56
#1  0x00007fffefc5df7d in dash::detail::ContextPtr<lunchbox::Any>::ContextPtr (this=0x7ffdbb7ca3d8) at ../dash/dash/detail/contextPtr.h:44
#2  0x00007fffefca653c in dash::detail::Attribute::Attribute (this=0x7ffdbb7ca3c0, attribute=0x7ffdbb789da0)
    at ../dash/dash/detail/attribute.cpp:39
#3  0x00007fffefc5c79b in dash::Attribute::Attribute (this=0x7ffdbb789da0) at ../dash/dash/attribute.cpp:36
#4  0x00007ffff0ceed57 in livre::DashRenderNode::initializeDashNode (dashNode=...) at ../Livre/livre/core/Dash/DashRenderNode.cpp:101
---Type <return> to continue, or q <return> to quit---
#5  0x00007ffff0cf38ff in livre::detail::DashTree::getDashNode (this=0xf09db0, nodeId=...) at ../Livre/livre/core/Dash/DashTree.cpp:99
#6  0x00007ffff0cf2d9c in livre::DashTree::getDashNode (this=0xbb2590, nodeId=...) at ../Livre/livre/core/Dash/DashTree.cpp:160
#7  0x00007ffff0d2de30 in livre::detail::RenderNodeVisitor::getDashNode (this=0x7fffa6c34940, nodeId=...)
    at ../Livre/livre/core/Visitor/RenderNodeVisitor.cpp:39
#8  0x00007ffff0d2d82a in livre::RenderNodeVisitor::onVisitBegin (this=0x7fffb75fcec0, nodeId=..., state=...)
    at ../Livre/livre/core/Visitor/RenderNodeVisitor.cpp:67
#9  0x00007ffff105082c in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=4, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:50
#10 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=5, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#11 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=6, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#12 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=7, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#13 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=8, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#14 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=9, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#15 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=10, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#16 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=11, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#17 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=12, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#18 0x00007ffff1050a23 in livre::detail::DFSTraversal::traverse (this=0x7fffa6c0f110, nodeId=..., depth=13, visitor=...)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:64
#19 0x00007ffff10504b2 in livre::DFSTraversal::traverse (this=0x7fffb75fcf00, rootNode=..., visitor=..., frame=0)
    at ../Livre/livre/Lib/Visitor/DFSTraversal.cpp:116
#20 0x00007ffff78fc764 in livre::detail::Channel::requestData (this=0x7fffa43b3120) at ../Livre/livre/Eq/Channel.cpp:316
#21 0x00007ffff78fc939 in livre::detail::Channel::frameDraw (this=0x7fffa43b3120) at ../Livre/livre/Eq/Channel.cpp:326
#22 0x00007ffff78f9dc9 in livre::Channel::frameDraw (this=0x7fffa43b21a0, frameId=...) at ../Livre/livre/Eq/Channel.cpp:620
#23 0x00007ffff6fc591e in eq::Channel::_cmdFrameDraw (this=0x7fffa43b21a0, cmd=...) at ../Equalizer/eq/channel.cpp:1658
#24 0x00007ffff08cebea in co::CommandFunc<co::Dispatcher>::operator() (this=0x7fffb75fd5f0, command=...) at ../Collage/co/commandFunc.h:62
#25 0x00007ffff08d8b92 in co::ICommand::operator() (this=0x7fff2637c1a8) at ../Collage/co/iCommand.cpp:214
#26 0x00007ffff70edd0a in co::WorkerThread<eq::CommandQueue>::run (this=0xd47000) at ../Collage/co/worker.ipp:40
#27 0x00007ffff708d509 in eq::detail::RenderThread::run (this=0xd47000) at ../Equalizer/eq/pipe.cpp:235
#28 0x00007fffeef0fcf2 in lunchbox::Thread::_runChild (this=0xd47000) at ../Lunchbox/lunchbox/thread.cpp:132
#29 0x00007fffeef0fa3e in lunchbox::Thread::runChild (arg=0xd47000) at ../Lunchbox/lunchbox/thread.cpp:110
#30 0x000000357a207a51 in start_thread () from /lib64/libpthread.so.0
#31 0x0000003579ae89ad in clone () from /lib64/libc.so.6

I guess this can be optimised, since the visible tree should be not that large?

Screen space block projection computation is wrong

Improve the NodeId to have "unlimited nb of frames" (32 or 64bits)

NodeId currently supports 18bit frame range which is creating difficulties at handling the frame ranges. We should look to extend it to have more frames. The constraint is Identifier should be decodable back ( i.e. NodeId )

Some of the bricks are missing after loading is complete

Some of the bricks are missing after loading is complete. When redraw is triggered the blocks appear.

Possible reason: The redraw is called before the commit is retrieved by the equalizer window. As there is no continious rendering, the rendering is not retriggered.

Possible solution: is to use a while loop blocking on pulling data from texture loader similar to textureuploader and data uploader. I have to investigate this a bit more because of the synchronous rendering.

Some collision detections seems to fail

Some black holes are appearing randomly:

Some lines are appearing randomly:

Livre - RESTBridge - cppnetlib compilation error

Livre compilation breaks in my workstation due to an unresolved dependency problem in the RESTBridge subproject. Apparently the 'cppnetlib' dependency is not being detected nor cloned. I have tried using CMake 2.8.12.2 and CMake 3.3.1 and it breaks in both cases, although in a different way.

Using CMake 2.8.12.2, the CMake configuration step finishes without problems but then the compilation fails because the compiler doesn't find the cppnetlib headers. Findcppnetlib cmake module it is not able to find the headers (since the cppnetlib repository was not checked out but oddly the CMake configuration process goes on):

cmake version 2.8.12.2

//->  CPPNETLIB_PATH =
//->  CPPNETLIB_INCLUDE_DIR = CPPNETLIB_INCLUDE_DIR-NOTFOUND
//->  CPPNETLIB_INCLUDE_DIRS =
//->  CPPNETLIB_LIBRARIES =
//->  CPPNETLIB_FOUND =
-- Configured RESTBridge [4f16cfb] with Boost cppnetlib FlatBuffers zeq
-- Configured Tuvok [aa30403] with BISON FLEX OpenGL OpenMP Qt5Core
Qt5OpenGL ZLIB
-- Configured Livre [f2a4571] with Boost Collage dash Equalizer
FlatBuffers GLEW_MX LibJpegTurbo Lunchbox OpenGL OpenMP PNG Qt5Core
Qt5OpenGL Qt5Widgets RESTBridge Threads Tuvok zeq WITHOUT BBPTestData
VTune ISC
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/egparedes/Development/github/upstream/Livre/build

Using CMake 3.3.1, the cppnetlib repository is not checked out but the CMake step stops and shows
an error since the library headers and binaries cannot be found. When running this CMake version a second time in the same folder, the repository is finally checked out but CMakes is still not able to find the library:

cmake version 3.3.1 - 1st run

//->  CPPNETLIB_PATH =
//->  CPPNETLIB_INCLUDE_DIR = CPPNETLIB_INCLUDE_DIR-NOTFOUND
//->  CPPNETLIB_INCLUDE_DIRS =
//->  CPPNETLIB_LIBRARIES =
//->  CPPNETLIB_FOUND =
CMake Error at
/opt/cmake-3.3.1/share/cmake-3.3/Modules/FindPkgConfig.cmake:340 (message):
  A required package was not found
Call Stack (most recent call first):
  /opt/cmake-3.3.1/share/cmake-3.3/Modules/FindPkgConfig.cmake:502
(_pkg_check_modules_internal)
  CMake/common/CommonPackage.cmake:97 (pkg_check_modules)
  RESTBridge/CMakeLists.txt:31 (common_package)

cmake version 3.3.1 - 2nd run

//->  CPPNETLIB_PATH =
//->  CPPNETLIB_INCLUDE_DIR = CPPNETLIB_INCLUDE_DIR-NOTFOUND
//->  CPPNETLIB_INCLUDE_DIRS =
//->  CPPNETLIB_LIBRARIES =
//->  CPPNETLIB_FOUND =
-- git clone --recursive https://github.com/cpp-netlib/cpp-netlib.git
/home/egparedes/Development/github/upstream/Livre/cppnetlib [d3e884f]
Submodule 'deps/asio' (git://github.com/cpp-netlib/asio) registered for
path 'deps/asio'
Submodule 'deps/gmock' (git://github.com/cpp-netlib/gmock) registered
for path 'deps/gmock'
Submodule 'deps/gtest' (git://github.com/cpp-netlib/gtest) registered
for path 'deps/gtest'
Submodule 'deps/igloo' (git://github.com/joakimkarlsson/igloo.git)
registered for path 'deps/igloo'
Submodule 'uri' (git://github.com/cpp-netlib/uri) registered for path 'uri'
Submodule path 'deps/asio': checked out
'e80030ffa178dbcca11d84ab607a87495a711a17'
Submodule path 'deps/gmock': checked out
'6b1759c3816d574bddde3e1725c51a811c8870e7'
Submodule path 'deps/gtest': checked out
'a6772271f71672e889776bfe49ec4efd9da036df'
Submodule path 'deps/igloo': checked out
'7d5ad81e705e61453adc16990dab8c825b41e20b'
Submodule path 'uri': checked out
'9567e16a5936bf0ebcea8b33d56863251dc94e9b'
-- Found ICU header files in /usr/include/x86_64-linux-gnu
-- Found ICU libraries: /usr/lib/x86_64-linux-gnu/libicuuc.so
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   system
--   regex
--   filesystem
-- Found OpenSSL:
/usr/lib/x86_64-linux-gnu/libssl.so;/usr/lib/x86_64-linux-gnu/libcrypto.so
(found version "1.0.1f")
-- Found Threads: TRUE
-- Performing Test HAVE_STD11
-- Performing Test HAVE_STD11 - Success
-- C++ Compiler ID: GNU
-- C++ Flags:  -std=c++11 -std=c++11 link flags:
-- CPP-NETLIB options selected:
--   CPP-NETLIB_BUILD_SHARED_LIBS:      ON    (Build cpp-netlib as
shared libraries: OFF, ON)
--   CPP-NETLIB_BUILD_SINGLE_LIB:       OFF    (Build cpp-netlib into a
single library: OFF, ON)
--   CPP-NETLIB_BUILD_TESTS:            ON    (Build the unit tests: ON,
OFF)
--   CPP-NETLIB_BUILD_EXAMPLES:         OFF    (Build the examples using
cpp-netlib: ON, OFF)
--   CPP-NETLIB_ALWAYS_LOGGING:         OFF    (Allow cpp-netlib to log
debug messages even in non-debug mode: ON, OFF)
--   CPP-NETLIB_DISABLE_LOGGING:        OFF    (Disable logging
definitely, no logging code will be generated or compiled: ON, OFF)
--   CPP-NETLIB_DISABLE_LIBCXX:         OFF    (Disable using libc++
when building with clang: ON, OFF)
--   CPP-NETLIB_DISABLE_FEATURE_TESTS:  OFF    (Disable the feature
tests (which may use a network connection): ON, OFF)
-- CMake build options selected:
-- Found PythonInterp: /usr/bin/python (found suitable version "2.7.6",
minimum required is "2")
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.6")
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   system
--   filesystem
C++ Flags:  -std=c++11 -std=c++11 -std=c++11 link flags:
-- Found GTest: gtest
CMake Error at
/opt/cmake-3.3.1/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148
(message):
  Could NOT find cppnetlib (missing: CPPNETLIB_LIBRARIES
  CPPNETLIB_INCLUDE_DIR)
Call Stack (most recent call first):
/opt/cmake-3.3.1/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388
(_FPHSA_FAILURE_MESSAGE)
  CMake/common/Findcppnetlib.cmake:88 (find_package_handle_standard_args)
  CMake/common/SubProject.cmake:158 (find_package)
  CMake/common/SubProject.cmake:194 (add_subproject)
  RESTBridge/.gitsubprojects:4 (git_subproject)
  CMake/common/SubProject.cmake:211 (include)
  CMake/common/Common.cmake:120 (include)
  RESTBridge/CMakeLists.txt:27 (include)

Frustum culling too aggressive for heavy off-axis frusta

In a CAVE setting, when the user looks 'from the side' on a segment, the frustum culling is to aggressive:

Missing bricks in first frame after load_equalizer change

Some bricks are missing for one frame when the load_eq changes the tiling, even though they should be on GPU memory.

Remote node upload events do not trigger redraw

Running livre with appNode + multiple nodes, the data threads from the remote nodes do not trigger a redraw, causing the appNode rendering to be complete, but not the wall rendering.

Voxels not rendered

While debugging the 'events per voxel' functor, I create volumes which have 157 in a few voxels and none in the rest. In Livre, I cannot see the voxels. I used the Gauss transfer function which should show values in the middle of the spectrum, moving the maxima around. All I can get is a homogenous blob. Also used --samples-per-ray=4096 just in case the volume was undersampled.

Clarify cache parameters

Documentation says today:
{code}
--data-cache-mem arg (=1024) Maximum data cache memory (MB) - caches
the raw data read from I/O in system
memory
--texture-cache-mem arg (=3072) Maximum texture cache memory (MB) -
caches the texture data on GPU memory
--texturedata-cache-mem arg (=8192) Maximum texture data cache memory (MB) -
caches the data that has been converted
into internal texture format in system
memory
{code}

--texture-cache-mem sounds ok (GPU cache). If I understand correctly, --texturedata-cache-mem is the CPU cache. But what is --data-cache-mem then, and why is it needed? And I guess the rendered set is just selected from the texture cache based on view point and SSE?

All options can drop '-mem', imo

Rendering has artifacts ( is broken ) when the camera is inside the volume

Rendering has artifacts ( is broken ) when the camera is inside the volume.

Possible problem: The rasterization of the surface of LOD bricks is happening with RenderBrick class. Here when near plane cuts the brick, there may be some rasterization issues. This has to be investigated.

The cache sizes does not match between memory and GPU

As shown in #228 the cache sizes does not match between cpu and gpu memory.

Sort-last support

Generic feature issue to track support of the sort-last implementation in Livre.

sort-last partitioning based on the visible rendering set: #201(2ec720f)
sort-last partitioning based on the tree layout: #201 (d0fff9b)
compositing
sub-decomposition of non-convex rendering subsets
- not needed if using tree-based compositing along one axis only.
Spatial sorting of the rendering set

Add old renderer as part of OSX compatibility

OSX supports max OpenGL 4.1.

FYI @eile

Race condition during dash init

The race observed earlier this week is still there, although less likely:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc9ffb700 (LWP 21399)]
0x00007fffef937001 in dash::Context::map (this=0x7cfe90, node=..., to=...)
    at /home/egparedes/Development/forks/Livre/dash/dash/context.cpp:117
117         impl_->map( node, *to.impl_ );
(gdb) bt
#0  0x00007fffef937001 in dash::Context::map (this=0x7cfe90, node=..., to=...)
    at /home/egparedes/Development/forks/Livre/dash/dash/context.cpp:117
#1  0x00007ffff0de9f14 in livre::detail::DashTree::createContext (this=0x7cfbc0)
    at /home/egparedes/Development/forks/Livre/livre/core/Dash/DashTree.cpp:64
#2  0x00007ffff0de976c in livre::DashTree::createContext (this=0x702730)
    at /home/egparedes/Development/forks/Livre/livre/core/Dash/DashTree.cpp:138
#3  0x00007ffff7b9631c in livre::DataUploadProcessor::DataUploadProcessor (this=0x7fff9434a600, 
    dashTree=..., shareContext=..., context=..., rawDataCache=..., textureDataCache=...)
    at /home/egparedes/Development/forks/Livre/livre/Lib/Uploaders/DataUploadProcessor.cpp:163
#4  0x00007ffff789126c in livre::Window::Impl::initializePipelineProcessors (this=0x7fff94385de0)
    at /home/egparedes/Development/forks/Livre/livre/Eq/Window.cpp:146
#5  0x00007ffff7890bf6 in livre::Window::Impl::configInit (this=0x7fff94385de0)
    at /home/egparedes/Development/forks/Livre/livre/Eq/Window.cpp:75
#6  0x00007ffff789042d in livre::Window::configInit (this=0x7fff943854c0, initId=...)
    at /home/egparedes/Development/forks/Livre/livre/Eq/Window.cpp:226
#7  0x00007ffff707cb25 in eq::Window::_cmdConfigInit (this=0x7fff943854c0, cmd=...)
    at /home/egparedes/Development/forks/Livre/Equalizer/eq/window.cpp:878
#8  0x00007ffff0677620 in co::CommandFunc<co::Dispatcher>::operator() (this=0x7fffc9ffabc0, 
    command=...) at /home/egparedes/Development/forks/Livre/Collage/co/commandFunc.h:62
#9  0x00007ffff068159c in co::ICommand::operator() (this=0x7fff94386370)
    at /home/egparedes/Development/forks/Livre/Collage/co/iCommand.cpp:214
#10 0x00007ffff7087277 in co::WorkerThread<eq::CommandQueue>::run (this=0x7d9fa0)
    at /home/egparedes/Development/forks/Livre/Collage/co/worker.ipp:40
#11 0x00007ffff702837a in eq::detail::RenderThread::run (this=0x7d9fa0)
    at /home/egparedes/Development/forks/Livre/Equalizer/eq/pipe.cpp:233
#12 0x00007fffef57abdd in lunchbox::Thread::_runChild (this=0x7d9fa0)
    at /home/egparedes/Development/forks/Livre/Lunchbox/lunchbox/thread.cpp:133
#13 0x00007fffef57a95c in lunchbox::Thread::runChild (arg=0x7d9fa0)
    at /home/egparedes/Development/forks/Livre/Lunchbox/lunchbox/thread.cpp:110
#14 0x00007fffef320182 in start_thread (arg=0x7fffc9ffb700) at pthread_create.c:312
#15 0x00007fffeb8bd47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

LOD/Frustum culling issue

livre --volume ~/Library/Models/3M_neuron_256_b.uvf --camera-position '0 0 -1.05'
Shows the volume, whereas
livre --volume ~/Library/Models/3M_neuron_256_b.uvf --camera-position '0 0 -1.1'
does not.

Will email .uvf, since I can't attach here.

With low number of samples, block's boundaries are visible

Fix #210 was a quick workaround for these problem. The sampling should start at boundaries of the volume.

generateRenderingSet() is done twice in Channel::frameDraw

see comments from #223 (diff)

SSE too conservative

To reproduce: vglrun ../release/bin/livre --volume fivox:// --frames '2 4' --sse 1
Then full-screen window.

Resolution is about 1k, which means that the total volume size should be around 1GB (cubic volume, ~1k px high in the front-most bricks, less in the "deeper" bricks)

It is more than 8 GB (see attached screenshot w/ stats):

As a user, I want a better experience with camera manipulation [LIV-220]

To provide a better user experience, in particular from a touch interface such as the DisplayWall, it is important that the camera always shows some interesting part of the data and that there is always an easy way to go back to a know position.

DOD:

The axes of rotation are constrained, to allow only rotations around the x and y axis
The zoom doesn't "jump" excessively, also when rendering is slow
The zoom is constrained within a reasonable range, defined as follow:
--- the volume cannot be smaller than ~50% of the window area
--- it is not possible to zoom through the volume and see the background

Additionally:

Test a mode of interaction which allows to both move and rotate the camera. For instance, when zoomed in, I can move the camera vertically along the main axis of the column of neurons, and rotate the view around that axis.

livre --volume fivox:// does not resample bricks when moving camera

OSX and GL2.1 and 64bit

Because of the integer texture sampler restrictions we can not use the same code path, we are using with the current GL4 renderer. The sampling of integer textures are supported from 1.30 and on.

For GL2.1 to work textures should be in normalized form and, this means substantial amount of code change in TexturePool, Renderer and the fragment shader.

The ray AABB intersection must take the near plane into account

Add a new renderer/technique that can render multiple blocks in a single pass is needed

Current renderer as stated in #228 is slow if there is transparency and large number of blocks.

A new renderer/technique is needed for rendering multiple blocks at a single pass.
Has to look at empty space skipping with current implementation. If it is easy, it can improve rendering speed and memory.

@chevtche is already working on an OpenGL 4 based renderer possibly based on "http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6231628&tag=1"

Higher LODs are not loaded while zooming in

Launch livre with

livre --volume uvf://$HOME/rat.uvf --sse 1 --camera-position "0 0 3"

Wait until 100% is loaded (watch statistics), then get closer with camera and keep watching "Loaded" percentage in statistics. It drops down to 0%, so only the fully loaded low-quality detail level is used for rendering.

I can also provide a smaller UVF volume if necessary, just let me know.

Unknown data source urls should not crash application

Rendering artefacts with screen-aligned bricks

See #113 for gaps between bricks.

TF: opaque elements are overexposed

To reproduce: Open GUI, move right-most point gradually towards opaque. When point reaches fully opaque, the rendering "jumps" from attached image 1 -> 2 (the purple splotches).

Command line used: vglrun livre --volume fivox:///gpfs/bbp.cscs.ch/apps/viz/bbp/dev/BBPTestData/master/share/BBPTestData/local/simulations/may17_2011/Control/BlueConfig?target=Column,report=voltage --time 6.68 --sse 1 --camera-position 0 0 .4

frame to timestep naming

We had renamed the FrameId variable in NodeIds to TimeStep because it was confusing people. It has been changed many places in Livre. The FrameRange concept may need to be revisited for this reason.

FYI @hernando

Statistics are showing wrong resolution(um/voxel)

In channel.cpp (at line 392) the calculation:
"Vector3f voxelSize = info.boundingBox.getSize() / info.voxels"
is wrong.

info.boundingBox.getSize() is the bounding box of the circuit but in Livre we are adding a cutoff
distance to this bounding box. So the number of voxels is too big.

Changes in RenderSettings are not reflected in renderer

When changing the transfer function, number of samples per pixel or ray from the livreGUI, the changes are not shown in the renderer. The new values are received via ZeroEQ, but from debugging it seems the a call to RayCastRenderer::update() is missing to use the new values.

Performance for 1K UVF @ 2K with SSE 1 too low

Ask me for UVF, it's a 1K cubed volume of the epileptic slice, but any other sized UVF volume should do as well

EQ_WINDOW_IATTR_HINT_HEIGHT=1080 EQ_WINDOW_IATTR_HINT_WIDTH=1920 bin/livre --volume uvf://$HOME/volume.uvf --sse 1 --camera-position "-1 0 0"

I get ~2fps on my GTX 480. Reducing the samples-per-ray to 64 gives me 6fps, but it still feels too slow, plus the quality gets bad quickly.

livre exits after ~73 minutes @60 fps

When rendering animations for instance. --num-frames by default is now 262143.

Update/Review the UVF data source to use the latest Tuvok library and data examples in original repo

To add tests for UVF data source I have tried to use uvf files from the original website but they did not work. Data source has to be reviewed and/or updated. New Tuvok library: https://github.com/bilgili/TuvokOrg

Frame range defined by --frames is not open at the end

Unlike the documentation of --frames, livre_batch.py and previous versions (like 102cbf2), --frames "0 1" generates two images on disk.

EQ_CHANNEL_SATTR_DUMP_IMAGE=/tmp/foo ./livre --frames "0 1" --animation

gives foo00000.png and foo00001.png in /tmp.

Draw artifacts when the camera is inside a volume

--num-frames 1 deadlocks

since af3bbe8

--num-frames 0|1|2

--num-frames 1 --synchronous

livre deadlocks in exit.