Comments 12
классно, но, в конечном счете мы решаем задачу абстрактную.
Предположим у нас есть строка - "Hello World"
каждая буква это абстракция - предположим это кубик - но кубик, значит сейчас пришла такая строка, но в бесконечном мире приходит, пускай и известного размера строка, если абстракция равна геометрии на кубиках, а если не на кубиках, то длины всегда будут переменными, потомучто горы или так сказать ландшафт и искревленные, сглаженные формы имеют разную длинну строк кубиков - упрощенно так сказать. тоесть профит мы увидим только на стриминге поидее.
на бсп например мир, не важно какая у вас абстракция мир будет делать ребилд, при добавлении браша, при добавлении выпуклости в бвх это чаще ребилд или поворот, поидее тут самое нагрузное, тоесть статичный уровень известных размеров, против статичного уровня из потока визуализатора по местоположению, аля frustumGetGeometry(x,y,z) -> получаем список точек.
типо ну ок, будет так, но на кубиках или в математике можно и на массивах всё это делать. Матрица [f32;16] как не крути, ну для удобства можно сделать [Vec4f;4], тоесть если прям жестко скипая удобство всё должно быть поидее прям flat максимально ). там еще по валгринд - кешгринд можно смотреть еффект.
тоесть чанк, кубиков 16х16х16 - это просто 4килобайта, против сложно иерархичного мира без кубиков.
Похоже на то как работают query из Bevy. Но в таком виде это использовать нереально - в репозитории дикий бардак.
Папка сборки должна быть в игноре и никакие артефакты не нужно класть в неё. Разве что в релизы отправлять.
если вы хотели сделать библиотеку, то надо было разделить публичные хэдеры, которые соскладировать в общую папку include и приватную имплементацию распихать по cpp файлам.
папку с исходниками обычно называют source или src, но никак не engine. В итоге структура должна выглядеть как-то так
├─📁 src
│ ├──📁 include # библиотечные публичные инклюды
│ │ ├──📄 attribute_vector.h
│ │ ├──📄 io.h
│ │ ├──📄 multi_proxy.h
│ │ ├──📄 single_proxy.h # соблюдаем конвенции именования
│ │ ├──📄 type_traits.h
│ │ └──📄 versioned_vector.h
│ ├──📁 attribute_vector
│ │ └──📄 attribute_vector.cpp
│ ├──📁 io
│ │ └──📄 io.cpp
│ ├──📁 proxy
│ │ ├──📄 multi.cpp
│ │ └──📄 single.cpp
│ └──📁 versioned_vector
│ └──📄 versioned_vector.cpp
├─📁 examples
│ ├──📄 tags.hpp # специфичные для примера заголовки
│ └──📄 main.cpp
└─📁 tests
├──📄 test_io.cpp
├──📄 test_proxy.cpp
├──📄 test_attr_vec.cpp
└──📄 test.cpp
есть некоторый inl файл с кучкой шаблонов на который никто не ссылается. по крайней мере никто из текстовых файлов
вы хотите это сделать библиотекой или просто показываете? если библиотека, то нужно какую-нибудь лицензию указать. Что-нибудь из пермиссивных желательно - apache 2.0, mit, zlib, bsd 3 clause, например. Ну или GPL если хочется чтобы все пользователи вашей библиотеки шарили код своих игр.
Отдельно предложил бы написать cmake файл и генерировать проект для VS на его основе - заодно и кроссплатформенность появится и можно будет выпилить из репозитория все эти vcxproject и sln в корне. Можно посмотреть как оформлятют библиотеки например в beman project
Про "SoA быстрее AoS" это полный бред. Автор даже не понял суть статьи на которую он ссылается. Там весь упор был сделан не на SoA vs AoS, а на то что данные нужно группировать с умом и комбинировать ОБА подхода, а не тупо использовать только один из них как написал автор. Согласно указанной статье нужно было сделать структуру с x, y, z и потом сделать 3 вектора этих структур, а не 9 векторов с отдельными значениями. 9 векторов это ХУДШИЙ вариант, потому что для обработки ЛЮБОЙ величины (позиции, скорости или ускорения) одной точки нужно загружать данные как минимум из трех очень удаленных адресов (x любой величины лежит ооочень далеко от y и z), а их в 99% случаев обрабатывают вместе.
Соглашусь с тем, что такой комментарий без контекста, действительно неверен. Однако в контексте графики, где атрибуты желательно загружать именно что сплошными кусками памяти(так действительно быстрее), то выбор СоА здесь актуален на мой взгляд. И правда стоило обозначить этот факт!
Незнаю что вы имете ввиду, но например в OpenGL загрузка координат идет массивом структур x,y,z, поэтому в том виде который указал автор их невозможно загрузить без предварительной обработки. Т.е. сплошной кусок памяти должен содержать по переменно x y z x2 y2 z2..., а не x x2...y y2..z z2 как у автора
Я имел ввиду: "SoA быстрее AoS", действительно стоило сделать ссылку на то как грузятся данные в шейдеры. А никто не запрещает использовать заранее подготовленные структуры, их также можно сделать тегом, что собственно я и использовал в тестах этого типа данных. Учитывыя, что есть glm, не вижу в этом никакой проблемы
Извините, не могу понять, где я использовал в качестве тегов отдельные осевые координаты?
Update: похоже вы имели ввиду там где я представил партикл, да там идут отдельные вектора для хуз, но я указал это скорее для наглядности. В своем коде я разумеется юзаю теги с век3
Я говорю о главе "SoA и AoS" которая является полным бредом где вы разбиваете x y z на отдельные массивы и утверждаете что так быстрее, при этом ссылаетесь на статью в которой написано СТРОГО НАОБОРОТ. В статье по ссылке описывается Hot/cold splitting и основываясь на этом нужно было разбить так как я описал выше,т.к. x y z в 99.99999% случаев используются вместе поэтому их нужно группировать в одну структуру, а не разбивать по разным уголкам оперативной памяти чтобы потом собирать их отовсюду насилуя кэш процессора.
Так и я за это. Я даже сначала подумал что вы имеете ввиду разделять хуз на векторы х, у и з. Написал кучу текста почему лучше хранить хуз в одной структуре, приводил доводы, но перечитав ваш комментарий понял что вы имеете ввиду, как раз противоположное. В этом вопросе я полностью на вашей стороне, я собственно сделал поправку в статье в честь этого
Клепать N! классов мешей, где N - число атрибутов.
2^N. Сразу настроило на негативный лад.
«ECS — like» вектор на с++