Кстати, недавно юнитеки сделали разделение физических сцен, чтобы симулировать не все физические объекты, а только объекты в нужных сценах. Т.е. достаточно использовать PhysicsScene.Simulate для нужной сцены, а остальной мир будет симулироваться автоматически. blogs.unity3d.com/ru/2018/11/12/physics-changes-in-unity-2018-3-beta
После прочтения у меня 6/6, но думаю если бы не прочел статью, угадал бы только половину. Мне тоже кажется, что лучше перенести на верх и в конце предложить пройти тест снова
Никто не говорил, что Rust — плохой. C++ тоже не плохой. Они разные и у каждого есть свои плюсы и минусы. UB в C++ и вправду мерзкие. Если вдруг где-то кто-то допустил ошибку, то сложно потом найти. Но это цена за производительность. И возможно есть еще люди, которые вставляют ассемблерный код для оптимизации(хотя компиляторы очень хорошо оптимизируют). Какой нибудь Java или C# тоже ведь не плохие языки, но никто не говорит, что «в этих языках можно сделать лучше». Может и можно, но там тоже свои проблемы.
Видимо неправильно сформулировал вопрос.
Я понимаю, что у Вас есть поддержка OpenGL, и если использовать API, то все будет работать. Но ведь в Quake и так используется OpenGL API.
Вы используете Mesa, а она как раз ориентирована для ускорения рендеринга, в том числе за счет использования аппаратного ускорения.
Просто странно что у Вас по сути есть всё что нужно, но все же рендеринг программный.
Через 20 лет, — говорит он, — кто-нибудь спросит: „А вот эта игра про ведьмака — кто написал историю?” И никто не будет знать: „Кто-то написал”, — ответят они
Думаю, если бы не игра, никто бы не и спрашивал про автора. Те кто читают книгу и так видят имя автора на обложке, но таких людей просто было бы на много меньше, так что игра пошла на пользу всем.
Когда ИИ сможет создать ИИ лучше, чем он сам, улучшенный ИИ сможет создать еще более улучшенный ИИ и так далее. В итоге скайнет решит уничтожить больше половины человечества и Джон Коннор нас спасет :)
В юнити нужно сделать примерно тоже самое что и в статье, только не нодами, а кодом.
В общих чертах Вам нужно научиться:
1. рисовать кистью по текстуре(векторное поле), для этого можно использовать RenderTexture либо напрямую задавать пиксели через texture2D.SetPixels.
2. надо написать свой вершинный шейдер, который поворачивает все вершины на определенный угол вокруг точки (v.x, 0, v.z). Чтобы получить значение угла Вам надо спроецировать координаты вершины на текстуру, и цвет в этих координатах будет направлением куда поворачивать.
Чтобы это смотрелось красивее, лучше менять силу поворота в зависимости от высоты вершины, т.е v.y.
P.S. промазал веткой, это ответ для artemev на комментарий выше
Я понял Вашу мысль :)
Но мне все-таки кажется, что независимо от того какая именно сторона выпала в случае с фальшивой монетой, это не влияет на исход, т.е. не важно для нас.
Давайте подождем ответы от автора статьи. Думаю кто-то из нас сильно удивиться :)
Выбора монет не было. Мы не подкидываем монеты 2 раза. Мы не считаем количество разных подбросов чтобы получить текущую ситуацию. По условию мы имеем уже подброшенную монету и уже видим решку и от этого отталкиваемся. Нам осталось лишь перевернуть и увидеть что на обратной стороне.
Чтобы посчитать вероятность нужно знать количество возможных исходов, а исходов у нас может быть только 2, потому что мы уже подбросили какую-то монету и мы уже знаем что выпала решка, и когда мы перевернем монету там будет либо решка либо орел.
blogs.unity3d.com/ru/2018/11/12/physics-changes-in-unity-2018-3-beta
Я понимаю, что у Вас есть поддержка OpenGL, и если использовать API, то все будет работать. Но ведь в Quake и так используется OpenGL API.
Вы используете Mesa, а она как раз ориентирована для ускорения рендеринга, в том числе за счет использования аппаратного ускорения.
Просто странно что у Вас по сути есть всё что нужно, но все же рендеринг программный.
Думаю, если бы не игра, никто бы не и спрашивал про автора. Те кто читают книгу и так видят имя автора на обложке, но таких людей просто было бы на много меньше, так что игра пошла на пользу всем.
В общих чертах Вам нужно научиться:
1. рисовать кистью по текстуре(векторное поле), для этого можно использовать RenderTexture либо напрямую задавать пиксели через texture2D.SetPixels.
2. надо написать свой вершинный шейдер, который поворачивает все вершины на определенный угол вокруг точки (v.x, 0, v.z). Чтобы получить значение угла Вам надо спроецировать координаты вершины на текстуру, и цвет в этих координатах будет направлением куда поворачивать.
Чтобы это смотрелось красивее, лучше менять силу поворота в зависимости от высоты вершины, т.е v.y.
P.S. промазал веткой, это ответ для artemev на комментарий выше
Что значит дайлап? dial-up?
Я решил практическим путем проверить и накидал код: cpp.sh/8ibyj
У меня получается 1/3 в ответе. Я где-то допустил ошибку?
Но мне все-таки кажется, что независимо от того какая именно сторона выпала в случае с фальшивой монетой, это не влияет на исход, т.е. не важно для нас.
Давайте подождем ответы от автора статьи. Думаю кто-то из нас сильно удивиться :)
Чтобы посчитать вероятность нужно знать количество возможных исходов, а исходов у нас может быть только 2, потому что мы уже подбросили какую-то монету и мы уже знаем что выпала решка, и когда мы перевернем монету там будет либо решка либо орел.