VertexElement containers confusion


#1

Hi, it seems there are quite a few container-like classes for VertexElements:
VertexDataDesc, VertexDeclarationProperties, VertexDeclarationKey and a class that uses Vector -> GpuProgramBytecode, maybe it would make sense to coalesce the services provided by all of these?


#2

VertexDataDesc is intended to be usable without a render backend, while VertexDeclaration has an underlying render backend object. Generally I put stuff into a separate *Properties object because it needs to be shared between multiple types (usually at least one for sim and another for core thread).

But as long as it makes sense and the stuff above is respected I wouldn’t mind changing it if you have a better design in mind.

I don’t know what you mean by " Vector -> GpuProgramBytecode".


#3

I didn’t mention VertexDeclaration since I’ve noticed it’s one of those types that straddles the CPU/GPU thread divide :smile:

As for GpuProgramBytecode, I’ve noticed it holds a Vector of VertexElement as such it could make use of VertexDataDesc instead?

VertexDeclarationProperties vs VertexDataDesc :
Both contain:

  • count/size functions getElementCount vs getNumElements
  • element access functions a checked getElement vs unchecked getElement
  • element access by semantic + index findElementBySemantic vs semantic + index + stream idx getElement
  • per-stream vertex size getVertexSize vs getVertexStride

VertexDeclarationProperties only functionality :

  • findElementsBySource
  • getElements accessor to protected mElementList member

VertexDataDesc contains much more interesting querying/modification functions.

So I’d propose that we extend VertexDataDesc with the few missing ‘pieces’, make the class copyable/comparable, add the functionality that will replicate the VertexDeclarationKey, and replace all uses of VertexDeclarationProperties and VertexDeclarationKey with VertexDataDesc.

Another bit of functionality that might make sense: add updateOffsets() to VertexDataDesc that would calculate the offsets ‘in-place’, instead of allocation-happy createElements ?

If that is something that would be accepted as a PR, let me know so I can whip something up :smile:


#4

Thanks for making an in-depth overview, certainly helps see things more clearly. I’d welcome a PR on the topic indeed.