Графический дизайн, арт игры, концепт, персонажи, текстуры, анимации, модели
GameDev.ru / Графический Дизайн / Форум / Взаимодействие дизайнеров и программистов. Что требовать дизайнерам и как им облегчить свою жизнь. (Комментарии к статье)

Взаимодействие дизайнеров и программистов. Что требовать дизайнерам и как им облегчить свою жизнь. (Комментарии к статье)

Страницы: 1 2 3 Следующая »
robotПостоялецwww17 сен. 20049:45#0
Комментарий к Статье Взаимодействие дизайнеров и программистов. Что требовать дизайнерам и как им облегчить свою жизнь

Статья для молодых дизайнеров, волею судеб попавших в разработку игр. В статье рассматриваются многие аспекты работы в команде, типичные требования к коненту, приводятся примеры решений некоторых распространённых проблем. Кроме того, упоминаются моменты, которые надо учитывать при разработке моделей сразу, чтобы потом не мучатся переделками.

neteraser[v_zapase]Новичокwww17 сен. 20049:45#1
От части бред, но в целом очень полезная и информативная статья, которая охватила все моменты приткновения. Раньше, начиная работу с моделером, приходилось писать подобные документы самому. Они, конечно, не составляли и половины описанного в этой статье, поэтому, если человек попадался неопытный, было прямо скажем тяжело. Теперь можно просто указывать ссылку на статью. Спасибо автору и всяческое уважение ему.
watВедущийwww17 сен. 200410:58#2
neteraser
про бред можно подробнее? С указанием кусков текста.
GLoomУчастникwww17 сен. 200411:08#3
neteraser
Спасибо.
И всё-же можно можно уточнить, что вызвало нарекания?
GLoomУчастникwww17 сен. 200411:57#4
Ой, там где про количество точек в модели вместо точек следует читать "вершин".
ZПостоялецwww17 сен. 200412:53#5
GLoom
Хорошая статья. Вот мои мъсли по вопросу:
1. Проблеммъ с именованием и размером обьектов надо решать четких диз-доком, т.е. его частью где описан content - четкое имя (Case-sensitive если надо) + размер. Также проверки в експортере, есть ли уже такой обьект (если его експортим не для тестов, а прямо в игру) в игре, и если нет - неразрешаем експорт пока обьект не переименуется (кто-то создал пустъе классъ для обьектов в игре скажем, потом дизайнеръ експортят поверх их реальнъе даннъе).
2. Проблеммъ с размещением по папкам не должнъ съществовать для дизайнеров, кроме как конечно ихний source art (.max) конечно же, но как подумаю можно и его скопировать при експорте. Все остальное просто експортится куда надо, имена мешей следятся и експортятся уникальнъм образом, текстуръ в зависимости от типа или експортятся по папкам, вместе с обьектами (тогда имена не проблема), или по дефиниции несколько обьектов пользуют одну текстуру (таким образом их делает дизайнер) и на етапе експорта ето не приводит к проблемам.
3. Бекап. Его безусловно надо делать, хотя один раз в неделю. На сервере скажем хранить последние 15 билдов (ихние delta, см. xdelta).
4. Анимированнъе обьектъ лучше хранить в одном MAX файле со всеми анимациями, отдельнъе анимации експортить используя текущее time line. Таким образом изменение меша надо сделать только один раз и оно скажется на все анимации обьекта. Економия времени дизайнера, один вид (если они ето уже не знают... :).
5. Експорт с помощью тех же утилит в MAX-е, если он длится долго должен сразу-же показъвать какой-то диалог ('Exporting...'), показъвать кое-какую статистику (чтобъ дизайнеру не бъло скучно первъе несколько секунд), ну и конечно-же иметь возможность експортить с опцией fast, или просто в междиннъй формат, которъй потом можно снаружи компилировать в конечнъй формат. (об етом можно почитать статью Noel Llopis-а, о поддержке content-а - очень полезно). Експорт для теста обьекта должен иметь место в експортере, его надо делать минимальнъм количеством кликов и потом иметь возможность запустить игру в режиме preview скажем (у нас shortcut для дизайнеров именно для етой цели - запускается пустой уровень с только-что експортнутъм обьектом + возможность смотреть его дифуз-лайтинг, etc.).
6. Експорт анимации костей можно делать 'в лоб', т.е. експортируя матрицъ каждой кости с даннъм fps и потом тупо их интерполируя (если не костантнъе) и все. Таким образом не имеет значения какой контроллер используется.

А иначе - интересная и очень полезная статья.

Btw, спасибо за Reset XForm, не знал... :)

neteraser
Да, покажи бред, пожалуста...

watВедущийwww17 сен. 200413:56#6
Zemedelec
> 3. Бекап.
Пункты 2.4-2.6 разве не про это?

> 6
шо-то я  не понял, какое отношение это имеет к артистам? И вообще, интерполирование матриц — спорный вопрос, может быть и можно так делать, но лучше не делать.

ZПостоялецwww17 сен. 200414:40#7
wat
> 6
шо-то я  не понял, какое отношение это имеет к артистам? И вообще, интерполирование матриц — спорный вопрос, может быть и можно так делать, но лучше не делать.

Да, ето имеет отношение к програмистам -> и к артистам ибо отбросит одно ограничение.
Интерполировать матрицъ я и не советовал, их надо преобразовать в кватернионъ. Но даже и матрицъ, при нормальном fps въглядит хорошо.
ДжыдайНовичокwww17 сен. 200417:05#8
Статья просто супер :)
neteraser[v_zapase]Новичокwww17 сен. 200417:29#9
> Да, покажи бред, пожалуста...
Да что вы такие серьезные все? Пожалуйста:

> Милые добрые люди, создающие внешний облик игры, которые зачастую нужнее и важнее всяких движкописателей, потому что они и только они вдыхают в килобайты кода жизнь.
Собственно вот он, Бред, однозначно и безоговорочно :)

Oleg LinkovПостоялецwww17 сен. 200417:32#10
гм. коротко обо всем. если честно я тоже нифига не понял каким местом это все относится к художникам или моделлерам. эта статья скорее похоже на памятку менеджера нервничающего перед выступлением где-нить на КРИ. в лучшем случае это материал для ведущего художника или арт-директора, но и для них он не нужен так как если уж люди доросли до должности лид-артиста или арт-директора, то они и сами должны это знать и понимать. А вопросы о бэкапе вообще не дело отдельно взятого художника. На своем рабочем месте, да, он должен блюсти хоть какой-то порядок, чтобы к очередному бэкапу он смог предоставить все что нужно сохранить, если по каким-то причинам данные не хранятся централизовано.
Редкие же вставки непосредственно для художников смотрятся как-то не к месту, особенно про оплату труда. О профессионализме художника судят обычно по его работам. Тут скорее вопрос о порядочности начальства и степени самоуверенности художника. Извращения со скриптами чтобы изменить свойства сразу множества объектов... это вообще как-то странно. Может я чего-то не понял, но чтобы изменять свойства сразу большого числа объектов очень хорошо подходит использование XRef'ов. Глеб, иструменты надо знать :)
-=InQ=-Постоялецwww17 сен. 200418:01#11
neteraser
сам ты Бред.
ZПостоялецwww17 сен. 200418:06#12
neteraser
Ето однозначно не бред. Такими словами люди не бредят, а лирически въводять мъсль, причем очень верную.

Gibby
Ето скорее статья для дизайнера в средне-маленьких проектах где иногда хаос. Где четко не ясно что и как должен делать художник и особенно как оперировать даннъми (кроме как сделать модел и залить куда-то).

-=InQ=-Постоялецwww17 сен. 200418:11#13
GLoom
кстати, «Предупрежден — значит вооружен» это перевод с латыни «Praemonitus, praemunitus». Так что вряд ли это советская пропаганда придумала :)
azazelloПостоялецwww17 сен. 200420:24#14
GLoom
спасибо за сборку столь многого в одном месте...

хотелось бы добавить касательно max/maya
>> Однако с точки зрения программиста использование MAX SDK напоминает скорее половое сношение в пассивной роли. ....
>>С другой стороны есть Max Script, который скрывает некоторые внутренние недостатки макса, однако работает медленнее, имеет собственные побочные эффекты.
с точки зрения многих прораммистов MEL - очень хороший язык(особенно UNIXоидов, благо MEL ~ csh :-) ) и отношение к Maya другое.
отдельно стоит упомянуть также разницу в архитектуре max & maya - а именно - маю можно так видоизменить/изуродовать UI, легко изменить рендеринг во viewport(т.е. ВИЗИВИНГ) и т.д. - что снижает необходимость в своих редакторах ещё больше, чем в max

Страницы: 1 2 3 Следующая »

/ Форум / Графический Дизайн / Общее

Тема в архиве.

2001—2018 © GameDev.ru — Разработка игр