Replaced 'code-block' with 'sourcecode'.
This commit is contained in:
parent
c806da9bb7
commit
db1c2bf0f8
@ -23,7 +23,7 @@ The description here is rather oversimplified, but the idea behind these operati
|
|||||||
|
|
||||||
Further information about the derivative operations can be found in the OpenGL/Direct3D API documentation, but the implementation in code is quite simple. Firstly you need to make sure that you have access to the fragments world space position in your shader, which means you need to pass it through from the vertex shader. Then you can use the following code in your fragment shader:
|
Further information about the derivative operations can be found in the OpenGL/Direct3D API documentation, but the implementation in code is quite simple. Firstly you need to make sure that you have access to the fragments world space position in your shader, which means you need to pass it through from the vertex shader. Then you can use the following code in your fragment shader:
|
||||||
|
|
||||||
.. code-block:: glsl
|
.. sourcecode:: glsl
|
||||||
|
|
||||||
vec3 worldNormal = cross(dFdy(inWorldPosition.xyz), dFdx(inWorldPosition.xyz));
|
vec3 worldNormal = cross(dFdy(inWorldPosition.xyz), dFdx(inWorldPosition.xyz));
|
||||||
worldNormal = normalize(worldNormal);
|
worldNormal = normalize(worldNormal);
|
||||||
|
@ -33,7 +33,7 @@ Triplanar Texturing
|
|||||||
-------------------
|
-------------------
|
||||||
The most common approach to texture mapping smooth voxel terrain is to use *triplanar texturing*. The basic idea is to project a texture along all three main axes and blend between the three texture samples according to the surface normal. As an example, suppose that we wish to write a fragment shader to apply a single texture to our terrain, and assume that we have access to both the world space position of the fragment and also its normalised surface normal. Also, note that your textures should be set to wrap because the world space position will quickly go outside the bounds of 0.0-1.0. The world space position will need to have been passed through from earlier in the pipeline while the normal can be computed using one of the approaches in the lighting (link) document. The shader code would then look something like this [footnote: code is untested as is simplified compared to real world code. hopefully it compiles, but if not it should still give you an idea of how it works]:
|
The most common approach to texture mapping smooth voxel terrain is to use *triplanar texturing*. The basic idea is to project a texture along all three main axes and blend between the three texture samples according to the surface normal. As an example, suppose that we wish to write a fragment shader to apply a single texture to our terrain, and assume that we have access to both the world space position of the fragment and also its normalised surface normal. Also, note that your textures should be set to wrap because the world space position will quickly go outside the bounds of 0.0-1.0. The world space position will need to have been passed through from earlier in the pipeline while the normal can be computed using one of the approaches in the lighting (link) document. The shader code would then look something like this [footnote: code is untested as is simplified compared to real world code. hopefully it compiles, but if not it should still give you an idea of how it works]:
|
||||||
|
|
||||||
.. code-block:: glsl
|
.. sourcecode:: glsl
|
||||||
|
|
||||||
// Take the three texture samples
|
// Take the three texture samples
|
||||||
vec4 sampleX = texture2d(inputTexture, worldSpacePos.yz); // Project along x axis
|
vec4 sampleX = texture2d(inputTexture, worldSpacePos.yz); // Project along x axis
|
||||||
@ -47,7 +47,7 @@ Note that this approach will lead to the texture repeating once every world unit
|
|||||||
|
|
||||||
This idea of triplanar texturing can be applied to the cubic meshes as well, and in some ways it can be considered to be even simpler. With cubic meshes the normal always points exactly along one of the main axes, and so it is not necessary to sample the texture three times nor to blend the results. Instead you can use conditional branching in the fragment shader to determine which pair of values out of {x,y,z} should be used as the texture coordinates. Something like:
|
This idea of triplanar texturing can be applied to the cubic meshes as well, and in some ways it can be considered to be even simpler. With cubic meshes the normal always points exactly along one of the main axes, and so it is not necessary to sample the texture three times nor to blend the results. Instead you can use conditional branching in the fragment shader to determine which pair of values out of {x,y,z} should be used as the texture coordinates. Something like:
|
||||||
|
|
||||||
.. code-block:: glsl
|
.. sourcecode:: glsl
|
||||||
|
|
||||||
vec4 sample = vec4(0, 0, 0, 0); // We'll fill this in below
|
vec4 sample = vec4(0, 0, 0, 0); // We'll fill this in below
|
||||||
// Assume the normal is normalised.
|
// Assume the normal is normalised.
|
||||||
@ -71,7 +71,7 @@ Both the CubicSurfaceExtractor and the MarchingCubesSurfacExtractor understand t
|
|||||||
|
|
||||||
The following code snippet assumes that you have passed the material identifier to your shaders and that you can access it in the fragment shader. It then chooses which colour to draw the polygon based on this identifier:
|
The following code snippet assumes that you have passed the material identifier to your shaders and that you can access it in the fragment shader. It then chooses which colour to draw the polygon based on this identifier:
|
||||||
|
|
||||||
.. code-block:: glsl
|
.. sourcecode:: glsl
|
||||||
|
|
||||||
vec4 fragmentColour = vec4(1, 1, 1, 1); // Default value
|
vec4 fragmentColour = vec4(1, 1, 1, 1); // Default value
|
||||||
if(materialId < 0.5) //Avoid '==' when working with floats.
|
if(materialId < 0.5) //Avoid '==' when working with floats.
|
||||||
|
@ -22,13 +22,13 @@ Since C++ templates are essentially a code-generation system built into the C++
|
|||||||
The way we work around this is by, as part of the bindings generation process, pre-compiling a number of different versions of each templated class.
|
The way we work around this is by, as part of the bindings generation process, pre-compiling a number of different versions of each templated class.
|
||||||
For example, in C++ a 3D vector containing 32-bit integers would be declared as
|
For example, in C++ a 3D vector containing 32-bit integers would be declared as
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
PolyVox::Vector3D<int32_t> my_vec(0,1,4);
|
PolyVox::Vector3D<int32_t> my_vec(0,1,4);
|
||||||
|
|
||||||
but in Python it would be accessed as
|
but in Python it would be accessed as
|
||||||
|
|
||||||
.. code-block:: python
|
.. sourcecode:: python
|
||||||
|
|
||||||
my_vec = PolyVoxCore.Vector3Dint32_t(0,1,4)
|
my_vec = PolyVoxCore.Vector3Dint32_t(0,1,4)
|
||||||
|
|
||||||
|
@ -12,7 +12,7 @@ Creating a volume
|
|||||||
=================
|
=================
|
||||||
To get started, we need to include the following headers:
|
To get started, we need to include the following headers:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
#include "PolyVoxCore/CubicSurfaceExtractorWithNormals.h"
|
#include "PolyVoxCore/CubicSurfaceExtractorWithNormals.h"
|
||||||
#include "PolyVoxCore/MarchingCubesSurfaceExtractor.h"
|
#include "PolyVoxCore/MarchingCubesSurfaceExtractor.h"
|
||||||
@ -21,7 +21,7 @@ To get started, we need to include the following headers:
|
|||||||
|
|
||||||
The most fundamental construct when working with PolyVox is that of the volume. This is represented by the :polyvox:`SimpleVolume` class which stores a 3D grid of voxels. Our basic example application creates a volume with the following line of code:
|
The most fundamental construct when working with PolyVox is that of the volume. This is represented by the :polyvox:`SimpleVolume` class which stores a 3D grid of voxels. Our basic example application creates a volume with the following line of code:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
SimpleVolume<uint8_t> volData(PolyVox::Region(Vector3DInt32(0,0,0), Vector3DInt32(63, 63, 63)));
|
SimpleVolume<uint8_t> volData(PolyVox::Region(Vector3DInt32(0,0,0), Vector3DInt32(63, 63, 63)));
|
||||||
|
|
||||||
@ -29,13 +29,13 @@ As can be seen, the SimpleVolume class is templated upon the voxel type. This me
|
|||||||
|
|
||||||
Next, we set some of the voxels in the volume to be 'solid' in order to create a large sphere in the centre of the volume. We do this with the following function call:
|
Next, we set some of the voxels in the volume to be 'solid' in order to create a large sphere in the centre of the volume. We do this with the following function call:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
createSphereInVolume(volData, 30);
|
createSphereInVolume(volData, 30);
|
||||||
|
|
||||||
Note that this function is part of the BasicExample (rather than being part of the PolyVox library) and is implemented as follows:
|
Note that this function is part of the BasicExample (rather than being part of the PolyVox library) and is implemented as follows:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
void createSphereInVolume(SimpleVolume<uint8_t>& volData, float fRadius)
|
void createSphereInVolume(SimpleVolume<uint8_t>& volData, float fRadius)
|
||||||
{
|
{
|
||||||
@ -80,7 +80,7 @@ Extracting the surface
|
|||||||
======================
|
======================
|
||||||
Now that we have built our volume we need to convert it into a triangle mesh for rendering. This process can be performed by the :polyvox:`CubicSurfaceExtractorWithNormals` class. An instance of the :polyvox:`CubicSurfaceExtractorWithNormals` is created as follows:
|
Now that we have built our volume we need to convert it into a triangle mesh for rendering. This process can be performed by the :polyvox:`CubicSurfaceExtractorWithNormals` class. An instance of the :polyvox:`CubicSurfaceExtractorWithNormals` is created as follows:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
SurfaceMesh<PositionMaterialNormal> mesh;
|
SurfaceMesh<PositionMaterialNormal> mesh;
|
||||||
CubicSurfaceExtractorWithNormals< SimpleVolume<uint8_t> > surfaceExtractor(&volData, volData.getEnclosingRegion(), &mesh);
|
CubicSurfaceExtractorWithNormals< SimpleVolume<uint8_t> > surfaceExtractor(&volData, volData.getEnclosingRegion(), &mesh);
|
||||||
@ -89,7 +89,7 @@ The :polyvox:`CubicSurfaceExtractorWithNormals` takes a pointer to the volume da
|
|||||||
|
|
||||||
The actual extraction happens in the :polyvox:`CubicSurfaceExtractorWithNormals::execute` function. This means you can set up a :polyvox:`CubicSurfaceExtractorWithNormals` with the required parameters and then actually execute it later. For this example we just call it straight away.
|
The actual extraction happens in the :polyvox:`CubicSurfaceExtractorWithNormals::execute` function. This means you can set up a :polyvox:`CubicSurfaceExtractorWithNormals` with the required parameters and then actually execute it later. For this example we just call it straight away.
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
surfaceExtractor.execute();
|
surfaceExtractor.execute();
|
||||||
|
|
||||||
@ -103,7 +103,7 @@ Rendering the surface with OpenGL is handled by the OpenGLWidget class. Again, t
|
|||||||
|
|
||||||
The OpenGLWidget::setSurfaceMeshToRender() function is implemented as follows:
|
The OpenGLWidget::setSurfaceMeshToRender() function is implemented as follows:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
void OpenGLWidget::setSurfaceMeshToRender(const PolyVox::SurfaceMesh<PositionMaterialNormal>& surfaceMesh)
|
void OpenGLWidget::setSurfaceMeshToRender(const PolyVox::SurfaceMesh<PositionMaterialNormal>& surfaceMesh)
|
||||||
{
|
{
|
||||||
@ -135,7 +135,7 @@ The begin and end indices are used in the OpenGLWidget::paintGL() to control wha
|
|||||||
|
|
||||||
With the OpenGL index and vertex buffers set up, we can now look at the code which is called each frame to render them:
|
With the OpenGL index and vertex buffers set up, we can now look at the code which is called each frame to render them:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. sourcecode:: c++
|
||||||
|
|
||||||
void OpenGLWidget::paintGL()
|
void OpenGLWidget::paintGL()
|
||||||
{
|
{
|
||||||
|
Loading…
x
Reference in New Issue
Block a user