А автор вообще не программист, если фазер ниасилил. Постеснялся бы позориться.
раб вакуумной лампы
> Запил движка это гарантированный фейл всего проекта. Если повезет - максимум
> говнопроект с 15 скачиваниями в стим за два года.
Как будто на UE/Unity нельзя сделать говнопроект с 15 скачиваниями в стим за два года. )))
harbinger
> Вся проблема в том что в скором времени, там перестанут зарабатывать проекты вообще, кроме уровня проектов, приближенного к уровню ААА проектов
раб вакуумной лампы
> Запил движка это гарантированный фейл всего проекта. Если повезет - максимум говнопроект с 15 скачиваниями в стим за два года.
Просто в большинстве случаев, как играми в целом, так и движками в частности, занимаются дилетанты, которые не имеют не только опыта в разработке игр, но и дисциплинированности, чтобы всё это дело серьёзно освоить. Я на данный момент начинаю выводить свой движок на уровень профессиональной заготовки, имеющей довольно серьёзный потенциал, и могу точно сказать, что смогу для начала сделать на нём игру, не хуже Portal 2. Скоро начну моделировать свою первую демку с ультрасовременной квартирой и уже на практике, исходя из потребительских требований, более осмысленно работать над движком. Есть люди, которые рвут стереотипы, но их единицы, подавляющее же большинство являются всего лишь исполнителями, не имея воли к достижению определённых высот. Вот и получается, что у молодняка есть стремления и желания, но нет серьёзности и опыта, а у выдохшихся стариков наоборот, поэтому всё так, как есть, и мало кто чем достойным может похвастать.
Daniil Petrov
PBR сделал уже?
kipar
> PBR сделал уже?
Давно!
Daniil Petrov
И полупрозрачные поверхности сортируются?
kipar
> И полупрозрачные поверхности сортируются?
Тебе заняться нечем?..
Daniil Petrov
ну, для меня это два критерия "годноты" движка. PBR понятно зачем, а если в сцене больше одной полупрозрачной поверхности, он должен корректно их отрисовывать, соответственно либо сортировать либо OIT.
kipar
Ну вообще-то я ещё и непрозрачные объекты сортирую, так как реализовал такую функцию:
После отсеивания объектов посредством Frustum Culling, у меня идёт проход вывода Color Pick Buffer и делается он так: непрозрачные объекты выводятся от камеры в глубину, где перед выводом каждого объекта делается тест Occlusion Query, т.е. передние объекты засерают буфер глубины и дальние объекты, которые уже этот тест не проходят, помечаются для дальнейшего рендера как невидимые и соответственно здесь не выводятся. А нужно это для того, что мне необходимо будет реализовать Ambient Occlusion Volumes, а в нём геометрия выводится не один раз. Ну а практика потом уже покажет на загруженных сценах, что быстрее = рендерить весь Frustum в Color Pick Buffer или сортировать и выводить моим методом...
NeoAxis Engine 2019
www.neoaxis.com
betauser
> NeoAxis Engine 2019
> www.neoaxis.com
Ради любопытства, версии движка 2019.х.х. названы так, чтобы часть трафика отжать у unity?
harbinger
> Ради любопытства, версии движка 2019.х.х. названы так, чтобы часть трафика отжать у unity?
Да сейчас вообще все, кому не лень, обзывают свои версии так... хоть кто-нибудь бы проявил оригинальность...
Одни проявили, а другие подхватили = что крестьянин, то и обезьянин!
harbinger
> Ради любопытства, версии движка 2019.х.х. названы так, чтобы часть трафика
> отжать у unity?
Нужно было показать, что это совсем новый движок. Раньше было NeoAxis Engine 1.0, 2.0, 3.5.
kipar
> И полупрозрачные поверхности сортируются?
Кстати, прозрачных объектов пока нет, так как в отложенном рендере их выводить довольно таки проблематично, поэтому пока отложил этот вопрос до лучших времён = пока и без этого большой список масса дополнений и доработок.
gamedevfor
> О чем это говорит? О том что взяв их движок ты НЕ ПОЛУЧАЕШЬ конкурентного
> преимущества, а только попадаешь навечно в кабалу.
А пиля свой движок на что попадаешь? Вот если на вскидку,вы много сможете движков назвать,которые могут с УЕ/Край/Юнити конкурировать? Если делать какой-то 2д,то ладно,если же ориентироваться на качественную графику и инструментарий,можно не один десяток лет на разработку потратить. В итоге тут вопрос не столько актуальности движка,сколько вопрос актуальности в предметной области конкретного проекта. Если брать в расчет очень особенный проект,который без тонны колхоза на существующих нормально не реализуешь,тогда да,лучше свое,но таких проектов мало,очень мало. В одно тело сделать что-то конкурентно способное задача далеко не тривиальная,да и без имени это инструмент будет интересен только самому себе,ну может еще нескольких заинтересует,но большого спроса явно так не получишь. В итоге получается слишком много если,которые влияют на факторы выбора. Да и надо понимать,что такие загоны оправданны только в случае с очень большими и дорогими проектами,где потери на отчисления получаются слишком большие,на практике это не середнячки и таких проектов единицы. Да и надо учитывать,что написать движок,по сути может практически любой программист,а написать нормальный движок - единицы.
Тема в архиве.