Выбор 3D движка с полной, законченой и удобной инфраструктурой

Пеши свой. Движог мечты. Чо как не мужик?

У меня уже есть, но для мой задачи не подходит:
http://catwasser.tk

Cube 2 не?

Пиши свой, будь как ...Кармак. Возможно потом все лоровцы будут гордиться тобой.

source engine,

просто худше г-но из 2004....делать на ЭТОМ чтото в 2016...просто вот глядя на сурс и то «как» там надо кодить-если тебя не блеванет через минуту,от этих идиом 2000-го года в 2016...то обмазывайся им наздоровье

в 2016 делать «карты» на сурсе-это худшее проклятье что можно пожелать

ты прав, чо :) С задним-то умом косплей Кармака не так уж и труден

Государству нужны программисты! Нам нужна русская версия WOW Кармака!

тему не читай & сразу отвечай

Но они же будут проповедовать плохое:

What motivated to move the team to C++ for idTech4 ?

John Carmack - There was a sense of inevitability to it at that point, but only about half the programmers really had C++ background in the beginning. I had C and Objective-C background, and I sort of «slid into C++» by just looking at the code that the C++ guys were writing. In hindsight, I wish I had budgeted the time to thoroughly research and explore the language before just starting to use it.

You may still be able to tell that the renderer code was largely developed in C, then sort of skinned into C++.

Today, I do firmly believe that C++ is the right language for large, multi-developer projects with critical performance requirements, and Tech 5 is a lot better off for the Doom 3 experience.

Отака краснознаменных клонов Кармака с серпом++ и новыми блестящими молотками... отполированными долгим задрачиванием.

Отака краснознаменных клонов Кармака с серпом++ и новыми блестящими молотками... отполированными долгим задрачиванием.

Это будет круто! Хочу увидеть!

А в чём нюанс? Просто с точки зрения меня как геймера Юнити оставил не лучшее впечатление.

в этом и ньюанс-на юнити ты просто делаешь игру не отвлкаясь ни на что,и тратя минимум времени на все включая модельки

сразу уточную-я пишу как «заваливавший не один свой проект»,также как и закончил пару проектов «с нуля»,также как «делал проект на юнити очень большой и не один(в смысле не соло)»

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

вот именно так и ведется-ты не наешь таких слов как «память»(ее выделение слежение виртуальная оперативная видео...зачем это все) не знаешь таких слов как «потоки»(их синхронизации рассинхрон ожидание и прочая чушь) «протокол»(интернет клиент сервер) «opengl»(в юнити ты не используешь ни dx ни опенгл апи,там(в юнити)все вынесено в отдельные функции) «загрузка текстур моделей область видимости»(и прочая граф-движковая чушь)...ты просто делаешь именно что тратя на «создание сервера»-одну минуту(ну 10 минут в первый раз),дбавление объектов и их привязка к игровой логики-вообще не занимает время-юнити само делает...там все очень круто(да на самом деле)
и к чему приводит:
1.у тебя «сетевой протокол» жрет 500кбайт/сек от одного клиента,и 10 киентов к 1 серверу 5 мбайт/сек,почему так-не потому что юнитик кривая,а потому что ты синхронизировал все объекты и еще и частицы...и чтоб это пофиксить-надо «оптимизировать игру(не юнити а твою логику))...заменяя „логику по умолчанию“ юнити также
2.у тебя отсутствует вообще какая либо защита от читов,вплоть до того что можно влезть в твою БД из любого клиента-опятьже не юнити а проект,просто юнити делает „по умолчанию“ а если ты не знаешь что „в тексте пароля можно отправить sql запрос парсингом трафика“-то да на „юнити сервере“ не стоит защиты и проверки получаемого текста ибо юнити понятия не имеет что ты используешь БД или какую БД ты используешь и что это поле являяется паролем...(также и с читами игровыми-это твоя логика делает читы а н еюнити
3.отжирается 1гб видеопамяти потому что у тебя сцена размером с город с „живыми объектами“(свойство по умолчанию юнити что объект анимирован и взаимодействует с другими объектами(физически-расчеты расстояний сталкновений) и всегда виден)-опятьже привет твоей логике
4.жрется 100% восьмиядерника...потому что у тебя цикл for проходит всех объекты мира(зачемто) когда на каждый объект можно навесить нужное событие и действие по событию и иметь 10% от 1 ядра нагрузку...опятьже твоя логика

...

и все в таким стиле
юнити это-у тебя будут квадратные головы и колеса,у тебя будут квадратные текстуры из майнкрафта,будет нехватающая озвучка музыка,будет „скудный мир“ и слабая игра,жрущая 100% любого ПК....но она БУДЕТ закончена на 100% даже если ты ниразу не программировал до этого,при этом ты не будешь отвлекаться на „программискую чушь“...и будет готово за пару месяцев

ниже опишу что такое делать с нуля...и чем хуже...

Пункты 1 и 2 не страшны, поскольку я делаю не сетевую игру.
А пункты 3 и 4 зависят от меня. Я программист в хорошем смысле этого слова и, думаю, если надо, то смогу исключить из просчётов то, что считать заведомо не нужно.
Ок, буду смотреть.
Но ты мне сразу вот подскажи одну страшную и жуткую вещь — смогу ли я «воровать» из других современных игр объекты и впихивать в движок. Т.е. понимает ли он какие-то стандарты на это дело. Моделист из меня как из говна пуля и это изменится не скоро.

На дельфях раньше примерно так и кодили :) Юнити продает не движок, а иллюзии, что чувак без опыта и профильных знаний «тоже сможет» в игры. Это понятная, с коммерческой точки зрения, хм... позиция. Но... в то же время еще и профанация :)

смогу ли я «воровать» из других современных игр объекты и впихивать в движок.

Не. Ты будешь судорожно гуглить маркет в поисках «ассетов» :)

как делаются проекты с нуля:

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

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

утро-так ладно начну движок делать,может так будет проще
написал int main(){}
еще неделя прошла
так давай начну с опций запуска
дописываешь две строки в main
еще недела прошла...все в дипресии и ты бросаешь проект(или жрешь бабло дальше них-я не делая)

почему так-потмоу что написав первую строчку или нарисовав первый полигон-ты понимаешь НАСКОЛЬКО много еще работы-с памятью и объектами с опенгл с синхронизациями привязкой собстенным_АПИ миллион функций «движка»...и это все еще за тыщу киллометров далеко от даже НАЧАЛА работы над проектом-ибо сначала надо накодить «базу»,минимальную логику,потом уже на этой основе кодить скрипты игры и сами объекты рисовать
и рисуя полигон носа-ты осознаешь насколько и КАК МНОГО надо еще моделек не говоря уже про текстуры
и что ты не можешь нарисовать «квадратное колесо»-ибо этож твой проект,ты хочешь все делать идеально(или хотяб не квадратное)

и даже ЕСЛИ ты дотянул до половины проекта,спустя два года-ты очень сильно захочешь перенести все на Юнити(или любой готовый движок)....даже попытаешься но юнити будет тормозить и выдавать квадратные колеса...и еще спустя 2 года появится новые юнити и новые ПК(спустя 4 года со старта твоего) которые в 2 раза мощнее старых и новый «юнити» делает все что ты хотел 4 года назад без тормозов уже и без квадратных колес...

НО-ты можешь сделать идеальный проект и на Юнити сейчас НО-именно что на юнити тебе также прийдется и рисовать высококачественные модельки,и перекодить половину юити выбросив ненужные события,и написав куу своей логики

и займет такой «идеальный» проект столькоже сколько «идеальный прокт с нуля»

тоесть суть в том что:
Если ты ЗНАЕШЬ как делать «идеальный проект»(именно что знаешь и здраво представляешь весь объем работ)-то реализация его одинакого медлена что на юнити что с нуля

НО-если ты НЕ ЗНАЕШЬ как делать проект-ты никогда не закончишь свой с нуля(даже с квадратными колесами),но ты 100% закончишь проект если начнешь его на юнити

почему-как я написал в прошлом посте-на юнити тебе не надо отвлекаться на «программистскую чушь» ты там просто сразу делаешь квадратные колеса и вешаешь на них события...

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

и на этом фоне-время-затраты на «создание» своего движка стремяться к 1% времени от времени создания всей игровой логики/скриптов всех моделей и текстур,и очевидно что накодив достаточно хорошо ты можешь сэкономить еще 1% времени(относительно юнити) за счет уже готовой структуры движка(когда в юнити ты будешь делать подпорки(для движка) какие тебе нужны)

...

когда как в 99% проектах на юнити-само создание проекта=(равно) времени написания движка,ибо проект простейший с квадратными колесами

вот и зачем писать свой движок для твого случая-когда можно использовать юнити

Нененене :) Про квадратные колеса в пресс-релизах юнитей ничо не сказано: там только истории безудержных успехов.

Но ты мне сразу вот подскажи одну страшную и жуткую вещь — смогу ли я «воровать» из других современных игр объекты и впихивать в движок. Т.е. понимает ли он какие-то стандарты на это дело. Моделист из меня как из говна пуля и это изменится не скоро.

про воровство....сам понимаешь линукс все дела...но всеже-воровство «качественной модельки» из любой популярной игры=времени на создание похожей модельки...ибо «воровать» ты будешь геометрию(в лучшем случае)...тебе понадобиться обрезать маркировать делать анимации(из геометрии без слоев)....это даже для менят(такогоже криворукого дизегнера) дольше чем кривыми руками нарисовать модельку с нуля....моделька в 3д редакторе-это слои анимации+текстурки,моделька сворованная-геометрия+логика в движке+текстуры отдельно...удачи парсить все это в одну модельку для блендера(ручками вбивая геометрию слои и анимации в блендер да,да сотни тыщь вершин полигонов ты ручками будешь именовать у каждой модельки сворованной)

ну и да самое главное-открой для себя гугл и ВНЕЗАПНО порталы по GPL/опенсурс моделькам(где их просто миллионы буквально,на все случаи и редактировать их можно прямо полсе экспорта)

Не.

Гм. Какой-то базис для старта мне будет принципиально важен. Пусть это даже будут классические «гитлеровцы». Пофиг.
Мне нужен будет набор моделей столов, стульев, людей, бутербродов и окурков.

Я пока просто спросил. На самом деле мой вопрос следует читать так: «Воспринимает ли движок рендера какие-то стандарты de facto или нужно будет создавать их с нуля?»
У меня забавная идея геймплея, но напрочь отсутствуют навыки моделирования. Я программист-плюсовик. Не менее, но и не более. А проект — соло.

модельки-это матрицы с 3д координатами,тебе рисовать их не надо ты их цифрами набровать можешь и экспортирвоать прямо из движка...

и раз ты такое пишешь то ты не понимаешь что такое opengl-это просто «система отображений координат» которыми ты кормишь память через opengl_api

а анимации движения видимость мира его поворот(да поворот)-это делает твой код перемещая координаты....

и моделька в 3д-редакторе-это сумма текстур(всех для модели) вместе с геометрией,с анимациями модельки)ходьба поднятие рук тдтп) какието спец эффекты(дым падения подобное)...это все кушает движок(юнити или неважно какой)-разделяя и выполняя все в «3 разных слоях логики»-скармливая 3д модель в видеопамять,используя сценарий анимации для изменения координат модели,и скармливая в видеопамять текстурки в зависимости от зоны видимости и под нужным углом

и взяв набор «3д координат»-это 10% от модельки в игре,все остальное делать руками

бабы будут?

то ты не понимаешь что такое opengl-это просто

Концепцию я понимаю. Более того — я лет 10 работал в геймдеве. Но я писал либо серверную часть либо просто игровую логику. Разумеется я знаю что такое матрицы перехода и прочие подобные штуки (хотя и не работал с ними почти никогда). Но я сейчас говорю про устоявшиеся форматы хранения моделей. Так, чтобы я мог скормить эту модель движку и он мне её отрисовал в нужных координатах, да ещё и с коллижион-боксами. Любой движок это должен уметь сам. Но для этого нужно движку дать то, что он умеет кушать. И меня интересует умеет ли Юнити жрать выхлоп всяких 3дмаксов или в чём там теперь рисуют.

Будут. А будешь себя плохо вести, то я дам тебе в качестве главного персонажа — негра-лесбиянку.

Может конечно, я вот ни в зуб ногой в геймдев или c#, а подиж в свободное от работы время наколупал пару геймплей прототипов. Потратил времени в сумме наверное меньше чем конпеляется все то чему нужно конпелятся в других движках(собственно получилось даже быстрее чем делать на js для браузера, в чем я достаточно ОК).

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

Да так оно и будет. Я просто интересуюсь а будут ли шары легко импортируемы. Не софтварно же их рисовать:)

Ну шары там в коробке есть https://docs.unity3d.com/Manual/PrimitiveObjects.html можешь наделать из них префабов и потом поменять на модельки когда придет время или внезапно найдешь подходящие.

Энгельс (и Каутский) передают тебе «спасибо»:)

Э-э-э... Это же Маркс? Они из-за бород очень с Энгельсом похожи...

Это Маркс да.

Угу. «Осталось только бизонье г-но убрать, но его много» (с) :)

Ну а какая разница? Понятно же что все равно выбрасывать прототип. Юзкейзу ТСа вполне подходит кмк.

Irrlicht можно попробовать.

Или любую версию UE.

Я копал в сторону 2007 как самый распространённый среди модмейкеров...

Т.е. ты брал устаревшую версию и удивлялся что она заточена под устаревшую вижуал студию? Автор, ты серьезно?

Другие версии точно так же заточены под устаревшие версии Студии. Просто эти версии другие.

Thief 1/2

Я мимокрокодил, но на id Tech 4 есть The Dark Mod, про который не раз читал отзывы в духе «это то, каким должен быть Thief».

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

Что на счёт Blender?

А он тут каким боком? На нём можно сделать игру, а не мультфильм?

Да. От первого лица.

Я тоже не говорил про паровых роботов. Просто заметил: «можно потыкать TDM, исследовать на наличие нужных фич».

В блендере можно все)

Только я вот почитал и они сами прямым тестом пишут, что их Game Engine — говно и они будут его переделывать нахрен и с обязательной потерей обратной совместимости.

Тогда это отличный шанс присоединиться к распаковке

и взяв набор «3д координат»-это 10% от модельки в игре,все остальное делать руками

слушай, вот интересно, не видел ли ты такой программы,

чтобы она логировала какие OpenGL/DirectX API выполняются для работы с этим «набором 3д координат» и позволяла сдампить их в виде моделек и текстур, отдельно?

то есть что-то типа хуков на API => лог API => дамп «наборов 3д координат» и текстур, шейдеров => восстановление «3д моделек» для движка => восстановление 3д-редактора из этого вот ???

может что готовое есть.

чтобы выдрать модельки из готового ЛЮБОГО openGL софта ???

«Воспринимает ли движок рендера какие-то стандарты de facto или нужно будет создавать их с нуля?»

дофига как стандартов моделек конкретных движков (Quake2 MDL, например и т.п.) так и общих форматов на уровне 3д-моделлер=>3д-движок (COLLADA, FBX, .blend, например — многие движки их напрямую понимают), так и форматов конкретного АПИ (у DirectX например есть свой).

см. assimp-viewer, поддерживает 10500 форматов различных моделек. нагугли в интернетах ассеты для них, например sharecg turbosquid exchange3d 3dvia ourbricks.com sketchfab 3dfoin.com TheFree3DModels

см. также Daz3D для персонажей, например — оно free, есть SDK на C++, экспорт в COLLADA и т.п.

также например unity asset store, morph3d (daz3d персы для unity)

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

многие движки понимают стандартные форматы типа того же MDL из quake, hl (кстати, см. хач3д), или той же COLLADA.

assimp умеет их показывать и конвертировать, например

ты свободно можешь записывать все что происходит в opengl или dx софта такого полно и он очень простой(самому можно написать за день...)

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

гуглить сможешь сам такого софта(который даже 3д кино как я описал делает) достаточно

apitrace