Взаимодействие рифта и плеера.


В настоящее время работу над протоколом ведет Макс Селиверстов:

http://seliverstoff.blogspot.ru/2014/09/openxd-tcp-oxdtcp-v0005a.html

https://github.com/Seliverstoff/OXD_TCP/tree/master/doc

***

Первая версия протокола:

1. Запуск рифта производится с изначально заданными параметрами в оконном FHD-режиме, с качеством "fantastic" (пока в UNITY не будет исправлен баг с крашем рифта при потере фокуса в полнооконном режиме) .
2. После старта rift отправляет на порт:11000 команду CONNECTED WITH SERVER и переходит в режим ожидания команд на загрузку сцены и старта анимации. До старта анимации Зритель видит титр демонстрируемого рифта.
3. Плеер отправляет rift-у команду LOAD:scene_name, по которой начинается загрузка сцены. на экране появляется первый кадр анимации.
4. Плеер отправляет rift-у команду PLAY и после окончательной загрузки сцены начинается воспроизведение анимации.
5. С началом воспроизведения анимации rift отправляет плееру сообщение START PLAYING scene_name и далее, каждую секунду:

Second 0
Second 1
Second 2
...
6. По завершении анимации rift отправляет сообщение RIFT END и через 5 (у нас пока пять) секунд (во время которых на экране последний кадр анимации), сообщение CLIENT CLOSED и закрывается.

***

Всем желающим производителям оборудования и разработчикам рифтов на индивидуальных условиях предоставляются как сами рифты, так и их исходные unity-проекты. Причина этого шага описана в  "Манифесте 5D REALITY". Если есть  интерес, пишите, познакомимся.

Комментарии

  1. между 3 и 4 надо добавить отправку подтверждения серверу, что-то вроде LOAD_OK
    Ну может еще что-то проверить, чтобы быть уверенным в том, что сцена готова к плею.
    И только потом - Play
    А вот дальше самое интересное ;-) Пытался тебе дозвониться, но не смог.
    В общем не рифт должен отправлять синхроинпульсы, а наоборот.
    А это влечет за собой особый подход к созданию проекта.
    Все довольно просто. Но надо сделать некоторые важные вещи.

    ОтветитьУдалить
  2. да, и порт 11000 используется некоторыми троянами, и может быть "забанен", лучше сделать возможность кастомной настройки порта.

    ОтветитьУдалить
  3. да, и п.1 лучше снести в *.ini файл, чтобы можно было менять режимы, подгоняя их под специфику оборудования
    тоже самое относится к IP и адресу порта

    ОтветитьУдалить
  4. 1. Отправку LOAD_OK действительно не плохо бы сделать. Пока будет так.
    2. Синхроимпульсы должен отправлять именно RIFT, это основа синхронизации. Некоторые параноики хотят получать с рифта еще и координаты ориентации платформы. Хорошая мысль, но на данный момент бессмысленная.
    3. Порт можно менять на какой угодно. Сейчас этот порт взят "с потолка".
    4. можно использовать и .ini-файл. Много чего можно. Прикол в том, что сейчас все эти работы никто не финансирует. И не собирается финансировать. Пока будет так как есть. Да и с братьями-девелоперами ещё пока информации нет (кроме тебя конечно), если не считать пары малолеток-анонимусов, пишущих всякий веселящий меня по утрам бред :)))

    Идеи и предложения отличные. Спасибо! Единственно не могу понять почему ты упорно настаиваешь на посылке синхроимпульсов в рифт, а не обратно? Никак не улавливаю причину.

    ОтветитьУдалить
    Ответы
    1. Дело в том, что это закон любой синхронизации - сервер задает ритм. Именно это позволяет к серверу подключить столько клиентов, сколько потребуется. А сейчас задача решена как 1-n-1. Посмотри как синхронизируется камеры через ген_лок, одна ведущая - остальные ведомые и таких примеров в мире синхронизации очень много.
      То что касается данных от окулуса - протокол сейчас асинхронный, и серверу ни что не мешает принимать сигналы от нескольких машин. Пока не реализовано разделение (то есть сервер не до конца понимает кто именно шлет сигнал), но это можно допилить.

      Удалить
    2. по п.2 - да, с "некоторыми параноиками" я это обсуждал, хотя они же убеждали меня в том, что это не так принципиально.
      Отправить не проблема, и сервер запросто схавает данные 4-12 клиентов, но вот проблема - они для него могут оказаться почти бесполезными. Это было бы полезно в случае с интерактивом, но если трек движения "статичен" - это не нужно. Приложение само нарисует картинку как надо, а сревер только двигает платформу. В случае с интерактивом, можно пытаться апроксимировать все данные и подстраивать платформу под них, но это тоже весьма сомнительно. Ибо в этом случае у нас есть 1 игрок, отвечающий за движение "тачки", и под него подстраивается платформа (сервер). Остальное как и в первом случае. И для этого игрока данные нужны не от окулуса, а от джойстика, а еще точнее - скрипта в игре, который наклоняет транспортное средство.

      Удалить
    3. Макс, ни о каком интерактиве сейчас и речи не идет. Главное дать возможность производителям втянуться в насыщение рынка предложениями. Для этого нужно подтянуть как можно больше разработчиков. Производители уверены, что они по прежнему будут тупо скачивать все из интернета и воровать друг у друга. Пусть так и думают. Если найдутся дебилы которые будут им интерактив делать за "две копейки" (а ведь найдутся), то флаг им всем в руки. будет такое говно как сейчас. А вот нормальный контент должен быть уже на защищенной системе. Но принципы интеграции нужно сейчас разрабатывать.

      И потом, я не уверен, что 5D должно быть по настоящему интерактивным. Не нужно путать "жопу с пальцем".

      Ты видел интерактивы от YOTO или AET? Приколись как-нибудь :)))

      Удалить
    4. Я про интерактив просто заикнулся, как об одном из вариантов решения (и кстати довольно просто решаемых - просто мне никто не верит, а не верят потому, что привыкли как ты выразился "скачивать").
      А ты вспылил ))) Спокойно коллега... ща с горки спустимся и ...

      Удалить
  5. Ты не учитываешь самой основной задачи. есть плеер который типа-сервер и есть один единственный рифт (или видео-файл) с которым нужно синхронизировать трек управления платформой. Всё.

    ОтветитьУдалить
    Ответы
    1. Именно это я и учитываю...
      Уже через несколько месяцев вам начнут задавать вопросы... И окажется что для их решения ВАМ надо будет переписать очень много. Не изобретайте велики ;-) Протоколы обмена и синхронизации выпилены многократно. Параллельные , такие, сякие... Сейчас ни такие не сякие - 1-к-1

      Если на платформе сидит 4 пользователя - возможно картинка как-то будет крутить, но если надо больше - а понадобиться обязательно, то начнутся эти самые вопросы. Потребуется кластерность.

      В случае с Unity у меня большие сомнения, что даже самая мощная карта потянет 4 пользователя одновременно... Ну 2 максимум... А это значит увеличение компом, вот и нужна синхронизация 1-к-N

      Удалить
    2. По поводу многопользовательской системы можно будет говорить когда появится три-четыре доступных шлема. А это случится не раньше конца сентября, начала октября. Если конечно чуда не произойдет. Но единственное чудо, на которое я рассчитываю, - появится что-то, что позволит мне ВООБЩЕ НИКОГДА БОЛЬШЕ ВСЕМ ЭТИМ НЕ ЗАНИМАТЬСЯ. ИншАлла.

      Удалить
    3. Любой грамотный разработчик обязан закладывать в систему перспективы ее развития, не заложил - не развился, ну или получил убытки. Вот я о чем. Нет сейчас девайсов - не важно - система должна иметь потенциал.

      Удалить
    4. Конечно ты прав. Нужно заложить по максимуму. Вот сейчас получу ответ от программиста который прикручивает плеер. Именно его требования легли в основу ТЗ Серафиму. Потом Чистяков подключится, потом с Украины пацаны подтянутся, латыши, питерские братья по разуму должны отморозится. Все ещё в коматозе пока.

      Я не вспылил. Почти. Усталость сказывается. Безнадёга...

      Удалить
  6. О! Забыл про белорусов сказать. Самых главных и передовых на сегодняшний день, среди нас. Они конечно сами себе на уме, как всегда, но возможно удастся достучаться до их загадочного разума. Пока безрезультатно. Хотя пока и время еще такое, Август. Все, кто на барабульках, отдыхают.

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения