3Д - скрины работ

Вот такой ковыряешь потихоньку сцену, ковыряешь, а количество элементов в окне редактора всё увеличивается и увеличивается, и в какой-то момент начинает превышать тысячу, а работа толком ещё и не начиналась... И в голову закрадывается шальная мысль: чувак, всё ли ты так делаешь?

Моя говноизбушка нервно курит в сторонке 

Так что всего этого больше нет, остались одни картинки

А жаль...
Нам бы прислал что ли, мы бы пристроили. Работа ведь Крутая!

Vanok, я тя умоляю точно такие же цилиндрики, как и у тебя. Засунь свою избушку в анрил, накинь текстурку и будет тоже самое.

Van, чё там крутого-то, болванки грубые. Материал всё вытягивает мегаскановский. Ну тын поскульптил и запёк, конечно, эт да.

Снёс я короче всё, что было нагорожено и полез, как и полагается, изучать блупринты.

Я считаю, что это одно из худших изобретений человечества. Программироавние мышкой. Хотя что только не делают люди лишь бы не учить C++.

Снёс я короче всё, что было нагорожено и полез

А модельки остались или были тоже уничтожены?

Vanok, я тя умоляю  точно такие же цилиндрики, как и у тебя. Засунь свою избушку в анрил, накинь текстурку и будет тоже самое.

Не только. У тебя же еще запеченные текстуры по первому классу. (diffuse, bump или height, specular...)

что только не делают люди лишь бы не учить C++

Ну, хотелось бы всё-таки большую часть времени уделять творчеству, а не программированию. Если бы был вагон времени, то можно и С++ поизучать и в Гудини поковыряться, но надо приспосабливаться к тому, что имеется в распоряжении.

А модельки остались или были тоже уничтожены?

Я же не отказался от своей затеи. Просто сейчас собираю полностью контролируемое, но генерируемое ползунками здание, с возможностью менять одним щелчком тип кровли, дверей, окон, крылец и т.п.

Соответственно все болванки перестраиваются под эти нужды - геометрия, пивоты, размеры модулей. В результате вместо нескольких десятков элементов в редакторе будет всего один блупринт на один дом. Поэтому на данном этапе делать какие-то законченные конструкции не рационально, в любой момент может понадобится всё переиначить. Ну, не тебе же всё это объяснять )

Я же не отказался от своей затеи. Просто сейчас собираю полностью контролируемое, но генерируемое ползунками здание, с возможностью менять одним щелчком тип кровли, дверей, окон, крылец и т.п.

Соответственно все болванки перестраиваются под эти нужды - геометрия, пивоты, размеры модулей. В результате вместо нескольких десятков элементов в редакторе будет всего один блупринт на один дом. Поэтому на данном этапе делать какие-то законченные конструкции не рационально, в любой момент может понадобится всё переиначить. Ну, не тебе же всё это объяснять )

Звучит круто. Посморим, что получится. А получиться должно хорошо.
А потом бы город парочкой ползунков делать. Как же это было бы ктуто.
Вот бы в M&B такое делать. Один детерминированный алгоритм-скрипт, делающий sco-файл.

В анриле точно такое есть. Парни из какой-то украинской конторы демку показывали, но я тогда не интересовался этим. Они там, правда, сплайнами улицы рисовали вроде, а анрил уже рандомно домики генерил. Выглядело круто.

Underdog, классно получается. 
да блюпринты штука хорошая, сам пока еще мало пользуюсь, на больших локациях пригодится.
на заборе текстура большая вообще? 2к есть или меньше? тут у меня в голове мысль закралась, как такой ассет правильно текстурить. можно тайлом, еще и на дома накинуть. сверху декалей или какой то грязи, по хаймпапе к примеру. в окружении многие вещи решаются развертками, не всегда опять же очевидно, какой способ лучше выбрать.
по поводу генерации можно к сплайну привязать блюпринт для рандомной расстановки мешей. не совсем то что ты описал, но точно в ту сторону нужно копать.

http://www.youtube.com/watch?v=oNb2RJh3Xp8

По блупринтам - сенькаю, гляну обязательно. Сам-то смотрел и повторял вот эти:

В первую очередь это, как самая необходимая, базовая информация (где-то 80% используемых приёмов и функций):

https://www.youtube.com/watch?v=aFwvZ-skzCU

Вот этот очень крутой, но не подходит для моих нужд, т.к. я делаю на основе археологических данных, и мне нужен контроль за длиной и шириной зданий. Но для геймдева - самое оно: https://www.artstation.com/artwork/BNqgl

Вот тоже ничего так, но сложно под конец становится концентрировать внимание  и понимание.  https://www.artstation.com/artwork/Kq5xy

Ну и спасибо камраду Снейку, который бывало по часу мне разжёвывал некоторые богатырские приёмчики)

По текстурам пока сложно. Сейчас делаю всё на 4к, а там видно будет.

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

По логике и КПД надо делать тайленые маты, но у меня стена, например, генерируется сейчас из элементов 2м, 1.5м, 1м, 0.5м подумываю, не добавить ли ещё и 0.25. Понятно, что невозможно накинуть на неё тайловый мат, т.к. или текстуры растянутся на маленьких элементах, или тайлинг слетит и будет шов. Пробовал делать длину стены скейлом, но тогда не будет возможности "включать" и "выключать" в нужном месте оконные и дверные проёмы...

По забору опять же, как матом подчеркнуть, что заострённая часть стёсывалась топором, а сам кол нет...

Как-то так, короче, ещё очень много интересного и неожиданного впереди))

Раз никто ничего не вылаживает, выложу я. Пока не далеко ушел от блокаута, но работа движется. 2 плана и референсы.

материал*ы дефолтные пеинтеровские. не так давно удалил лавку, стойку (на рефах их видно), скорее всего верну, пока без них. свет особо не делал, т.к. думаю как реализовать эфект гиперпространства, есть  опыт работы с афтер ефектом, попробую с помощью него сделать. не уверен правильно я выбрал идею для первой сцены, просто хотелось не только моделить, но и со светом, ефектами поработать и тд.

Уже атмосферно, это точно. Если ещё и космос представить за окном, то можно и погрузиться в картинку даже в таком виде.

Еще немного домоделил дом и натянул текстуры. Текстуры, конечно, накладывал коряво, я бы даже сказал по-нубски, без всяких там запеканий и т.п., но для какой-нибудь третьесортной браузерной игры, наверное, сгодится 

Полагаю, такими темпами к выходу Баннерлорда вы уже станете готовым мододелом для локаций


Единственно - у вас что, домик морилкой покрашен? Некрашенная древесина же на воздухе быстро сереет... Или он просто игрушечный?

Еще немного домоделил дом и натянул текстуры. Текстуры, конечно, накладывал коряво, я бы даже сказал по-нубски, без всяких там запеканий и т.п., но для какой-нибудь третьесортной браузерной игры, наверное, сгодится 

Кстати, получилось весьма хорошо. Теперь можно поколдовать в фотошопе над бампом.

Я считаю, что это одно из худших изобретений человечества. Программироавние мышкой. Хотя что только не делают люди лишь бы не учить C++.

конечно же это одно из лучших изобретений.

уметь в с++, это не парочка нод в блупринтах, зачем моделеру уметь в ООП, знать синтаксис и прочее. (хотя уметь программировать безусловно будет плюсом)
более того "нельзя просто так зная плюсы взять и начать кодить в анриале" там у епиков свои код стандарты, нужно понимать архитектуру двигла, нужно знать апи, куча тонкостей с UClass-ами.
а в блупринтах что-то простое можно чуть ли не брутфорсом подобрать вариант. В них все максимально интуитивно : что нужно ключевое написал в в поиске методов - оно тебе показало что на выбор.
А вот если уж если серьзно этим заняться перейти с блупритов на с++ ЗНАЧИТЕЛЬНО проще чем учить плюсы с нуля без контекста движка.
Я б даже посоветовал тем кто знает ++ движек начать изучать с блупринтов , так как они познакомятся с его особенностями, основной архитектурой, и методами.

конечно же это одно из лучших изобретений.

Я так не считаю.

а в блупринтах что-то простое можно чуть ли не брутфорсом подобрать вариант

Автокомплит все же делает свое дело.

уметь в с++, это не парочка нод в блупринтах, зачем моделеру уметь в ООП, знать синтаксис и прочее

Все же я не считаю C++ ООП. Да, ООП там есть, но в C++ можно писать и без ООП. Хотя моделеру можно не уметь в программирование.

более того "нельзя просто так зная плюсы взять и начать кодить в анриале" там у епиков свои код стандарты, нужно понимать архитектуру двигла, нужно знать апи, куча тонкостей с UClass-ами.

Так всегда при использовании какой-либо технологии: COM, WinAPI, Qt...

К тому же есть вещи, которые не делаются блюпринтами в принципе, только на C++.

но есть же разница :
запустил редактор и в пару кликов создал класс стандартный, создал какую-то "логику в три клика", -поделка* готова.
VS
установить среду разработки, и SDK необходимые,
потом без знания с++  - тупик, кто знает едет дальше,
разбираться с епиковскими макросами чтоб просто объявить класс (а их там очень много),
потом искать нужные модули у двигла с нужными тебе методами,
наконец можно писать код для "логики в три клика",
на хот релоад можно особо не надеяться(надежность его высока но не 100%), поэтому каждое изменение кода - это рекомпайл, и перезапуск проекта.

и то и другое будет иметь идентичный результат в 90% случаев. (в зависимости от  самой "логики в три клика")

да плюсы намного производительней, имеют значительно более мощный функционал, а блупринтовое апи это всего лишь 5% и меньше от настоящего функционала двигла.
Но тем не менее когда "моделлеру нужно сделать процедурную генерацию", для этого ему не надо учить с++, и это прекрасно! Порог вхождения околонулевой!
Даже школьники с этим могут справиться.
И я повторюсь - те кто планирует всерьез заняться разработкой на анриале выучат с++ в любом случае, только у них это произойдет намного проще чем учиться по книжкам без контекста реальных задач.

конечно же это одно из лучших изобретений.

Изобретенных более 30 лет назад Ну, не блупринты, а похожее. А так да, если нужно что-то сделать быстро (опробовать алгоритм) и/или человеку, кто не силен в программировании, то такой подход - лучшее решение. В UE4 еще один фактор начинает влиять - блупринты компайлятся быстрее, когда лишь незначительные изменения в проекте и проект не особо большой.

В UE4 еще один фактор начинает влиять - блупринты компайлятся быстрее, когда лишь незначительные изменения в проекте и проект не особо большой.

Компиляция C++ Это еще та вещь. Она просто невыносимо долгая, так еще может не скомпилироваться и не слинковаться потом.

разбираться с епиковскими макросами чтоб просто объявить класс (а их там очень много),

UCLASS(), GENERATED_BODY(). В Qt примерно такаже фигня.

установить среду разработки, и SDK необходимые,

Хех. То еще удовольствие. Тупо Visual Studio 5 часов у меня ставилась. А еще эти SDK от UE. А еще, по классике жанра, надо будет что-то собрать перед использованием. И эта сборка может часа 2-3 занять. (Qt в release с -O3 на пять процессов без сборки и выполнения тестов и половины (если не двух третей) библиотек у меня собиралось примерно 1 час и 10 минут)

Порог вхождения околонулевой!

Вот такое оно программирование мышкой. Для моделера какого-то это плюс. Но мне абсолютно не нравятся технологии с порогом вхождения, близким к нулю. Я считаю, что они не могут быть хорошими для профессионала в той области, для которых созданы. Но может быть полезно, для тех, кто хочет что-то сделать в той области. (не важно как, лишь бы сделать)

анриале выучат с++ в любом случае, только у них это произойдет намного проще чем учиться по книжкам без контекста реальных задач.

Не. Они так не выучат C++. Может быть, научатся говнокодить или писать более-менее приемлимый код. Но врятли поймут разницу между map[key] = value; и map.insert({key, value}); или между std::vector<char> и std::vector<bool>.

не особо желаю продолжать тут офтопить ,но

Но врятли поймут разницу между map[key] = value; и map.insert({key, value}); или между std::vector<char> и std::vector<bool>.

нет у с++ такого что можно понять только избранным...
у меня достаточно знакомых которые в с++ незнают ничего ,но  в блупринтах они  могут отличить
массив булей, от массива символьных переменных
так же как и знать разницу между между присвоением переменной в ассоциированном массиве по ключу, от добавление новой ассоциативной пары.

блупринты не поддерживают лишь малую часть обычного ООП-шного принципа программирования.(типа множественного наследования)
в остальном проектирование точно такое же как и на плюсах, один в один. имено поэтому так легко с них перейти на плюсы.
то что у епиков свои типы массивов TArray,TMap не меняет абсолютно ничего.


я понимаю раздраженность снижением порога вхождения... но блупринты не претендуют на замену плюсов.
На них конечно  возможно сделать какой-то полноценный продукт,
основные ихние задачи
 - это быстрое прототипирование, получение пруф оф концепт с последующим проектированием системы на плюсах.
 - собрать из написанных программистами на плюсах модулей в цельную геймплейную логику, гейм дизами, левел дизами, моделлерами и так далее .

не особо желаю продолжать тут офтопить

Да и у меня тоже, но:

Ну вот и вы показали как они знают C++. Очень плохо. std::vector<bool> не является массивом bool. Это битовое поле. А std::vector<char> это массив чаров.
map.insert({key, value}); - это, действительно добавление пары в ассоциативный массив. Но вот что такое map[key] = value; если в массиве нет этого key? Эта конструкция тоже добавляет пару в массив, но медленно. Сама по себе конструкция map[key] уже добавляет в массив пару {key, Value() /*значение типа value по умолчанию*/}, если нет пары с таким key.
и таких вещей в C++ уйма.

то что у епиков свои типы массивов TArray,TMap не меняет абсолютно ничего.

Как всегда. В любой библиотеке пишут свои строки, свой аналог STL... А в gamedev вообще не любят использовать STL.

типа множественного наследования

В языках с нормальным ООП эта фича не нужна. Но в C++ нет интерфейсов, так что приходится использовать.

гейм дизами, левел дизами, моделлерами

По мне, эти не должны вообще прогать.

и таких вещей в C++ уйма.

и все они гуглятся по первой ссылке по нужде

Ну вот и вы показали как они знают C++.

я немного не это утверждал, я как раз сказал что они не знают ничего о с++ ... но они отличили известные им типы с известными им методами.
тоесть они знакомы концепцией массивов.

Я сам пишу код под анриал на плюсах, и просто не пользуюсь std::vector так как есть епиковские типы под которые все заточено, и мне не стыдно признать что я чего-то не знаю. Если бы std::vector мне понадобился я просто почитал бы документацию по нему.

проблемы перехода с блупринтов на с++ будет только с концепцией указателей и ссылок, все остальное как библиотеки со своими методами - простым чтением загугленых доков решается.

Рабочее, для "Reign of Guilds".

Какой это кайф наконец-то лепить не персонажей))

¯\_(ツ)_/¯

секатор, Возможно...

Оставалось место на ювишке, добавил сумку и карты игральные, чё добру пропадать)

Upd залью ещё и куртяшку крайнюю в процессе...