Яковлев Як-9, обычный, рядовой истребитель, 1943 год.
Максимальная скорость 600км/ч на высоте 4000м.
16км — это меньше двух минут.
Для 1945 нормальные скорости 680-720км/ч.
Играть в «NATOвские истребители не могут в Эстонии превысить скорость звука, потому, что территория настолько мала и кончается слишком быстро для разгона» не охота.
С другой стороны интересно посмотреть, как это всё будет летать над танками, среди которых ультра-максимальная скорость 72км/ч. Такая же для обычного эсминца.
Скорость вне дороги 16-20км/ч, что потребует до 60 минут на 16км.
Оно, конечно, если бы я хотел поэкспериментировать с самолётиками и только — это одно.
Ещё одно простое качество, которое лично мне резко ощущается как разница между книгой и электронкой — это закладка пальцем. Да, я знаю, что функционал закладок существует, но я им не пользуюсь.
Сценарий «на пальцах»:
1.Я понимаю, что мне нужно свериться с абзацем 7 или 70 страниц назад. Но я не знаю сколько точно.
2.Я закладываю палец на текущем месте.
3.Я быстро пролистываю прошлый текст в поиске того абзаца. Левым большим пальцем, пользуясь упругостью бумаги.
4.Я читаю тот абзац.
5.Я просто и моментально возвращаюсь к «текущему пальцу».
Можно, конечно, усложнить, так как пальцев у хумана много. Собственно, учебники так и читаются в пять текущих пальцев. Но это уже излишнее усложнение. :-)
Чего нет в электронках для этого сценария.
1.«Текущего пальца».
2.Быстрого пролистывания прошлого.
3.Быстрого возврата к текущему пальцу.
Если нафантазировать, то я бы делал так:
1.На экране… На экране! Не в меню за тремя кликами, а сразу на экране. Кнопка в виде, хотя бы, якоря.
2.Когда я нажму якорь, текущая страница «закладывается пальцем»
3.Одновременно слева открывается изображение среза книги.
4.На срезе книги отмечены главы. Пусть не вертикальными линиями, согласен. Но хотя бы горизонтальными. И якорь. Или несколько якорей. Пусть различаются цветами.
5.Жестом drag-up или drag-down листается разумное количество страниц. Это не progress-bar, у которого 1 сантиметр = 200 страниц. Жест должен листать со скоростью, например, 1 сантиметр = 10 страниц. Причём страница за страницей. И без тормозной анимации.
6.Нажатием на якоря на этом срезе я должен открыть книгу сразу на этой странице.
7.Drag left на якоре удаляет якорь.
8.Изображение среза закрывается жестом drag left у левого края экрана. И таки тоже открывается же через drag right у левого края экрана. Это чтобы остальной экран оставить для жестов листания по одной странице.
9.Если на открытой странице включён якорь, то нажатие на него гасит его обратно.
А знаете, я бы и у правого края такой функционал замутил для будущих страниц. Надо просто выкинуть пункт 3.
youtu.be/Q0Rq6KNZW44?t=5116
Диктовать-то диктовал. Но результат был одинаковый «кто все эти люди?!.»
Прошло один-единственный раз в жизни, когда звенел собственно в авиакомпанию.
а с точки зрения рендера такой диапазон чисел просто смысла не имеет
Смысл есть — если оба, и камера, и объект на 20км от центра, при этом рядом друг с другом, то неточность float, как я предполагаю, можно будет наблюдать вблизи. Хотя бы потому, что графический mesh точно так же поплывёт.
О математике: зависит от математики. Иногда авторы дают сущие трюизмы. Иногда авторы дают темы, настолько нерелевантные хабру, что я не знаю, что и говорить.
Это я знаю, но.
Да, я могу отказаться от PhysX и использовать свою кинематику, основанную на double. Этого хватит на 17 миллионов (или миллиардов? не помню) километров, что для «наземной» симуляции весьма достаточно. Хватит и на миллиметровую точность или ещё точнее.
Но сам-то мир Unity3D, вроде бы, построен на float, и, помимо кинематики в вакууме, есть:
* коллизии. Сможет ли Unity безглючно рассчитать контакт автомобиля или лучше самолёта с террейном далеко от центра, если расстояние в сантиметрах будет выше ёмкости float? А мешей объектов друг с другом?
* графическое отображение. Сможет ли Unity безглючно визуализировать террейн и окружающие объекты так же далеко от центра?
Вот у меня такой вопрос: с чего вы решили, что я в 2015 сэкономил на ассете авторства 2017?
Кстати, подскажите, за что это вы рекомендуете transform двигать в update?
И ещё вопрос: почему во время моей борьбы с SyncVar в его доке было сказано, что синхронизируется всё идеально?
Хотя позже оказалось, что он только спускает с сервера на клиента, никогда наверх, качает достаточно редко и сглаживание не предусматривается в принципе.
I have always wished for my computer to be as easy to use as my telephone;
my wish has come true because I can no longer figure out how to use my telephone.
/Bjarne Stroustrup/
Одинаково интересует так же и конкретное решение: как одним сканером создать устойчивую систему, которая самопроизвольно обнуляет пересортицу и кучу всех складских проблем.
Конструкцию этой серебряной пули хоцца узнать. Какой параметр оптимизирован? Не в смысле «результат 0.05%», а суть формулы.
Спасибо!
Максимальная скорость 600км/ч на высоте 4000м.
16км — это меньше двух минут.
Для 1945 нормальные скорости 680-720км/ч.
Играть в «NATOвские истребители не могут в Эстонии превысить скорость звука, потому, что территория настолько мала и кончается слишком быстро для разгона» не охота.
С другой стороны интересно посмотреть, как это всё будет летать над танками, среди которых ультра-максимальная скорость 72км/ч. Такая же для обычного эсминца.
Скорость вне дороги 16-20км/ч, что потребует до 60 минут на 16км.
Оно, конечно, если бы я хотел поэкспериментировать с самолётиками и только — это одно.
Сценарий «на пальцах»:
1.Я понимаю, что мне нужно свериться с абзацем 7 или 70 страниц назад. Но я не знаю сколько точно.
2.Я закладываю палец на текущем месте.
3.Я быстро пролистываю прошлый текст в поиске того абзаца. Левым большим пальцем, пользуясь упругостью бумаги.
4.Я читаю тот абзац.
5.Я просто и моментально возвращаюсь к «текущему пальцу».
Можно, конечно, усложнить, так как пальцев у хумана много. Собственно, учебники так и читаются в пять текущих пальцев. Но это уже излишнее усложнение. :-)
Чего нет в электронках для этого сценария.
1.«Текущего пальца».
2.Быстрого пролистывания прошлого.
3.Быстрого возврата к текущему пальцу.
Если нафантазировать, то я бы делал так:
1.На экране… На экране! Не в меню за тремя кликами, а сразу на экране. Кнопка в виде, хотя бы, якоря.
2.Когда я нажму якорь, текущая страница «закладывается пальцем»
3.Одновременно слева открывается изображение среза книги.
4.На срезе книги отмечены главы. Пусть не вертикальными линиями, согласен. Но хотя бы горизонтальными. И якорь. Или несколько якорей. Пусть различаются цветами.
5.Жестом drag-up или drag-down листается разумное количество страниц. Это не progress-bar, у которого 1 сантиметр = 200 страниц. Жест должен листать со скоростью, например, 1 сантиметр = 10 страниц. Причём страница за страницей. И без тормозной анимации.
6.Нажатием на якоря на этом срезе я должен открыть книгу сразу на этой странице.
7.Drag left на якоре удаляет якорь.
8.Изображение среза закрывается жестом drag left у левого края экрана. И таки тоже открывается же через drag right у левого края экрана. Это чтобы остальной экран оставить для жестов листания по одной странице.
9.Если на открытой странице включён якорь, то нажатие на него гасит его обратно.
А знаете, я бы и у правого края такой функционал замутил для будущих страниц. Надо просто выкинуть пункт 3.
А мне любопытно.
Да, согласен.
Но если самолёт летит над танком? :-)
Диктовать-то диктовал. Но результат был одинаковый «кто все эти люди?!.»
Прошло один-единственный раз в жизни, когда звенел собственно в авиакомпанию.
Но самое интересное
Я сравниваю два подчёркнутых слова и чего-то не понимаю 8-)
Смысл есть — если оба, и камера, и объект на 20км от центра, при этом рядом друг с другом, то неточность float, как я предполагаю, можно будет наблюдать вблизи. Хотя бы потому, что графический mesh точно так же поплывёт.
О математике: зависит от математики. Иногда авторы дают сущие трюизмы. Иногда авторы дают темы, настолько нерелевантные хабру, что я не знаю, что и говорить.
Хотя вопрос включал графику к физике, что могло подразумевать фреймворк/либу, предположительно Unity ;-)
А что, есть графика на double?
Да, я могу отказаться от PhysX и использовать свою кинематику, основанную на double. Этого хватит на 17 миллионов (или миллиардов? не помню) километров, что для «наземной» симуляции весьма достаточно. Хватит и на миллиметровую точность или ещё точнее.
Но сам-то мир Unity3D, вроде бы, построен на float, и, помимо кинематики в вакууме, есть:
* коллизии. Сможет ли Unity безглючно рассчитать контакт автомобиля или лучше самолёта с террейном далеко от центра, если расстояние в сантиметрах будет выше ёмкости float? А мешей объектов друг с другом?
* графическое отображение. Сможет ли Unity безглючно визуализировать террейн и окружающие объекты так же далеко от центра?
Или таки придётся делать floating origin?
Толковый скрипт, с удовольствием пользуюсь.
www.explainxkcd.com/wiki/index.php/1489:_Fundamental_Forces
«Oh, noes!» Снова картинки расширения вселенной! 8-)
sharpkeys до сих пор живой.
«При этом нельзя касаться стены, вообще. Если коснулись стены – вся команда возвращается на исходную позицию.»
Мы можем договориться о таких правилах?
Тогда решительно лбом сносим стену, возвращаемся на исходную и бегом в пролом.
Кстати, подскажите, за что это вы рекомендуете transform двигать в update?
И ещё вопрос: почему во время моей борьбы с SyncVar в его доке было сказано, что синхронизируется всё идеально?
Хотя позже оказалось, что он только спускает с сервера на клиента, никогда наверх, качает достаточно редко и сглаживание не предусматривается в принципе.
my wish has come true because I can no longer figure out how to use my telephone.
/Bjarne Stroustrup/
Конструкцию этой серебряной пули хоцца узнать. Какой параметр оптимизирован? Не в смысле «результат 0.05%», а суть формулы.
Спасибо!