Почему когда вы говорите об оценке сроков, учитываете только непосредственную реализацию (имплементацию) разработчиками? Но ведь разработка еще состоит из сбора требований, архитектуры и дизайна, тестирования, в конце концов. Если у вас нет перед началом разработки software requirements specification (SRS), то это лишь означает, что вам самим придется выяснять требования в том или ином виде, что занимает ничуть не меньше времени, чем написание SRS. В целом имплементация занимает примерно треть времени разработки проекта. Так что совершенно не удивителен ваш вывод «умножай на 3».
Не обычный. Для bump mapping нужна карта нормалей, которую не так просто сделать для такого спрайта зомби как в статье. Куда проще нарисовать освещение с нескольких сторон. Здесь же обратный алгоритм — построение карты нормалей из нескольких освещенных картинок. Ну а после того как карта нормалей есть — там да, обычный bump mapping.
Для обучения подходит все ))
Для написания прототипов, пожалуй лучше взять какой-то игровой движок. OSG — это не игровой движок, а графический. В игровом движке есть такие вещи как физика, звук, контроллеры персонажей и прочее, чего нет в графическом.
Надо же, вот так неосторожную фразу кинешь, поймут неправильно :)
С самим OSG все нормально, он хорошо написан, хорошая документация. Просто не каждой игре подходит Scene Graph. Есть и другие способы деления сцены на части. К примеру, есть BSP деревья, которые часто более производительны. Но повторюсь еще раз — я не хотел обидеть OSG, просто он не подошел нашей игре. Хотя я подозреваю, что для игр он в принципе хуже подходит, чем для какого-то 3D редактора, например.
Использовали примерно 8 лет назад в одной игре. Но на финальном этапе выкинули из-за плохой производительности. Хотя с точки зрения удобства использования — мне нравился OSG.
Реакция будет такая же, как если на вашу просьбу рассказать про проект на котором придется работать, вы получите ответ — только после трудоустройства, ибо NDA.
А на велосипеде такой эффект может быть из-за того, что GoPro была в центре руля, а iON ближе к скраю. Естественно ближе к краю руля более резкие движения при езде на велосипеде.
Как хорошо вы умеете писать — интересно, последовательно все излагая, структурированно. Буду у вас учиться.
Но, увы, ваш стартовый экран напоминает веб-сайт, на котором 70% пространства заполнено баннерной рекламой. Интерфейс слишком перегружен информацией. В целом концепт такой не нов. Например, тот же iGoogle — воплощение идеи стартовой страницы, где все обновляется и на виду. Но, как известно, ему осталось жить менее месяца.
Вот только если бы гитхаб не выстрелил, он бы не впоминал это как “Вау, это было приключение” в старости, а скорее «Блин, какой я был дурак». Такова природа риска — вы либо пьете шампанское и вам есть что рассказать, либо очень сожалеете.
Солидарен с первым студентом, что нужно начинать с вопроса «нужен ли доступ по ключу?». Это сделает схему более структурированной — сразу будет две никогда не пересекающиеся ветки. Сейчас же можно пойти направо, потом улететь в самый левый конец — сплошные виражи и лабиринты.
Ой ли… вы можете «всегда разобраться при необходимости», только если у вас есть фундаментальные знания, понимание что где и как применяется, но вы слегка плаваете или забыли.
А если о какой-то области вы даже не слышали, то как говорят в наших краях «you don't know what you don't know». Посыл такой, что если вы не знаете какую-то область и где она примененяется, то встретив задачу, легко решаемую с помощью методов из этой области, вы будете выдумывать что-то свое и скорее всего гораздо менее эффективное, а иногда совершенно некорректное решение.
Да, я понимаю, что при большем количестве записей, время расчетов будет больше. Но время будет пропорционально больше каким бы инструментом вы не пользовались — MapReduce на 10 компах или все на одном компе c подсчетом скриптом. Отчего в контексте статьи (выбора технологии) я не понимаю почему нужно отдать препочтение одной технологии над другой в зависимости от количества записей.
Как объяснил камрад ffriend в своей статье, преимущество MapReduce — в минимизации передвижения данных между узлами и локальности вычислений. Так какая разница сколько записей?
Для написания прототипов, пожалуй лучше взять какой-то игровой движок. OSG — это не игровой движок, а графический. В игровом движке есть такие вещи как физика, звук, контроллеры персонажей и прочее, чего нет в графическом.
С самим OSG все нормально, он хорошо написан, хорошая документация. Просто не каждой игре подходит Scene Graph. Есть и другие способы деления сцены на части. К примеру, есть BSP деревья, которые часто более производительны. Но повторюсь еще раз — я не хотел обидеть OSG, просто он не подошел нашей игре. Хотя я подозреваю, что для игр он в принципе хуже подходит, чем для какого-то 3D редактора, например.
Но, увы, ваш стартовый экран напоминает веб-сайт, на котором 70% пространства заполнено баннерной рекламой. Интерфейс слишком перегружен информацией. В целом концепт такой не нов. Например, тот же iGoogle — воплощение идеи стартовой страницы, где все обновляется и на виду. Но, как известно, ему осталось жить менее месяца.
А если о какой-то области вы даже не слышали, то как говорят в наших краях «you don't know what you don't know». Посыл такой, что если вы не знаете какую-то область и где она примененяется, то встретив задачу, легко решаемую с помощью методов из этой области, вы будете выдумывать что-то свое и скорее всего гораздо менее эффективное, а иногда совершенно некорректное решение.