Опять уже сдался было, сел ужинать и, внезапно, понял, где, вероятно, корень проблемы.
Преобрзование растяжения у меня выполнялось по прежнему через x * minMid + xMid, а не матрицами, причём координату z я после перспективного искажения не преобразовывал вовсе. Стоило домножить её на 2 (r у меня был выставлен в -0.5) и хоть я не уверен пока (спешу опубликовать находку), почему именно 2 (эксперименты показывают, что это явно не -1/r), но суть ясна - надо сначала реализовать честную камеру на матрицах.
P. S. Кстати, подозрительно справа проступает синяя полоска, наверное из-за ещё каких-то ошибок округления или граничных случаев.
Да и верхняя горизонтальная граница стала зубчатая.
Куда же пропали "r *" и "+1" из знаменателя? Разве там не должно быть: bc_screen.x/(r * (pts[0][3] + 1)? Они как-то хитро сократились из-за последующего деления на сумму тех же компонент?
Зачем в преобразовании нормальных векторов вообще появляется транспонирование? Разве не проще применить сразу обратную без её транспонирования (как и записано в предыдущем шаге преобразований)?
И далее разве утверждение
нормаль к преобразованному объекту получается преобразованием исходной нормали, обратным к транспонированному M
не упускает того факта, что потом надо ещё транспонировать целиком произведение обратнотраспонированной на нормаль? Что также расширяет первый вопрос о целесообразности транспонирования "туда и обратно".
P. S. Или поскольку нормаль — это вектор, то нам без разницы транспонирована она или нет в записи (важны лишь координаты), а запись такая только ради порядка умножения матрицы на вектор (как в OpenGL)? Значит в OpenGL всегда делается лишняя операция транспонирования? Это не сказывается на производительности (где-то есть наоборот выигрыш за счёт такого подхода)?
Ради быстрого результата пока оставил умножение вектора строки на матрицу, и, если я правильно понял, вращение получилось правильное - это вокруг OZ на 0.2 Пи с помощью матрицы
Дошёл до этого урока про матричные преобразования, думая, что тут-то я просто возьму соответствующий код из своей старой реализации движения, вращения и проецирования проволочного куба, но, кажется, я запутался в столбцах и строках. Помню где-то читал, что в DirectX используются векторы строки и умножение на матрицу преобразования, а в OpenGL всё наоборот - вектора столбцы и умножение матрицы на этот вектор. Это так? Может быть тема раскрыта в следующих статьях курса (я их ознакомительно пролистал, но не нашёл)?
Причём всё было ещё более менее понятно до тех пор, пока я не решил погуглить про эффективные реализации матричной математики на JS, потому что я наткнулся вот на это: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Matrix_math_for_the_web Где матрица сдвига выглядит как и в моей реализации (через умножение вектора на матрицу)
1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
x, y, z, 1
Но потом матрица вращения вокруг Oz там транспонирована по сравнению с той, что у меня.
Здесь то в статье всё одинаково транспонировано относительно моих матриц и сдвиг и вращение и проецирование. Можно было бы предположить, что это в той статье ошибка, но у них там ссылка https://jsfiddle.net/b8zjc3ys/, где всё работает. Возможно ещё дело в "правой" или "левой" системе координат, в том, направлен Z в экран или из, а Y -- вверх или вниз. Или в том, вращение по часовой стрелке или против. Да ещё на странице https://glmatrix.net/ в разделе "A note about Matrix formatting", говорят что в докуемнтации OpenGL одно представление, а в коде другое.
Я пару часов над этим багом сидел и когда уже сдался и пошёл играть в Starcraft, прямо во время загрузки игры, понял в чём ошибка! Меня подвела преждевременная оптимизация - я использовал метод subarray, получая значения пикселя текстуры. Этот метод возвращает объект, данные которого хранятся в том же буфере, что и вся текстура. И затемнение я делал меняя значения этого объекта, а затем уже копировал его в буфер кадра. А так как точки текстуры в следствие интерполяции с последующим округлением соотносятся с точками экрана не как 1 к 1, то есть одна и та же точка текстуры соответствует нескольким пикселям экрана, то одни и те же точки в буфере подвергались затемнению несколько раз. Заменил subarray, на slice, который возвращает новый массив, и артефакт исчез.
Пишу на JS. Затемнение на основе нормалей полигонов и текстурирование по отдельности выглядят нормально, но при затемнении поверх текстуры появляется сетчатая "штриховка". Подозреваю что причина в каких-то округлениях, но где именно?
вы их все слили в интернет, так что сейчас все будут бегать кругами и придумывать новые
Ящитаю, это очень хорошо. Человечество от этого только выиграет. Если все так и будут
всегда поступать, со временем сформируется "база знаний" автоматизирующая решение подобных задач, высвобождая время для более полезных вещей. Хотя, конечно, есть некоторая вероятность, что потеря такого фильтра навсегда лишит общество некоего жизненно важного градиента, оставив нас в локальном минимуме эффективности. Но это скорее в предельно длительной перспективе, а на наш век всё-таки — одна выгода.
Какой смысл в использовании JWT, если всё равно используются сессии на стороне сервера?
Я думал его основная цель — сокращение числа запросов к хранилищу, которое требуется для серверной сессии.
В начале вы пишете, что с сокетами JWT не взлетел
так как в данном протоколе передача хедера Authorization с jwt токеном невозможна
и единственная альтернатива — параметры URL, а в итоге получается, что вы используете другую альтернативу
он отправляет событие auth_login по сокетам, с jwt токеном
— передаёте JWT в теле сообщения через сокеты.
Наверное я что-то неправильно понял. Впрочем как и с той статьёй, что вы рекомендовали
Когда я её в своё время прочитал вместе с комментариями, показалось, что никто на самом деле и не знает, зачем нужен Refresh токен, и вообще как и какие проблемы решает JWT, а какие создаёт. Чего стоят одни только вопросы реализации отзыва токена и безопасности его хранения на стороне пользователя.
Элементарно. Запускать бинарник из процесса, который стартует (инсталирует, суспендит, закрывает) службу и выполняет в ней бинарник, при этом перехватывает stdout бинарника и пишет его в системный журнал
Это совсем не элементарно и потому вызывает сомнения в целесообразности.
Какую проблему решит такой подход по сравнению с изоляцией логики логирования классическими средствами модульности (абстракции, библиотеки)?
В проектах какой компании можно встретить реализацию такого подхода к Windows Service? Где-то можно почитать об опыте его использования? Ведь надёжное межпроцессное взаимодействие штука не дешёвая.
Как именно можно перенаправить Windows Service StdOut в Event log при запуске службы, следуя принципам двенадцати факторов?
И почему кстати Event log предпочтительнее иных средств, например, тестовых файлов?
У меня только 8 лет на шарпе, и я как раз столкнулся с подобной ситуацией, только вместо node.js (который мне как раз знаком), предлагается Go. Не знаю как реагировать. Есть только подозрение, что цели этой затеи работодателя противоположны моим, как разработчика.
Опять уже сдался было, сел ужинать и, внезапно, понял, где, вероятно, корень проблемы.
Преобрзование растяжения у меня выполнялось по прежнему через x * minMid + xMid, а не матрицами, причём координату z я после перспективного искажения не преобразовывал вовсе. Стоило домножить её на 2 (r у меня был выставлен в -0.5) и хоть я не уверен пока (спешу опубликовать находку), почему именно 2 (эксперименты показывают, что это явно не -1/r), но суть ясна - надо сначала реализовать честную камеру на матрицах.
P. S. Кстати, подозрительно справа проступает синяя полоска, наверное из-за ещё каких-то ошибок округления или граничных случаев.
Да и верхняя горизонтальная граница стала зубчатая.
В упомянутых в статье исходниках вижу какое-то противоречие приводимым математическим выводам.
Куда же пропали "r *" и "+1" из знаменателя? Разве там не должно быть:
bc_screen.x/(r * (pts[0][3] + 1)? Они как-то хитро сократились из-за последующего деления на сумму тех же компонент?
Опять нужен сеанс дебага по фотографии.
Явно стало лучше, но как-то не до конца. Как же так?
Зачем в преобразовании нормальных векторов вообще появляется транспонирование? Разве не проще применить сразу обратную без её транспонирования (как и записано в предыдущем шаге преобразований)?
И далее разве утверждение
не упускает того факта, что потом надо ещё транспонировать целиком произведение обратнотраспонированной на нормаль? Что также расширяет первый вопрос о целесообразности транспонирования "туда и обратно".
P. S. Или поскольку нормаль — это вектор, то нам без разницы транспонирована она или нет в записи (важны лишь координаты), а запись такая только ради порядка умножения матрицы на вектор (как в OpenGL)? Значит в OpenGL всегда делается лишняя операция транспонирования? Это не сказывается на производительности (где-то есть наоборот выигрыш за счёт такого подхода)?
Результат
Ради быстрого результата пока оставил умножение вектора строки на матрицу, и, если я правильно понял, вращение получилось правильное - это вокруг OZ на 0.2 Пи с помощью матрицы
Дошёл до этого урока про матричные преобразования, думая, что тут-то я просто возьму соответствующий код из своей старой реализации движения, вращения и проецирования проволочного куба, но, кажется, я запутался в столбцах и строках. Помню где-то читал, что в DirectX используются векторы строки и умножение на матрицу преобразования, а в OpenGL всё наоборот - вектора столбцы и умножение матрицы на этот вектор. Это так? Может быть тема раскрыта в следующих статьях курса (я их ознакомительно пролистал, но не нашёл)?
Причём всё было ещё более менее понятно до тех пор, пока я не решил погуглить про эффективные реализации матричной математики на JS, потому что я наткнулся вот на это: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Matrix_math_for_the_web
Где матрица сдвига выглядит как и в моей реализации (через умножение вектора на матрицу)
Но потом матрица вращения вокруг Oz там транспонирована по сравнению с той, что у меня.
Здесь то в статье всё одинаково транспонировано относительно моих матриц и сдвиг и вращение и проецирование.
Можно было бы предположить, что это в той статье ошибка, но у них там ссылка https://jsfiddle.net/b8zjc3ys/, где всё работает.
Возможно ещё дело в "правой" или "левой" системе координат, в том, направлен Z в экран или из, а Y -- вверх или вниз. Или в том, вращение по часовой стрелке или против.
Да ещё на странице https://glmatrix.net/ в разделе "A note about Matrix formatting", говорят что в докуемнтации OpenGL одно представление, а в коде другое.
Я пару часов над этим багом сидел и когда уже сдался и пошёл играть в Starcraft, прямо во время загрузки игры, понял в чём ошибка!
Меня подвела преждевременная оптимизация - я использовал метод subarray, получая значения пикселя текстуры. Этот метод возвращает объект, данные которого хранятся в том же буфере, что и вся текстура. И затемнение я делал меняя значения этого объекта, а затем уже копировал его в буфер кадра. А так как точки текстуры в следствие интерполяции с последующим округлением соотносятся с точками экрана не как 1 к 1, то есть одна и та же точка текстуры соответствует нескольким пикселям экрана, то одни и те же точки в буфере подвергались затемнению несколько раз. Заменил subarray, на slice, который возвращает новый массив, и артефакт исчез.
Пример
Пишу на JS. Затемнение на основе нормалей полигонов и текстурирование по отдельности выглядят нормально, но при затемнении поверх текстуры появляется сетчатая "штриховка".
Подозреваю что причина в каких-то округлениях, но где именно?
Ящитаю, это очень хорошо. Человечество от этого только выиграет. Если все так и будут
всегда поступать, со временем сформируется "база знаний" автоматизирующая решение подобных задач, высвобождая время для более полезных вещей. Хотя, конечно, есть некоторая вероятность, что потеря такого фильтра навсегда лишит общество некоего жизненно важного градиента, оставив нас в локальном минимуме эффективности. Но это скорее в предельно длительной перспективе, а на наш век всё-таки — одна выгода.
Я думал его основная цель — сокращение числа запросов к хранилищу, которое требуется для серверной сессии.
В начале вы пишете, что с сокетами JWT не взлетел
и единственная альтернатива — параметры URL, а в итоге получается, что вы используете другую альтернативу — передаёте JWT в теле сообщения через сокеты.
Наверное я что-то неправильно понял. Впрочем как и с той статьёй, что вы рекомендовали Когда я её в своё время прочитал вместе с комментариями, показалось, что никто на самом деле и не знает, зачем нужен Refresh токен, и вообще как и какие проблемы решает JWT, а какие создаёт. Чего стоят одни только вопросы реализации отзыва токена и безопасности его хранения на стороне пользователя.
На части скриншотов "Python" в Google Trends включает ещё и запросы касающиеся змей.
Это совсем не элементарно и потому вызывает сомнения в целесообразности.
Какую проблему решит такой подход по сравнению с изоляцией логики логирования классическими средствами модульности (абстракции, библиотеки)?
В проектах какой компании можно встретить реализацию такого подхода к Windows Service? Где-то можно почитать об опыте его использования? Ведь надёжное межпроцессное взаимодействие штука не дешёвая.
Как именно можно перенаправить Windows Service StdOut в Event log при запуске службы, следуя принципам двенадцати факторов?
И почему кстати Event log предпочтительнее иных средств, например, тестовых файлов?
Как должен логировать в консоль, например, Windows Service?
Чем настройки отличаются от конфигурации?
По моим предположениям:
У меня только 8 лет на шарпе, и я как раз столкнулся с подобной ситуацией, только вместо node.js (который мне как раз знаком), предлагается Go. Не знаю как реагировать. Есть только подозрение, что цели этой затеи работодателя противоположны моим, как разработчика.
Чтобы стать незаменимым?