- 23 Oct, 2014 2 commits
-
-
Christian Schulte zu Berge authored
refs #386
-
Christian Schulte zu Berge authored
refs #386
-
- 17 Oct, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* Tied tgt::OpenGLJobProcessor and tgt::OpenGLGarbageCollector closer together regarding OpenGL garbage collection * AutoEvaluationPipeline checks for valid OpenGL state after each processor call (only in debug)
-
- 15 Oct, 2014 2 commits
-
-
Christian Schulte zu Berge authored
Moved AbstractJob and OpenGLJobProcessor from campvis-core to tgt and adapted and cleaned up all necessary includes/references.
-
Christian Schulte zu Berge authored
The new OpenGL wrapping API allows for full multi-threaded access to OpenGL contexts. Instead of one single thread scheduling all OpenGL jobs for all contexts, the new GlContextManager allows for OpenGL access from multiple threads while ensuring that each OpenGL context is acquired by only one thread at a time. Detailed list of changes: * tgt::GlContextManager keeping track of which threads acquire which OpenGL contexts and which threads currently have a context acquired. * OpenGLJobProcessor does no longer schedules and execute the OpenGL calls for all existing contexts, but only for one single context that can be used for background tasks or other jobs that explicitly need a valid OpenGL context. * AbstractPipeline now implements the Runnable interface and thus runs in it's own thread. This thread also owns the pipeline's OpenGL context. * AbstractPipeline has a new pure virtual method executePipeline() that has to perform all computations done by the pipeline. * AbstractPipeline now takes directly care of calling Painter::paint() of the pipeline's canvas (instead of signalling the Painter). However, the Painter interface needs further cleanup. * AutoEvaluationPipeline was adapted to the new AbstractPipeline API, hence executing processors is no longer delegated to the OpenGLJobProcessor or the SimpleJobProcessor but entirely done in AutoEvaluationPipeline::executePipeline() and thus in the pipeline's thread. * Adjusted CampVisApplication, DataContainerInspectorWidget, and GeometryTransferFunctionEditor to the new API.
-
- 08 Oct, 2014 1 commit
-
-
Christian Schulte zu Berge authored
Added directories of various needed resources (textures, sampledata) to the CampvisShaderDirectories CMake variable, which is used for deployment. Replaced various occurences of CAMPVIS_SOURCE_DIR with ShdrMgr.completePath().
-
- 30 Sep, 2014 2 commits
-
-
Jakob Weiss authored
-
Jakob Weiss authored
* new QtJobProcessor singleton: used to execute jobs in the Qt thread * CampvisApplication now has a map to obtain the window for a pipeline
-
- 07 Aug, 2014 1 commit
-
-
Christian Schulte zu Berge authored
According to Visual Leak Detector, CAMPVis is now memory leak free. :)
-
- 03 Aug, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* Slight changes to the API: renamed signal::trigger() to signal::triggerSignal() and signal::queue() to signal::queueSignal() * Replaced all sigslot signal emits through operator() with emits through emitSignal() to enable debug feature. * Fixed a possible race condition when deleting a GeometryTransferFunction and its editor window at the same time (as this will happen from different threads). refs #384
-
- 27 Jul, 2014 2 commits
-
-
Christian Schulte zu Berge authored
* Moved campvis::Runnable interface to tgt namespace (since it's needed by sigslot, which only depends on tgt) * Introduced sigslot::signal_manager singleton class that will manage the dispatching of signals in its own thread * Started proof-of-concept implementation of asynchroneous signals for signal0<> and signal1<>. Both classes define their own signal_handleN deriving from _signal_handle_base, which defines the signal to dispatch. Proof-of-concept implementation seems to work so far. refs #384 Conflicts: core/tools/opengljobprocessor.h ext/tgt/runnable.h Conflicts: application/CMakeLists.txt core/tools/opengljobprocessor.h
-
Christian Schulte zu Berge authored
If you need one of these two C++11 headers, include <ext/threading.h> instead, which will use C++11 headers if present or TBB's compatibility layer otherwise. closes #567
-
- 10 Jul, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* Introduced two new tgt::LogManager log levels LuaInfo and LuaError. * ScriptingWidget registers itself as logger and prints the Lua output into the console window.
-
- 02 Jun, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* Implemented one single gloabel Lua VM for the entire CampVisApplication instead of one VM for each pipeline. * The global Lua VM has a "pipelines" table/array, holding the pointers to each loaded pipeline * ScriptingWidget support cycling through last executed commands via the arrow keys * LuaVmState supports redirecting Lua's print() function to a custom one that uses tgt::Logmanager for printing (just as proof-of-concept). This shall later be extended to pass all Lua output to the scripting console.
-
- 31 May, 2014 1 commit
-
-
Christian Schulte zu Berge authored
With scripting enabled, the main window now has an additional scripting widget that allows to interact with a Lua VM. The current proof-of-concept implementation creates a Lua VM for every instantiated CAMPVis pipeline while the console just interacts with the first pipeline's one. However, the Lua VM concept has to be reiterated later anyway. It may make more sense to have just a single central Lua VM for the entire application, which is shared by each pipeline.
-
- 10 May, 2014 2 commits
-
-
Artur Grunau authored
As there's currently only one Lua pipeline, we could so far get away with storing it in the `scripting` directory, giving it a generic name and registering it manually. However, this approach won't work anymore once additional Lua pipelines start to be implemented. To support multiple Lua pipelines, implement a registration mechanism for scripted pipelines based on PipelineFactory and similar to PipelineRegistrar. It scans each active module's `pipelines` directory for Lua pipelines, parses them and generates a registration header that, when included, registers them with PipelineFactory. As a result of the above, the test Lua pipeline had to be moved to `modules/preprocessing/pipelines/` and could be renamed ResamplingDemoLua. References #1
-
Artur Grunau authored
This commit marks the start of work on making Lua pipelines as easy to register and instantiate as regular ones. A sample Lua pipeline has been made available to the application so that problems with integrating Lua pipelines can be discovered and fixed. References #1
-
- 05 May, 2014 2 commits
-
-
Christian Schulte zu Berge authored
Introducing nifty error texture in case that there is nothing to render. Updated copyimage.frag to use texture coordinates instead of viewport pixels.
-
Christian Schulte zu Berge authored
-
- 24 Apr, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 13 Feb, 2014 1 commit
-
-
Christian Schulte zu Berge authored
Beautifying VolumeExplorerDemo and VolumeRendererDemo sample rederings by fine tuning transfer functions.
-
- 07 Feb, 2014 1 commit
-
-
Christian Schulte zu Berge authored
Removed oblivious tgt::QtContextManager and merged functionality into tgt::GLCanvas and tgt::GlContextManager. Meanwhile, improved OpenGL context initialization and pipeline creation in CampvisApplication.
-
- 06 Feb, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 15 Jan, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 13 Jan, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 02 Jan, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 13 Dec, 2013 1 commit
-
-
Christian Schulte zu Berge authored
* Moving to Apache 2.0 license * Updated AUTHORS.txt
-
- 15 Oct, 2013 2 commits
-
-
Sebastian Pölsterl authored
-
Christian Schulte zu Berge authored
-
- 11 Oct, 2013 1 commit
-
-
Christian Schulte zu Berge authored
Work on Issue #44: Removed GLContext interface and merged functionality into GlCanvas. Introducing abstract (Qt-free) tgt::GlContextManager interface, being implemented by tgt::QtContextManager. Further clean up of related code.
-
- 09 Oct, 2013 1 commit
-
-
Christian Schulte zu Berge authored
-
- 08 Oct, 2013 6 commits
-
-
Christian Schulte zu Berge authored
-
Christian Schulte zu Berge authored
CampvisApplication manages multiple DataContainers, updated PipelineTreeWidget to show correct DataContainer/Pipeline/Processor hierarchy
-
Christian Schulte zu Berge authored
Refactoring pipeline concept #5: Moved Pipeline registration to modules module and gen_pipelineregistration.h which will soon be generated by CMake.
-
Christian Schulte zu Berge authored
Refactoring pipeline concept #4: (Almost) got rid of hard pipeline definition in campvis.cpp. Implemented console argument parsing in CampvisApplication dynamically adding the pipelines listed as arguments
-
Christian Schulte zu Berge authored
-
Christian Schulte zu Berge authored
-
- 27 Sep, 2013 1 commit
-
-
Christian Schulte zu Berge authored
-
- 10 Sep, 2013 1 commit
-
-
Christian Schulte zu Berge authored
-
- 04 Sep, 2013 1 commit
-
-
Christian Schulte zu Berge authored
-