Использование QOpenGLBuffer

[Igors]

Добрый день

Подобную тему уже создавал, но, как говорится, "быльем поросло". А сейчас пришлось обновляться до новой версии одной из базовых либ - и опять пришлось многое переделывать.

- Есть исходные данные стандартные для OpenGL - вертексы и индексы, число индексов на фейс (могут быть не только тр-ки) + всякая опциональная всячина (нормали, цвет, UV(s)  др). Хранятся они в массивах/векторах, в общем у любого пользующего OpenGL практически то же самое. Данные могут шариться разными объектами, напр N объектов может использовать одни и те же вертексы и индексы, или только индексы. Ну и конечно все данные буферированы с использованием QOpenGLBuffer чтобы не гонять их CPU -> GPU при каждом рисовании

- И вот возникает "еще одно" представление/рисование объекта. Юзер включает бубочки и ожидает увидеть объект с высокой деталировкой (вместо исходного с низкой). Что однако, не означает "объект изменился" - нет, он хочет только "видеть", а все действия по-прежнему выполнять с исходным простым объектом, (а не таскать тонны геометрии)

Ясно что решение одно - хранить высоко деталированный объект на карте, но как это сделать ?

Спасибо

[__Heaven__]

В функциях gl имеется параметр stride. Может его задействование как-то поможет...

[Racheengel]

А разве при изменении "простого" объекта не должен будет меняться "сложный"?
Скорее всего, тут "хранить" надо некую изменяемую модель данных. А оба OpenGl-представления генерировать при изменении модели.

[Igors]

В функциях gl имеется параметр stride. Может его задействование как-то поможет...

stride - это просто размер единицы вертексных данных, который может быть больше требуемого. Напр если данные хранятся как QVector<QVector4D> то указав stride = 16 мы можем их скормить напрямую, без перевода в QVector<QVector3D>

А разве при изменении "простого" объекта не должен будет меняться "сложный"?

Конечно должен. Изменения бывают 2 типов

а) изменилась вся модель полностью
б) изменились вертексы и нормали к ним (только значения, их число осталось тем же)

Скорее всего, тут "хранить" надо некую изменяемую модель данных. А оба OpenGl-представления генерировать при изменении модели.

Так вот и хотелось бы поговорить/конкретизировать как генерировать разные OpenGL-представления.

[Igors]

Как должна быть создана картинка в стартовом посте

- есть исходный объект (слева). Он копируется 3 раза. Пока все 4 объекта используют одни и же QOpenGLBuffer для вертексов, индексов, нормалей и.т.д. Все шарится

- Теперь юзер открывает UI каждой из копий и назначает уровни деталировки 1, 2, 3 соответственно. Должны быть созданы/посчитаны новые данные, которые записываются в буфера. Теперь у каждого объекта все буфера свои. Ничего не шарится

Возиожно (хотя и не показано на картинке) юзер скопирует любой из объектов - копия шарит оригинал. Если же  копия или оригинал изменены (напр как-то деформированы), то 2 буфера (вертексы и нормали) у каждого свои, остальные буфера по-прежнему шарятся
 

[__Heaven__]

Я смотрю описание glVertexAttribPointer

stride
Specifies the byte offset between consecutive generic vertex attributes. If stride is 0, the generic vertex attributes are understood to be tightly packed in the array. The initial value is 0.

Вроде как им можно сказать конвейеру брать каждую вторую/третью вершину.

[Racheengel]

Так вот и хотелось бы поговорить/конкретизировать как генерировать разные OpenGL-представления.

Щас подумал - видно, я ранее чушь сказал... Хранить-модифицировать надо высокополигональную модель.
Потому что из хай-поли лоу-поли сделать можно, а наоборот - это неоднозначно.

[Igors]

Вроде как им можно сказать конвейеру брать каждую вторую/третью вершину.

Можно и так, но обычно используется для согласования размеров единицы исходных/передаваемых данных. К этой теме отношения не имеет

Щас подумал - видно, я ранее чушь сказал... Хранить-модифицировать надо высокополигональную модель.
Потому что из хай-поли лоу-поли сделать можно, а наоборот - это неоднозначно.

Самокритика - это прекрасно, но в данном случае все наоборот: исходные данные LOW-resolution меш, часто его называют "cage". Заметим что частенько результат заметно лучше если исходные полигоны 4-угольники (а не тр-ки).   

[Racheengel]

Я имел в виду, что поскольку 1-й объект (исходный) - это некий треугольник в 3д, то как мы можем быть уверенными, что в хай-поли оно превращается в 4-й (сильно сглажены углы), а не должно оставаться таки треугольным?
Судя по картинкам - это не просто хай-поли, а объект плюс деформация.

[Igors]

Судя по картинкам - это не просто хай-поли, а объект плюс деформация.

Да, точнее "не просто триангуляция". Это называется SDS (surface sub-division) и известно уже не один десяток лет. Вертекс заменяется взвешенной суммой соседей. Если не вдаваться в тонкости с sharpness - можно самому написать за день. Конечно это не "magic", хороший рез-т получается для достаточно грамотных, аккуратных исходных cage(s).

Однако и это не имеет отношения к теме   

[ssoft]

Разную детализацию на основе одних и тех же вертексных данных можно получить путем формирования различных массивов индексов. Например, загрубив полигональный объект путем пропуска вершин по какому-либо критерию, можно выполнить тесселяцию столько раз, сколько нужно. Тогда для одного набора вершин получим несколько наборов индексов для разной степени детальности.

Для облегчения перетаскивания объектов несколько раз видел прием, когда все примитивы в момент перемещения отображаются в режиме отображения точек. Получается просто, легко и может даже эффектно.

[__Heaven__]

Насчёт упрощения представления, кстати, есть несколько способов: feature lines, bounding box, node cloud, element centroid

[Igors]

...загрубив полигональный объект путем пропуска вершин по какому-либо критерию,

И что это будет за объект с выкинутыми вертексами? 

Для облегчения перетаскивания объектов несколько раз видел прием, когда все примитивы в момент перемещения отображаются в режиме отображения точек. Получается просто, легко и может даже эффектно.

Тут у меня очередные "чудеса на виражах" Если рисовать точки и wireframe с помощью gl(Multi)DrawElements (установив glPolygonMode) то скорость почти в 3 раза НИЖЕ чем для "залитых" полигонов даже с текстурами и материалом! Если же соскочить на glDrawArrays для точек, то конечно шустрее, но я попадаю в др беду - не работает Cull(Back)Fаce

Ну и вообще-то вопрос был как хранить разные представления

[Igors]

Ладно, попробуем набросать структуры данных, может обсуждение станет более конкретным.
Вот "принципиальная схема"

Код

C++ (Qt)
typedef QVector<QVector3D> TVerArray;  
typedef QVector<int> TIndArray;
 
struct CRenderObject {
...
// данные рисования, могут шариться любым кол-вом CRenderObject
 QSharedPointer<CGeometry> m_geometry;
 
// уровень деталировки, 0 = исходная геометрия
 int m_detailLevel;       
 
// Если к объекту применены нелинейные преобразования
// то его "личные" вертексы и нормали должны использоваться
// (вместо тех же данных в m_geomretry)
 TVerArray m_vertex, m_normal;
};
 
// класс данных рисования
struct CGeometry {
...
  TVerArray m_vertex, m_normal, m_color, m_uv0, m_uv1;
  TIndArray m_indices, m_ver_per_face;
};

Вот собсно и все - теперь надо куда-то поселить буфера (QOpenGLBuffer). Вот как и куда?

[ssoft]

Полигональная модель всегда может быть преобразована (в конечном счете) к набору треугольников. Если по какому-то принципу исключить из рассмотрения некоторые вершины, то можно "загрубить" исходный объект. При этом изменится и его геометрическая форма, хотя исходные данные будут прежними, кроме массива индексов.

Если исходные данные представляют собой уже массивы треугольников или других примитивов, то для проведения такого анализа потребуется формировать и анализировать связи вершин между собой.

Или можно хранить копии одного объекта с разной детализацией? Тогда достаточно в момент рендеринга выбирать нужный вид.