# Vertex Texture Fetch

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

## Recommended Posts

Yes, I am aware that there have been threads on this topic before. I've read each one individually, and none have given me any information I haven't already found in the DirectX documentation, amongst the samples, MSDN or the internet. I have a render target with a A32B32G32R32F surface format, one of the two formats my system supports for VTF (the other is R32F). This render target is filled with Perlin noise, which ranges from 0 to 1.0. The vertex buffer I am using contains a grid of vertices, the positions ranging the texture coordinates, i.e. a square from (0, 0) to (1.0, 1.0). My vertex shader takes the position of each vertex, and throws it into the jaws of texldl. It uses the noise contained within the vertex texture to reposition the vertex to a point within the square from (-1.0, -1.0) to (1.0, 1.0). The idea is that after executing the shader, the vertices are more or less randomly distributed within that region. Here is the scene code, which follows the general method used by bits of code I've found on the net:
// worldViewProj is set
InitTransforms();

// Set the render target to D3DVERTEXTEXTURESAMPLER0 = 257
// I suspect that the problem lies somewhere here
device->SetTexture(257, renderTarget);

device->SetStreamSource(0, vertData, 0);
device->VertexFormat = CustomVertex::PositionColored::Format;
device->DrawPrimitives(PrimitiveType::PointList, 0, 995328);

Here is the vertex shader, written in assembly:
vs_3_0

def c4, 2.0, -1.0, 0, 0

dcl_position v0
dcl_color v1
dcl_2d s0
dcl_position o0
dcl_color o1

texldl r0, v0, s0
// Move the vertex
// Multiply by worldViewProj
m4x4 o0, r0, c0
// Use the same colour
mov o1, v1

Running this gives me a screen void of vertices (no errors!). In fact they don't seem to be any anywhere, even though there 995328. I know for certain that the render target is filled with Perlin noise. If I skip texldl, then I get my square grid of vertices (coloured white, because that's how I initialised them):
vs_3_0

def c4, 2.0, -1.0, 0, 0

dcl_position v0
dcl_color v1
dcl_2d s0
dcl_position o0
dcl_color o1

// texldl r0, v0, s0
// Skip, use the original data instead
mov r0, v0
// Move the vertex
// Multiply by worldViewProj
m4x4 o0, r0, c0
// Use the same colour
mov o1, v1

I also tried leaving them in this grid, and using the vertex texture data to colour the vertices, which should just give me the same result as if I had put the texture it normally (I know this is should be done in a pixel shader, except this is a test of the vtf). As shown here:
vs_3_0

def c4, 2.0, -1.0, 0, 0

dcl_position v0
dcl_color v1
dcl_2d s0
dcl_position o0
dcl_color o1

// texldl r0, v0, s0
// Skip, use the original data instead
mov r0, v0
// Move the vertex
// Multiply by worldViewProj
m4x4 o0, r0, c0
// Use the colour from the vtf
texldl r0, v0, s0
mov o1, r0

This gives me a black square (as opposed the Perlin noise), leading me to believe that my texture is going astray on it's way to the vertex shader. The matrix worldViewProj passes through to the shader perfectly fine. I've tried to share as much of my own efforts as possible, and also pre-empt as many responses as possible. I would very much appreciate any help on this, as it's been causing me many problems. Thanks in advance. Edit: Also, I have an NVIDIA Quadro FX 3500 graphics card, vtf is fully supported. [Edited by - Mouldy C Cortex on February 5, 2008 7:11:52 AM]

##### Share on other sites

If outputing your perlin noise texture as the color gives you just black, that could be your problem. If the information in the texture is < 0, you wouldn't see anything on the screen when you use this data to move your vertices. Again, PIX will let you look at the textures you've set as inputs to the pipeline to verify they are correct.

neneboricua

##### Share on other sites
I can't tell you what the problem is, but I can suggest some things that might help you find it.

Put Direct3D into debug mode using the control panel app, if you haven't already. This will help find D3D errors.

(BTW, why are you using "257" instead of the proper constant?)

Try a much simpler example, just one vertex and a simple texture with a single value for all pixels.

You can output the value of the vertex to the pixel shader, and draw it there. This way you'd be able to see what value you're getting.

Try using R32F and see if that works any better.

##### Share on other sites
Texldl requires that you provide the level of detail as w component in the source register. As you use the position as coordinates w may be 1. Maybe this is the reason. You should try to force w to 0.

##### Share on other sites
Lots of thanks, PIX certainly helped - I fixed up a few texture issues which I wasn't aware of.

I've used 257 since this is managed C++ code, and there is no D3DVERTEXTEXTURESAMPLER0 constant. By the way, I get the same bad results if I use 0.

My texture has only level of detail, so the LOD argument in the w component shouldn't make a difference, nonetheless I've reintroduced a line of code into my shader to cover this.

I've also set both the z and w components of the vector which I retrieve from texldl to 1.0.

Now I have a single point at (-1.0, -1.0), regardless of the now constant colour in the texture. This reinforces my idea that the problem lies somewhere with SetTexture.

I will continue to search for a solution.

Edit: I found this: http://www.robertwrose.com/2005/05/vertex-texture-sampling-notes.html

It turns out that I had created my device with CreateFlags::SoftwareVertexProcessing, which is the only flag I've even used, when I needed CreateFlags::HardwareVertexProcessing (CreateFlags::MixedVertexProcessing is also an option, which specifies both). I have looked into these flags before, but they're not very well documented, and it didn't seem to matter... until now.

I'm just glad it works! Thanks to everyone, the help was much appreciated.

[Edited by - Mouldy C Cortex on February 6, 2008 2:18:32 AM]

1. 1
2. 2
Rutin
20
3. 3
khawk
16
4. 4
A4L
14
5. 5

• 12
• 16
• 26
• 10
• 11
• ### Forum Statistics

• Total Topics
633756
• Total Posts
3013708
×