[Feature request] support vertex texture fetch on GL3 / DX10+

[MonkeyFirst]

"Ability from the box" that allow you create textures for vertex fetch still not haven't.

Actually, i'm may to imagine how to tweak engine for supporting manual created VTF-textures on GL-Renderer. But currently i'm use DX11-Renderer and absolutely don't know how to create VTF texture in DX11.

But also i think what this must be a standard feature for both renderers and not user's tweaks of renderer.

[friesencr]

On my voxel renderer that I am working on I made a texture buffer object that take in an index buffer.

https://github.com/friesencr/Urho3D/blob/voxel/Source/Urho3D/Graphics/OpenGL/OGLTextureBuffer.h

I just hacked mine in to get it to work because I didn't feel like setting up all the datatypes.
https://github.com/friesencr/Urho3D/blob/voxel/Source/Urho3D/Graphics/OpenGL/OGLTextureBuffer.cpp#L118

This change also broke the name 'IndexBuffer' since it wasn't an index buffer anymore.

[MonkeyFirst]

Yours vtf hacking more clever then mine, and may be used as std method for both renders, i guess
For GL i'm just change format if vft flag is set
in OGLTexture2D.cpp - bool Texture2D::SetData()

graphics_->SetTextureForUpdate(this);

bool wholeLevel = x == 0 && y == 0 && width == levelWidth && height == levelHeight;
unsigned format = GetSRGB() ? GetSRGBFormat(format_) : format_;

if (vtf)
{
    format = GL_RGBA16F;

    //format_ = GL_RGBA16F_ARB;
}

then I just load manually special prepared image and put it in proper TU for special shader

[cadaver]

I have pushed some changes to master that were necessary for D3D11 VTF to work properly. Otherwise OpenGL worked out of the box. I tested with the Terrain shader on fairly recent Nvidia & Intel hardware, and simply made it read the weight texture (which is plain RGBA8) in the VS and pass it directly to PS.

If you need the texture to be RGBA16F, please set that format already in Texture2D::SetSize(), then set the data appropriately, though I understand you can't use a load from a regular Image in that case. I would rather not add a VTF boolean flag. Is what you're doing necessary for older hardware?

Terrain GLSL code:

#include "Uniforms.glsl"
#include "Samplers.glsl"
#include "Transform.glsl"
#include "ScreenPos.glsl"
#include "Lighting.glsl"
#include "Fog.glsl"

varying vec4 vColor;

uniform sampler2D sWeightMap0;

void VS()
{
    mat4 modelMatrix = iModelMatrix;
    vec3 worldPos = GetWorldPos(modelMatrix);
    gl_Position = GetClipPos(worldPos);
    vec2 texCoord = GetTexCoord(iTexCoord);
    vColor = textureLod(sWeightMap0, texCoord, 0);
}

void PS()
{
    gl_FragColor = vColor;
}

Terrain HLSL code (D3D11 only):

#include "Uniforms.hlsl"
#include "Samplers.hlsl"
#include "Transform.hlsl"
#include "ScreenPos.hlsl"
#include "Lighting.hlsl"
#include "Fog.hlsl"

Texture2D tWeightMap0 : register(t0);
SamplerState sWeightMap0 : register(s0);

void VS(float4 iPos : POSITION,
    float3 iNormal : NORMAL,
    float2 iTexCoord : TEXCOORD0,
    out float4 oColor : TEXCOORD0,
    out float4 oPos : OUTPOSITION)
{
    float4x3 modelMatrix = iModelMatrix;
    float3 worldPos = GetWorldPos(modelMatrix);
    oPos = GetClipPos(worldPos);
    float2 texCoord = GetTexCoord(iTexCoord);
    oColor = Sample2DLod0(WeightMap0, texCoord);
}

void PS(float4 iColor : TEXCOORD0,
    out float4 oColor : OUTCOLOR0)
{
    oColor = iColor;
}

Please close the issue if this was satisfactory.

[MonkeyFirst]

Is what you're doing necessary for older hardware?

How much older? I suppose that older ATI 9500 support or GFX 7600 support VTF each in own way, on old GL and DX9.

Anyway, maybe also add some function to engine that allow do check, something like - bool checkSupportingVertexTextureFetch(format) ?

[cadaver]

There seemed to be vendor-specific rules that are rather complex (including things like what filter settings and mipmapping you're using), especially for the old hardware, so if that can be avoided I'd rather not go there.

Maybe you could assume that VTF is available (with sane formats) if you're able to run GL3 / D3D11?

I will however verify that setting floating point texture data works on all APIs.

[MonkeyFirst]

I will however verify that setting floating point texture data works on all APIs.

Actually i'm don't remember why am use GL_RGBA16F texture it really was RGBA8(*.tga file) with baked noise in each channel for this fx

but am set for GL to convert it internally into floating.

[boberfly]

Heh I restarted my GL4 patches again locally friesencr and made a TextureBuffer class very similar to yours, except I've also made a GPUBuffer class which is designed to house all the different BO's and setting them with an enum in SetSize, same for DX11.

Cadaver would you accept stuff like the extra shader stages in a patch as long as it doesn't break GL3.2/ES 2.0 and supports DX11, for instance, by having appropriate fallbacks or flags?

MonkeyFirst: Fancy explosion, I saw the article to make that one with a noise function... :)

[cadaver]

Yes, that's very much my hope to receive things like tessellation / geometry shaders as contribution because I don't presently have time / expertise to implement them (and any related API) myself.

Naturally, when something as big as that is contributed the hope / expectation is that you then continue the development and fixing of possible issues, so that it doesn't become a commit-and-run type operation, resulting in increased amount of burden to the core contributors (or alternatively: unmaintained code), which has been somewhat of a danger as Urho3D has grown.

[boberfly]

Fair call on the maintenance burden, it might make sense to keep it in another branch for now as I'm worried that I wouldn't have the time to maintain it. Although Sinoid on the forums is also doing similar things, so it might make sense that we all collaborate so we don't do duplicate efforts.

'No expertise' and 'Cadaver/Lasse' don't go together in my head at all, btw... :P but yeah, lack of time is always a killer.

[MonkeyFirst]

Fancy explosion, I saw the article to make that one with a noise function... :)

Yeah, but it so far from finished fx

I trying last master with VTF changes for DX11 and found what it not working. The shader compiled is fine. Moreover I may change clip factor of pixels in material editor, but I guess what VS shader do not read texture.

LitSolidVTF.hlsl
http://pastebin.com/gZBbKci2

Samplers.hlsl
http://pastebin.com/muZuXk9m

Uniforms.hlsl
http://pastebin.com/F0ksaJRz

Also am add setting for displace texture in xml file

-texture-
-address coord="u" mode="clamp" /-
-address coord="v" mode="clamp" /-
-address coord="w" mode="clamp" /-
-filter mode="nearest" /-
-mipmap enable="false" /-
-texture-

it placed into NormalMap TU (only this map used for VTF in VS shader)
and this ramp texture placed to DiffMap TU

so i'm think the main thing to solve this is there
http://stackoverflow.com/questions/19091415/vertex-texture-fetch-always-return-0

maybe also need add parameter in xml file something like
-vertexfetch = "true" and if this are presented in xml then renderer push texture to VSSetSampler and then also push this map in PSSetSampler because some times need read the same map in both shader

[MonkeyFirst]

oh, I found what in void Graphics::PrepareDraw() (D3D11Graphics.cpp) some textures are also established for VS shader( with PS) this firstDirtyTexture_... is this textures from material TU-slots or this for other use?

[MonkeyFirst]

I suppose that i found some new issue. And that's why my VTF not working on DX11.
If in VS and PS constant buffers ( MaterialVS / MaterialPS) we create a uniforms with the same name in both it's actually will be working only in one of them, and only one of they grab values from material editor (user uniform section).

Now am use uniforms with various names and common uniform(for VS/PS) i'm put in VS(MaterialVS) and then pass they into PS shader through VS-shader output values + semantic.

In this case I see some displacement, but now have other problems with ramp texture.

[MonkeyFirst]

I'm don't know why but this VTF works only with directional and spot lights

and I got this with point light

how type of light may affect on this?

DiffVTF.xml
-technique vs="LitSolidVTF" ps="LitSolidVTF" psdefines="DIFFMAP"-
-pass name="litbase" -
-technique-

litSolidVTF.hlsl
http://pastebin.com/63rUnNx9
Uniforms.hlsl
http://pastebin.com/AcQPfmqP
Samplers.hlsl the same as in master

[cadaver]

The dirty textures range should be set whenever SetTexture() is called in D3D11, so the end result should be that the exactly same textures in same units are available for both VS & PS. I'll investigate the difference with point lights, it seems odd.

@boberfly: that's one of the tough parts writing a graphics engine, one should update knowledge regularly. In this case I haven't used geometry shaders, tessellation, or compute, which, in the end, I guess ties back to the lack of time :)

[cadaver]

With the shader you provided, I'm not able to make it behave differently under different lights. All CBuffer parameters seem to be working as expected.

I sometimes have seen a situation where defining VS outputs & PS inputs in different order wreaks havoc in the compiled D3D11 shader, for example defining COLOR0 before TEXCOORD0 in VS and COLOR0 after TEXCOORD0 in PS, so make sure the order is same. The point light uses different texcoord inputs/outputs than the others.

If you want me to investigate further, please provide all your current data (shader code, material, technique, textures), that produces the light issue, in a zip archive or similar to make sure we're using the same data.

[MonkeyFirst]

Yes you're right it was an order, but strange my out/in-put variable placed in same position in both shaders VP and PS and out side any define group.
now I just make upper my value in both shaders, and placed it under oWorldPos in VS and iWorldPos in PS and now it works fine. This need to be documented in help for shaders, because not all knows this.
And am close this issue for a while