florianrhiem/vfrendering

A vector field rendering library

vfrendering's Issues

Suggestion: choice of entity for vector visualisation

Two suggestions:

• simple 2D dots
• 3D spheres

There are two cases I can think of where a choice besides / in addition to arrows may be useful:

• If the data set is large, it may make sense to just draw dots instead
• There may be differences in the data points besides the vector orientation and magnitude (in my case there may be different atom types). It would be nice to be able to draw corresponding coloured spheres in addition to the arrows

Demo does not compile

It seems the demo does not compile:

/usr/bin/ld: libVFRendering.a(glad.c.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/lib/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/VFRenderingDemo.dir/build.make:99: VFRenderingDemo] Error 1
make[1]: *** [CMakeFiles/Makefile2:143: CMakeFiles/VFRenderingDemo.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

I believe this is because the -ldl is missing in the linking. If I append this manually to the linkline:

/usr/bin/c++ CMakeFiles/VFRenderingDemo.dir/demo.cxx.o -o VFRenderingDemo libVFRendering.a /usr/lib/libglfw.so.3.2 qhull-prefix/src/qhull-build/libqhullcpp.a qhull-prefix/src/qhull-build/libqhullstatic_r.a -ldl

it works.

Suggestion: renderer-specific colormaps

Visualising a surface together with arrows could be visually clearer if e.g. the surface has a colormap but the arrows are grey, as with identical colormaps the triangles of surface and arrows "melt together".

A new option in the RendererBase could maybe work as follows:

• when the CM of a renderer is "default" (or similar), the View's CM is used
• otherwise the CM in the renderer will override the View's setting

Suggestion: build_demo_qt/glfw switches

Two switches which could be passed to the project would make sense in order to (optionally) reduce dependencies.

Rendering to buffer of different size to screen

In order to produce high-quality publication-ready images, it would be a very useful feature to not be limited to the current screen's resolution.
Unfortunately, I do not know what this would entail and what kind of data structure a corresponding function should return. But I assume VFRendering would be the right place to implement this, not in the host code using this library?

Alpha-value parameter for transparent renderers

Would this be reasonably easy to implement via the shaders, simply giving all a renderer's triangles an alpha value?

It would be useful for all renderers, but especially transparent isosurfaces would be a very cool feature, see for example this: