• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
robustpotato

VTF Pixel Coordinate problem

7 posts in this topic

Hi.

I am trying to use VTF, to create a terrain. I have a heightmap of 1024x1024.
I have sampled this for vertex heights on a grid that is 2048x2048, stretching the heightmap so there are 2 vertices for every pixel. I want to be able to stretch it further. For the vertices that have no pixel, they will interpolate (If I'm not mistaken, HLSL handles that when you sample a texture).

To work out my texture coordinates I am taking the vertex position and dividing by the grid size.

My problem is the 1st 2 rows of vertices along 1 axis are giving me the same heights.

In theory the texture coordinates should be:
for the 1st row 0/2048 = 0.
for the 2nd 1/2048 = 0.00048828125.

I have used PIX to try and debug it but on both rows the coordinates both are calculated as 0.000
It seems to be rounding after 3 decimal places. therefore both rows sample the same pixels and the heights are identical.

Can I use better precision or is there another way to sample using exact coordinates? rather than 0.0-1.0

I'm guessing this would occur elsewhere on the terrain also, but its harder to find. at a glance it looks like its all used correct pixel samples and interpolated the ones that are in between.

Cheers
0

Share this post


Link to post
Share on other sites
I think that DX9 VTF only supports POINT filtering

You will have to implement your own interpolation scheme

You can specify the sampling filter in HLSL like so:

[source lang="cpp"]sampler2D gSmpColor = sampler_state { Texture = <gTexColor>; MinFilter = LINEAR; MagFilter = LINEAR; }[/source]
(You can change PIX decimal places in the options)

For small in-memory terrains you can avoid VTF and use a static vertex and index buffer and some tricks with offsets

These links might be useful:

My VTF technique using interpolation:
[url="http://skytiger.wordpress.com/2010/11/28/xna-large-terrain/"]http://skytiger.wordpress.com/2010/11/28/xna-large-terrain/[/url]

This topic includes a rough description of my non-VTF technique:
[url="http://www.gamedev.net/topic/620084-a-good-heightmap-lod-technique-no-vtf-please/"]http://www.gamedev.net/topic/620084-a-good-heightmap-lod-technique-no-vtf-please/[/url]
0

Share this post


Link to post
Share on other sites
Hey thanks for the reply. I have actually seen your large terrain already. Kinda what inspired what I'm doing. Im taking a mesh and moving around with the camera and snapping to the grid and then just pulling the heights from a texture.

[quote]I think that DX9 VTF only supports POINT filtering[/quote]
I can specify LINEAR in the sampler and get different results when specifying POINT. with point there are clear "Steps" but linear produces a smooth slope.
[source lang="plain"]Texture HeightMap_LowRes;

sampler TextureSampler = sampler_state
{
texture = <HeightMap_LowRes> ;
magfilter = linear;
minfilter = linear;
mipfilter= linear;
AddressU = clamp;
AddressV = clamp;
};
[/source]
from the vertex shader...
[source lang="plain"]
float4 VTFCoords = float4((worldPosition.x)/TerrainSize,(worldPosition.z)/TerrainSize,0,0);
float height =(float)tex2Dlod(TextureSampler, VTFCoords);[/source]
When the worldPosition.x is 0 or 1. the same height occurs (when the z is constant of course).

In your method you pull the 4 nearest pixels and do your own interpolation. You must work out those 4 points as texture coordinates. You said your heightmap is over 8k in one dimension. do you not get a problem with calculating the precise pixel coordinates? My issue is at the edge. So if I were to interpolate from 4 points at the edge, they would be 2 matching pairs as the coordinates seem to be the same. (I need to recheck in PIX after changing the decimal places).

Thank you for the links.

Kinda got my heart set on VTF as I have tried other LOD methods before, but am yet to try VTF. Your "pizza" method seems quite elegant. For now Im just using a square mesh, I want to try and make it quite low res, My application doesnt require showing a terrain right to the horizon, just the immediate area around it, but it needs to support larger terrains, so when you move it will show a new area instantly (from 1 heightmap). What I have so far looks great. I just need to sort out the interpolation. But even if I do I think my samples will pick the same heights.

Feel like I am missing something obvious?


Thanks for the help, much appreciated!
0

Share this post


Link to post
Share on other sites
DX9 might or might not support linear filtering, depending on the GPU. Actual DX9-era GPUs won't support it, but more modern ones might. You can check the [url="http://zp.amsnet.pl/cdragan/query.php?dxversion=9&feature=capabilities&featuregroup=selected&adaptergroup=all&featureselected%5B%5D=319&featureselected%5B%5D=318&featureselected%5B%5D=312&featureselected%5B%5D=311&orientation=horizontal"]caps[/url] at runtime to see if your code will work or not.


If your texture is 1024 pixels wide, then 0 is the left-hand boundary of the left-most pixel, 1/1024 is the right-hand boundary of the same pixel and 0.5/1024 is the centre of that pixel.
So, assuming you've got the "clamp" address mode set, then it's expected that 0 and 1/2048 will return the same value.
0

Share this post


Link to post
Share on other sites
I read something about that before. Does that mean I should aim for the centre of the pixel?

So for example 234,591, I'd attempt to get 234.5, 591.5.

What happens when it comes for pixel 1024? 1024.5? the texture coordinate would be higher than 1? or are we assuming the 1st pixel is 0 and the 1024th pixel is 1023

or is 1 the right bounds of the right most pixel.

If that is so then calculating the correct pixel may be awkward. I may have to draw some diagrams.

Again thanks for the help
0

Share this post


Link to post
Share on other sites
The way texcoords work is that 0 is the left/top edge of your image, and 1 is the bottom/right edge, which is very abstract and disconnected from the notion of pixels.
If you're thinking in integer coordinates for an array of 1024 pixels, then 0 is the [i]index[/i] of the leftmost pixel and 1023 is the [i]index[/i] of the rightmost pixel.

To reconcile the two, we can imagine a grid of 1024 squares scaled down to be 1 unit wide total. Each cell would then be 1/1024 units wide. The offset from the edge of a squares to it's centre would be 0.5/1024 units. We can pretend that these squares are pixels, even though that's not technically true ([i]pixels are just points in 2d space with no pre-defined shape or size -- the filtering mode used gives them shape, e.g. nearest/point filtering makes them appear as squares[/i]).
So to convert from an integer pixel index to a texture coordinate at the very centre of that pixel, you can use [font=courier new,courier,monospace](pixel index + 0.5) / pixel count[/font].

So, yes, 1023.5/1024 is the exact centre of the rightmost pixel.
If clamp mode is used, then 1.0 is the right hand edge of the rightmost pixel. If wrap mode is used, then 1.0/0.0 are the same -- on the edge between the first and last pixels. Edited by Hodgman
0

Share this post


Link to post
Share on other sites
[quote]not get a problem with calculating the precise pixel coordinates[/quote]

no because worst case 32 bit floating point precision between 0.0 and 1.0 is 1 / 16,777,216 (between 0.5 and 1.0)
and I only need precision down to 1 / 16,384 to hit the centroids Edited by skytiger
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0