I'm learning DirectX 11 and have reached basic HLSL part. I want to use multiple constant buffers in vertex shader, so I need to find the correct StartSlot for VSSetConstantBuffers. I searched on Google and found that someone suggested using GetResourceBindingDescByName.
I tried GetResourceBindingDescByName, but found that it can only get the correct StartSlot for the first cbuffer. For example, in my vertex shader:
cbuffer Test1
{
float4 a;
};
cbuffer Test2
{
float4 b;
};
Now GetResourceBindingDescByName("Test1", &bind_desc) works correctly, but GetResourceBindingDescByName("Test2", &bind_desc) will fail (return E_INVAILDARG).
Could anyone help me?
The reflection only contains symbols use by a shader. As confirmed in the comments, b was not use, and the problem is solve once b is referenced in the code and not strip away by an optimisation.
Related
I'm rather new with webgl: I was wondering how I would go about configuring / setting up the fragment shader so that it would change the colour based on how much time has currently passed.
If the GLSL (Shader code) part is unclear, it's probably best to start out by looking at examples and experimenting in the GLSL Sandbox or Shader Toy.
It's basically just setting the output of the Shader, gl_FragColor to a value depending on a uniform variable (uniform means the same for all processed fragments).
Uniform values can be set from javascript by first retrieving the location of your uniform variable and then setting it to a value, every time time you want to change it (for you it would be every time you draw a frame). The example assumes you already have a compiled and linked webgl program.
var program = yourProgram;
var uniformNameInShader = "time";
var location = gl.getUniformLocation( program, uniformNameInShader );
function drawLoop ( ) {
gl.uniform1i( location, Date.now() );
render();
}
But honestly, you may want to learn the fundamentals from a tutorial, because... you know ... research effort and stuff ...
Simple question but I can't find the answer in a specification anywhere. I'm probably missing the obvious answer somewhere.
How many textures can I use at once in a WebGL Fragment shader? If it's variable, what is a reasonable number to assume for PC use? (Not so interested in mobile).
I need at least 23 in one of my shaders so want to know if I'll be able to do that before I start work on the code or if I'll need to do multiple passes.
I'm pretty sure you can find out with
var maxTexturesInFragmentShader = gl.getParameter(gl.MAX_TEXTURE_IMAGE_UNITS);
WebGL (OpenGL ES 2.0) only requires 8 minimum for fragment shaders.
Note that the number of textures you can access is separate from the amount of times you can access 1 texture. Therefore, for example, if you wanted to access 2 textures using only 1 texture unit then combine the textures and adjust your UV coords. So for example put the contents of 2 textures [A] and [B] side by side into one texture [AB] and then
vec4 colorFromTexA = texture2D(samplerAB, uvForTexA * vec2(0.5, 1.0));
vec4 colorFromTexB = texture2D(samplerAB, uvForTexB * vec2(0.5, 1.0) + vec2(0.5, 0.0));
Of course you probably need to turn set filtering for no mips etc...
You can find the answer at http://webglstats.com/webgl/parameter/MAX_TEXTURE_IMAGE_UNITS
It seems you are out of luck as the stats suggest that most only have 16.
I am trying to use my own vertex structure, upload the vertices into a vertex buffer (indices into index buffer, without FVF code), set up the vertex declaration and stream source and use, and draw them using DrawIndexedPrimitive with fixed shader (but not FVF).
Do I have to write my own shader to use directx 9 SetVertexDeclaration ?
Can I use a customised vertex structure with SetVertexDeclaration and fixed-pipeline ?
If I can ,is there any restriction on fixed-pipeline and vertex declaration ?
Customised vertex structure:
struct PosNormTexCoord
{
float x,y,z;
float nx,ny,nz;
float tu,tv;
};
Unfortunately, you can't use fixed pipeline with custom vertex format. But your structure can be expressed in FVF, why would you want to skip its usage?
UPDATE: Because I needed something right away, I've created a simple shader wrapper that does the sort of thing I need. You can find it here: ShaderManager on GitHub. Note that it's designed for Objective-C / iOS, so may not be useful to everyone. If you have any suggestions for design improvements, please let me know!
Original Problem:
I'm new to using GLSL shaders. I'm familiar enough with the GLSL language and the OpenGL interface, but I'm having trouble designing a simple API through which to use shaders.
OpenGL's C interface to interact with shaders seems cumbersome. I can't seem to find any tutorials on the net that cover the API design of such things.
My question is this: does any one have a good, simple, API design or pattern to wrap the OpenGL shader program API?
Take the following simple example. Say I have one vertex shader that just emulates fixed functionality, and two fragment shaders - one for drawing smooth rectangles and one for drawing smooth circles. I have the following files:
Shader.vsh : Simple vertex shader, with the following inputs/outputs:
-- Uniforms: mat4 Model, mat4 View, mat4 Projection
-- Attributes: vec4 Vertex, vec2 TexCoord, vec4 Color
-- Varying: vec4 vColor, vec2 vTexCoord
Square.fsh : Fragment shader for drawing squares based on tex coord / color
Circle.fsh : Fragment shader for drawing circles based on tex coord / color
Basic Linking
Now what is the standard way to use these? Do I link the above shaders into two OpenGL shader programs? That is:
Shader.vsh + Square.fsh = SquareProgram
Shader.vsh + Circle.fsh = CircleProgram
Or do I instead create one big program where the fragment shaders check some conditional uniform variables and call out to a shader function to generate their result. E.g:
Shader.vsh + Square.fsh + Circle.fsh + Main.fsh = ShaderProgram
//Main.fsh here would simply check whether to call out to square or circle
With two individual programs I would presumably need to call
glUseProgram(CircleProgram); or glUseProgram(SquareProgram);
Before each type of element I want to draw. I would then need to set the uniforms (Model / View / Projection) and attributes of each program before I use it. This seems so unwieldy.
With the single ShaderProgram option I would still need to set some sort of boolean switch (circle or square) in the fragment shader that would be checked before drawing each pixel. This also seems complicated.
As a side note, am I allowed to link two fragment shaders, each with a main() function, into one shader program? How would OpenGL know which one to call?
Setting Variables
The calls:
glUniform*
glVertexAttribPointer
Are used to set uniforms and attribute pointer locations on the current program.
Different classes and structures may need to access and set variables on the current shader (or change the current shader) from different places in the code. I can't think of a nice way to do this that decouples the shader code from the code that wants to use it.
That is, each shape I want to draw will need to set vertex and texture coordinate attributes - requiring the handles to those attributes generated by OpenGL.
The camera will need to set its projection matrix as a uniform in the vertex shader, while the class managing the model matrix stack will need to set its own uniform in the vertex shader.
Changing shaders part-way through drawing a scene would mean that all these classes will need to set their uniforms and attributes again.
How do most people design around this?
A global dictionary of shaders accessed by handle or name, with getters and setters for their parameters?
An OO design with shader objects that each have parameters?
I've looked at the following wrappers:
Jon's Teapot: GLSL Shader Manager - This wraps shaders in C++ classes. It seems like little more than a wrapper that enforces OO principles on a C API, resulting in a C++ API that is much the same.
I am after any sort of design that simplifies the use of Shader programs, and am not concerned about the particular paradigm used (OO, procedural, and so on)
I see this is tagged with iOS, so if you're partial to Objective-C, I'd take a good look at Jeff LaMarche's GLProgram wrapper class, which he describes here and has source available here. I've used it within my own applications to simplify some of the shader program setup, and to make the code a little cleaner.
For example, you can set up a shader and its attributes and uniforms using code like the following:
sphereDepthProgram = [[GLProgram alloc] initWithVertexShaderFilename:#"SphereDepth" fragmentShaderFilename:#"SphereDepth"];
[sphereDepthProgram addAttribute:#"position"];
[sphereDepthProgram addAttribute:#"inputImpostorSpaceCoordinate"];
if (![sphereDepthProgram link])
{
NSLog(#"Depth shader link failed");
NSString *progLog = [sphereDepthProgram programLog];
NSLog(#"Program Log: %#", progLog);
NSString *fragLog = [sphereDepthProgram fragmentShaderLog];
NSLog(#"Frag Log: %#", fragLog);
NSString *vertLog = [sphereDepthProgram vertexShaderLog];
NSLog(#"Vert Log: %#", vertLog);
[sphereDepthProgram release];
sphereDepthProgram = nil;
}
sphereDepthPositionAttribute = [sphereDepthProgram attributeIndex:#"position"];
sphereDepthImpostorSpaceAttribute = [sphereDepthProgram attributeIndex:#"inputImpostorSpaceCoordinate"];
sphereDepthModelViewMatrix = [sphereDepthProgram uniformIndex:#"modelViewProjMatrix"];
sphereDepthRadius = [sphereDepthProgram uniformIndex:#"sphereRadius"];
When you need to use the shader program, you then do something like the following:
[sphereDepthProgram use];
This doesn't address the issues of branching vs. individual shaders that you bring up above, but Jeff's implementation does provide a nice encapsulation of some of the OpenGL ES boilerplate shader setup code.
Basic Linking:
There is no standard way here. There are at least 2 general approaches:
Monolithic - one shader covers many cases, using uniform boolean switches. These branches don't hurt performance because the condition result is constant for any fragment group (actually, for all of the fragments).
Multi-object program compositing - main shader declares a set of entry points (like 'get_diffuse', 'get_specular', etc), which are implemented in separate shader objects attached. This implies individual shader for each object, but any kind of caching helps.
Setting Variables: Uniforms
I will just describe the approach I developed.
Each shader program has a list of uniform dictionaries. It's used to fill the uniform source list upon program (re-)linking. When the program is activated, it goes through the uniform list, fetches values from their sources and uploads them to GL. In the result, data is not directly connected with the user shader program, and whatever manages it does not care about the program using it.
One of these dictionaries can be, for example, a core one, containing model,view transformations, camera projection and maybe something else.
Setting Variables: Attributes
First of all, shader program is an attribute consumer, so it is what has to extract these attributes from a mesh (or any other data storage) and upload them to GL in a way it needs. It should also make sure that types of provided attributes match the requested types.
When using with monolithic shader approach, there is a possible unpleasant situation when one the disabled branch ways requires a vertex attribute that is not provided. I would advice using another attribute's data to supply the missing one, because we don't care about the actual values in this case.
P.S.
You can find an actual implementation of these ideas here: http://code.google.com/p/kri/
Would someone provide/point me to an explanation of or tutorial on using multiple vertex streams in HLSL and XNA? I'm interested in how they're stored/accessed by the GPU, advantages of or uses for streams in custom shaders, etc.
I've seen a few examples on using multiple vertex streams for instanced geometry, but I'm having a hard time wrapping my head around the underlying mechanism.
Update
If I have a vertex shader which accepts two parameters (borrowed from this tutorial)
InstancingVSoutput InstancingVS(InstancingVSinput input, float4x4 instanceTransform : TEXCOORD0, float4 color : TEXCOORD4)
{
InstancingVSoutput output;
float4 pos = input.Position;
pos = mul(pos, transpose(instanceTransform));
pos = mul(pos, WVP);
output.Position = pos;
output.Color = color;
return output;
}
It seems from the example that I pulled this from that instanceTransform and input are pulled from separate streams. However, in this case, the input stream is a list of six vertices, and the instanceTransform comes from a stream of a much larger number of elements, consisting of translation matrices. This is supposed to be used for instanced geometry.
I'm confused about how many times this shader gets executed - is it VertexBuffer0.VertexCount*VertexBuffer1.VertexCount? The problem with this kind of thing is that, once someone's figured it out, they don't bother contributing a well-written document back to the community detailing their discovery.
Argh.
Since no one else has chimed in yet, I'll give it a go :-) this is a great thread on the apphub forums about Vertex Streams:
http://forums.create.msdn.com/forums/p/46229/276901.aspx
from one of the answers:
The gist is this: different streams
can have different data layouts, and
your VertexDeclaration determines what
data gets pulled from what stream.
So, for instance, you could have one
buffer that stores all your positions
and one buffer which stores all your
colors, and you could set those to
different streams; alternatively you
could munge them into a single stream,
but this isn't always convenient.
Hope it helps ;-)