Vbo index in vertex shader

Is there any way to get the current index from within the vertex shader?

as a simple example:

say we have an array with 8 values.
float vboarray[8]

These get passed to gl as a vbo array.

in the vertex shader, I would like to be able to identify the index of the shader.

ie.

main(){

glPosition.x = getPositionX(currentIndex);
glPosition.y = getPositionY(currentIndex);
glPosition.z = getPositionZ(currentIndex);

}

I’m implementing a LOD that has tiled (sort of) hightmaps, and would like to avoid sending xyz coords. I would like to send just Z and one xy per tile, the rest of the coords in the tile would calculate their xy based on the index and the xy for the tile.

VBOs are a particular method of sending data to the pipeline. There are other methods as well, like immediate mode, draw arrays, VARs etc. In short, no, there is no way and it would be no good either.

Originally posted by Zulfiqar Malik:
VBOs are a particular method of sending data to the pipeline. There are other methods as well, like immediate mode, draw arrays, VARs etc. In short, no, there is no way and it would be no good either.
I understand what VBO’s are. Let me explain why this would be good. If you are sending your data in a vbo array then you can also send lots of information in the implied structure of the array without sending extra data. ie. if you store your height map in this fashion:

0, 1, 2, 3, | 16, 17, 18, 19,
4, 5, 6, 7, | 20, 21, 22, 23,
8, 9, 10, 11,| 24, 25, 26, 27,
12, 13, 14, 15,| 28, 29, 30, 31,

32, 33, 34, 35,| 48, 49, 50, 51,
36, 37, 38, 39,| 52, 53, 54, 55,
40, 41, 42, 43,| 56, 57, 58, 59,
44, 45, 46, 47 | 60, 61, 62, 63,

If you are doing a LOD then you can send contigious portions that represent a tile of data
to the vertex shader.

If the shader has knowledge of the index, then it can calculate some interesting things like x,y position without having to send the x,y coordinates.

So you want to have the indices?
It’s not available.

I’m implementing a LOD that has tiled (sort of) hightmaps, and would like to avoid sending xyz coords. I would like to send just Z and one xy per tile, the rest of the coords in the tile would calculate their xy based on the index and the xy for the tile.
I see but graphics card don’t have trouble processing vertices. Why assemble a vertex (XYZ) in a shader?

[b]Originally posted by amendol:

If you are doing a LOD then you can send contigious portions that represent a tile of data
to the vertex shader.

If the shader has knowledge of the index, then it can calculate some interesting things like x,y position without having to send the x,y coordinates.[/b]
i’m not sure… but wouldn’t the DX10 geometry shader give you this?

Originally posted by V-man:
[b]So you want to have the indices?
It’s not available.

[quote]I’m implementing a LOD that has tiled (sort of) hightmaps, and would like to avoid sending xyz coords. I would like to send just Z and one xy per tile, the rest of the coords in the tile would calculate their xy based on the index and the xy for the tile.
I see but graphics card don’t have trouble processing vertices. Why assemble a vertex (XYZ) in a shader?[/b][/QUOTE]This is for a Level of Detail system. I would like to be able to render a planet (and have many planets in the system) with an accuracy of about 1M. The planets are from real data, not made up… This makes for very large data. In trying to optimize, I have found that the most important thing is dealing with the data, and the less the better. I can get away with just a height per vertex if I had a “geometry processor”, but it is becoming apparent that I don’t:(

I’m fairly new to glSlang (not OpenGL). I haven’t found the geometry-shader-like functionality in the slang books, and this is being confirmed here. So it looks like my data will need to be more than 3 times as large.

So the question is: when do we get our GL geometry shaders!!??!!

I am not sure what exactly your problem is.
May be this could give you a little help:

You have a problem with sending a lot of X,Y,Z coordinates to your vertex shader (its too much)?
You think, you could “generate” X and Y out of Z or something like this, so you need only Z (one value [Z] in stead of three [X,Y,Z]).

Your Application have a bottleneck in sending so many different [X,Y,Z] and is slowed down by memory transfers (Vertices) into GL?

You could send always the same Vertex, so it will be no more bottleneck in memory transfers [vertex cache] or memory consumption.

But you have to send the [Z] too (as part of the only 1 Vertex or as uniform or vertex-texture or something else) to compute your full vertex [X,Y,Z] in the vertex shader that you need.

I never tried this, and its possible that this will slow down more than it would help.
But I know even with VBO’s a scene with many many millions vertices have mostly a bottleneck in memory transfers (another negative aspect: triangles will be very small [1-2 pixels] and this don’t like most of the graphic cards [quad pipes]).

Originally posted by Heady:
[b]I am not sure what exactly your problem is.
May be this could give you a little help:

You have a problem with sending a lot of X,Y,Z coordinates to your vertex shader (its too much)?
You think, you could “generate” X and Y out of Z or something like this, so you need only Z (one value [Z] in stead of three [X,Y,Z]).

Your Application have a bottleneck in sending so many different [X,Y,Z] and is slowed down by memory transfers (Vertices) into GL?
[/b]

For the LOD system the problem is this:
</font>[li]Think Google-Earth with higher detail.[/li]> [li]There are orders of magnitude more polygons than can be rendered by even todays best cards, or stored in system ram. [/li]> [li]<font size=“2” face=“Verdana, Arial”>The LOD needs to have a way of selecting sets of polygons to render based on distance of the eye. and manage these from:[/li]
Disk->userspace->gfx

I’ve come up with a system that stores the data as z values only, the X,Y can be calculated with very simple math using the index.

But. I don’t have an index, so I need to come up with a different scheme.

Thanks for your suggestion on texture lookups. That should work, but I’m not sure what kind of performance hit it would take.

I may just have to settle with xyz and an index array until GL 2.X

[b]

You could send always the same Vertex, so it will be no more bottleneck in memory transfers [vertex cache] or memory consumption.

But you have to send the [Z] too (as part of the only 1 Vertex or as uniform or vertex-texture or something else) to compute your full vertex [X,Y,Z] in the vertex shader that you need.

I never tried this, and its possible that this will slow down more than it would help.
But I know even with VBO’s a scene with many many millions vertices have mostly a bottleneck in memory transfers (another negative aspect: triangles will be very small [1-2 pixels] and this don’t like most of the graphic cards [quad pipes]).[/b]

Geometry shaders are not available so forget about it. If you have too much data, it’s a matter of managing memory because certainly, you won’t be displaying all those planets at high rez on screen. You could also make use of formats that save memory like signed short for vertices and normals.
You could use textures in vertex shaders for displacement. This can save you the z coordinate.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.