Is this possible on the vertex shader.

Is it possible to index between vertices on the vertex shader in order to dynamically offset the output position, it doesn’t seem to be doable.

What shader stage would this be possible in or is it simply not possible in any shader stage.

Considering this is a single very average rectangle quad and between the vertices i want to change the x coordinate by offseting the x position depending on a array look up.

VertexShaderOutput MainVS(in VertexShaderInput input)
{
    VertexShaderOutput output = (VertexShaderOutput)0;
    float4x4 vp = mul(View, Projection);
    float4 pos = mul(input.Position, World);

    // more then 10 values in the array doesn't work only looks at the first and second indexs.
    pos.x += WorldLights[pos.y].x;  

    pos = mul(pos, vp);
    output.Position3D = pos;
    output.Position = pos;
    return output;
}

float4 MainPS(VertexShaderOutput input) : COLOR
{
    float4 col = float4(0.0f, 0.0f, 0.0f, 0.0f);
    float depthMag = input.Position3D.z;
    col.r = depthMag;
    col.g = 1.0f;
    col.b = 1.0f;
    col.a = 1.0f;
    return col;
}

in game 1

public static Vector2[] WorldLights = new Vector2[10]
        {
            new Vector2(100, 0),
            new Vector2(0, 0),
            new Vector2(400, 300),
            new Vector2(400, 300),
            new Vector2(400, 300),
            new Vector2(400, 300),
            new Vector2(400, 300),
            new Vector2(400, 300),
            new Vector2(400, 300),
            new Vector2(400, 300)
         };

I have three ways i can get around the issue but if i could somehow change the interpolation via a index by telling the vertex shader to evaluate the index in the interpolation that would be optimal.
All the other solutions come with some sort of price and or are more expensive and less efficient.

I don’t quite understand what you are trying to do. Do you want the edges to not be straight? That would require you to tessellate the mesh, which can not be done from shaders in the versions Monogame are compatible with.

As long as your target is DX11 and SM4+ you can use SV_VertexID if all you need is the index. Mojoshader doesn’t understand it for targeting GL (SM3 only IIRC).

If you need to read actual VBO data Monogame doesn’t support the modern binding model that came along with SM4 so you’ll have to pump it into an image since shader resource bindings are orphan-uniforms+textures, thus unaware of SRVs, buffer-backed textures, etc.

Ideally what id like to do is gain control over the rasterization output position between two vertices on the vertice shader. In order to manipulate the depth write z buffer position that is being compared algorthmically.

Though i pretty much gave up on that already vtf wouldn’t help in this case.

Yeah, you can’t do that without tessellation or geometry shader (pretty sure that you mean you want to manipulate the actual edge and not just interpolation modifiers [like noperspective/nointerpolation] - since you could do those in texture to a degree).

If you need to bypass fx and use hlsl cso’s and build geom or tess shaders - that’s an option. Not sure how this would be done with OpenGL shaders tho – hypothetically one could have device support detected at runtime and pre-compile for target device on first run if the file doesn’t exist and then do the same sort of thing. I was planning on figuring out how to set it up for OpenGL too but I’m overworked lately and have no free time.

Ya i sort of side stepped the initial problem with a dual pass vertex shader.

but…

Unfortunately one final problem associated to the same thing appeared at the very end anyways. This time however i could see no way around it.

Below depth cones that don’t interpolate vertice to vertice throw off the distance, as im purposely throwing either the start or the end vertex out of bounds for a special case.
The shown artifact here can be seen as a arc from a point light in the grey box extending two arc’ed cones out above the box. Unfortunately while i can mitigate it i can’t properly fix it.

To make it work properly i would have to be able to create a vertice at a specific position between two vertices on the shader on the fly, to fix it which would allow me to rework the original double pass solution, into a single pass as well.

The only other option i can think of is probably not worth trying. Which is to use setdata to create a depth map per frame, while set data has decent speed and this would in other ways simplify things. Doing this computationally cpu side kinda defeats the whole objective.

So on this idea im going to admit defeat.