Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 01 Sep 2010
Offline Last Active Yesterday, 05:48 AM

#5210134 A question on texture sampling

Posted by oggs91 on 11 February 2015 - 04:17 PM

essentially the sampler is what brings your texture from a raster image to a 2d parameterized texture space, so you can index your texture in the shader not with pixel positions but with a continuous floating point value in 2 axis in range [0,1]


ok, nice, but how do we determine what color is on position [0.234, 0.789] ? first of all we need the texture size lets assume it's [512, 512]

[0.234, 0.789] * [512, 512] = [119.808, 403.968] okay ... but at this exact position is obviously no pixel

going the simple way we can just use the NEAREST pixel position [120, 404]


well but that looks pretty crappy, especially if we zoom into the texture ... another possibility would be to interpolate between the 4 surrounding pixels

[119, 403], [120, 403], [119, 404], [120, 404]

this method is called bilinear interpolation




i already mentioned zooming into the texture ... this is called the magnification filter and this case can be perfectly handled with bilinear interpolation ... but now imagine the shown texture covers less pixels than in the original texture


if we use nearest we only get the one pixel marked on the right, if we use bilinear interpolation we get 4 pixels ... but actually we need the pixels of the whole patch .. and somehow combine the colors


on the left you can see the result with linear interpolation, pretty ugly because we dont use enough information from our texture, this effect is called aliasing


and finally this is where mipmapping steps in

the mipmaps of a texture are downsampled versions of the original textures ( original is the bottom one )

each mip level has half it's size of the previous level



resume to the image from before, we have a big area in texel space we have to cover ... we can now choose an appropriate mip level from our texture pyramid depending on the size of the area in texture domain ... choosing colors from appropriate mipmaps leaves us with image (b) from before



but wait there is more! if two pixels in screenspace are now textured from two different mipmap levels we can get artifacts, 

compare bilinear mipmap with trilinear mipmap



trilinear filtering solves our problem, it samples a second mipmap level and interpolates again linearily between the sampled colors from the two chosen mipmap levels


but wait ... there is even more biggrin.png

if you still have not enough from this subject look into ripmapping and anisotropic filtering

#5209892 Texturemap Rendering and Sampling

Posted by oggs91 on 10 February 2015 - 05:20 PM

i thought this a bit further... as you said the blur should be only applied to pixels with alpha=0

therefore would normalize the blur kernel with the sum of weights at positions where alpha != 0


if i apply the blur once i get a border of 1 pixel around my chart

in the 1d case (with blur [0.5 1 0.5]) it would look like this:



so applying the "blur" multiple times with a fragment shader, eventually fills the whole texture

#4970503 Smooth character movement over a heightmapped terrain.

Posted by oggs91 on 17 August 2012 - 05:06 AM

assuming u use a regular rectangular grid in the mesh, u have to determine what triangle your player steps on

then use the three height values of the corressponding triangle as barycentric coordinates to calculate the height

#4969025 Digging

Posted by oggs91 on 13 August 2012 - 05:49 AM

i guess you look for isosurface extraction from a voxel lattice
search for transvoxel, marching cubes, dual contouring

in the projecr transvoxelXna on github we've implemented a simple version of the transvoxel algo from eric lengyel

u can pm me if u want more info :)

#4968997 File IO

Posted by oggs91 on 13 August 2012 - 03:36 AM

i guess the file is still openend when u call your program the second time

#4856230 OpenGL 1,2,3,4 general question

Posted by oggs91 on 01 September 2011 - 05:16 AM

i've found a nice up to date tutorial site !! =)

#4856179 OpenGL 1,2,3,4 general question

Posted by oggs91 on 01 September 2011 - 01:56 AM


Recently i've started to learn OpenGL trough OpenTK (wrapper for c#)
after reading lots of tutorials for OpenGL and DirectX stuff, i realized that all directX tutorials are strongly seperated by the directX version (dx9, dx10, dx10.1, dx11)
why doesn't that happen to opengl?
where should i start to learn about the latest opengl version (i think it's 4, 4.2 ?)

on this site changes to opengl are listed, are there any major changes or just additional functionality added ? (EXT_*, ARB_*) are those, i think it's called, vendor extensions?, the only changes between opengl version or are those just added functionality, not mentioning changed basic features

i'm a bit confused about this whole opengl word :D btw. directx looks somewhat cleaner, wouldn't opengl be easier with an object oriented approach ?!

#4841628 Voxel Algorithm

Posted by oggs91 on 28 July 2011 - 09:01 AM

I'd like to implement a piece of voxel terrain, according to this paper:

but i got really stuck at page 34/35, it's about voxel sharing
(Fig. 3.8a) -> i understand that only on the locations 0,1,2,3 a new vertex is allowed, but what i don't understand is the following 3 Bit direction code!

If you didn't already, read the paper :) it's very intresting - but not very easy, at least for me, to understand

In the event that the sample value at a corner is exactly zero, the vertex lying on any
active edge adjacent to that corner is placed precisely at the corner location. The only
corner at which a new vertex is allowed to be created is corner 7, so vertices for any other
corners must be reused from preceding cells. A 3-bit direction code leading to the proper
cell can easily be obtained by inverting the 3-bit corner index (bitwise, by exclusive
ORing with the number 7), where the bit values 1, 2, and 4 indicate that we must subtract
one from the the x, y, and/or z coordinate, respectively.
For cells occurring along the minimal boundaries of a block, the preceding cells
needed for vertex reuse may not exist. In these cases, we allow new vertex creation on
additional edges of a cell. While iterating through the cells in a block, a 3-bit mask is
maintained whose bits indicate whether corresponding bits in a direction code are valid.
When a direction code is used to locate a preceding cell, it is first ANDed with the
validity mask to determine whether the preceding cell exists, and if not, the creation of a
new vertex in the current cell is permitted. (This test always fails for 4-bit direction codes
having the bit with value 8 set. This is the motivation for assigning the codes 0x81,
0x82, and 0x83 to the maximal edges instead of 0x01, 0x02, and 0x03.)
For each cell, we must have space to store four vertex indexes corresponding to the
locations shown in Figure 3.8(a) so that they can be reused by cells triangulated at a later
time. It is never the case that all four vertex slots are used at once (because a vertex lying
on the interior of an edge implies no vertex at the corner), but we must be able to identify
the vertices using a fixed indexing scheme. The vertices used by a cell are always owned
by the cell itself, the preceding cell in the same row, one of two adjacent cells in the
preceding row, or one of four cells in the preceding deck. We can therefore limit the
vertex history that we store while processing a block to two decks containing 1616 cells
each and ping-pong between them as the z coordinate is incremented.