Storing vertices in the array or in the linked list?

#1

For an application with OpenGL, written in C/C++, that should handle large mesh objects, which data structure would you choose today to store and manage vertices? the array or a linked list?

#2

Well, OpenGL wants an array in GPU memory. So you can avoid storing the data in CPU memory altogether; and if you do store a copy in CPU memory, synchronising the two is going to be more efficient with an array.

The fact that you’re even asking the question leads to suspect you might be using ancient books or tutorials which use glBegin/glEnd. If that’s the case, forget whatever you’ve learned and find something which was written in the last decade.

1 Like
#3

Yes, as you suspect my code has its roots in the previous decade, when i start to coding.
This is a bit of my code (this version uses linked lists):

	glBegin(GL_TRIANGLES);
	// TODO: use a single call to glDrawArrays Instead of passing each item (?)

		tri = mesh->pTriangle;
		while( tri )
		{
			if( m_bSmooth && m_model->pNormal )
			{
				// Draw with vertex normals:
				glNormal3f(tri->na->x, tri->na->y, tri->na->z);
				glVertex3f(tri->va->x, tri->va->y, tri->va->z);

Then I compile the Draw function into a OpenGL Display List.
Note the comment “TODO:”, I had forgotten it (should be a few years old).
May be I read something. Is glDrawArrays or glDrawElements what you mean?

#4

Yes. But with modern OpenGL, the vertex and index arrays are normally stored in GPU memory via buffer objects.

#5

Thanks for the suggestion.
I imagine the use of these methods requires a new configuration of the whole code. I’ll have to study for a while. Display Lists are still in use?
Can I still rely on OpenGL for several years or is recommended the migration to other APIs?

#6

No. They don’t exist in 3+ core profile. They’re still available in the compatibility profile but they’re not likely to be significantly faster than just running through the glBegin/glVertex/glEnd each frame.

Well, Apple intends to deprecate OpenGL in favour of Metal. But it isn’t going to be disappearing on Windows (or Linux); there’s too much software which depends upon it. That isn’t an issue for Apple, who historically have tended to burn everything to the ground and start over every few years, but Windows survives on compatibility. Vulkan seems to be the preferred successor for performance, but there’s probably not much point unless you’re pushing the hardware to the limit.

1 Like
#7

This is really going to depend on which GPU vendor’s driver that he’s using. For instance, I do recall that on NVidia drivers, compiling immediate mode batches into display lists like this results in draw performance that’s even better than vertex array batches read from VBOs (without extensions). The only way I ever found to equal that perf was using vertex array batches read from VBOs using NV bindless extensions.

That said, that’s only one GPU vendor’s drivers, and this was from tests I ran a number of years ago. So something could have changed, and doubtless the support for this legacy GL functionality isn’t going to be as good on all drivers. Best bet: Use the support in the latest OpenGL. That will likely be plenty fast enough for you, and will be more likely to be supported well across more GL drivers. If you need that extra ++ though, consider use of vendor-specific extensions.

From what I’ve heard, yes (except on Apple as GClements said). There are a bunch of existing commercial and non-commercial OpenGL apps and libraries in-use, and sectors of the market that haven’t converted to Vulkan yet, so most GPU vendor’s just can’t afford to just end OpenGL support. As GClements mentioned, Apple is an exception. And devs are even implementing ways around that, running OpenGL and Vulkan on top of Metal via API translation layers.

At OpenGL BOFs (talks), Khronos has repeatedly indicated that OpenGL is here to stay. However, it’s very clear that most of the latest feature development is all going into Vulkan. GL devs that want to use this are being pointed to the GL-Vulkan interop extensions, or to consider converting over to Vulkan. That said, OpenGL is higher level and more approachable for a beginning graphics developer. So I’d recommend starting there.

1 Like
#8

Apple intends to remove OpenGL; they deprecated it last year.

#9

Well, it means that I will have to renovate my code.
Recently I tried the way to host all the vertices of the model in a linked list. It has its advantages and its disadvantages. So, I’ll have to abandon the benefits of the linked list for an array structure. Or, is always possible to temporarily copy the vertex object in a linked list if necessary. I have a function that temporarily copyes the vertices list in a octree for the nearest neighbor search purpose. I get a mounth to write it!

Ok, for now I stay with OpenGL (I love what has always worked) and meanwhile I start to look at how Vulkan works.