0

I have a large buffer with many vertices which are all layed out in an even grid in the XZ plane but with varying heights in the Y axis. To join up these vertices the index buffer is written in a way that most of these vertices will be included in 6 different triangles. The only way I can think of giving these vertices normal attributes is by having the vertices being repeated six times in the vertex buffer or calculating the normals in a geometry shader.

Neither of these options are very desirable since the vertex buffer may be very large and a geometry shader will probably decrease rendering performance quite heavily.

Is there some way to have vertex attributes update per primitive rather than per vertex or per instance? If not is there another less expensive way I could achieve this?

I am quite new to OpenGl and 3D graphics rendering in general so I'm sorry if I am misunderstanding something.

fltray10
  • 31
  • 6
  • Tutorial Hunting is tricky. If you don't already know a lot about what you're looking for, odds are high you'll find bad tutorials before you find good ones and may not be able to tell bad advice from good. Search carefully and try to focus on tutorials from recognized domain experts. – user4581301 Jan 17 '21 at 22:54
  • 2
    Are you sure you want to give your triangles per-face normals like that? This usually will not have the desired effect. – Nicol Bolas Jan 18 '21 at 01:40
  • @NicolBolas I have heard of the method where you would get an average of the normals for all the primitive the vertex is a part of, and have that as the normal for that vertex. would you suggest that I try that method? – fltray10 Jan 18 '21 at 09:41
  • @fltray10: yes, that's the usually recommended method. See https://stackoverflow.com/a/6661242/524368 – datenwolf Jan 18 '21 at 11:26

1 Answers1

1

with many vertices which are all layed out in an even grid in the XZ plane but with varying heights in the Y axis

If any of the constituent values of an attribute differ, they are in effect different vertices.

is by having the vertices being repeated six times in the vertex buffer

Given the fact, that if they have different Y and normal, they're distinct vertices, and hence no repetition occurs.

desirable since the vertex buffer may be very large

It's a tricky balancing act, but increased buffer size can be desirable if it means that there's a strict bijective mapping between vertex attribute values and index into the buffer. The output of the vertex stage is cached, and in case of indexed drawing, the index is the caching key, i.e. if the same index is used multiple times, for example for a vertex that's shared by several triangles, then the cached result of the computation can be directly used from that index.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • I will consider just increasing the buffer size, the main problem is the loading time for the vertex buffer which is already around a second and a half. – fltray10 Jan 18 '21 at 09:37
  • @fltray10: How many vertices are you putting in there? If your bottleneck is loading times (and not the GPU's capabilities) you've to work on the loading procedures. – datenwolf Jan 18 '21 at 10:44
  • It depends on the configuration of the program but usually 1,000,000 vertices, which all have position and color/texture attributes. I failed to mention the loading of the index buffer is also included in that loading time aswell. Right now to load these I just run through a for loop to set the values for each vertice before giving it to the gpu, I'm not sure what the most optimal way is for loading in buffers so I will probably do more research there – fltray10 Jan 18 '21 at 11:05
  • @fltray10: 1e6 vertices is practically nothing, as far as a modern GPU is concerned. To put things into perspective, assume a vertex with vec3 position, vec3 normal and vec4 color; that's 10 · sizeof(float) = 40 bytes; that ×1e6 = 40MB. PCIe-3×16 has a bandwidth of 12GB/s, which amounts to 0.003s = 3ms upload time. – If it takes several seconds to upload, whatever you do, you're __*not*__ bottlenecked by the amount of data you're uploading. – datenwolf Jan 18 '21 at 11:33
  • There are some other things going on in the loading process which may justify a longer time such as a perlinnoise algorithm on a 1000*1000 float buffer to determine the height of each vertex but still I guess I should optimise this process more. Right now I simply have a for loop for the filling the vertex buffer, index buffer and then upload to the GPU. thank you for helping me recognise that this loading process needs more optimisation. – fltray10 Jan 18 '21 at 11:34