• Advertisement
Sign in to follow this  

Getting data from multiple vertex data

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'm trying to write a 2D map editor. It is based on triangles. The problem I have is drawing the selection. Here is how it should look like when I select one vertex:
[attachment=13016:selection.png]

What I have is Triangle class which creates a vertex buffer where all the triangle vertex positions, colors and texture coordinates are. I have a separate class where I store the data for the selection. It has a stl map which maps two integers (vertex indices, lower first) to a structure which contains two bool values to decide if the vertices are selected or not. Now all I need is a way too use that information too draw the edges like in the picture. So for every entry in that map I want to draw a line which gets the positions of the vertices from the vertex buffer of the Triangle class and the information whether or not the vertices are selected from e.g. another vertex buffer in the Selection class. The problem is that I don't know how or if it is possible to bind two vertex buffer at once. If anyone knows or can think of a better way to do this please tell me.

Oh, the picture is not exactly what I want. In my case there should be a third half selected edge that goes down from the selected vertex. Edited by Maxjen

Share this post


Link to post
Share on other sites
Advertisement

The kind of primitive is not encoded in the VBO directly but given as argument in the glDraw* routines. You can of course use the same VBO for rendering triangle faces followed by rendering lines of the same mesh. All you need is a separate index buffer (IBO) for the lines, although it is usually a good thing to draw the faces using indices, too. Then the latter IBO addresses the vertices in the VBO in a face manner, while the former one does so in a line manner.

Share this post


Link to post
Share on other sites

If you mean you want 2 buffers, the vertices, and lets say colors to tell you the color of the vertex (you only need a boolean or something like that but i thought it would be nice to be able to use different colors etc. for other things) you can probably do it using a VAO

 

Im not perfectly familiar with using OpenGL though so it might be possible without one too.

Share this post


Link to post
Share on other sites

[quote name='Waterlimon' timestamp='1356881440' post='5015759']
If you mean you want 2 buffers, the vertices, and lets say colors to tell you the color of the vertex (you only need a boolean or something like that but i thought it would be nice to be able to use different colors etc. for other things) you can probably do it using a VAO
[/quote]

Indeed is it possible to pass the geometric vertex attributes in one VBO (still sticking to VBOs here because the OP mentioned them explicitly) and the color attribute in another one, assembling them on the GPU to yield in the full featured vertex. This is more a question of how the selection is encoded when sighted from the GPU side. For example, the selection can be processed on the CPU in a way that writes the color in dependence to the selection state into the 2nd VBO. This would allow to load just the color to the graphics card instead of the entire vertex data. However, whether this makes sense depends on the purpose of the selection: In an editor it is probable that the geometry is changed on the selected vertices. Hence loading the geometry as well may be done anyway, so that splitting into 2 VBOs may introduce needless work.

Share this post


Link to post
Share on other sites

If you mean you want 2 buffers, the vertices, and lets say colors to tell you the color of the vertex (you only need a boolean or something like that but i thought it would be nice to be able to use different colors etc. for other things) you can probably do it using a VAO

 

Indeed is it possible to pass the geometric vertex attributes in one VBO (still sticking to VBOs here because the OP mentioned them explicitly) and the color attribute in another one, assembling them on the GPU to yield in the full featured vertex. This is more a question of how the selection is encoded when sighted from the GPU side. For example, the selection can be processed on the CPU in a way that writes the color in dependence to the selection state into the 2nd VBO. This would allow to load just the color to the graphics card instead of the entire vertex data. However, whether this makes sense depends on the purpose of the selection: In an editor it is probable that the geometry is changed on the selected vertices. Hence loading the geometry as well may be done anyway, so that splitting into 2 VBOs may introduce needless work.

But if you keep the line drawing and vertex drawing in separate buffers, wouldnt that allow you to use the same vertex position buffer for the triangles AND the lines?

Because id imagine if they are interleaved, you would either need 2 copies of the vertex position, 1 with line data mixed in, or you would need to keep the line data there even when youre not using it (not much of a problem probably though)

Share this post


Link to post
Share on other sites

[quote name='Waterlimon' timestamp='1356882893' post='5015765']
...

But if you keep the line drawing and vertex drawing in separate buffers, wouldnt that allow you to use the same vertex position buffer for the triangles AND the lines?
Because id imagine if they are interleaved, you would either need 2 copies of the vertex position, 1 with line data mixed in, or you would need to keep the line data there even when youre not using it (not much of a problem probably though)
[/quote]

It is also possible when the vertex data are not separate (which seems ATM be the case when looking at the OP). The problem with discussing this is that we don't know so far how drawing is actually done.

 

For sure, a clean way under the condition of not replicating data would be to use 3 VBOs (1 with the data shared between face and line drawing, 1 with the data used for face drawing only, and 1 with the data used for line drawing only), and 2 IBOs (1 for face drawing and 1 for line drawing). On the other hand there is the possibility to ignore data passed in, at least easily when using shader scripts.

 

We don't know the frequency of selections, the frequency of alterations to the vertex data, the amount of vertex data (but this is probably relatively small-sized because the OP mentioned a 2D map editor), and how drawing is performed, but I assume that it is possible performance-wise that the entire vertex data is updated on each iteration.

 

BTW: To go to the extremes, it is also possible to draw the faces and lines in a single pass by using appropriate shader scripts. For each pixel when being computed in the fragment shader, one can determine the distance from the edge of the face and use it to decide whether to pass the face color or the line color to the framebuffer. However, this all is speculative as long as the OP doesn't tell / ask for more ;)

Share this post


Link to post
Share on other sites

Though i wouldnt suggest doing it that low level.

 

What if you want to make the game objects out of multiple triangles for some technical reason?

 

I think you should instead make a higher level "triangle" object and use that data for the line drawing, so that you dont even need to render the triangles if you dont want to, isntead of relying on the triangle rendering data.

Share this post


Link to post
Share on other sites

[quote name='Waterlimon' timestamp='1356885784' post='5015779']
Though i wouldnt suggest doing it that low level.
 
What if you want to make the game objects out of multiple triangles for some technical reason?
 
I think you should instead make a higher level "triangle" object and use that data for the line drawing, so that you dont even need to render the triangles if you dont want to, isntead of relying on the triangle rendering data.
[/quote]

I don't understand. What "low level" do you mean?

 

If you meant "drawing faces and lines in a single pass": I would not call this low level (I would not suggest it for the given problem though, at least not without having more informations). First, the method is in no way limited to a single triangle. Second, it doesn't suffer from z-fighting (what is a simple to solve problem here because of the use case in a 2D map, but you mentioned "game objects" where in general z-fighting is a problem when doing  multi-pass drawing). Third, for drawing you ever have the need to come to a structure that can be used by OpenGL (in this case), and this is ever "low level" so to say; whether the editor manages the map data in addition in a more sophisticated structure is another question, but the OP especially targeted drawing.

Share this post


Link to post
Share on other sites

I meant that the line drawing shouldnt perhaps be so strongly tied with the rendering of the triangles.

 

Its a 2D map editor and not a mesh editor, so i would imagine that some day OP might face a situation where he needs multiple triangles for some more complex effect, but wants it to act like a single triangle.

 

So it might make more sense to have a more abstract representation for the triangles, and then the rendering of triangles, and then the rendering of the lines, which is based on the abstract representation of the triangles and not the rendering of them.

 

Performance shouldnt be a problem for a 2D map editor, but flexibility/extensibility is probably important.

Share this post


Link to post
Share on other sites

Notice please that the suggested method of using 2 IBOs and 2 passes allows for drawing with different line styles, including to elide edges as well. There is neither a need to use all attributes of a vertex nor the need to use all vertices listed in a VBO. It just allows for re-using vertex positions.

 

Using the one-pass method is, as already said, an extreme solution, nevertheless able to fulfill the given requirements of the OP. I don't suggest it but have mentioned it to demonstrate that splitting vertex data is not needed at all. For sure, if the requirements are changed afterwards, any solution working so far may break then. I think that the suggested solution is in accordance with your thoughts of a flexible enough method, just to make the chance of breaking it less probable.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement