- Dmitry_Milk
- Участник
totoro
> Дельты поворотов должны применяться каждый кадр, иначе объект за мышкой не будет поворачивать.
Самая левая ось всегда будет следовать за мышкой. Положение второй будет зависеть от первой, да, но ты можешь не отпуская кнопку мыши вернуть первую ось в ноль (ведь мы начали с нулевых углов в момент нажатия кнопки мыши) и тогда вторая ось будет вести себя как надо.
Dmitry_Milk
> Ну, например, ты нажал кнопку мыши для осуществления поворотов - с этого момента объект у тебя крутится эйлером
ну...мышкой у меня ArcBall-ом крутится нормально (как и сама камера ArcBall-ом крутится, это ж cad), там проблем нет, но в CAD-е поворот мышкой - это так, для понта, основные повороты должны быть чёткими, по трём осям и в основном 0...90...180...270, поэтому в моём случае такой подход не проканает, т.к. мне нужно вводить угол в GUI, то есть все твои манипуляции по сути работают только для одного раза, ну как бы для одноразового ввода дельты (ввёл цифру, нажал enter), после всё теряется и обратно только через undo/reset.
master-sheff
> Так что ли?
ни видео не очень понятно. Так ты победил эти углы? Если да, то попробуй повернуть, например, сначала по X на 90, потом по Y на 90, затем по X вернись на 0, потом по Y вернись на 0 и посмотри, встанет твой объект в исходную позицию или нет.
THE_MASTER
> ни видео не очень понятно. Так ты победил эти углы?
Так у него не CAD, у него поверхностный шутер. Там эйлеровы углы ложатся естественным образом, вертикальная ось перса совпадает с вертикальной осью мира и является самой левой в цепочке преобразований. Остальные оси уже вторичны.
Вот если 6DOF типа Descent или Shattered Horizon - тогда та же проблема что в CADе. Новичкам в дескенте особенно "весело", когда корабль выворачивает после пары движений мышкой, пока не освоятся с тем, что надо дополнительно ролл подкручивать клавой :)
Решил проверить как лучше размещать индексы, чтобы на полную использовать вершинный кэш. Оказалось что tri_strip полосками дает всего 7% дополнительных вызовов VS, а tri_list квадратами по 4х4 .. 4х16 индексов дают 10 - 20% дополнительных вызовов. Причем дублирование стабильно на 21-25 значениях индекса.
Я ожидал что большее переиспользование индексов и типа мешлеты даст лучший результат. Оптимизировать VS пока нет смысла, но просто интересно почему так?
/A\
>Я ожидал что большее переиспользование индексов и типа мешлеты даст лучший результат.
а что значит мешлеты ? речь про мешь шейдеры?
Andrey
> а что значит мешлеты ?
Как мешлеты, но старым способом.
Проверил на мобилках, так там вершинный кэш всегда почти на максимум используется, а когда доходит до однопиксельных треугольников еще и интерполяция аттрибутов отключается.
Заодно проверил как работает IndirectDraw.
На десктопах все одинаково. На мобилках намного интереснее, на Adreno 505 indirect в 2 раза медленее, на Mali G610 indirect в 1.5 раза быстрее, на Mali T830 и G57 не работает firstInstance в indirect maxDraw=1, на Adreno 660 и PowerVR BXM одинаково.
В целом на свежих мобилках можно сделать GPU-driven подход.
Хочу рисовать квадраты в через фрагментный шейдер, чтоб не через компьют, но треугольниками получается лишние потоки на границе треугольников. Решил обрезать треугольник до квадрата через gl_ClipDistance, а в итоге он отрисовался как квадрат из 2х треугольников с helper invocation посередине, да как так то?
Если обрезать через буфер глубины, то также. Похоже на какую-то оптимизацию от NV, где железо может рисовать только треугольники.
/A\
> Хочу рисовать квадраты в через фрагментный шейдер
А точки большого размера пробовал?
}:+()___ [Smile]
> А точки большого размера пробовал?
Забыл про них)
Точки не разбиваются на треугольки.
А как делают отражения для множества мелких источников света?
Например фонари на мокром асфальте/воде. Нужно проверить что из каждой точки виден источник света и нужно как-то ограничить перебор всех источников света. Для воды это сделать сложно, так как рябь дает всевозможные углы. Reflection probe может потерять мелкие источники.
/A\
> фонари на мокром асфальте/воде
Для плоских отражающих поверхностей рендер в текстуру чем плох?
Mikle
> > фонари на мокром асфальте/воде
> Для плоских отражающих поверхностей рендер в текстуру чем плох?
Я про спекулярные отражения, тут рендер в текстуру не поможет. И где ты видел плоский асфальт? )
/A\
> спекулярные отражения, тут рендер в текстуру не поможет
Отрендеренную текстуру выводить с бампом, причём, чем сильнее бамп, тем меньше заметно отклонение от плоскости, весь асфальт на данной картинке можно будет считать плоским. Можно сделать Френель, зависимый от нормали.
Mikle
Ты про планарные отражения? Они же для зеркал.
Тут даже рендер в текстуру не нужен, по BRDF находится конус в котором могут быть отражения, нужно только получить все источники света в этом конусе и сделать это для каждого пикселя.
В киберпанке над таким долго мучались и только с RTX смогли сделать нешумящие отражения.