Russian Qt Forum

Привет, друзья!
Интересуюсь такой темой. Возможно ли гарантировано перевести массив QVector3D в массив float?
Для наполнения буфера QOpenGLBuffer нужно в качестве void *data передавать координаты вершин (xyzxyzxyz...). Но если я храню вершины именно в таком виде, то проводить какие-либо операции с таким массивом неудобно. Постоянно приходится индексы домножать на 3... Вот и интересуюсь возможностью передавать в void *data указатель на массив QVector3D.

Та неужели ??? И вумные итераторы никак не помогают?  :)

Таких средств в языке нет, все приводят. Для очистки совести вставьте

C++ (Qt)
Q_ASSERT(sizeof(QVector3D) == sizeof(float) * 3);

Нет, итераторы помогают в другой задаче.
В этой же я рассматриваю вариант иметь QVector<QVector3D> vertices и в функцию наполнения буфера вставлять vertices.data(). Но я боюсь так делать, потому что завтра класс QVector3D может обзавестись новыми членами...

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

Да, можно.

Структура Vertex, например, плотно пакуется, поэтому можно использовать

C++ (Qt)
struct Vertex
{
   float x;
   float y;
   float z;
}
 
Q_STATIC_ASSERT( sizeof( Vertex ) == 3 * sizeof( floet ) );
 
QVector< Vertex > vertices;
QOpenGLBuffer buffer;
 
...
 
buffer.write( offset, vertices.constData(), 3 * vertices.count() );
 

Все же нужно гарантировать размер, поэтому используем Q_STATIC_ASSERT

C++ (Qt)
typedef QVector3D Vector3D;
 

а если завтра поломают кютешный, то пишете свой класс, и меняете только тайпдеф:

C++ (Qt)
typedef MyValidVector3D Vector3D;
 

Old, мне нравится ваш вариант.
А нам стандарт гарантирует, что x и z не будут поменяны местами в памяти? Ну это так, уже перфекционизм :)

Да

Напомню что QVector3D - мягко говоря, далеко не самая лучшая реализация класса вектор/точка. Напр сейчас большинство таких классов в различных приложениях имеют не 3, а 4 float. Возможно есть смысл подыскать более продвинутый класс, зависимостей он не тянет

Igors, вы можете посоветовать какой-то конкретный класс?
Для 4 float можно же взять QVector4D

Напр очень неплох btVector3 (open sources Bullet). Или погуглите Vec3, Vector3, Vec3f
Тут дело не просто в "четырех", подумайте зачем так сейчас делают (Вы знаете ответ, даже создавали такие темы)

Честно говоря, я не увидел преимуществ у btVector3 над QVector3D...

Не понимаю, на что именно вы намекаете. Четвёртая координата - так называемый множитель. Я всегда использую w=1.

у btVector3 w=0 в конструкторе

Видимо Вы просмотрели doхygen документацию, а Вы сам хедер-то откройте (btVector3.h), там "аж кишит", какие уж тут "намеки".

А Вы поизучайте, сравните напр доступ к членам, конструкторы по умолчанию, операции скалярного и векторного произведения и.т.п. Возможно Вы обнаружите что btVector3 многое делает "совсем не так как в книжке" :) Он заточен на профессионала, а QVector3D - на читателя ассыстента.

"Ты посмотри какой котон, какие лейблы..." (c) СОиП
:)

QVector3D богомерзок... Юзайте флоты и будэ щастя...

А на чем основывается это мнение ?

Ну вот нужно, например, glVertexPointer использовать.
Массив из QVector3D надо сперва преобразовать в массив флотов.
Потому что чего-то типа QVector3DList у нас нету, и никто не гарантирует, что эти вектора будут лежать в памяти последовательно.

QVector3D сейчас это:

C++ (Qt)
struct
{
    float x;
    float y;
    float z;
}
 

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

То, что завтра этот класс может изменить свою внутреннюю структуру, это другой вопрос.

glVertexPointer (как и др ф-ции передачи геометрии) имеет stride, который как раз для данных "не идущих подряд". Так что это не проблема

Еще аргументы против QVector3D? Или Вы просто так сказали про "богомерзкость"?  :)

Как минимум это уже потенциальная проблема.
К тому же при аллокации вектора будут вызываться конструкторы класса, соответственно деструкторы при деаллокации. Производительность будет страдать.

stride может сам по себе и не проблема, но это еще один дополнительный параметр, который придется принимать во внимание.

Так а конструктор в этом классе ничем не отличается от обычного копирования float, деструктор по умолчанию. Думаю, что все потенциально лишние копирования компилятор соптимизирует.

Хорошо, если так. Но если вдруг разработчик решит еще пару фич туда запихать?

А вот тогда, его придется заменить своим, с нужным устройством и поведением. :)
Но это "тогда", а чем он вам сейчас не нравиться?

Ну тогда

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

Воткнуть вместо нуля sizeof - ой как много работы  :)

Совершенно верно
Нет, конструктору велено заполнить нулями - он и заполнит

C++ (Qt)
std::vector <QVector3D> vec(n);
<QVector3D> temp[32];  // или так
<QVector3D> v0, v1, v2;  // или даже так
 

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

Ну это еще цветочки. Что еще плохо в QVector3D ?

Вы переживаете, что изменится внутреннее устройство?

Что это значит? Вам не хватает функционала, вы хотели бы, что-бы он был более наворочен? Тогда с производительностью это может быть не совместимо.

Не обижайтесь, но пока это похоже на капризы, основанные на страхе. ;)
Ну и да, я не призываю использовать QVector3D. :)

"Сам по себе" QVector3D не является чем-то ужасно плохим :)
Просто, скажем так, все зависит от области применения.
Если надо посчитать несколько десятков 3д-векторов в пространстве - то не проблема. Сами юзаем иногда.
Но когда речь о высокопроизводительном приложении с большими объемами данных - то для подобных целей считаю данный класс неуместным.
Раньше приложение у нас использовало массивы из QVector3D. Когда перешли на plain float array - производительность выросла, а расход памяти уменьшился. Плюс стало возможно "напрямую" юзать всякие там sse-интринзики :)

Является

производительность - верю. Но расход памяти и, особенно, "sse-интринзики" - ой заливаете  :)

Почему? :)


"вай, мамай клянус!"
А как прикажете применить интринзики к QVector3D  ???

Racheengel,

C++ (Qt)
#include <QVector>
#include <QtDebug>
 
struct A{
    A(){
        qDebug() << "Constructed";
        a_ = 0;
    }
    A(const A &other) {
        qDebug() << "Copied";
        a_ = other.a_;
    }
    float a_;
};
 
 
int main()
{
    QVector<A> vec;
    vec.reserve(3);
    vec.append(A());
 
    qDebug() << sizeof(A);
    return 0;
}
 

Вроде, ничего лишнего

В памяти вектор QVector3D это последовательность float: x, y, z, x, y, z, ...
С помощью плохих кастов можно получить float*

Имеется ввиду:

C++ (Qt)
QVector3D vec[ 100 ];
 
// или
 
QVector<QVector3D> vec( 100 );
 

В этих случаях 100 раз будет вызываться дефолтный конструктор QVector3D.

Или x,y,z, [gap], x,y,z, [gap]

Кто гарантирует, что на разных платформах не появится никакого чудо-выравнивания, например?

C++ (Qt)
#include <QVector>
#include <QVector3D>
#include <QtDebug>
#include <QTime>
 
 
int main()
{
    QTime time;
    time.start();
    QVector<QVector3D> vec(9999999);
    qDebug() << time.elapsed();
    return 0;
}

Насчёт гапов тоже интересуюсь. Только не нашёл ссылок на стандарт. В c99 они возможны. А что насчёт c++11?

Стандарт. Структуры в памяти располагаются строго друг за другом.
Вот в самой структуре поля могут выравниваться, но они будут одинаково выравнены, что для:

C++ (Qt)
struct vec
{
    float x;
    float y;
    float z;
};
 
vec v;
 

что для:

C++ (Qt)
float v[ 3 ];
 

Здесь заклинивает Qt "идеология", которая на первое место ставит "удобство использования". Это конечно хорошо, но в случае QVector3D это просто идет в ущерб качеству кода. Плохо просто все, начиная с имени класса. QVecоr3D - оказывается "3D" надо понимать как  "трехмерный", а не "3 double ". Напр QVec3f было бы уместнее. Имена методов не лучше, напр

QVector3D::dotProduct
QVector3D::crossProduct

Эти операции настолько ходовые что часто их делают даже операторами. А тут длинные static портянки которые задолбают через неделю работы.

Ладно, не будем придираться к именам, содержательная часть
Отак от! Оказывается выбор между normalize() и normalize_safe() (нормализация с проверкой) Qt пользователю не нужен. Будем просто сами всегда проверять (удобство использования), а не удается нормировать - вернем нулевой, пусть будет Nan на следующей операции. Перлы с fuzzy  из той же оперы. Как можно было накосячить в том что прекрасно известно десятки лет - хз.

Идиотское setX(Y, Z) - нет слов

distanceToXXX - на мой взгляд, просто оскорбление. Типа "ты ничего в геометрии не рубишь, записать 1 строку тебе тяжело. Не беда - мы вот сделали такой чудесный класс что и без всяких познаний (чисто на букваре) все сделаешь! Кормись, лошок, кормись!". Зачем же так плохо думать о пользователе?  :'( :'(

SSE нет и намека, хотя люди его уже лет 10 имеют. По нынешним временам это просто неприлично. Кстати, именно поэтому не спешите городить свой класс.

Зато да, для человека с этим никогда не работавшего - все прекрасно, просто отлично. Но ведь это надувательство.  Ладно, будем надеяться что таких классов в Qt немного, и на солнце есть пятна

У вас очень тонкая грань между "удобство использования" и "Кормись, лошок"

Насчет "одинакового выравнивания везде и всегда", увы, не соглашусь.

http://stackoverflow.com/questions/5397447/struct-padding-in-c

Да и практика иное показывает.

А для float, float, float такие примеры есть?

Еще раз.
Структуры в памяти всегда располагаются без паддинга, одна к одной.
Паддинг внутри структуры может отличаться в зависимости от архитектуры, но ровно такой-же паддинг будет и при упаковки массива таких типов. Проще говоря структура из 3 float всегда будет выравниваться также как и массив из 3 float.

/offtop

"reinterpret_cast класса в массив"
Из-за подобных хитростей программист с++ и может цитирую
Продолжайте срач :)

А почему Вы думаете она вообще существует?
Очень разная эмоциональная окраска - но смысл-то одинаков :)

Ах как мы блещем знанием хабровских статеек! Пусть вопрос не стоит выеденного яйца (всегда можно использовать stride) - но не напрасно же читал!  :)

Ну на самом деле это действительно очень гадкий хак и я бы им не пользовался. :)

Old, а что бы вы сделали?

Вот есть у нас 3 флота. На 3д вектор это 12 байт, верно? Допустим, у нас 10 миллионов векторов. Это 120 мегабайт (примерно). Каждый страйд плюс 1 байт означает, что как минимум 10 мб будут уходить в нирвану. Много это или мало? Вроде бы мало, да. Но тут 10, там 10, и кто знает, как оно через пару месяцев будет, с какими данными (какого объема) придет зоказчег...

Ну то есть, мелочь, конечно же... А потом народ удивляется - купили комп с 4 гигами памяти, только винда голая стоит, а 3 гига уже заняты с прыжка :)

Не один а 4 (40 Mb). Но все SSE (AVX и.т.п) требует чтобы адрес был выровнен на 16, иначе exception. Поэтому на эти расходы идут, скорость важнее

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

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

Набросок:

C++ (Qt)
class VecRef
{
public:
    VecRef( float *v ) : m_data( v ) {}
 
    float    &x() const { return m_data[ 0 ]; }
    float    &y() const { return m_data[ 1 ]; }
    float    &z() const { return m_data[ 2 ]; }
 
private:
    float    *m_data;
};
 

Т.е. сама ссылка данные о точке не хранит, а имеет указатель на первый float точки из коллекции.

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

Спорно или нет - но так делают.

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