Jump to content

  • Log In with Google      Sign In   
  • Create Account


oggs91

Member Since 01 Sep 2010
Offline Last Active Yesterday, 09:16 AM

#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 !! =)
http://arcsynthesis.org/gltut


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

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

Hello!

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 ?)

http://www.opengl.org/wiki/History_of_OpenGL
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:
http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf

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
36
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.



PARTNERS