Jump to content
  • Advertisement
Sign in to follow this  
derek7

where is vs or ps input???

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

matrix ViewProjMatrix;
vector Blue = {0.0f, 0.0f, 1.0f, 1.0f};

// Input structure describes the vertex that is input
// into the shader. 
struct VS_INPUT
{
    vector position  : POSITION;
};

struct VS_OUTPUT
{
    vector position : POSITION;
    vector diffuse  : COLOR;
};

//
// Main Entry Point, observe the main function 
// receives a copy of the input vertex through
// its parameter and returns a copy of the output
// vertex it computes.
//

VS_OUTPUT Main(VS_INPUT input)
{
     VS_OUTPUT output = (VS_OUTPUT)0;
 
    // transform to view space and project
    output.position  = mul(input.position, ViewProjMatrix);

    output.diffuse = Blue;

    return output;
}


I guess input data is at vertex buffer. and automaticly feed to the vs. So if let it run well ,I must match format of vertex in vertexbuffer with format of vertex in vs.Am I right?

Share this post


Link to post
Share on other sites
Advertisement
OMG another problem come .
Below is very simpel ps code.
It multitexture 3 texture into one.

The INPUT are 3 coordinate.
I know ps input depend on vertex output but
How did I know what vertex output????


sampler BaseTex;
sampler SpotLightTex;
sampler StringTex;

//
// Structures
//

struct PS_INPUT
{
float2 base : TEXCOORD0;
float2 spotlight : TEXCOORD1;
float2 text : TEXCOORD2;
};

struct PS_OUTPUT
{
vector diffuse : COLOR0;
};

//
// Main
//

PS_OUTPUT Main(PS_INPUT input)
{
// zero out members of output
PS_OUTPUT output = (PS_OUTPUT)0;

// sample appropriate textures
vector b = tex2D(BaseTex, input.base);
vector s = tex2D(SpotLightTex, input.spotlight);
vector t = tex2D(StringTex, input.text);

// combine texel colors
vector c =b *s +t;

// increase the intensity of the pixel slightly
c += 0.1f;

// save the resulting pixel color
output.diffuse = c;

return output;
}


Share this post


Link to post
Share on other sites
In fact you are partially right and partially wrong.

Your VS input definition tells the VS which data will be used. In your example:

struct VS_INPUT
{
vector position : POSITION;
};

This tells the shader that only position info should be used.

That means you CAN send any data you want. Say your vertex format is:
class MYVERTEX
{ VECTOR3 Position;
VECTOR3 Normal;
VECTOR2 uv;
}

If you send a whole vertex buffer consisting of 1000 vertices with this info, the VS will only fetch the position and completely discard the Normal an UV info because it doesn't need it.

The VS knows which data it must get because you declare your vertex information usinf a vertex declaration. In de VDECL you tell that the first 3 floats are the position, the next 3 floats are the normal and the next 2 floats are the UV coords. That way if your VS input is:

struct VS_INPUT
{
float3 position : POSITION;
float2 uv : TEXTURE0;
};

The API knows tat it must take the three first floats and use them as the position and the last 2 and use tham as the UV. It completely discards the normal information.

Now, I'm sure you are thinking that this makes you pointless to worry about the data you send. Of course you can create a vertex that defines position, homogeneous, normal 4 texture sets, vertex color, tangent, bone info and more and send it to a shader. The problem is that (a)you are wasting more memory than required and memory is always an issue and (b)you are actually sending that info through the buffer. You will consume your bandwidth.

Now, of course you can limit your vertices to just the required info, so you create your mesh M that uses the shader S. But you will find that sometimes you want to process that same mesh M using other shader T and that the shader T requires more info than S. In that case you get short of info and your shader will not show (or show strange info).

Then, my advice, define a common vertex format that uses your most used info. Its common to have position, normal, UV1, UV2, tangent (for bump), vertex color and bone info. In fact you will be sending more info than required but consider that on low end cards, your bottleneck is not the data transfer but the data processing. So you will get bottleneck in your PS or your VS. Only in high end cards the data may be processed faster and the Bandwidth may become an issue. This way you will be able to use mix and match many shaders and objects. Anyway if BW becomes an issue, you can easilly optimize your rendering in order to optimiza BW usage.

Luck!
Guimo



Share this post


Link to post
Share on other sites
Quote:
Original post by derek7
OMG another problem come .
Below is very simpel ps code.
It multitexture 3 texture into one.

The INPUT are 3 coordinate.
I know ps input depend on vertex output but
How did I know what vertex output????


The PS dependa on your established VS. You can mix VS and PS but you are responsible of matching the VS output with the PS input. In your previous example, check this VS output:

struct VS_OUTPUT
{
vector position : POSITION;
vector diffuse : COLOR;
};

it clearly defines that your VS will return that data info. So you can use that VS with any PS that requires this data input.

Look your second example:
struct PS_INPUT
{
float2 base : TEXCOORD0;
float2 spotlight : TEXCOORD1;
float2 text : TEXCOORD2;
};

This VS requires 3 texcoords but your previous VS returns position and color. Thats why the SEMANTICS are used for. They allow the API to match the values from one return to the next input. In the same way your APP sends info to the shader using the SEMANTICS, the API matches the VS output with the PS input using the semantics.

Now notice that a PS produces color. Color has 4 components A, R, G, B. Divided in to paths A (alpha) and RGB (color). Thats the only information a PS can output. Thats why this is the common structure you will fins for any PS:
struct PS_OUTPUT
{
vector diffuse : COLOR0;
};


Now, how can you enhance your shaders usage into a more coherent organization. There are specifications like the DirectX FX Framework or nvidia CgFX. An FX file is a single program that may hold many VS and PS. The FX file has a single objective like rendering a GOLD effect or a PLASTIC effect. The same FX file holds many PS and VS in order to target specific platforms, like a VS for 3.0 another for 2.0, another for 1.1. The same for PS.

What makes FX files interesting is that they hold Technique information. A technique allows the mixing of VS and PS in order to maximize the quality. That way in your GOLD.FX file you may have VS_2_0 and VS_1_1 and PS_2_0 and PS_1_4 and PS_1_1. So mixing them all you are able to create 16 techniques of rendering gold, some of them faster, some of them more realistic. The techniques may even have multipass in order to apply multiple shaders on the same mesh.

How you use a FX file, depends of your architecture, but it usually means:
Load the FX
BeginPass
Set the FX
Select technique
Activate pass 0
Send mesh
Activate pass 1 (if effect has more than 1 pass)
Send mesh
Activate pass 2 (if effect has more than 2 passes)
Send mesh
End technique
EndPass
Present

Latest FX especification (1.0) involves chining effect in order to create a flexible rendering engine.

Luck!
Guimo


Share this post


Link to post
Share on other sites
thanks . it is very clear.
But there is something confused.

PS INput take VS output, but if I only have PS , no VS,

How I know what data do fixed piple output ?

Share this post


Link to post
Share on other sites
Consider all possible data is output from Fixed Pipe to the PS. But not all data carries information. Say if you activate only one texture, you may try to use the second or third texture stage in the PS but of course you will find nothing.

Luck!
Guimo

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!