Что такое хорошая структура кода для независимой от API обработки вершины? [закрытый]

Закрытый. Этот вопрос основан на мнении. Это в настоящее время не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, таким образом, ему можно ответить с фактами и цитатами путем редактирования этого сообщения.

Закрытый в прошлом году.

В настоящее время работая над 3D механизмом медиа с помощью C# и я столкнулся с небольшой загадкой. Мне выяснили мой цикл раздирания, я получил большую сменную архитектуру и систему управления контентом и даже материальный конвейер все распланированные. Затем механизм планируется для использования DirectX и OpenGL (через плагины 'рендерера'), наряду с программируемым конвейером обоих API.

Так или иначе в начале этой недели я запустил при работе над слоем краткого обзора механизмов для обработки вершин (я боялся этого в течение многих недель теперь). И поскольку некоторые из Вас знают, обработка вершины между графическими API нисколько не связана или то же. Хорошо отчасти связанный ;), но не то же. В OpenGL вершины обработки очень просты, Вы создаете пользовательскую структуру вершины, отправляете ее в GPU и затем позволяете Вашим программам построения теней обработать остальных. Это идеально подходит для гибкого графического конвейера, OpenGL не требуется, чтобы знать, какие элементы содержатся с каждой вершиной. DirectX, с другой стороны, требует, чтобы мы создали объявления для каждой структуры вершины и затем отправили их в GPU.

Проблема - то, что я не буду знать, какая структура вершины передается, и я определенно хотел бы постараться не создавать уровень абстракции, который включает объявление каждого элемента вершины посредством перечислений и некоторого краткого обзора класс 'VertexDeclaration'; это вызвало бы некоторые проблемы:

1) Получение элементов вершины будет болью по меньшей мере. Я мог использовать некоторый 'VertexSemantic' и попросить положения вершины '-z', но при обработке большого количества вершин для чего-то как скелетная анимация, это может иметь много издержек.

2) Не очень удобное для пользователя рассмотрение основного фокуса механизмов является 'новичками'. Я хотел бы за пользователей смочь создать пользовательские вершины и сетчатые буферы, не имея необходимость объявлять тонну объектов, используя ценное время разработки.

3) больше?

Теперь я мог сделать что-то с атрибутами и затем создать объявления для структур вершины в рендерере DirectX. Например, идите вперед и создайте некоторые перечисления:

// 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
}

Теперь я могу создать атрибут, что пользователи могут обратиться к 'полям' каждого элемента в их структуре вершины:

    public class VertexElementAttribute : Attribute
    {
        #region Properties
        /// 
        /// Gets the total size (in bytes) of the element.
        /// 
        public int Size
        {
            get;
            set;
        }
        /// 
        /// Gets the number of values contained with-in the element.
        /// 
        public int Count
        {
            get;
            set;
        }
        /// 
        /// Gets the type semantic of the element.
        /// 
        public ElementType Type
        {
            get;
            set;
        }
        /// 
        /// Gets the usage semantic of the element.
        /// 
        public ElementUsage Usage
        {
            get;
            set;
        }
        #endregion

        #region Init
        /// 
        /// Creates a new vertex element attribute.
        /// 
        /// The number of values contained within the element.
        /// The total size (in bytes) of the element.
        /// The type semantic of the element.
        /// The usage semantic of the element.
        public VertexElementAttribute(int count, int size, ElementType type, ElementUsage usage)
        {
            Count = count;
            Size = size;
            Type = type;
            Usage = usage;
        }
        #endregion
    }

Пример того, на что могла быть похожей пользовательская структура вершины:

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
}

Это было бы хорошо. В плагине DirectX (рендерер) я мог просто создать служебный класс, который может создать семантику для каждого типа структуры и затем кэшировать данные, таким образом, объявления не должны быть воссозданы для каждой вершины.

Я не мог даже добавить НИ ОДИН перечислимая величина к ELementUsage так, чтобы пользовательские значения могли использоваться для того, что когда-либо означает..., но с другой стороны они только работали бы в OpenGL, потому что DirectX требует, чтобы Вы отметили каждую вершину..., если нет что-то, что я пропускаю.

Мой вопрос (вопросы):

Существует ли лучший способ пойти об этом (помимо использования атрибутов)? Существует ли способ избегать использования VertexDeclarations в DirectX? Есть ли какая-либо вещь, которую Вы не можете понять о 'моем' вопросе?

Править:

Проблема с использованием атрибутов получила бы данные элемента из каждой вершины. Скажите, что я хотел получить положения каждой вершины в сетчатом буфере. Так как я пошел с атрибутами, я не могу только сделать 'вершины. Положение', я должен был бы создать служебный метод, который мог извлечь ссылку поля из структуры вершины, как 'Утилита. GetElement (вершина, ElementUsage. ПОЛОЖЕНИЕ)'. Этот метод должен был бы использовать отражение, чтобы сначала найти атрибут, затем возвратить ссылку на значение поля. Устанавливание значения даже не было бы (я думаю) быть возможным?

Иначе должен был бы создать интерфейс IElement и реализовать каждый элемент (Positon, Нормальный, и т.д.). Интерфейс мог иметь свойство Name, которое я могу возвратить непосредственно в наследованной структуре элемента, как PositionElements' Name, свойство просто возвратило бы "Positon".

Затем я мог держать массив IElement indside структура Вершины, которая содержит методы как AddElement (IElement), GetElement (имя строки), GetElement (международный индекс), Вставляют, Замена, и т.д. Я реализовал бы все элементы, известные DirectX так, чтобы плагин рендерера мог проанализировать структуру вершины для создания массива объявлений вершины.

Проблема с этим - то, что я не уверен, может ли массив' []' использоваться в качестве данных элемента вершины. Как, что содержат другие байты массив (если таковые имеются), который препятствовал бы мне от передачи структуры Вершины (содержит массив IElement), непосредственно к DirectX, затем к GPU?

Реализация его, этот путь абсолютно идеально подошел бы для того, для чего я нуждаюсь в нем. Другой вопрос, мог наследовавшиеся типы IElement (элементы) быть классом, или значения элемента должны быть типами значения?

задан Cœur 13 December 2017 в 10:54

0 ответов

Другие вопросы по тегам:

c# opengl slimdx code-structure vertexdata

Что такое хорошая структура кода для независимой от API обработки вершины? [закрытый]

0 ответов

Похожие вопросы: