Архитектура VBO

[Racheengel]

Сколько вертексов имеет простейший кубик? Человек знакомый с OpenGL ответит 24 (а не 8 как начинающий).

Сам по себе кубик имеет 8 вертексов, остальное - это представление модели, которая визуализируется. Зависит от того, как рисовать. Если квадами - то 24, если треугольниками - то, считаем, 36 (по 6 точек на грань, если без стрипов). А если индексами, то зададите вы все те же 8 вертексов, плюс массивы индексов.

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

[Igors]

Зависит от того, как рисовать. Если квадами - то 24, если треугольниками - то, считаем, 36 (по 6 точек на грань, если без стрипов). А если индексами, то зададите вы все те же 8 вертексов, плюс массивы индексов.

Кубик из тр-ков имеет 12 фейсов и те же самые 24 вертекса. Тут уже одни вертексы шарятся, другие нет. Просто берем квады и каждый бьем на 2 тр-ка, никакие новые вертексы не нужны. Создать 36 можно но бессмысленно.

Сам по себе кубик имеет 8 вертексов, остальное - это представление модели, которая визуализируется.

Рендерится конкретное представление, а не что там "само по себе/существу"

Но количество вертексов то у вас не изменяется.

Для кубика нет, у него и так все "расщарено", а в общем случае меняется (аттач)

Что ж так плаваете в азах? Это же на уровне "популярных знаний"  

[Racheengel]

Для кубика нет, у него и так все "расщарено", а в общем случае меняется (аттач)

Так я про это и спрашивал - что меняется для каждого из представлений?
Ну, теперь понятно, что "меняется все" - и нормали, и полигоны.
Т.е. есть варианты с различной детализацией.

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

В общем случае вам все равно нужно для каждого случая генерировать разные данные. Вопрос только в том, чем мы будем жертвовать - памятью или производительностью?

[Igors]

Так я про это и спрашивал - что меняется для каждого из представлений?
Ну, теперь понятно, что "меняется все" - и нормали, и полигоны.

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

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

В общем случае вам все равно нужно для каждого случая генерировать разные данные. Вопрос только в том, чем мы будем жертвовать - памятью или производительностью?

Это все рассказано в первом же посте. Интересует решение без жертв, или, на худой конец, доказательство невозможности такового.

[OFF]К сожалению, Вы взяли на вооружение стиль Верес'а, по-простому говоря "на шару".

Напишу-ка так. Не, я конечно не уверен, да и занимался этим немного и хз когда. Ну а вдруг прокатит? А если нет - не беда, вот мне и растолкуют почему. Так я и буду получать знания через ля-ля на форуме, без всяких усилий.

Это не очень корректно по отношению к ТС - мне нетрудно разжевать, но не для чисто праздного любопытства. А главное - минимум 5-летний опыт Верес'а показывает что такой метод ничего не дает. Результаты ужасны, причем все хуже и хуже 
[/OFF]
 

[Racheengel]

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

У Вас на скриншоте 2 модели шара - высокополигональная слева и низкополигональная справа.
Каким образом тогда Ваша цитата связана с Вашим скриншотом?
Они взаимоисключающие.
Либо Вы делаете higl-poly & low-poly model для разных случаев (естественно, и нормали в этом случае разные)...
Либо, если меняются ТОЛЬКО нормали - то рисуйте через glDraw[Arrays|Elements], тогда у Вас будет возможность безболезненно переключаться между массивами нормалей

Оффтоп: а при чем тут Верес и его стиль

[__Heaven__]

Racheengel, в обоих вариантах одинаковое количество полигонов. Меняются только нормали. Это обман зрения.

[Racheengel]

Racheengel, в обоих вариантах одинаковое количество полигонов. Меняются только нормали. Это обман зрения.

Да, но:

Но появилась новая фича - пользователь хочет иметь возможность показа измельченной (грубо говоря триангулированной) модели

Я так понимаю, что тут не только в нормалях разница, а имеется в виду высокополигональная модель, которую Игорь не хочет хранить в памяти, а хочет запузырить на видеокарту через VBO

Или опять не так?

[Igors]

Либо, если меняются ТОЛЬКО нормали - то рисуйте через glDraw[Arrays|Elements], тогда у Вас будет возможность безболезненно переключаться между массивами нормалей

2 полигона модели сферы что выше

1-й ссылается на вертексы (0, 1, 2, 3)
2-й ссылается на вертексы (4, 5, 1, 0)  // т.е. вертексы 0 и 1 шарятся этими полигонами

Все вертексы имеют нормали для левой картинки выше.  Также меня есть предвычисленные нормали для обоих полигонов. Ну и как я их "подменю"?

[Racheengel]

А как Вы нормали для каждой из сфер храните?
Я бы ожидал массивы такой же длины, как и для вертексов, с 4 нормалями на полигон.

Т.е. для варианта 1 было бы:
V = [v0, v1, v2, v3] [v4, v5, v1, v0]
N1 = [n0, n1, n2, n3] [n4, n5, n6, n7]

А для варианта 2:
V = [v0, v1, v2, v3] [v4, v5, v1, v0]
N2 = [m0, m1, m2, m3] [m4, m5, m6, m7]

где n - нормали, рассчитанные для "модели 1", а m - нормали, рассчитанные для "модели 2".
Далее с помощью glNormalPointer(N1) или glNormalPointer(N2) переключаетесь между ними.

Надеюсь, написал понятно (Вы же используете glNormalPointer и glVertexPointer в коде?)

[Igors]

Вы же используете glNormalPointer и glVertexPointer в коде?

Вот как раз для них и не выходит

А для варианта 2:
V = [v0, v1, v2, v3] [v4, v5, v1, v0]
N2 = [m0, m1, m2, m3] [m4, m5, m6, m7]

Счетчики V и N(N2) должны быть одинаковы. Если 6 вертексов (v0..v5) то и нормалей будет использоваться 6 (а не 8 ). И если подаются одни и те же индексы v0, v1 для 2 полигонов, то и нормали будут юзаться одни и те же. Др словами у OpenGL ОДЫН индекс на все - про все.

Пробовали учить человека играть в преферанс "на практике"?

.. а самая старшая черва ?
.. а 6 пик - вистовать обязательно ?
.. а мизер - это когда не брать взяток?  
...
...

Как это ужасно  

[Racheengel]

Ок. Вроде я понял проблему. Похоже, ничего не остается, как дублировать вертексы. Имхо всяко лучше, чем тормозные glBegin/glEnd. Да, с одной стороны возрастет расход памяти на координаты вертексов, но с другой Вы можете тогда отказаться от массива индексов и использовать glDrawArrays.

Возможно, извращениями с шейдерами можно добиться лучших результатов, но тут я не советчик. Не юзал шейдеры ни разу.

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

[__Heaven__]

Я дополню. Если использовать буферы, то жертвовать придётся памятью GPU. Тем самым можно освободить ОЗУ.

[Igors]

Похоже, ничего не остается, как дублировать вертексы...

Ну как-то Ваш вывод не блещет оригинальностью и/или свежими идеями  И кроме банального "альтернатива скорость - расход памяти" напомню еще фактор "объем кода". Паршивенький glBegin/glEnd = один маленький метод, а вот "еще одно представление данных" - ой нет

Но Вы так и не сказали, о каких объемах данных идет речь,

"Общий случай" - юзер решает какие модели грузить и сколько. В общем мульены - дело давно рядовое.

Возможно, извращениями с шейдерами можно добиться лучших результатов, но тут я не советчик. Не юзал шейдеры ни разу.

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

[Igors]

Я дополню. Если использовать буферы, то жертвовать придётся памятью GPU. Тем самым можно освободить ОЗУ.

Так это собсно и есть тема для обсуждения. "Flat" рисование (правая сфера) было просто к слову (просто ситуевина принципиально та же). Обсуждение "кого же освобождать" лишено смысла - ясно что данные надо хранить на GPU.

Итак вот у нас появилось "другое/альтернативное представление", в случае деталированной модели оно неизбежно, тут уже не заткнуть. И мы хотим "запузырить ее на видеокарту через VBO" . Ваши действия?

[Racheengel]

И кроме банального "альтернатива скорость - расход памяти" напомню еще фактор "объем кода". Паршивенький glBegin/glEnd = один маленький метод, а вот "еще одно представление данных" - ой нет

Да ну, какой там объем то Пара вызовов glNormalPointer, glVertexPointer, да еще glDrawArrays в конце)
Но если памяти жалко, можно фрагментами рендерить.
Сгенерили часть данных в вектора - отрендерили - повторили.
Других решений пока не вижу, тем более все равно у Вас нормали заранее просчитываются.

А шейдеры, конечно, слишком уж узкоспециальное решение, согласен.