*************
Prerequisites
*************
The PolyVox library is aimed at experienced games and graphics programmers who wish to incorporate voxel environments into their applications. It is not a drop in solution, but instead provides a set of building blocks which you can use to construct a complete system. Most of the functionality could be considered quite low-level. For example, it provides mesh extractors to generate a surface from volume data but requires the application developer to handle all tasks related to scene management and rendering of such data.

As a result you will need a decent amount of graphics programming experience to effectively make use of the library. The purpose of this document is to highlight some of the core areas with which you will need to be familiar. In some cases we also provide links to places where you can find more information about the subject in question.

You should also be aware that voxel terrain is still an open research area which is only just seeing widespread adoption in games and simulations. There are many questions to which we do not currently know the best answer and so you may have to do some research and experimentation yourself when trying to obtain your desired result. Please do let us know if you come up with a trick or technique which you think could benefit other users.

Programming
===========
This section describes some of the programming concepts with which you will need to be familiar:

**C++:** PolyVox is written using the C++ language and we expect this is what the majority of our users will be developing in. Note that you do have the option of working with other languages via the SWIG bindings but you may not have as much flexibility with this approach, and you will need to undertake additional work as the bindings are not currently complete.

**Templates:** PolyVox also makes heavy use of template programming in order to be both fast and generic, so familiarity with templates will be very useful. You shouldn't need to do much template programming yourself but an understanding of them will help you understand errors and resolve any problems.

**Callbacks:** Several of the algorithms in PolyVox can be customised through the use of callbacks. In general there are sensible defaults provided, but for maximum control you may wish to learn how to define you own. In general the principle is similar to the way in which callbacks are used in the STL.

Graphics Concepts
=================
Several core graphics principles will be useful in understanding and using PolyVox:

**Volume representation:** PolyVox revolves around the idea of storing and manipulating volume data and using this as a representation of a 3d world. This is a fairly intuitive extension of traditional heightmap terrain but does require the ability to 'think in 3D'. You will need to understand that data stored in this way can become very large, and understand the idea that paging and compression can be used to combat this.

**Mesh representation:** Most PolyVox projects will involve using one of the surface extractors, which output their data as index and vertex buffers. Therefore you will need to understand this representation in order to pass the data to your rendering engine or in order to perform further modifications to it. You can find out about more about this in the Wikipedia article on `Polygon Meshes <https://en.wikipedia.org/wiki/Polygon_mesh>`_

**Image processing:** For certain advanced applications an understanding of image processing methods can be useful. For example, the process of blurring an image via a low pass filter can be used to effectively smooth out voxel terrain. There are plans to add more image processing operations to PolyVox particularly with regard to morphological operations which you might want to use to modify your environment.

Rendering
=========
**Runtime geometry creation:** PolyVox is independent of any particular graphics API which means it outputs its data using API-neutral structures such as index and vertex buffers (as mentioned above). You will need to write the code which converts these structures into a format which your API or engine can understand. This is not a difficult task but does require some knowledge of the rendering technology which you are using.

**Scene management:** PolyVox is only responsible for providing you with the mesh data to be displayed, so your application or engine will need to make sensible decisions about how this data should be organised in terms of a spatial structure (octree, bounding volumes tree, etc). It will also need to provide some approach to visibility determination such as frustum culling or a more advanced approach. If you are integrating PolyVox with an existing rendering engine then you should find that many of these aspects are already handled for you.

**Shader programming:** The meshes which are generated by PolyVox are very basic in terms of the vertex data they provide. You get vertex positions, sometimes vertex normals, and sometimes additional data copied/interpolated from the volume. It is the responsibility of application programmer to decide how to use this data to create visually interesting renderings. This means you will almost certainly want to make use of shader programs. Of course, in our :doc:`texturing <texturing>` and :doc:`lighting <lighting>` documents you will find many ideas and common solutions, but you will need strong shader programming experience to make effective use of these.

If you don't have much experience with shader programming then there are many free resources available. The Wikipedia page on `Shaders <https://en.wikipedia.org/wiki/Shader>`_ may provide a starting point, as may the documentation for the `OpenGL <https://www.opengl.org/documentation/>`_ and `Direct3D <https://msdn.microsoft.com/en-us/library/windows/desktop/ff476080>`_ libraries. There is nothing special about PolyVox meshes so you would be advised to practice development on simple meshes such as spheres and cubes before trying to apply it to the output of the mesh extractors.