46 lines
5.4 KiB
Plaintext
46 lines
5.4 KiB
Plaintext
Changes for PolyVox version 0.2
|
|
===============================
|
|
This is the first revision for which we have produced a changelog, as we are now trying to streamline our development and release process. Hence this changelog entry is not going to be as structured as we hope they will be in the future. I'm writing it from memory, rather than having carefully kept track of all the relevent changes as I made them.
|
|
|
|
Refactor of basic voxel types
|
|
-----------------------------
|
|
Previous versions of PolyVox provided classes representing voxel data, such as MaterialDensityPair88. These classes were required to expose certain function such as getDensity() and getMaterial(). This is no longer the case as now even primitive data types such as floats and ints can be used as voxels. You can also create new classes to represent voxel data and it is entirely up to you what kind of properties they have.
|
|
|
|
As an example, imagine you might want to store lighting values in a volume and propergate them according to some algorithm you devise. In this case the voxel data has no concept of densities or materials and there is no need to provide them. Algorithms which conceptually operate on densities (such as the Marching Cubes Surface Extractor) will not be able to operate on your lighting data but this would not make sense anyway.
|
|
|
|
Because algorithms now know nothing about the structure of the underlying voxels, some utility functions/classes are required. The principle is similar to the std::sort algorithm, which knows nothing about the type of data it is operating on but is told how to compare any two values via a comparator function object. In this sense, it will be useful to have an understanding of how algorithms such as std::sort are used.
|
|
|
|
We have continued to provide the Density, Material, and MaterialDensityPair classes to ease the transition into the new system, but really they should just be considered as examples of how you might create your own voxel types.
|
|
|
|
Some algothms assume that basic mathematical operations can be applied to voxel types. For example, the LowPassFilter needs to compute the average of a set of voxels, and to do this it need to be possible to add voxels together and divide by an integer. Obviously these operations are provided by primitive types, but it means that if you want to use the LowPassfilter on custom voxel types then these types need to provide operator+=, operator/=, etc. These have been added to the Density and MaterialDensityPair classes, but not to the Material class. This reflects the fact that applying a low pass filter to a material volume does not make conceptual sense.
|
|
|
|
Changes to build system
|
|
-----------------------
|
|
In order to make the build system easier to use, a number of CMake variables were changed to be more consistent. See :doc:`install` for details on the new variable naming.
|
|
|
|
Changes to CubicSurfaceExtractor
|
|
--------------------------------
|
|
The behaviour of the CubicSurfaceExtractor has been changed such that it no longer handles some edge cases. Because each generated quad lies between two voxels it can be unclear which region should 'own' a quad when the two voxels are from different regions. The previous version of the CubicSurfaceExtractor would attempt to handle this automatically, but as a result it was possible to get two quads existing at the same position in space. This can cause problems with transparency and with physics, as well as making it harder to decide which regions need to be updated when a voxel is changed.
|
|
|
|
The new system simplifies the behaviour of this surface extractor but does require a bit of care on the part of the user. You should be clear on the rules controlling when quads are generated and to which regions they will belong. To aid with this we have significantly improved the API documentation for the CubicSurfaceExtractor so be sure to have a look.
|
|
|
|
Changes to Raycast
|
|
------------------
|
|
The raaycasting functionality was previously in a class (Raycast) but now it is provided by standalone functions. This is basically because there is no need for it to be a class, and it complicated usage. The new functions are called 'raycastWithDirection' and 'raycastWithEndpoints' which helps remove the previous ambiguity regarding the meaning of the two vectors which are passed as parameters.
|
|
|
|
The callback functionalilty (called for each processed voxel to determine whether to continue and also perform additional processing) is no longer implemented as an std::function. Instead the standard STL approach is used where a function or function object is used a a template parameter. This is faster than the std::function solution and should also be easier to integrate with other languages.
|
|
|
|
Usage of the new raycasting is demonstrated by a unit test.
|
|
|
|
Changes to AmbientOcclusionCalculator
|
|
-------------------------------------
|
|
The AmbientOcclusionCalculator has also been unclassed and is now called calculateAmbientOcclusion. The unit test has been updated to demsonstrate the new usage.
|
|
|
|
Changes to A* pathfinder
|
|
------------------------
|
|
The A* pathfinder has always had differnt (but equally valid) results when building in Visual Studio vs. GCC. This is now fixed and results are consistent between platforms.
|
|
|
|
Copy and move semantics
|
|
-----------------------
|
|
All volume classes now have protecected copy constructors and assignment operators to prevent you from accidently copying them (which is expensive). Look at the VolumeResample if you really do want to copy some volume data.
|