问题
Currently working on a 3D media engine using C# and I have come across a little conundrum. I have my rending loop figured out, I got a great plug-in architecture and content management system and even a material pipeline all planned out. Then engine is planned to use DirectX and OpenGL (via 'renderer' plug-ins), along with both APIs' programmable pipe-line.
Anyways, at the beginning of this week I started on working on the engines abstract layer for processing vertices (I have been dreading this for weeks now). And as some of you know, vertex handling between graphic APIs' is not at all related or the same. Well kinda related ;), but not the same. In OpenGL handling vertices is very straight-forward, you create the custom vertex structure, send it to the GPU and then let your shaders handle the rest. This is perfect for a flexible graphics pipe-line, OpenGL is not required to know what elements are contained with each vertex. DirectX on the other-hand requires us to create declarations for each vertex structure and then send them to the GPU.
The issue is that I will not know what type of vertex structure is being passed and I would definitely like to avoid creating the abstraction layer that involves declaring each element of a vertex through enumerations and some abstract 'VertexDeclaration' class; this would cause some issues:
1) Getting vertex elements will be a pain to say the least. I could use some 'VertexSemantic' and ask for the positions of vertex 'a - z', but when processing a lot of vertices for something like skeletal animation, it can have a lot of overhead.
2) Not very user-friendly considering the engines' main focus is 'newbies'. I would like for users to be able to create custom vertices and mesh buffers, without having to declare a ton of objects, consuming valuable development time.
3) more?
Now I could do something with attributes and then create declarations for vertex structures inside the DirectX renderer. For instance, go ahead and create some enums:
// for getting the format layout of the element
public enum ElementFormat
{
Float, Float2, Float3, Byte, etc, etc
}
// for determining the 'usage'
// (here is 'another' where DirectX limits vertex structures ><)
public enum ElementUsage
{
Position, Normal, Color, TextureCoord, etc, etc
}
Now I can create an attribute that users can apply to the 'fields' of each element in their vertex structure:
public class VertexElementAttribute : Attribute
{
#region Properties
/// <summary>
/// Gets the total size (in bytes) of the element.
/// </summary>
public int Size
{
get;
set;
}
/// <summary>
/// Gets the number of values contained with-in the element.
/// </summary>
public int Count
{
get;
set;
}
/// <summary>
/// Gets the type semantic of the element.
/// </summary>
public ElementType Type
{
get;
set;
}
/// <summary>
/// Gets the usage semantic of the element.
/// </summary>
public ElementUsage Usage
{
get;
set;
}
#endregion
#region Init
/// <summary>
/// Creates a new vertex element attribute.
/// </summary>
/// <param name="count">The number of values contained within the element.</param>
/// <param name="size">The total size (in bytes) of the element.</param>
/// <param name="type">The type semantic of the element.</param>
/// <param name="usage">The usage semantic of the element.</param>
public VertexElementAttribute(int count, int size, ElementType type, ElementUsage usage)
{
Count = count;
Size = size;
Type = type;
Usage = usage;
}
#endregion
}
An example of what a custom vertex structure could look like:
public struct VertexPositionColor
{
[VertexElement(3, sizeof(Vector3), ElementType.FLOAT3, ElementUsage.POSITION)]
public Vector3 Xyz;
[VertexElement(4, sizeof(Color), ElementType.FLOAT4, ElementUsage.COLOR)]
public Color Rgba;
... etc
}
This would be nice. In the DirectX plug-in (renderer) I could just create a utility class that can create the semantics for each structure type and then cache the data so the declarations don't have to be recreated for each vertex.
I could even add a NONE enumeration value to ELementUsage so that custom values may be used for what ever means... but then again they would only work in OpenGL because DirectX requires you to mark each vertex... unless there is something I am missing.
My question(s):
Is there a better way to go about this (besides using the attirbutes)? Is there a way to avoid using VertexDeclarations in DirectX? Is there any thing you may not understand about 'my' question?
EDIT:
An issue with using attributes would be getting element data from each vertex. Say I wanted to get the positions of each vertex in a mesh buffer. Since I went with attributes, I can't just do 'vertex.Position', I would have to create a utility method that could extract a field reference from a vertex structure, like 'Utility.GetElement(vertex, ElementUsage.POSITION)' . This method would need to use reflection to first find the attribute, then return the reference to the field value. Setting the value would not even (i think) be possible?
Another way would be to create an IElement interface and implement each element (Positon, Normal, etc). The interface could have Name property that I can return directly inside the inherited element structure, like the PositionElements' Name property would just return "Positon".
Next I could hold the array of IElement indside a Vertex struct that contains methods like AddElement(IElement), GetElement(string name), GetElement(int index), Insert, Replace, etc. I would implement all elements known to DirectX so that the renderer plug-in could parse a vertex structure to create an array of vertex declarations.
The issue with this is that I am not sure if an array '[]' can be used as vertex element data. Like, what other bytes does an array contain (if any) that would hinder me from passing the Vertex struct (contains the IElement array) directly to DirectX, then to the GPU?
Implementing it this way would be absolutely perfect for what I need it for. Another question is could the inheriting types of IElement (the elements) be a class, or do element values have to be value-types?
回答1:
It has been a long time since I've done any directx or opengl, so take my advice with a grain of salt, but I remember doing something like this a while ago.
I think I did something like this:
var graphicsStream = new GraphicsStream();
var elements = graphicsStream.Create<Vector3>(Usage.Position);
graphicsStream.Create<Color>(Usage.Color);
graphicsStream.Create<Quaternion>(Usage.Fribble);
elements.SetData(new[] { new Vector3(), new Vector3() });
var vertexFormat = graphicsStream.GetFormat();
graphicsStream.Validate(); // ensure all the streams have the same length
// get a particular element by type
var p = graphicsStream.GetData(Usage.Position, 1);
You'd have a graphics stream which was a set of typed data sets with a usage applied. From this you can generate an appropriate vertex format. The API would let you change individual elements or upload and replace the entire vertex buffer in one go.
The biggest downside is that you don't have one structure that represents a "column" in your vertex structure.
I don't know if this is the kind of thing you're looking for. Why would a design like this not be appropriate?
回答2:
You could have a look at how OGRE handles this. In particular The render system documentation about VertexElement and also the vertex buffer classes. OGRE is C++ but I am sure you will be able to get the design patterns easily converted to C#.
来源：https://stackoverflow.com/questions/2189494/what-is-a-good-code-structure-for-api-independent-vertex-processing