Создание массива вершин фигуры с помощью редактора

[Hrundel]

2 Hrundel У вас в коде ошибка, течет память и оставляет видимым диалог прогресса, если файл нельзя открыть.

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

[8Observer8]

Я немного продвинулся вперёд. Мне удалось нарисовать треугольник:



Ещё я из следующего примера добавил: оси, поворот с помощью мыши, приближение и отдаление с помощью колёсика мыши: http://www.gamedev.ru/code/articles/OpenGL_Qt4

Код: https://github.com/8Observer8/CubeFromBlender/tree/one_triangle

Подскажите, пожалуйста, как узнать в Blender какой вершине соответствует какой индекс?

[m_ax]

А что в итоге получилось?
Какая то невообразимая архитектурная каша.. Один чих и всё развалится(

Почему каша, и какой именно "чих" все это развалит? Обоснуйте.

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

Чих - это не только файл..

Во-первых, ваш "парсер" слишком много знает.. Он сильно завязан на гуи, хотя парсер вообще не должен знать об этом ни-че-го.. Такая архитектура вообще противоречит принципам ООП, раз уж тут об этом речь зашла.. Если измениться интерфейс прогрессдиалога или сам прогрессдиалог, то придётся лезть под капот этого парсера.. 

Во-вторых сама реализация парсера.. мм.. не самая изящная.. 
   

[Igors]

Далее будет очень черновой код. Мне главное идею понять, правильно ли я делаю? В следующей функции я заполняю три массива: m_vertexArray, m_colorArray, m_indexArray:

Код

C++ (Qt)
void Scene::setPointsAndIndexes(QList<QVector3D> &points, QList<QVector3D> &indexes)
 

А кто Вам мешал заполнить все три массива сразу при чтении obj файла? И почему Scene планируется в расчете только на 1 объект? Их может быть и больше. Куда Вы все время летите, почему все тяп-ляп? Разберемся c glDrawElements

glDrawElements(GL_TRIANGLES, count, GL_UNSIGNED_INT, indices);

1-й аргумент - что рисуем, какие примитивы - у нас треугольники
2-й аргумент  - сколько треугольников
3-й аргумент  - сколько байт на индекс, чего ж GL_UNSIGNED_BYTE, индекс может ссылаться на вертекс напр 10000. Конечно GL_UNSIGNED_INT
4-й аргумент - массив int'ов (указатель)

В obj файле

f 1 2 4
f 5 8 6
f 1 5 2
...

Значит подаваемый массив { 1 2 4 5 8 6 1 5 2.. }

Теперь с glVertexPointer(3, GL_FLOAT, 0, m_vertexArray);
В obj файле

v 1.000000 1.000001 -0.999999
v 1.000000 -0.999999 -1.000001
v -1.000000 -0.999999 -1.000001...

Значит подаваемый массив
{ 1.000000 1.000001 -0.999999
   1.000000 -0.999999 -1.000001
 -1.000000 -0.999999 -1.000001...
}

[Igors]

Во-первых, ваш "парсер" слишком много знает.. Он сильно завязан на гуи, хотя парсер вообще не должен знать об этом ни-че-го.. Такая архитектура вообще противоречит принципам ООП, раз уж тут об этом речь зашла.. Если измениться интерфейс прогрессдиалога или сам прогрессдиалог, то придётся лезть под капот этого парсера.. 

Не вижу где он "завязан" на UI, ну может QMessageBox. А так нормально, юзается интерфейс прогрессдиалога, в кишки не влазим. И, зная Вас, убежден что никакого feedback'а в Вашей реализации не случилось бы вообще - ушли бы гулять с собачкой, и все 

Во-вторых сама реализация парсера.. мм.. не самая изящная.. 

Так никто ж не мешает показать "более изящную", богатырскую силу буста и освоившего его программиста 

[Old]

А кто Вам мешал заполнить все три массива сразу при чтении obj файла?

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

И почему Scene планируется в расчете только на 1 объект? Их может быть и больше.

Потому что он скопипастил его из примера, он там даже ссылку на него привел.

чего ж GL_UNSIGNED_BYTE, индекс может ссылаться на вертекс напр 10000. Конечно GL_UNSIGNED_INT

А почему нет, у нас всего 8 вершин, байта хватит с головой.

[Old]

Не вижу где он "завязан" на UI, ну может QMessageBox.

И QInputDialog?

А так нормально

Сойдет.

Так никто ж не мешает показать "более изящную", богатырскую силу буста и освоившего его программиста 

Точно-точно, у вас же есть готовая, так сказать "профессиональная" - покажите.

[Igors]

Точно-точно, у вас же есть готовая, так сказать "профессиональная" - покажите.

Ну вот, то обзываете меня всяко - то "покажите" . Нет уж, да и не смог бы, это был заказ.

А вот где ж ота вся умность std/boost которой некоторые так гордятся? Формат легкий и приятный, есть куда более гнусные. Следовало ожидать что вот "щас", "на раз" - но ничего не происходит. Ну где же Ваши "карандаши" которые так усердно затачивались? А если дойдет до дела - опять позорный split, или как? 

[Old]

Ну вот, то обзываете меня всяко - то "покажите" . Нет уж, да и не смог бы, это был заказ.

Другого ответа я и не ждал. Все как всегда. Зато написать "халтура" это вы первый.

А вот где ж ота вся умность std/boost которой некоторые так гордятся? Формат легкий и приятный, есть куда более гнусные. Следовало ожидать что вот "щас", "на раз" - но ничего не происходит. Ну где же Ваши "карандаши" которые так усердно затачивались?

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

Полигонной геометрией я занимаюсь давненько...

А если дойдет до дела - опять позорный split, или как? 

Нет, будет boost::spirit.

[Hrundel]

Во-первых, ваш "парсер" слишком много знает.. Он сильно завязан на гуи, хотя парсер вообще не должен знать об этом ни-че-го.. Такая архитектура вообще противоречит принципам ООП, раз уж тут об этом речь зашла.. Если измениться интерфейс прогрессдиалога или сам прогрессдиалог, то придётся лезть под капот этого парсера.. 

Не вижу где он "завязан" на UI, ну может QMessageBox. А так нормально, юзается интерфейс прогрессдиалога, в кишки не влазим. И, зная Вас, убежден что никакого feedback'а в Вашей реализации не случилось бы вообще - ушли бы гулять с собачкой, и все 

Во-вторых сама реализация парсера.. мм.. не самая изящная.. 

Так никто ж не мешает показать "более изящную", богатырскую силу буста и освоившего его программиста 

Спасибо, Игорь, мне уже и добавить нечего 

Что касается "завязки" на GUI - ну знаете, я все-таки семестровый проект пишу, а не корпаративный продукт от Adobe. Строгой независимости классов с меня никто не требует. 

[m_ax]

Во-первых, ваш "парсер" слишком много знает.. Он сильно завязан на гуи, хотя парсер вообще не должен знать об этом ни-че-го.. Такая архитектура вообще противоречит принципам ООП, раз уж тут об этом речь зашла.. Если измениться интерфейс прогрессдиалога или сам прогрессдиалог, то придётся лезть под капот этого парсера.. 

Не вижу где он "завязан" на UI, ну может QMessageBox. А так нормально, юзается интерфейс прогрессдиалога, в кишки не влазим. И, зная Вас, убежден что никакого feedback'а в Вашей реализации не случилось бы вообще - ушли бы гулять с собачкой, и все 

Во-вторых сама реализация парсера.. мм.. не самая изящная.. 

Так никто ж не мешает показать "более изящную", богатырскую силу буста и освоившего его программиста 

Спасибо, Игорь, мне уже и добавить нечего 

Что касается "завязки" на GUI - ну знаете, я все-таки семестровый проект пишу, а не корпаративный продукт от Adobe. Строгой независимости классов с меня никто не требует. 

Дело не только в завязке на гуи.. (хотя это уже о многом говорит)
Сама реализация парсера в аля процедурном стиле(
Да и использование сплита.. где то я это уже видел)   

[Old]

Что касается "завязки" на GUI - ну знаете, я все-таки семестровый проект пишу, а не корпаративный продукт от Adobe. Строгой независимости классов с меня никто не требует.  

Не обижайтесь, я нисколько не хочу принизить ваш код.
Просто мне было непонятно, откуда такая избирательност, почему наш "профессионал" хвалит одного и ругает другого? Хотя и у вас и у 8Observer8, есть что поругать, и что похвалить.
Сейчас я понимаю, что 8Observer8 "в опале" за то, что не внемлет "профессионалу". И главное он может не переживать дальше: все что он будет делать - будет называться халтурой.

[Hrundel]

Не обижайтесь, я нисколько не хочу принизить ваш код.
Просто мне было непонятно, откуда такая избирательност, почему наш "профессионал" хвалит одного и ругает другого? Хотя и у вас и у 8Observer8, есть что поругать, и что похвалить.

Да я и не обижаюсь совсем   Я на великое не претендую. Я, ведь, еще учусь!

Ну, на счет Игоря, могу сказать, что он как-то помог написать мне кусок кода. Мне было все очень понятно. Его стиль мне нравиться. Это наверное как в искусстве - кто-то импрессионистично картины пишет, кто-то академично. И то, и другое имеет место быть. Рамок быть не должно - иначе не будет открытий. А правила, конечно, соблюдать надо. Без граммотности красота не возможна.

Давайте лучше переключимся на ТС. Что-то он не отвечает больше. Получается у него там парсеную модельку показать?

Да, и мнение M_AX по коду ТС, тоже было бы интересно выслушать.

А по поводу сплита я как-то не понимаю. Для всего есть свой инструмент. Вилкой суп есть не будешь. Сплит прост и удобен. Ошибок в его работе вроде как не замечено.

На счет парсера в "аля процедурном стиле" тоже не понял. Может быть какой-то другой стиль в подходе к парсеру? И он действительно необходим?
Тогда, прошу привести пример кода. А то, как-то, M_AX голословно все у вас.

[OKTA]

Мне кажется, что Old и Igors давно уже должны устроить ООП-баттл 

[8Observer8]

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

Вот кубик, который задаётся в самой программе:



Исходники: https://github.com/8Observer8/Cube