# Vertex Data Structures

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

## Recommended Posts

Hello,

I am improving some code I have for my DirectX 11 college assignment and one of the things I want to take care of is the way my code deals with vertices.
I have a couple of types of vertices that are simply defined like this:

struct VertexColorPosition
{
DirectX::XMFLOAT4 Position;
DirectX::XMFLOAT4 Color;
};

So, for the moment I'm relying on templates to do everything about vertices, but this approach often seems to get inconvenient.

Is there a more clever way to deal with vertices?

I found things like D3DFVF (but it seems to be a part of DX9).

##### Share on other sites

You can store them as byte streams + vertex descriptions. Then any operation can be done on them and you don't need an actual C++ type.

##### Share on other sites

You can store them as byte streams + vertex descriptions. Then any operation can be done on them and you don't need an actual C++ type.

So, if I understood you well, I should create a simple mesh format (internal for my application) and I could avoid using any vertex structures in code?

I will look into the topic, although it seems a bit too complex for my current time schedule.

##### Share on other sites
What's the exact reason why you don't want the vertex structures?
An advantage is that it's directly clear what they do/ contain and you can access the elements easily.

##### Share on other sites

What's the exact reason why you don't want the vertex structures?
An advantage is that it's directly clear what they do/ contain and you can access the elements easily.

The current implementation (Vertex Structs) has produced a bit of a mess, because there were different types of structs (containing different kind of elements) and I run into problems when I'm trying to do something to a set of vertices, create shapes and similar because I end up with code duplication for different kind of vertices. I tried to implement some conversions between the types, but that also created different set of problems (for example, what to do with the color of vertices when converting from a type that doesn't have color to one that does? I ended up coding the color in the part of the code that should be vertex-type agnostic).

But, I do agree that there is a big advantage to being able to see what is the type of vertex from the structure name and accessing the elements easy.

I'll probably stick to that for now, and clean the code up a bit. Most of the problems can probably be solved with better application design.

##### Share on other sites

Having an actual C++ type for the vertex structure I'd argue isn't really that useful. The fact that you can see the actual memory layout is a downside, as that's what's making it inflexible, and it isn't even important until you serialize it or create an input layout out of it. Processing of mesh data should be generic enough to not care about the memory.

Specific structures can quickly fall into the anti-pattern of building out the fattest possible vertex struct, and only some of the data is used which is abysmal in both performance and usability.

##### Share on other sites
Most of the time I use reasonably opaque vertex data as Dingleberry suggests. Any time I need to do operations on the mesh though, I tend to split it up into several streams of data e.g. Positions and UVs and tangents etc. Alternatively, I also have functions that take an e.g. Vec3* to operate on positions and a stride value that defines the size between each vertex. So to increment between each vertex you can do ((char*)pPositions) += stride.

1. 1
2. 2
3. 3
4. 4
Rutin
13
5. 5

• 24
• 10
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633695
• Total Posts
3013373
×