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

How to get pixel coordinates in HLSL (quick question)

5 posts in this topic

My vertex declaration has a [b]D3DXVECTOR2 tex0; [/b](texture coordinates).Is this what I need to get a pixel's location in the shader?Like right now I'm using a sample [i].fx[/i] file from a tutorial that blends 3 textures together depending on a blendmap rgb value.I wanna make it blend 7 textures and instead of rgb to use some values from a struct I made.The point is,I'm not exactly sure what tells you the pixel's location.Is it the texcoords?

This is the sample file - I hope it's not troublesome that I post it for a second time in this forum,the first time it was a different issue.

[CODE]
//=============================================================================
// Terrain.fx by Frank Luna (C) 2004 All Rights Reserved.
//
// Blends three textures together with a blend map.
//=============================================================================

uniform extern float4x4 gViewProj;
uniform extern float3 gDirToSunW;
uniform extern texture gTex0;
uniform extern texture gTex1;
uniform extern texture gTex2;
uniform extern texture gBlendMap;
static float gTexScale = 16.0f;
sampler Tex0S = sampler_state
{
Texture = <gTex0>;
MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = POINT;
AddressU = WRAP;
AddressV = WRAP;
};
sampler Tex1S = sampler_state
{
Texture = <gTex1>;
MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = POINT;
AddressU = WRAP;
AddressV = WRAP;
};
sampler Tex2S = sampler_state
{
Texture = <gTex2>;
MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = POINT;
AddressU = WRAP;
AddressV = WRAP;
};
sampler BlendMapS = sampler_state
{
Texture = <gBlendMap>;
MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = POINT;
AddressU = WRAP;
AddressV = WRAP;
};

struct OutputVS
{
float4 posH : POSITION0;
float2 tiledTexC : TEXCOORD0;
float2 nonTiledTexC : TEXCOORD1;
float shade : TEXCOORD2;
};
OutputVS TerrainVS(float3 posW : POSITION0, // We assume terrain geometry is specified
float3 normalW : NORMAL0, // directly in world space.
float2 tex0: TEXCOORD0)
{
// Zero out our output.
OutputVS outVS = (OutputVS)0;

// Just compute a grayscale diffuse and ambient lighting
// term--terrain has no specular reflectance. The color
// comes from the texture.
outVS.shade = saturate(max(0.0f, dot(normalW, gDirToSunW)) + 0.3f);

// Transform to homogeneous clip space.
outVS.posH = mul(float4(posW, 1.0f), gViewProj);

// Pass on texture coordinates to be interpolated in rasterization.
outVS.tiledTexC = tex0 * gTexScale; // Scale tex-coord to tile.
outVS.nonTiledTexC = tex0; // Blend map not tiled.

// Done--return the output.
return outVS;
}
float4 TerrainPS(float2 tiledTexC : TEXCOORD0,
float2 nonTiledTexC : TEXCOORD1,
float shade : TEXCOORD2) : COLOR
{
// Layer maps are tiled
float3 c0 = tex2D(Tex0S, tiledTexC).rgb;
float3 c1 = tex2D(Tex1S, tiledTexC).rgb;
float3 c2 = tex2D(Tex2S, tiledTexC).rgb;

// Blendmap is not tiled.
float3 B = tex2D(BlendMapS, nonTiledTexC).rgb;
// Find the inverse of all the blend weights so that we can
// scale the total color to the range [0, 1].
float totalInverse = 1.0f / (B.r + B.g + B.b);

// Scale the colors by each layer by its corresponding weight
// stored in the blendmap.
c0 *= B.r * totalInverse;
c1 *= B.g * totalInverse;
c2 *= B.b * totalInverse;

// Sum the colors and modulate with the shade to brighten/darken.
float3 final = (c0 + c1 + c2) * shade;

return float4(final, 1.0f);
}
technique TerrainTech
{
pass P0
{
vertexShader = compile vs_2_0 TerrainVS();
pixelShader = compile ps_2_0 TerrainPS();
}
}
[/CODE]

Basically the variables I don't understand are [b]shade [/b]and why is [b]AdressUV [/b]only used in the structs and it's not even mentioned in the shader functions.
0

Share this post


Link to post
Share on other sites
It looks like shade is performing a shadow like effect based off the direction of the sun and the position of the normal. The only address u and v I see is in the sampler, telling the shader to wrap (tile / repeat) the texture.

Seven textures is a lot for one shader but anyway, I usually have a value stored in my vertex formatted struct (calculated on the CPU once) that I pass to the shader that tells me how much of a cretin texture to sample for each vert. Then I sample the textures (3 in my situation) using the textcoords like any other rendering and then for each one I multiply them by the custom amount I passed in ( 0 - 1). I then add all the colors together. This allows me to blend (splatter) textures.

Hope this helps,
Dj Edited by DJTN
0

Share this post


Link to post
Share on other sites
[quote name='DJTN' timestamp='1337184039' post='4940687']
It looks like shade is performing a shadow like effect based off the direction of the sun and the position of the normal. The only address u and v I see is in the sampler, telling the shader to wrap (tile / repeat) the texture.
[/quote][quote name='DJTN' timestamp='1337184039' post='4940687']
It looks like shade is performing a shadow like effect based off the direction of the sun and the position of the normal. The only address u and v I see is in the sampler, telling the shader to wrap (tile / repeat) the texture.
[/quote]

so in a 512 x 512 texture a UV of 0.5,0.5 will be the pixel at location 256,256 on the texture,right?
0

Share this post


Link to post
Share on other sites
[quote name='Bogomil' timestamp='1337184436' post='4940689']

so in a 512 x 512 texture a UV of 0.5,0.5 will be the pixel at location 256,256 on the texture,right?
[/quote]

Yes. Top left (0,0) bottom right (1,1).
0

Share this post


Link to post
Share on other sites
ok 1 last thing - about WRAP.If AdressU and AdressV are set to WRAP and they are exactly 1/4 the size of the whole area im working with,will that tile them exactly 4 times?Like if texture1 is 100x100 in size and the terrain mesh is 400x400 size,that tiles texture1 perfectly 4 tiems,right?So then I can just use UV's from 0.0 to 4.0 for that texture?
0

Share this post


Link to post
Share on other sites
Hi Bogomil,

[quote name='Bogomil' timestamp='1337187206' post='4940694']
ok 1 last thing - about WRAP.If AdressU and AdressV are set to WRAP and they are exactly 1/4 the size of the whole area im working with,will that tile them exactly 4 times?Like if texture1 is 100x100 in size and the terrain mesh is 400x400 size,that tiles texture1 perfectly 4 tiems,right?So then I can just use UV's from 0.0 to 4.0 for that texture?
[/quote]
Yeah, kind of.
One of the ideas behind texture coordinates is to make your code independent from the resolution of the actual textures, which is why those coordinates are relative (in [0,0] to [1,1]).
For a shader it doesn’t matter whether texture1 has 100x100 pixels and texture2 400x400. If both textures are accessed with the same texture coordinate, e.g. in [0,0] to [1,1], they will be tiled equally. In order to repeat texture1 four times, you’d have to scale the texture coordinate only for texture1, i.e. [0,0] to [4,4].
The texture filters and mip mapping will take care for varying scales, i.e. if you’d use [0,0] to [8,8] the texture displayed will be down-filtered. Even if you pick something odd [0,0] to [7,7] the filtering will interpolate the colors accordingly.

Currently, you use a simple bilinear filter. The GPU can do better. You may want to experiment with an anisotropic filter (the thing you usually turn on in video games. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]). It adapts the filtering to varying distances and viewing angles. Also make sure you build mipmaps for your textures.

[CODE]SamplerState g_samAnisotropic
{
Filter = ANISOTROPIC;
MaxAnisotropy = 8;
AddressU = Wrap;
AddressV = Wrap;
};[/CODE]
MaxAnisotropy steers the quality, is hardware-dependent and usually somewhere between 1 and 16, if I recall correctly.

Cheers!
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