I'm working on a game engine in D3D11, and I need to access multiple textures from the same pixel shader.  The thing is, these are volume (3d) textures, not standard 2d textures, and I need to access them dynamically (ie. I need to be able to select the texture by an index or variable).

I'd love to use texture arrays, but to my knowledge there is no such thing as a 3d texture array.

I could use a set of if statements something like:

Code:

if (index == 0) texture0.Sample(sampler_state,location);
if (index == 1) texture1.Sample(sampler_state,location);
// ect...

but I can't see that being that fast.

My next option is to use 1 large 3d texture and simply use the index as an offset, but I risk hitting the limits on the texture dimensions, and total texture size.

I plan on using the textures as a sort of mipmap, but each subsequent texture won't be smaller than the last (they will all be the same size), rather each subsequent texture (or mip level) will cover a larger area.  So I can't just use a 3d texture with mipmapping enabled (unless there is someway to specify the size of each mip level that I am unaware of).

Any suggestions or ideas?

Hmmm...  I'm gonna say a good hashing algorithm applied to an arbitrary number is better.  As a means of generating a random deterministic value for coordinate P, its complexity is O(1) rather than O(|P|).  A random number generator can be turned into a crude hashing algorithm by reseeding it with each query, but that's a little wasteful for something like a Mersenne Twister which uses a lot of state data.

Still, I'd rather have my question answered by the OP, as there could be more interesting applications I'm not aware of.

That's probably the best option.  You can tailor the hash function to be as complex or as simple as possible (depending on your needs) and still be sure its 100% reversible, no errors, ect...

IMHO having done basic, assembly, lua, java, C and C++ (along with playing around with a zillion other languages but not having done anything large/serious with them), if I were to do it all over again I'd probably start with C#.

Lua is slower than most of the conventional languages, and I've found doesn't scale up to larger projects easily.  Great for scripting, but not for engine or high performance work.

Java's main advantage is being portable, but when it comes to games it seems that everything that java can do, C# does and often much better.  I also found java to be overly restrictive, it has a very narrow view of OO programming (which is funny being built around it from the ground up) and I found I spent more time working around the language than working with it.

C, while being portable, is very heavily tied to the APIs of the system.  Also its very low level, so if you're a low-level type of guy it may just be your thing.  The thing is, expect to write alot of code to do even simple things, and you pretty much have to do everything yourself.  Unless you're into micro-controllers and embedded or low-level systems, or the type of person that runs linux with no GUI, its probably not the language you're looking for.

C++, while being the programming language I use now almost exclusively, is a big bloated mess that takes years to understand why you don't want to actually ever use C++.

I have no real experience with Python, so I really don't know.  I find it curiously horrifying that a program language meant for production code is named after Monty Python...

C# seems to be the happy medium.  Easy to pick up and get going, yet deep enough to handle large/complex projects.  It doesn't shoe-horn you into a certain programming style, in fact it seems to support just about any and every style under the sun.  Its not as portable as say Java but with unity can still be run on just about any system that you might want to target as an indie-gamer.

I hate how whenever I post in GameDev.net I spend more time defending WHY I want to learn/do what i want to do rather than actually learn HOW.  Lets not turn TigSource (which is way awesomer BTW) into that.

Even if isn't not the best route learning Win32 will teach him alot of why you don't want to write another SDL/SFML, ect...

Got to agree with the evil of the define approach. I did it when making our framework that supports pc, mac, ios, blackberry, android, and likely linux. Its a real mess to update now alas. The only real benefit I think is you can easily drop all of the source into an IDE set a define or two and use it.

You still have defines, you just restrict them to the .c or .cpp files.  Have a standard API-independent header.  Then have a .c/.cpp file for each platform that is guarded by a #define.  That way no platform specific stuff leaks out (in particular all the macros and stuff that often come along with platform headers).  Clean, very easy to extend, and easy to implement.  Though a truly independent header that handles all the bells and whistles can take a bit of time/effort.

Code:

#if defined(_WIN32)
//.. win32 code
#endif
#if defined(__linux)
//.. linux code
#endif
#if defined(__APPLE__)
//.. apple code
#endif

This way lies madness.  It does not scale well at all.  Separate source files for each platform with common headers are the way to go.

Look again at my source to see how I did this.

I must concur.

I've run into that issue before.  I believe it has something to do with the WinProc needing to be built in the executable rather than in a library...maybe?  I can't remember

I've been able to put the WinProc function in a library and statically link it.  Never tried with a dll and dynamic linkage though.  Perhaps the library has different compiler options that don't mesh with the main program?

I think you are not suppose to add the index at the end. The TEXCOORD with index at the end is used in DX9, in DX11 it is done a bit differently, but I don't recall how.
You can give any label you like(unless it's a special label). But something about the indices is different.
So you can have for instance float3 color: PERVERTEXCOLOR; if you like.

Quite possibly, but then how do you link from the vertex declaration to the vertex shader?  They even have the semantic index just for that from what I understand.  And it still doesn't explain the need for SV_POSITION in the pixel shader.

I've scoured the MSDN website but its not explained at all as far as I can tell.  Any ideas where I can find some real information on what I can, can't, and should do?

D3D11 ERROR: ID3D11DeviceContext::DrawInstanced: Vertex Shader - Pixel Shader linkage error: Signatures between stages are incompatible. Semantic 'TEXCOORD' is defined for mismatched hardware registers between the output stage and input stage. [ EXECUTION ERROR #343: DEVICE_SHADER_LINKAGE_REGISTERINDEX]

I think it explains everything? You didn't successfully link the shader because of mismatched input and output. You can't rely on any result when compilation or linkage fails.

Then what wasn't linked?  The only time I get that error is when SV_POSITION is not defined in the pixel shader.  When it is defined no errors.  I have no use for SV_POSITION in the pixel shader, why is it required?  Not to mention SV_POSITION in the vertex shader means something completely different than SV_POSITION in the pixel shader.

Vertex shader looks like:

Code:

// *************************************************************************************
// ShaderTest1_VS.hlsl
//
// Ryan Boghean
// Feb 01, 2013
//
// *************************************************************************************

#include "LinearAlgebra.hlsl"



// ---------------------------------------------------------------------------------------------------------------------------
// constants/types
// ---------------------------------------------------------------------------------------------------------------------------

// ----- constants -----
cbuffer CameraConstants : register(b0) {

// perspective constants
float4 vp_rect; // x0, y0, x1, y1
float4 vp_dim; // width, height, width/height, 0.0f
float4 vp_z_values; // (x,y) = viewport z, (z,w) = perspective z
float4 vp_fov; // (horizontal fov, vertical fov, 0.0f, 0.0f)

// camera constants
float4 cam_origin; // camera origin point
float4 cam_lookat; // camera look-at point
float4 cam_up; // camera up vector

// matrices
float4x4 persp_matrix; // perspective matrix transformation
float4x4 cam_matrix; // camera matrix transformation
float4x4 cam_persp_matrix; // combined perspective/camera transformation matrix
};


// ----- structures -----
struct VIn {

// vertex data
    float4 position : POSITION;
float4 tex : NORMAL0; // texture coords in object space
    float4 color : NORMAL1;

// instance data
float4 offset : NORMAL2;
float4 dim : NORMAL3;
float4x4 transform_matrix : TEXCOORD0;
float4x4 transform_inverse : TEXCOORD4;
};

struct VOut {
    float4 position : SV_POSITION;
float4 tex : TEXCOORD0; // texture coordinates in object space
float4 normal_x : TEXCOORD1; // world x-axis in object space
float4 normal_y : TEXCOORD2; // world y-axis in object space
float4 normal_z : TEXCOORD3; // world z-axis in object space
float4 ray : TEXCOORD4; // ray vector in object space
float4 rayi : TEXCOORD5; // ray inverse vector in object space
    float4 color : TEXCOORD6;
};



// ---------------------------------------------------------------------------------------------------------------------------
// VShader
// ---------------------------------------------------------------------------------------------------------------------------

// ----- VShader -----
VOut VShader (VIn input) {

// calculate inverse/transpose of the transformation matrix
float4x4 transform_matrix = input.transform_matrix;
float4x4 transform_inverse = input.transform_inverse; // used to transform ray into object space
float4x4 transform_inverse_transpose = transpose(transform_inverse); // used to transform normals

// calculate position and ray
float4 pos = mul(transform_matrix,input.position); // transform vertex into object space
float4 ray = mul(transform_inverse, pos - cam_origin ); // transform ray into object space
float4 rayi = float4(1,1,1,1) / ray; // ray inverse
pos = mul(cam_persp_matrix,pos); // transform vertex into clip space

// calculate normals
float4 normal_x = mul(transform_inverse_transpose, float4(1,0,0,0) );
float4 normal_y = mul(transform_inverse_transpose, float4(0,1,0,0) );
float4 normal_z = mul(transform_inverse_transpose, float4(0,0,1,0) );

// done
    VOut output;
    output.position = pos;
output.tex = input.tex;
output.normal_x = normal_x;
output.normal_y = normal_y;
output.normal_z = normal_z;
output.ray = ray;
output.rayi = rayi;
    output.color = input.color;

    return output;
}

Pixel shader looks like:

Code:

// *************************************************************************************
// ShaderTest1_PS.hlsl
//
//
// Ryan Boghean
// Feb 01, 2013
//
// *************************************************************************************

struct PIn {
float4 position : SV_POSITION;
float4 tex : TEXCOORD0; // texture coordinates in object space
float4 normal_x : TEXCOORD1; // world x-axis in object space
float4 normal_y : TEXCOORD2; // world y-axis in object space
float4 normal_z : TEXCOORD3; // world z-axis in object space
float4 ray : TEXCOORD4; // ray vector in object space
float4 rayi : TEXCOORD5; // ray inverse vector in object space
    float4 color : TEXCOORD6;
};


// ----- pixel shader -----
float4 PShader (PIn input) : SV_TARGET {
    return input.color;
}

//float4 PShader (float4 position : SV_POSITION, float4 color : TEXCOORD6) : SV_TARGET {
//    return color;
// }

I get no errors on compile.  In the case where SV_POSITION is not used I get a warning:

D3D11 ERROR: ID3D11DeviceContext::DrawInstanced: Vertex Shader - Pixel Shader linkage error: Signatures between stages are incompatible. Semantic 'TEXCOORD' is defined for mismatched hardware registers between the output stage and input stage. [ EXECUTION ERROR #343: DEVICE_SHADER_LINKAGE_REGISTERINDEX]

Came across a funny D3D11 error that has me kinda puzzled.

I have a very simple vertex and pixel shader that in combination with some otherwise simple code shows a cube on screen (usual 'hello world' type app as I play around with changes from D3D9 to D3D11).

Normally my pixel shader input struct is my vertex shader output struct, but to try some stuff out the pixel and vertex shaders are in different files with different inputs/outputs.  Now the vertex shader outputs match up with the pixel shader inputs, but sometimes if they are not identical, there are errors... sometimes...

For example:

Code:

float4 PShader (float4 position : SV_POSITION, float4 color : TEXCOORD6) : SV_TARGET {
   return color;
   }

renders fine while:

Code:

float4 PShader (float4 color : TEXCOORD6) : SV_TARGET {
   return color;
   }

does not render fine (colors are all screwy).  Playing around with different structure layouts likewise yielded equally confusing results.  I was under the impression that as long as the values going in and out of the semantics matched up you were fine (ie. if u sent a normal in TEXCOORD2, and retrieved the normal in TEXCOORD2, regardless of how it was defined all was fine).  But this doesn't seem to be the case.  For example, in the code snippets above why does "float4 position : SV_POSITION" need to be defined, if it is not going to be used?

There's something about this I'm not understanding.

REAL programmers use http://en.wikipedia.org/wiki/Brainfuck.  The rest are all amateurs.

Fair enough, if that's the way everyone does it, and thx for the replies.  It always baffles me how a multi billion dollar industry is built on such poorly designed APIs.

OpenCL as well as OpenGL have a notion of "mapping memory" it doesn't allow concurrent access from cpu and gpu though. Mapped in that case means "mapped for cpu" so trying to launch a kernel/draw call on mapped memory is probably either an error or undefined behavior.

Yes I understand that.  Cuda, if I remember correctly, (its been a while since I used it) has a notion of mapped memory space that can be directly accessed by both the CPU and GPU at the same time.  Different from the OpenGL/OpenCL/DirectX mapping notion.

I don't know about OpenCL but I'm pretty sure cuda has memory mapping, so both the CPU and GPU can read/write sections of memory at the same time (which obviously can lead to sychronization issues if you're not careful).