Below is a descriptive introduction to Visualization Library key features and functionalities. Take a couple of minutes to read this page as you will find a lot of useful information about how VL works, how to take full advantage of VL's power and how VL compares to plain OpenGL or other libraries.
The first and most important feature of Visualization Library is surely its simple and straightforward design. Every aspect of Visualization Library has been developed keeping in mind these important principles:
VL is a low-level, fast, fine-grained C++ middleware on top of OpenGL.
Visualization Library is simple to integrate into your framework, you do not need to adapt your own framework to Visualization Library. Moreover, Visualization Library has been designed to seamlessly work side by side with other rendering frameworks, thus allowing a gradual and risk-free transition to Visualization Library.
Accurate OpenGL mapping:
Visualization Library exposes OpenGL functionalities in a manner that reproduces as closely as possible the original OpenGL semantics and adopts as closely as possible the OpenGL wording and conventions.
Visualization Library development has been heavily inspired by the idea of simplification promoted by OpenGL 3.x/4.x and OpenGL ES 2.0. For this reasons many legacy OpenGL features like edge flags, accumulation buffers, feedback mode, the inefficient immediate mode commands etc. are not used by Visualization Library. While retaining full compatibility with OpenGL 1.1 class hardware, this ensures that Visualization Library size is kept to a minimum and that only the most efficient rendering paths are used.
Full support to modern GPUs:
Visualization Library architecture has been designed from the ground up to take full advantage of the most modern OpenGL 4.x features like OpenGL Shading Language, Vertex and Pixel Buffer Objects, Framebuffer Objects, Occlusion Culling, Multiple Render Targets, Geometry Shaders, Tessellation Shaders, Geometry Instancing, true double precision GPU computation and so on, thus providing all the necessary tools to create extraordinary 3D graphics applications.
Probably the single most important factor that made OpenGL the de-facto standard in the 3D graphics industry has been its ability to evolve and to provide always new features with a consistent API, while at the same time maintaining backwards compatibility. Learning from this lesson, mantaining compatibility even with OpenGL 1.1 class hardware is considered a top priority for Visualization Library.
Many rendering engines implement their functionalities as a "black box". This approach usually tends to simplify the life of the casual user as many details are hidden inside the "black box". Instead with Visualization Library the user has transparent access to all the switches and buttons provided by OpenGL from a friendly C++ object oriented framework. This kind of approach might be a bit intimidating at the beginning but the extra effort will be well invested, as you will soon be able to create your own rendering pipeline, your own shading model, your own post processing effects or something that no one has even conceived yet!
Uber-scene-graphs? OpenInventor/Peformer clones? no thanks!
While many rendering engines still advertise proudly their "scene-graph oriented architecture", more and more developers are starting to realize that a uber-scene-graph architecture is far from being an optimal data structure for modern 3D engines. Visualization Library, with its radical design, is a remarkable example of this trend and promotes the notion of data structure separation and specialization. Put in simple words, while a uber-scene-graph 3D engine uses a single, overloaded data structure (usually a DAG) to represent transforms, spatial/visibility relationships, material properties etc, Visualization Library separates these concepts, utilizing for each of them an optimal domain-specific data structure (possibly referencing each other). This intuitive approach not only provides superior performances but allows you to customize and extend each aspect independently from all the others.
Debug friendly behaviour:
Developing modern 3D graphics applications requires every day more and more human resources in terms of programmers and skills. It is a fact that a considerable part of such resources is spent for bug fixing and feature stabilization. This is especially true for 3D graphics applications where cutting-edge technology and highly customized tools are often developed in-house. In order to facilitate the developer's job, Visualization Library has been designed to perform a number of checks that help the developer to identify possible bugs as early as possible and to issue sensible and detailed error messages.
In order to privide the maximum degree of code robustness and reliability Visualization Library comes with a set of regression tests which perform hundreds of tests. Such tests are run consistently throughout the development and especially before every release. Furthermore, the regression test framework has been developed to run under all the platforms and GUI backends supported by Visualization Library.
Even if Visualization Library can be used wherever there is an OpenGL context, several utility classes are available to facilitate even more the integration of VL into your applications. VL officially supports all the most popular C/C++ GUI frameworks such as Win32, MFC, Qt4, wxWidgets, GLUT, SDL and Cocoa (experimental). A "GUI binding" mainly consists of a window class that, using the framework-specific API, is capable of creating and setting up a vl::OpenGLContext, manages unicode keyboard input, mouse events, file drag and drop, OpenGL resource sharing, framebuffer swap, multiple OpenGL windows and many other things. Thanks to the many ready-to-use GUI bindings available, the developer can start using Visualization Library in just a few minutes and has only to concentrate on creating great 3D graphics applications!
There is no doubt that the OpenGL Shading Language is the present and the future of OpenGL. For this reason Visualization Library architecture has been carefully designed from the ground up to exploit the full power of the OpenGL Shading Language and to make it accessible to everyone. VL makes the OpenGL Shading Language so simple to use that setting up a complete GLSL program requires just a couple of lines of code! Advanced features such as geometry instancing, texture arrays, geometry shaders, tessellation shaders, multiple render targets etc. are fully supported as well.
Visualization Library also provides a set of simple and powerful classes to perform volume rendering, isosurface extraction and 3D plots from volume data.
The mission of Visualization Library is not only to provide cutting edge technology for 3D graphics application but also to open the world of hardware accelerated 2D graphics for applications like plotting, charting, data mining and many others. The lack of support for hardware accelerated 2D graphics is almost embarrassing and even when such support is claimed, very few times the performances come close to the full potential of modern GPUs.
Using such classes the developer has full access to standard functionalities like boxes, lines, ellipses, tansforms, clipping etc. but also to advanced features like texturing, point sprites, stencil operations, antialiasing, high quality text rendering and all the blending modes supported by OpenGL!
In order to maximize the rendering performances Visualization Library employs several techniques:
vl::Actor, vl::Effect, vl::LODEvaluator, vl::DistanceLODEvaluator, vl::Actor::setLODEvaluator(), vl::Effect::setLODEvaluator(), vl::Renderable::setDisplayListEnabled(), vl::Geometry::setVertexBufferObjectsEnabled()
Visualization Library uses a simple and extensible scene management system and provides several ready-to-use scene managers:
Scene managers using other techniques like PVS (potentially visible set) etc. can be also used implementing an appropriate vl::SceneManager subclass.
Note that Visualization Library allows you to seamlessly use multiple scene managers at the same time!
Visualization Library automatically sorts transparent objects in order to perform a correct rendering. The user is not required to setup any special "transparent bin" or other trickery to define any explicit rendering order as Visualization Library automatically detects and manages transparent objects. However, the developer retains full control over the object rendering order via the vl::Actor::setRenderRank(), vl::Actor::setRenderBlock() and vl::Effect::setRenderRank() methods. The developer can also install a custom vl::RenderQueueSorter using the vl::Rendering::setRenderQueueSorter() method.
In case you need to render a convex transparent object then you have to ensure that its polygons are properly depth-sorted. You can do this by simply installing a vl::DepthSortCallback to your vl::Actor.
Visualization Library can naturally manage complex scenarios where Effects and/or Actors define several LODs with possibly multiple rendering passes each and with animations defined for each pass and LOD. Visualization Library not only manages naturally such scenarios but also ensures that the animations are computed only once per frame, for only the visible LODs, for each pass, for both Shaders and Actors!
Visualization Library features a complete vector and matrix math library designed to replicate as closely as possible in C++ the OpenGL Shading Language types and functons. VL's math library provides the developer with 2, 3, and 4 components vector (
int etc.), 2x2, 3x3, 4x4
double matrices, vector/vector, vector/matrix and matrix/matrix operations, a quaternion class to conveniently represent and manipulate rotations and orientations and much more. The glsl_math.hpp module also provides C++ implementations of the most important OpenGL Shading Language scalar and vector functions.
Modern OpenGL applications make heavy use of framebuffer objects (
EXT_framebuffer_object extension) to implement efficient render to texture, offscreen rendering and post processing effects. Visualization Library has been designed to take full advantage of framebuffer objects where available and makes rendering to a framebuffer objects as easy as using the standard OpenGL framebuffer. Besides providing the standard framebuffer object functionalities, Visualization Library goes the extra mile, delivering first-class support for framebuffer objects also in conjuction with many other extensions like
ARB_texture_cube_map, 3D textures and so on.
vl::FramebufferObject, vl::FBOAttachmentAbstract, vl::FBORenderbufferAttachment, vl::FBOColorBufferAttachment, vl::FBODepthBufferAttachment, vl::FBODepthStencilBufferAttachment, vl::FBOStencilBufferAttachment, vl::FBOTexture1DAttachment, vl::FBOTexture2DAttachment, vl::FBOTexture3DAttachment, vl::FBOTextureAttachment, vl::FBOTextureLayerAttachment, vl::BlitFramebuffer
The extension mechanism provided by OpenGL has proved to be one of the key factors for the success and longevity of this elegant API. However, exploiting effectively all the possible hardware configurations and all the available extensions can easily become an overwhelming task. For this reason Visualization Library tackles this task for you, querying the available extensions in an automatic manner and selecting and using the most appropriate ones to deliver maximum performance and stability. We refer to this intelligent selection mechanism as "Progressive OpenGL Extension Management". The principle is very simple, wherever an OpenGL feature is requested not only Visualization Library looks for an extension to support it but looks for the best implementation of that functionality, checking first among the functions which are directly supported by the current OpenGL implementation, then looking among the ARB extensions, then looking among the EXT extensions, then among the vendor specific extensions if necessary.
VL provides its own serialization framework called VLX. VLX is actually more than a serialization framework. VLX comes in two forms: VLT (text) and VLB (binary). A VLT file is something like XML or JSON but much less verbose and more efficient in terms of parsing and data extraction. A VLT file can typically contain GLSL shader code as is (impossible with XML and JSON), when loaded can automatically resolve object references, even cyclical ones, can recognize automatically large block of numerical data and present them as an std::vector<> of double or long 'long. VLT files can also be linked together and refer to objects defined in other VLT or VLB files. A VLB file is simply a compact binary encoding of a VLT file. VLT have been designed to store data efficiently yet to be easily editable by humans, while a VLB has been designed to retain all the information contained in a VLT file but storing them for quick input/output.
VLT and VLB files can currently contain geometries, actors, transform, materials, lights, textures, cameras and all the most common VL classes. More will be added in the future and more can be added by the user either by subclassing existing ones or creating new serialized classes from scratch.
The VLX framework allows the user also to modify the VLX hierachy before it is serialized into a VLT or VLB much like a COLLADA user would moanipulate the XML DOM tree to add custom fields.
Taking advantage of the latest and most advanced texturing techniques is a breeze with Visualization Library. The vl::Texture class provides out of the box and transparent support for all the texture formats supported by OpenGL 4.1! This includes multitexturing support, 1D, 2D and 3D textures, cubemap textures, texture rectangles, 1D and 2D texture arrays, automatic mipmaps generation (hardware-accelerated where available), anisotropic filtering, compressed textures, depth textures, integer textures, non normalized floating point textures, and much more! You can also easily manipulate texture parameters, texture matrices, automatic texture coordinate generation and texture environment settings using a few intuitive classes!
Text rendering and manipulation (not to mention Unicode support) has always been the Achilles' heel of many 3D graphics applications. Visualization Library inverts this situation and brings to VL developers first class Unicode support, high-quality text rendering, and feature-rich text manipulation classes. Visualization Library not only provides high-quality Unicode text rendering (based on FreeType) but also a set of powerful text manipulation classes that can be considered a library on their own. In particular the vl::String class implements a feature-rich Unicode text manipulation engine that can be used not only to load, parse, split, trim, search and replace text but that can interoperate with
std::wstring, can encode to/from Latin1, UTF8 and UTF16BE/LE, can perform Unicode-aware case transformations and much more!
In order to load and write resources VL uses an extensible system called "Virtual File System". Anything that can be written to or read from can be implemented as vl::VirtualFile. Anything that is capable of containing or enumerating
VirtualFiles can be implemented as a vl::VirtualDirectory. Using this mechanism VL can read and write files that are stored in the RAM, on a disk, that are compressed in an archive or that are transparently downloaded from an HTTP connection. VL provides out of the box support for memory files and directories, disk files and directories, zipped files and directories, and a codec to read and write GZ compressed files. This mechanism can be easily extended to implement
VirtualDirectories that operate over Internet or that encode, compress or encrypt stream of data on the fly, in a manner that is completely transparent to Visualization Library's resource IO functions!
Visualization Library provides support to all the most common image file formats like
BMP. Not only vl::Image is capable of storing any kind of texture (2D, 3D, cubemaps, arrays, compressed images etc.) supported by OpenGL, but can also load and write them on a variety of virtual devices (even custom defined) using the Virtual File System mechanism. vl::Image can also store its data on a local memory buffer or directly on the GPU memory, taking full advantage of the
ARB_pixel_buffer_object extension. Moreover, vl::Image allows you to perform operations like sampling the pixel of an image regardless of it's data format and type, and convert among several image formats and types, like converting a
GL_RGBA/GL_FLOAT image into a
GL_LUMINANCE/GL_UNSIGNED_BYTE one (automatically performing a color to grayscale conversion)!
Visualization Library implements an intuitive and extensible mechanism to load and write a broad range of resource types such as images, 3d file formats like
AC3D etc. This mechanism is centered around three simple concepts:
This way not only it is possible to load and write resources in a simplified and centralized way, regardless of the resource type, but the resource types supported can be extended by the user implementing a new vl::ResourceLoadWriter and registering it to the vl::LoadWriterManager. Futhermore, the user can also provide a customized vl::ResourceLoadWriter to override the ones shipped with Visualization Library if it is needed. When, for example, an application requests an image using the vl::loadImage() function, the appropriate vl::ResourceLoadWriter is picked by the vl::LoadWriterManager, and the resource is loaded from the specified path or vl::VirtualFile.
vl::LoadWriterDICOM, vl::LoadWriterPNG, vl::LoadWriterJPG, vl::LoadWriterTIFF, vl::LoadWriterDDS, vl::LoadWriterTGA, vl::LoadWriterBMP, vl::LoadWriterDAT, vl::LoadWriter3DS, vl::LoadWriterOBJ, vl::LoadWriterAC3D, vl::LoadWriterPLY, vl::LoadWriterSTL, vl::LoadWriterMD2
Some applications do not need complex LOD or CLOD management algorithms to display height fields or terrains, either because the data displayed has a limited size or because particular constraints are applied to the camera (like in RTS games for example) for which only a limited portion of the terrain is visible at a given time. This applications can greatly benefit from the vl::Terrain scene manager which implements a fool-proof, high-precision (8, 16 and 32 bits heightmaps) and efficient terrain/heightfield generation and management system. All the user has to provide is a texture for the terrain, a heightfield image and a detail texture following very simple and precise guidelines. The vl::Terrain class takes care of all the rest, like dividing the provided images into chunks, generating the geometry, generating the kd-tree, computing the appropriate texture coordinates in order to prevent seams and so on. If the OpenGL Shading Language is available, the vl::Terrain class can also store the heightmap directly on the GPU and can generate the geometry on the fly using a technique called "vertex texture fetch" (http://developer.nvidia.com/object/using_vertex_textures.html). This technique allows the application to save GPU memory and to manage even greater terrain databases at a higher speed.
Visualization Library memory management has been designed following three main principles:
Visualization Library provides the developer with several ready-to-use and configurable geometrical primitives like bicubic bezier surfaces, extrusions, cubes, spheres, toruses, grids, pyramids, circles, point clouds etc.
Visualization Library 2.0.0-b3 Reference Documentation
Updated on Tue Feb 7 2017 00:26:07.
© Copyright Michele Bosi. All rights reserved.