Я не спец по Qt и вряд ли смогу переписать редактор для godot. Да и мне это не интересно.

Отдельно есть редактор на Qt.

Я не спец по Qt

Ушёл думать...

Да и мне это не интересно.

Это, конечно, хозяин-барин. Если очень хочется именно свой движок...

Решил я написать 3d движок своей мечты

Зачем?

А вот в душе не знаю. Мне Krita понравилась, несмотря на её тяжёлое детство. Но это субъективщина.

Для фана. Плюс ни один существующий движок меня не устраивает.

А где этот renderwudget.cpp, я его не могу найти.

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

https://github.com/fra-zz-mer/RenderMasterEditor/blob/master/renderwidget.cpp

Gtk то зачем если Qt есть? На мобилки не получится, так как мне нужны compute шейдера и структурные буферы как минимум

ну дык для фана каждый своё делает себе, а присоединица к проектy только за бабло, фан на хлеб не намажеш.

У godot редактор убогий.

Так толсто. Ты порвал мой новый 32" 4K монитор. А еще залил жиром новый ковер, который я купил для своего кота. Ты не охренел? И да, ты никогда не сделаешь редактор лучше того, над которым трудится множество людей фуллтайм. А если такой выпендрежник и любитель опенсорса - давай вливайся и помогай делать Godot. Распылять усилия и делать 100500 непонятных поделок это фуфло.

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

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

А вас то устраивают? Для каких целей? Игрушки - да, бери хоть unity хоть unreal и вперёд. Меня интересует качество графики. С этим unity не справляется. Кубик в дефолтной сцене выглядит как полное г. Нет смены дня и ночи, недостоверный скатеринг. Да, можно довести визуал до тех, что в официальных видосах, но это очень геморно. Unreal уже лучше. Но лично мне он не подходит для экспериментов так как слишком долго рекомпилятся шейдеры, в плюсовую часть сложно залазить. Ue в целом монстр. Marmoset очень хорошая штука но он заточен под предметную визуализацию, а жаль. Blender - красиво но все таки пока не реалтайм, хотя вроде они идут к этому. Будем следить. Lumion - закрытый, но это почти то, что я хочу сделать. Godot - посмотрел сегодня, в целом неплохой но по сути они стремятся к unity (кроссплатформенность, универсальность). Panda - ковырял его но чем он не понравился уже не помню. Xenko - c# :(

Какой кастомный редактор? Он у меня на Qt как отдельный проект. Пока делаю на msvc, ибо для меня visual studio это удобно

в вижуалстудию можно втыкать свои плагины. я решил что ты прямо в студию решил встроить сиё поделие.

У godot редактор убогий.

так это же хорошо - сразу ясно, что можно начать улучшать

C# не пашет с Qt

враньё

плюс мне нужна максимальная производительность

тогда самописный движок вообще не вариант, берите готовый

И вот горячий энтузиазм автора как дождичком смыло. Это ЛОР, детка! :D

Firefox уже движок его и улучшай

А где смыло то?

Не приписывай ЛОРу заслугу тогго, что автор просто начинающий школьник.

Давай с нуля, да под вулкан, да под GPL. Тогда будет интересно.

Токсичная аура ЛОРа нагибает любой энтузиазм в зародыше. ;)

В наше время проще написать заново, чем пытаться разобраться в существующем монструозном проекте

https://github.com/fra-zz-mer/RenderMaster

Почему гитхаб? Как собрать проект?

Что я вижу: будет некий редактор в который можно будет запихать модельки, расставить, накинуть и настроить материалы, источники света. На выходе будет красивая реалтаймовая картинка.

Модельки в каком формате? Что понимается под «настроить материалы»? Планируется ли давать пользователю шейдеры или будет фиксированный набор параметризуемых шейдерных программ, а каждый материал на них основан будет? Источники света — какую предполагается использовать модель освещения (Фонга, Кука-Торренса, cel shading), каустики, тени, 3д лучи?

Загрузка моделей через FBX SDK

А чем libAssimp не угодил?

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

Похоже, что мы единомышленники :) У меня есть движок (библиотека c++ классов) 3д графики, поддерживающий освещение по Фонгу (в теории можно добавить любые модели освещения; shadow maps в разработке), загрузку моделек через libAssimp, рендеринг с камеры в текстуру (через FBO), собственное наречие шейдерного языка glsl (я добавил импорты, абстрагирование от способа передачи текстур в шейдер и ещё пару мелочей), рендеринг через OpenGL 4.5 Core Profile + ARB_bindless_texture (но в теории можно написать альтернативный renderer plugin и использовать в нём Vulkan, например). Собрать со всеми плагинами и 3 семплами можно через упрощатор сборки в репозитории вызвать ./download-and-build.sh. После успешной сборки в этом же упрощаторе можно звать ./kawaii-scene-generator.sh и ./kawaii-scene-viewer.sh. Первый — процедурный генератор простенькой сценки, второй — просмотрщик сцен (как своего собственного формата (например из генератора сцены), так и внешних (через libAssimp)). Третий сэмпл — это чёрный экран. Нужен, в основном, для проверки рендерер плагинов на минимальную работоспособность, а также бенчмаркания движка на накладные расходы. На этом движке очень даже реально написать такой редактор, как тебе хочется (если хочется не динамических 3д лучей с каустиками). Я сейчас пишу на нём (пытаюсь) мультиплеерный платформер (называется BallRise, почти готов, но пока не сообщает о победе / поражении и лагает сеть), аркаду с идеей «hedgewars в 3д» (нууу.. pumpkin_wars уже грузит ассеты..) и головоломку, смысла которой не понимаю сам (эта игра, пожалуй, дальше всех от завершения прототипа) :D

Если бы токсичная.. Скорее уж летаргическая :D

А чтобы был.

Из знакомых мне bitbucket и github я выбрал второй. Движок собирается через VS 2017 как обычно (проект Engine), после этого нужно будет запустить батник install.bat из cmd с правами администратора. Для запуска используется проект Test.

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

По системе материалов еще не решил. Знаю, что наружу будут торчать PBR параметры (albedo, roughness, metallic..). Внутри это будет либо «захардкоженый» материал с единственным шейдером, либо буду делать generic-материалы: можно будет указать различные pass-ы, текстуры, параметры - на этот счет у меня много мыслей.

BRDF будет Cook-Torrance. Diffuse - Blinn Phong либо можно будет более продвинутые посмотреть, для specular GGX NDF вместе с Schlick-GGX geometry shadowing function. Для теней обычный PSSM. Каустики, рефракции, SSS и прочих продвинутых эффектов пока не планировал.

Скинь свои контакты)

Движок собирается через VS 2017 как обычно (проект Engine), после этого нужно будет запустить батник install.bat из cmd с правами администратора. Для запуска используется проект Test.

Это то понятно, а под эту ОС как собрать?

Модели в формате fbx. Я конечно за открытые форматы но без fbx движок будет не нужный ибо он самый популярный.

А разве не .dae, .obj и всякого рода велосипеды?

По системе материалов еще не решил. Знаю, что наружу будут торчать PBR параметры (albedo, roughness, metallic..). Внутри это будет либо «захардкоженый» материал с единственным шейдером, либо буду делать generic-материалы: можно будет указать различные pass-ы, текстуры, параметры - на этот счет у меня много мыслей.

Я вот как раз ничего лучше не придумал, чем выдать пользователю сверхмощную пушку шейдеров — хочешь PBR, хочешь нефотореалистические вещи :) Предлагаю PBR добавить «сбоку» от шейдерных материалов, а рендерер плагины пусть определяют через
glsl шейдеры (так будет определять Misaka3D), или что другое.

libAssimp наверно хорошая штука, но пока лишнюю зависимость не буду вкручивать.
Загрузка моделей через FBX SDK - единственная зависимость, но без нее никак:(

А заменить FBX SDK на кроссплатформенный свободно пермиссивный libAssimp совсем не вариант?

BRDF будет Cook-Torrance. Diffuse - Blinn Phong либо можно будет более продвинутые посмотреть, для specular GGX NDF вместе с Schlick-GGX geometry shadowing function

И это всё будет одна большая модель освещения? Или разные на выбор?

Для теней обычный PSSM

Вот, кстати, да — светильников сколько (1, 8, user defined), каких типов светильники? А то если реализовать PSSM, то примерно на 10 доте может получиться бенчмарк видеорамы :D Точечные светильники вообще тяжёлые с их кубическими shadow map-ами.

Скинь свои контакты)

В профиле гитлабовском почта указана.

Движок собирается через VS 2017 как обычно (проект Engine), после этого нужно будет запустить батник install.bat из cmd с правами администратора. Для запуска используется проект Test.

Это то понятно, а под эту ОС как собрать?

Иначе, мне лично, тяжело оценить, какой из движков RenderMaster и Kawaii3D подходит больше для реализации редактора сценок. Нужно ведь решить, на базе какого движка будет приложение.

RenderMaster

Stable ABI (Application Binary Interface). I.e engine binaries stable across different compiler that supports COM and different release of one compiler. No need recompile engine if you migrate to new compiler.

Это ещё зачем? IMHO связывать себе руки стабильным API, а уж тем более ABI, совершенно ни к чему на ранних этапах развития проекта. Иными словами обратная совместимость строго говоря с ничем (редактор сцен ведь еще не дописан) не нужна. Когда требуется сломать совместимость для дальнейшего развития, ломай не сомневаясь, раз уж все юзеры (приложения, зависящие от библиотеки) могут быть посчитаны по пальцам одной руки, да ещё и тобой написаны. А идти исключительно ради обратной совместимости на _такие_ жертвы, как COM (он, на минуточку, только на Windows существует) явно не стоит.

Это то понятно, а под эту ОС как собрать?
Иначе, мне лично, тяжело оценить, какой из движков RenderMaster и Kawaii3D подходит больше для реализации редактора сценок. Нужно ведь решить, на базе какого движка будет приложение.

Под linux пока не портировал.

А заменить FBX SDK на кроссплатформенный свободно пермиссивный libAssimp совсем не вариант?

Загрузчики на все остальные форматы как-нибудь надо вкрутить, но сейчас на это нет времени. FBX же закрытый формат, его не заменить.

И это всё будет одна большая модель освещения? Или разные на выбор?

Одна PBR модель.

Вот, кстати, да — светильников сколько (1, 8, user defined), каких типов светильники? А то если реализовать PSSM, то примерно на 10 доте может получиться бенчмарк видеорамы :D Точечные светильники вообще тяжёлые с их кубическими shadow map-ами.

На каждый лайт по shadow мапе. Сколько пользователь создаст лайтов, столько и будет. Понятно, что тени не бесплатная вещь.

Это ещё зачем? IMHO связывать себе руки стабильным API, а уж тем более ABI, совершенно ни к чему на ранних этапах развития проекта. Иными словами обратная

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

Под linux пока не портировал

Чтобы портировать на линукс, придется выкинуть COM. Так же нужно будет выбрать систему сборки. Для плюсового проекта в 2019 де-факто выбора 3 — qmake, cmake и meson. Так как Qt в RenderMaster не используется, qmake будет смотреться максимально странно.

Загрузчики на все остальные форматы как-нибудь надо вкрутить, но сейчас на это нет времени. FBX же закрытый формат, его не заменить.

Странно. Говоришь закрытый, а вот Kawaii3D через libAssimp его грузит и не жалуется (ссылка на гугль-дриве на png, что же они все жмут бедный несчастный скриншот, как только могут..). Или это не тот fbx и позарез нужен именно текстовый?

На каждый лайт по shadow мапе

Естественно :D

Сколько пользователь создаст лайтов, столько и будет

Хорошо, это и интересовало.

Все это можно будет собирать разными компиляторами кому как удобно.

И много компиляторов насчитал? И вообще движок ведь не 10 лет собирается, так что пользователь (программист, пишуший игру, например) или мейнтейнер, тем более, вполне может собрать и движок и все плагины как ему надо. Главное — доступ к исходникам :)

Чтобы портировать на линукс, придется выкинуть COM.

У меня COM совсем немного (в нескольких местах) - ifdef-ами огорожу.

Так же нужно будет выбрать систему сборки. Для плюсового проекта в 2019 де-факто выбора 3 — qmake, cmake и meson. Так как Qt в RenderMaster не используется, qmake будет смотреться максимально странно.

Напишу простенький make файл и все. В Qt будет как обычно собираться.

Странно. Говоришь закрытый, а вот Kawaii3D через libAssimp его грузит и не жалуется

Да, есть открытые реализации, видел. Но спецификации FBX нет в публичном доступе.

И много компиляторов насчитал? И вообще движок ведь не 10 лет собирается, так что пользователь (программист, пишуший игру, например) или мейнтейнер, тем более, вполне может собрать и движок и все плагины как ему надо. Главное — доступ к исходникам :)

https://en.cppreference.com/w/cpp/compiler_support - живые. Умножай на все версии. Не приятен именно момент привязки бинарей к конкретной версии.

У меня COM совсем немного (в нескольких местах) - ifdef-ами огорожу.

А как же совместимость ABI :D?

Напишу простенький make файл и все. В Qt будет как обычно собираться.

А вот и нет. Qt Creator не откроет проект, основанный на makefile. Но собираться будет, отчего нет. Пока новый файл в проект не добавишь, или не удалишь существующий.. Без IDE очень тяжко придётся. Если же разрабатывать двиг только на винде, а на линухе только компилять и использовать, то это не TRUE_Ъ. К тому же синхронизировать .sln и makefile заколебёшься. А вот cmake и meson будут собирать тебе проект под все поддерживаемые ОС.

https://en.cppreference.com/w/cpp/compiler_support - живые. Умножай на все версии

Ээ, нет! Только на те версии, где ABI сломали.

Не приятен именно момент привязки бинарей к конкретной версии.

Вас клинит на бинарях.. мне жаль это говорить, но, кажется, у вас проприерчанка, так же известная как волчанка проприетарщика :D

Не надо ему ничего подсказывать и помогать. Он сам выбрал всё самое ненужное и помойное. Если он выбрал VisualStudio, то о линуксе не может быть и речи, а следовательно это оффтоп.

Так почти же.

Он уже функционален и юзабелен.

Но ещё же не вышел? Значит, у автора есть шанс.

До апреля запилить стабильное кросс-платформенное решение? Нуачо, всякое может быть, да.

Не надо ему ничего подсказывать и помогать

Надо.

Он сам выбрал всё самое ненужное и помойное

Именно поэтому советы кодеров мира линукс будут здесь так ценны.

Если он выбрал VisualStudio, то о линуксе не может быть и речи

Если сборочная система cmake, то вполне можно разрабатывать студией на винде и в то же время QtCreator-ом или Code::Blocks, или ещё чем под линуксом.

Ты опоздал, Blender 2.8 уже почти вышел.

Его ГУИ всё такое же гуано, а поддержка amdgpu / OpenCL такая же кривая? Ну-ну.

Скачай да попробуй.

За пол года я полностью переписал движок. Вкратце по фичам:

-Deferred render подход -Заимлементил физически корректное освещение -Система gameobject-ов -Манипулятор -Выбор объекта по клику (Picking) -Импорт FBX -Система материалов -Нормал маппинг

https://github.com/fra-zz-mer/RenderMaster

молодец

API DirectX 11 или OpenGL 4.5

два ненужно подряд? Vulkan не подходит?

Во-первых, в последние годы это меняется. Во-вторых, зачем? Есть тот же UE4 и Unity. Освой, займись написанием плагинов. Профит получал бы уже сейчас, если бы год назад этим занялся.

Плюс в редакторе будет минимальный функционал «только для графония», т.е не будет: физики, скриптов, анимаций, skinned, и.т.д.

Не нужно. Не взлетит. И тогда ничем оно не будет лучше Blender.

За пол года я полностью переписал движок

А система сборки всё так же студия-only?