- foxes
- Постоялец
Gladiator
Не привязывайся к точным данным. Не измеряй всё в км. Работай с условными единицами.
Пример простой:
Возьмем 1234.567 = 10х10 км
А теперь корабль подлетает к другому короблю, с скоростью 1 км/ч = 0.000278 км/с.
dT обновления мира допустим 1 сек.
Т.о. корабль должен сдвигаться через каждую сек. на 0.000278 км.
Но 1234.567 + 0.000278 = 1234.567. Вот такая арифметика с float.
И в итоге получится что корабль стоит на месте. Пока скорость не увеличишь или пока dT не увеличится.
Нужно изменять начальную точку отчета.
Нужно абсолютные позиции хранить в double.
asvp
Понятно. Спасибо за ответ!
Хотя я не думаю что это необходимо в моём случае.. Это же не симулятор стыковки кораблей :) Да и дополнительный оверхед в виде дабловых позиций я думаю ни к чему :)
Всем спасибо за ваши мнения!
Gladiator
> Это же не симулятор стыковки кораблей
Да какая разница. Все равно если улетишь далеко от начала координат, то стоять на месте будешь. Поэтому делают относительные координаты.
Почитай про Space Engine и вот он решил эту проблему.
Но раз юзаешь Unity3D, то он не заточен по такие проекты.
asvp
> Но раз юзаешь Unity3D, то он не заточен по такие проекты.
Да на юнити помню на это ограничение стояло. Так и не стал заморачиваться, все равно потом куча дополнительных проблем возникало при переносе центра координат всего мира в центр активной зоны, именно для юнити. Они давали возможность делать большие миры когда с NASA сотрудничали (по моему это 2-3.2 версии), потом все развалилось.
asvp
> он не заточен по такие проекты.
Да? Все дело в прямизне рук. Вот пример на Юнити:
Более того можно посмотреть проект. Тут: ScrawkBlog Бесплатно.
seaman
Я знаю этот проект, изначально он создавался на чистом шейдере, все что там рендерилось это 1 QUAD. Вся его фишка в том что он написан на базовых методах OpenGL, к которым Unity предоставляет доступ, в обход самого движка. Если есть интерес писать в движке движек то вперед.
foxes
> Вся его фишка в том что он написан на базовых методах OpenGL, к которым Unity
> предоставляет доступ, в обход самого движка.
Не ко всем версиям OpenGL. Конкретно к той, на которой написан оригинальный Proland (3.3) - нет. Так что автор порта переписал все с нуля, с учетом "особенностей" юнити.
Belfegnar
> Так что автор порта переписал все с нуля, с учетом "особенностей" юнити.
Я не думаю что он очень сильно парился.
foxes
ну я покурил его сорцы немного несколько месяцев назад. Он с c++ на c# переписал. И на DX11 пересел. Так что попарился все-таки, думаю))
на оптимизацию забил, как я понял: там что-то около пол-мегабайта каждый кадр льется, gc рыдает наверн. ну и на мультитаск забил: все задачи в мейне в начале кадра разом фигачит.
foxes
> Вся его фишка в том что он написан на базовых методах OpenGL, к которым Unity
> предоставляет доступ, в обход самого движка. Если есть интерес писать в движке
> движек то вперед.
Юнити не предоставляет базовых методов OpenGL в обход движка. Просто есть три стандартных способа рисовать на экране:
1. Поместить объект на сцену.
2. Рисовать меши без предварительного создания объектов при помощи класса Graphics.
3. Рисовать примитивы без предварительного создания мешей при помощи класса GL, используя OpenGL-подобный синтаксис. К OpenGL оно не имеет отношения и на Windows прекрасно работает через DirectX.
О существовании способов 2 и 3 народ часто вообще не догадывается.
Мне всегда было любопытно, этот 4 способ кто-нибудь когда-нибудь зачем-нибудь использовал?
Тема в архиве.