- 1
- 2
gl.drawArrays(gl.QUADS, 0, 4);
// WebGL рисует черный экран с четырьмя точками.-
JavaScript / Говнокод #14327
+167
bormand vs WebGL. Акт второй.
Как оказалось, в OpenGL ES выпилили GL_QUADS и GL_POLYGON.
Но т.к. в js несуществующее поле это null, а null это 0, а 0 это GL_POINTS, то рисуются 4 точки ;)Запостил:
bormand,
07 Января 2014
Follow us!
Правильно сделали. Выпилили устаревшее говно. Треугольники только нужны. На крайний случай можно оставить точки и линии, но и то не сильно нужно
> но и то не сильно нужно
Линии не трожь! Заебешься же потом их треугольниками рисовать ;) А из точек, емнип, делаются отличные и очень дешевые системы частиц.
а бугорки когда дождинка разбивается о землю - точками
Трабла тут в том, что из прямоугольников не сложить произвольную фигуру.
Ну если это не пиксели :)
так вот на треугольники хардвар саппорт есть, а на многоугольники может когда-то и была хардвар поддержка в каких-нибудь редких opengl френдли картах, то сейчас уже не встретишь такую карту.
Нахуй не надо. Просто надо отказаться от стандартной питушни "разделим треугольник на два, долго сортируя его вершины и разбирая джва случая - промежуточна вершина справа от грани или промежуточная вершина слева от грани".
Потому что кармак не осилил цветное освещение, а видяхи не осилили чтобы всё плавало под водой и ещё пейсатели опенглорендера не осилили ещё дохрена чего, вот статья по теме: https://www.quaddicted.com/engines/software_vs_glquake
В смысле? На какой карте? На любой, даже 98 года.
Это про ку1, он у меня на ускорителе вообще не шел, а я про ку2, там реально разная цветовая гамма.
Твой пост:
> Почему q2 на софтваре и на 3d выглядит по-разному?
Ты понял что блять написал?
В ку2 кармак ниасилил цветное освещение в софтваре, то ли цветов не хватило, то ли ещё что, а в ускоренных режимах осилил.
На 3д ускорителе, не приёбуйся. Бля, там гамма абсолютно другая - на софтваре q2dm1 зеленый, а на 3d - желтый.
Как отделять полигоны друг от друга в батче? Делать какой-то разделитель? Передавать длину? Делать 100500 батчей по одному полигону вместо одного стрипа? У тебя меш будет весить больше, чем если его составлять из тупых треугольников :)
А бить модель на треугольники, в большинстве случаев, надо один раз - при экспорте модели.
Короче, имхо, оно того не стоит.
Хм, как же процессор это делает?
Что-то мне кажется, что на видюхе все-таки стоит какой-то совсем кастрированный аппаратный модуль (ALU'шки, счетчики, регистры и т.п.) для разбиения треугольников на пиксели + железный интерполятор varying переменных по площади этого треугольника. Ну не тратят же они на это ресурсы модулей, которые занимаются пиксельными шейдерами? Эти пиксельные шейдеры на старых видюхах были довольно убогими, и до совсем недавнего времени даже циклы не могли крутить. А треугольники же как-то рисовали ;)
И впиливать в такой модуль поддержку чего-то кроме треугольников - усложнять и замедлять его.
Но я могу ошибаться, т.к. архитектуру видюх не изучал.
Ну вот x86 взять. Снаружи CISC, типа удобство для программера (хотя с таким набором как сейчас и в разных процах совершенно разные наборы комманд, оптимизация кода приводит к написанию N веток).
Но внутри ведь оно RISC, то есть бьётся декодером на мелкие операции (МОПы).
Декодер инструкций конечно занимает довольно много места на кристале и электичества тоже. Но это получается как фасад, более удобный для человека.
И одна инструкция это как батч, а внутри она может разбиваться на сотни МОПов (см. строковые фичи из SSE4.2)
>>считается теми же модулями
Вот MMX,SSE,AVX и x86 целочисленные инструкции, они исполняются на одних и тех же вычислительных блоках.
Операции с памятью (неважно какой набор) используют одни и те же LOAD/STORE, дробные - тоже.
Только SSE,AVX - это примитивные своего рода батчи. Идея та же.
Block Reuse короче.
Кстати борманду тоже +1.
Плюс там код исполняется только пачками (нвидия зовет их варпами) по 32 потока. И если я правильно понял, они всегда идут синхронно. Т.е. крутить в пределах одного варпа в одном потоке цикл до 2 а во втором до 3 не выйдет. Тот, в котором 2 итерации должен тупо пропускать инструкции и ждать, пока второй делает третью...
Вот в таких условиях я бы не рискнул мутить заливку произвольного многоугольника...
Хотя это и есть будущее нв и интел к одному идут, хоть и с разных сторон - ассимиляция видюхи и проца.
Ну и кому интересно (в частности Борманду) почитайте о NVidia GRID - занимательно, но нужно знать буржуйский
No problem :)
> почитайте о NVidia GRID
Да мне это юзать негде, разве что в общем плане посмотреть, для развития.
А я когда-то хотел сделать свой игровой движок на крестах. Но что-то меня вовремя остановило...
А нвидиевские и атишные GPU же можно не только для игрух юзать.
Просто 32 полноценных треда будут жрать больше, чем 32 вот таких вот слепленных в кучу. И транзисторов будет на порядок больше, а там их уже где-то 2.5миллиарда.
А для обработки картинок, физики, да всяких FFT слепленные треды, имхо, вполне подходят.
Ну и эта синхронность не только недостаток. Треды в пределах одного варпа могут общаться друг с другом без синхронизации и ожиданий.
RISC и её последователи тем-то и хороши, что они могут шустро делать очень много мелких и простых операций.
Минималистичный подхоод - разбиение на примитивы, простые блоки и последующую компоновку он имеет много применений.
И в лего, и в проектировании софта, и в строительстве домов и в геймдеве тоже.
Я бы назвал многоугольники графическим сахаром.
PS. +1 LispGovno по треду.
Тем более они не так часто и нужны. Большинство интересных и красивых моделек в играх все-таки не квадратные кирпичи, и не додекаэдры, а нечто, имеющее кучу криволинейных форм, которые удобней всего приближать как раз большим числом треугольников.
Это ты открыл для себя SIMD? :)
>называется по-другому.
MIMD, внезапно.
undefined | 0 // => 0
undefined >>> 0 // => 0
А в стоке нету потому что еще никто не комментировал.
Разве не undefined?
undefined конечно. Выше уже об этом отписали.