1

I am in a situation where I would like to use VAO/VBO to recycle the same vertexes and use indexes to speed up rendering.

All is fine, apart my textured models use UV coordinates and for the very same vertexes (approx >80%) I may end up having different UV coordinates based on which triangle I'm expected to be rendering (in fact, I'm using md2 models and textures).

This way of rendering was fine and dandy for good old immediate mode; now days, what is the best way to address this and render through VAOs/VBOs?
What comes to mind is to explode the triangles and create very large VBOs with repeated vertexes so that I can link the proper UV coordinate to each of the "same".

I have to say I don't like this... any idea?

Ps. For folks who don't understand the format: if you want to use texture mapping, I believe you have to use the custom UV coordinates based on the triangle you're rendering. Otherwise the texture colours are all messed up!

Emanuele
  • 1,265
  • 1
  • 10
  • 36
  • 1
    "*I may end up having different UV coordinates based on which triangle I'm expected to be rendering*" Um... why? – Nicol Bolas Apr 10 '16 at 17:18
  • @NicolBolas This is the md2 spec (Quake 1/2). In the good old days (I'm talking early 2000) the same vertex had different UV coordinates based on which triangle was being rendered to - in some cases even 4. As you can imagine with VAOs/VBOs you can only have one UV (AFAIK ofc :) and this simply doesn't work in a _compacted_ form. Check the link I provided for more info. – Emanuele Apr 10 '16 at 17:23
  • "*the same vertex had different UV coordinates based on which triangle was being rendered to - in some cases even 4.*" That doesn't explain *why* you want that. What purpose does that ability serve? Who cares if the MD2 format allows it or not? If it serves no useful purpose, you shouldn't use it. – Nicol Bolas Apr 10 '16 at 17:24
  • @NicolBolas Perhaps you don't understand... if I don't specify the multiple different UV coordinates the texture mapped object is all jumbled up. I *want* to use texture mapping and this is how texture mapping is defined! – Emanuele Apr 10 '16 at 17:26
  • If you split the geometries up in different arrays, position in one array, uv1 in one uv2 in another etc. you can just bind the ones you want (event bind subranges) in whatever combination you desire. – Tafuri Apr 10 '16 at 17:53
  • @Emanuele: I followed the link to the MD2 page and skimmed it. There does not appear to be *anything* on that page about the same vertex having multiple sets of texture coordinates. So what exactly are you talking about? Are you talking about the fact that the same vertex position may be used in different triangles with different texture coordinates? – Nicol Bolas Apr 10 '16 at 18:11
  • @tafuri It's not different textures, it's for the same one. What you suggest doesn't apply. – Emanuele Apr 10 '16 at 18:18
  • @nicolbolas That is the case: as written in the question the same vertex can be used in different triangles, and depending on the triangle it most likely have different UV coordinates within the same texture. – Emanuele Apr 10 '16 at 18:21
  • @Emanuele: I think you have a misconception about what a vertex is in OpenGL (and all the other rendering APIs). If you are using different texture coordinates, it will be by definition a different vertex. – derhass Apr 10 '16 at 18:21
  • @derhass I think not. In this case the same vertex is used to draw different triangles. Depending on the triangle it *will* have a different UV coordinate for the same texture. If you read the md2 format you'll see that the total UV in one model is greated than the vertexes, because tha same vertex can use a different UV depending on which triangle I'm rendering. I hope I'm wrong but I don't think so. Cheers. – Emanuele Apr 10 '16 at 18:27
  • @Emanuele: _nothing_ in the md2 format specification can change what a vertex is _in OpenGL_. The only relevant point where a concept you are mentioning is actually needed is texture seems - and it is usually a non-issue to just provide separte vertices for these cases. – derhass Apr 10 '16 at 18:32
  • @derhass Well, that's my question. How can I do that with VAO/VBO without *exploding* the repeated vertexes? Is there a way to specify index of UV together with index of vertexes? – Emanuele Apr 10 '16 at 18:34

1 Answers1

4

All is fine, apart my textured models use UV coordinates and for the very same vertexes (approx >80%) I may end up having different UV coordinates based on which triangle I'm expected to be rendering

Then they are different vertices. A vertex is the whole combination of all its attributes (position, normal, color, texture coordinates, etc.). If only one of these values is different you're dealing with an entirely different vertex.

datenwolf
  • 149,702
  • 12
  • 167
  • 273
  • Ok then, you're saying that by virtue of different UV coords the only solution is to duplicate the xyz values when their UV is different? No other way of compacting it via indexes? – Emanuele Apr 10 '16 at 18:39
  • @Emanuele: That is correct, you can't compact it further. In OpenGL, indexes can only refer to whole vertexes (XYZ + UV), you can't have separate XYZ and UV indexes. – Dietrich Epp Apr 10 '16 at 19:04
  • @dietrichep Thanks, please post it as an answer and I'll tag it. I couldn't believe that we still don't have a slution for this. What do modern engines? Do they expand or what other techniques do they use? – Emanuele Apr 10 '16 at 19:09
  • 1
    @Emanuele: There is a solution to this. The solution is to duplicate the XYZ data. I don't understand how this somehow "isn't a solution". If you are going to use separate indexes for UV and XYZ data, you'll end up with worse performance and extra memory usage, since the extra indexes will take up more memory than you save by deduplicating a couple hundred vertexes on a 10,000 triangle model. It will also totally thrash the cache. You can actually make it work if you really try, but... just duplicate the data. It's so much easier and faster. – Dietrich Epp Apr 11 '16 at 03:53
  • @dietrichepp Indeed, I hoped for a more compact way... But I'll explode the dataset. Cheers! – Emanuele Apr 11 '16 at 05:55
  • 1
    @Emanuele: The paradox thing about GPUs (as I recently learnt at a workshop hosted by the AMD Radeon Technology Group) is, that compactifying data is poisoning performance and you can often gain tremendous increases in performance by expanding data to the GPUs native data types (like using 32 bit values for memory accessed through samplers). – datenwolf Apr 11 '16 at 12:20
  • @datenwolf Ah interesting! It sorts of make sense, no jumps basically... Still is quite weird, because then it doesn't come cheap memory wise (3 times more?) – Emanuele Apr 11 '16 at 12:40