VK
Не понял?
В SetPositions передавать одно, а в SetNormals вообще что-то левое. Почему это два метода?
Size: a a a
2020 February 11
FM
В SetPositions передавать одно, а в SetNormals вообще что-то левое. Почему это два метода?
Ну у тебя условно plane_position = {...} plane_normal = {}
VK
Всё, что можно оставить на время компейляции, лучше оставить именно там.
Как ты во время компиляции создашь в драйвере у конечного пользователя PSO? Мы о PSO говорим
d
В SetPositions передавать одно, а в SetNormals вообще что-то левое. Почему это два метода?
только вот эти функции мне не нужны, вместо них просто реализуешь интерфейс и записываешь в буферы того кто попросит когда попросят
FM
Естественно если у тебя не совпадает количество элементов
FM
То это ошибка
L
Ну яб сделал примерно что-то такое:
Renderer<Layout>
Primitive<Layout>
Т.е. примитивы определённого формата можно сувать только в определённые штуки, которые их едят.
Renderer<Layout>
Primitive<Layout>
Т.е. примитивы определённого формата можно сувать только в определённые штуки, которые их едят.
L
class IMesh {
public:
struct vertex {
math::vec4 pos;
math::vec3 norm;
math::vec3 tang;
math::vec2 uv;
std::uint32_t matID;
};
struct buffer_info {
std::uint32_t verticesCount;
std::uint32_t trianglesCount;
} getBufferElementsCount() = 0;
void fillBuffers(vertex* vertexBuffer, std::uint32_t* triangleBuffer) = 0;
Material* matFromID(std::uint32_t id) = 0;
protected:
~IMesh() = default;
};кто что скажет насчёт интерфейса меша?
Т.е. для вот этого конкретный формат vertex в качестве параметра этапа компиляции.
VK
А что плохого?
AOS плохо тем, что тебе под каждый формат вершин придётся для вещей, где пофиг на всякие нормали и касательные (все пассы, которые пишут только в глубину, а не в цвет), создавать разные input layouts, а это на GPU лишние контексты, а ещё у тебя данные лежат в таких пассах менее плотно тогда, хуже для кэша
L
AOS плохо тем, что тебе под каждый формат вершин придётся для вещей, где пофиг на всякие нормали и касательные (все пассы, которые пишут только в глубину, а не в цвет), создавать разные input layouts, а это на GPU лишние контексты, а ещё у тебя данные лежат в таких пассах менее плотно тогда, хуже для кэша
В таком случае лучше разделять SOA не на каждый параметр, а сгруппировать их.
VK
только вот эти функции мне не нужны, вместо них просто реализуешь интерфейс и записываешь в буферы того кто попросит когда попросят
Вот да, да меш это ресурс с диска вообще, const, какие у него могут быть сеттеры
FM
AOS плохо тем, что тебе под каждый формат вершин придётся для вещей, где пофиг на всякие нормали и касательные (все пассы, которые пишут только в глубину, а не в цвет), создавать разные input layouts, а это на GPU лишние контексты, а ещё у тебя данные лежат в таких пассах менее плотно тогда, хуже для кэша
Ну так а трафик по памяти уменьшается
VK
Ну яб сделал примерно что-то такое:
Renderer<Layout>
Primitive<Layout>
Т.е. примитивы определённого формата можно сувать только в определённые штуки, которые их едят.
Renderer<Layout>
Primitive<Layout>
Т.е. примитивы определённого формата можно сувать только в определённые штуки, которые их едят.
Depth prepass должен всё есть, что скормили
d
Вот да, да меш это ресурс с диска вообще, const, какие у него могут быть сеттеры
к этому интерфейсу вполне можно динмеш прикрутить, и у этой реализации будут всякие get set, но там явно будет иначе всё
FM
Не думаю что создание нескольких дополнительных PSO изменит картину
d
Ну яб сделал примерно что-то такое:
Renderer<Layout>
Primitive<Layout>
Т.е. примитивы определённого формата можно сувать только в определённые штуки, которые их едят.
Renderer<Layout>
Primitive<Layout>
Т.е. примитивы определённого формата можно сувать только в определённые штуки, которые их едят.
яннп
FM
Ведь для DepthPass тебе все равно придеться создавать PSO
FM
Отдельный
L
Depth prepass должен всё есть, что скормили
В том смысле, что делим данные меша на две части: одна, которая требуется для depth-пассов, а другая "остальное".
VK
В таком случае лучше разделять SOA не на каждый параметр, а сгруппировать их.
Может быть, да. Для записи в глубину без альфатеста надо только позиции, с альфатестом — позиции и текстурные координаты. Нормали и касательные рядом положить вполне есть смысл, да