Обновить
1
0

Пользователь

Отправить сообщение

Вместо того чтобы переводить экранные координаты и тд можно вопсользоваться всего 1 нодой GetActorEyesViewPoint

Перетаскивать игрока на карту и делать Possess так себе способ, лучше сразу правильно учить. PlayerStart + настройка GameMode

Зато UE займет добрую сотню другую гигов места на харде))

А сколько по времени и места заняло? Хотя бы примерно знать порядок

В защиту iCloud предположу, что он проверяет только вирусы для своих ос, то есть iOS, macOS, watchOS, tvOS и тд. А судя по статье вы загружали вирусы для винды(?). Собственно основные пользователи данного сервиса яблоководы.
Стоит опробовать данное облако с яблочными вирусами.

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

Странный плюсовый код. Впервые вижу подобную конструкцию auto main(int argc, char** argv) -> int { ...}, применение лямбды там где не нужно (если это лямбда). Смысл в этом если можно просто int main() { ... }. Вот для чего чего, но для точки входа это извращение.
И опять эти var-ы и двоеточия в типах и вывернутый на изнанку порядок объявления переменных.
Меня от такого синтаксиса тошнит. Что котлин не нравится, что свифт (из того что пробовал).

Вот например каналы ютуба с полетами бпл с камерами, не знаю как все, но первый летает на 2-3 маверике
https://www.youtube.com/user/koshff2
https://www.youtube.com/user/niklinkin
https://www.youtube.com/c/AnVikKorzh
Они спокойно летают над Москвой внутри мкада и вдоль жд недалеко от Шереметьево

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

Добавлю еще, что код в виде картинок не очень идея, код принято в виде текста выкладывать.
И почему 4 а не 5 движок?

Я бы создавал SkeletalMeshComponent в C++ классе и проверял его в BeginPlay используя checkf. И спрашивается зачем нужен PlayerController если управление все равно пишется в самом игроке? Либо класс не нужен либо перенести в него управление (хотя такое лучше когда можно менять персонажей).

Лучше добавить ссылку на прошлую часть в эту, так будет проще ориентироваться.
Для проекта стоит использовать Git, очень странно видеть проект который его не использует, очень полезная привычка. А так же делиться кодом/проектом куда лучше, чем через облака (привет первая часть статьи)

На фоне С++, Java это очень простой язык...

А смысл в этом если доступ простым смертным к нему закрыт? Если в гугломагазин можно было физиком/самозанятым попасть, то тут нет.

Он есть еще в Maya, 3Ds Max и думаю еще куче другого софта, обычно в паре со своим скриптовым языком. Только вот в Гудини питон не рекомендуют использовать для взаимодействия с геометрией, только изменение интерфейса программы и создание/удаление нод, так как слишком медленно.

SDL грубо говоря Сишный аналог плюсового SFML, построенный на структурах, сырых указателях и без ООП, что мало вписывается в концепции современного языка, так что относить его к плюсовым либам считаю неправильным. Перечислены для плюсов в большинстве графические библиотеки для 2д игр.

LWJGL это только биндинги к языку плюсовых апи. С их помощью можно писать игры, но они все лишком уж низкоуровневые, например OpenGL, OpenAL, OpenVR, Vulkan и тд. Хотя сам язык мало подходит для игр и кроме майнкрафта сложно назвать известные проекты.

Unreal Engine 4 используют С++, Blueprint и некоторое подобие JavaScript

Скрипт был только в 3 версии движка, в 4 и 5 его нету, формально к нему можно приписать еще и C# и Python. Первый используется в скриптах сборки, а второй в автоматизации в редакторе.

void InitializeComponent();

И далее если метод переопределяется то должен быть либо virtual либо что предпочтительнее override

В данной статье в основном затронем программирование на C++, т.к. полноценное программирование в Unreal Engine 4 возможно именно на этом языке.

Можно создавать игры без использования С++, BP тоже полноценное программирование.

чтобы переопределить их поведение в стандартных методах BeginPlay(), Tick() и EndPlay() и получить пользовательский actor

определенное в методах InitializeComponent() и TickComponent()

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

using namespace Unigine;

Плохая практика выдающая нуба в плюсах.

Все объекты в Unreal Engine 4 наследуются от UObject, доступ к ним возможен при помощи стандартных C++ указателей или умных указателей Unreal Smart Pointer Library.

В движке используется сборщик мусора и поэтому не нужны никакие умные указатели если речь идет об объектах наследуемых от UObject

Типы данных

Помимо своих типов данных в UE можно использовать и стандартные плюсовые типы, странно что в табличке не перечислены типы с фиксированным размером, например uint32_t

Что делает в контейнерах ranged for?

В UE есть еще другие контейнеры, например стэк, очередь и тд.

Вывод в консоль

Не будет работать в UE без предвариательного создания логгера с указанным именем

Доступ к компоненту

Зачем искать компоненты если в полях класса есть ссылки на все компоненты?

В Unreal Engine 4 компонент USceneComponent (или производный) отвечает за действия с трансформацией actor’а.

Не отвечает и только при условии что он есть root актера, но рута может и не быть или им может быть любой другой объект

Поиск Actor

Зачем использовать итераторы в обычном цикле если можно использовать ranged for?

if (SphereCollider != nullptr)

лишняя писанина, можно просто короче

if (SphereCollider)

AKAsset* SpawnedActor1 = (AKAsset*) GetWorld()->SpawnActor(AKAsset::StaticClass(), NAME_None, &Location);

Где проверка на наличие мира (то есть не равенство nullptr)? И зачем использовать небезопасный Си-стайл кастинг?

Unreal Engine 4 позволяет расширять функциональность редактора с помощью Blueprint/Python скриптов.

Ложь. Блюипринты предназначены только для игровой логики и они прилично ограничены. А питон только для автоматизации. Расширять функционал редактора и создавать новые ноды для BP можно только на С++.

Создав скрипт мира

В UE данный скрипт (называется Level BluePrint) популярностью не пользуется, о нем мало кто знает и не рекомендуется его использовать.

UPrimitiveComponent* Trigger;

Обычно принято создавать тип тот же что и у создаваемого объекта, в данном случае USphereComponent

bool bHit = GetWorld()->LineTraceSingle(Hit, Start, End, ECC_Pawn, Params);

Где проверка мира на корректность? И В Чаще используется для рэйкаста LineTraceSingleByChannel

Гуи UE написан на Slate который можно использовать вне игровых проектов. А ваш движок, точнее редактор на сколько знаю написан на Qt, хоть на нем написан весь коммерческий 3д софт, но он тяжелый и неповоротливый.

В UE очень многие пользуются только BP, тех кто использует плюсы в разы меньше, особенно в ру сегменте. Еще в UE очень распространена практика: Класс Движка -> С++ Класс Пользователя -> Blueprint Класс. В С++ классе вся логика, а в BP все что относится к внешнему виду. Причем писать логику можно почти для всего, гуи, ниагара и тд, простыми актерами не ограничивается

Ни слова что в UE в С++ используется сборщик мусора и рефлексия, которая повсеместно используется. Можно было пару слов сказать про UPROPERTY и привести аналог из вашего движка. Я еще думал что в UE много макросов, но судя по именам (заглавными буквами) тут их еще больше, макросы зло.

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

Конечно же называют.

Сколько не перечитал уроков/гайдов/книг и не посмотрел видео и курсов по движку на русском, а так же активно сижу на офф форумах, так ни разу не видел что их так называли. Звучит довольно странно. Для меня похоже на "...кошки представлены несколькими животными...". Такое название используется либо для определения что такое либо для названия вообще всех актеров, но никак не маленьких групп.

Unreal Engine 4 хранит ссылки на исходный контент (*.fbx, текстуры и т.д.), представленные файлами *.uasset в папке проекта.

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

В UE основной объект сцены — Actor. Каждый actor обладает иерархией компонентов, определяющих его функциональность. Есть набор стандартных actor’ов, добавление которых на сцены создает экземпляр actor’а с предустановленным набором компонентов.

Тоже можно поспорить. Actor (или если быть точным то AActor) это пустой компонент, который можно разместить (или заспавнить) на сцене, все остальные объекты от него наследуются если их надо поместить на сцену. Все объекты (включая Actor) в движке наследуются от UObject.

На все ноды можно назначить C# (или C++) компонент, чтобы применить программную логику или расширить базовую функциональность нод.

В анреале надо просто наследоваться от нужного компонента чтобы его расширить/изменить поведение. ООП подход.

В Unreal Engine 4 источники света представлены несколькими actor’ами Light.

...

В Unreal Engine 4 атмосферное освещение обычно представлено набором actor’ов

...

Для симуляции тумана в Unreal Engine 4 вы привыкли использовать разные типы actor’ов

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

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

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

Ни слова про InstancedStaticMesh (как компонет), про блендинг анимаций, дерево переходов (State Machines).

Еще хотелось бы услышать про систему коллизий, например для UE надо создавать геометрию с префиксами UCX UBX UCP USP для разных типов, либо можно использовать полную модель как простую. Еще можно в движке создать (но упрощенно). Для меня создание коллизий это одна из базовых вещей которые я хочу узнать о движке.

Шейдеры выполняются на железе. Рейтрейсинг есть у 2 калек, особенно с ситуацией в стране, хотя и до этого с конскими ценами на видеокарты. В написании графики редко кто использует даже 4 opengl, все сидят на 3 версии.

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

Замена полигонам? Для видеокарты не существует этих ваших вокселей, ни в OpenGL, ни в Vulkan, ни в DirectX. Только полигоны (треугольники)) и точки.

Говорю как опытный программист графики.

А статья выглядит как одно большое сравнение. И сравнивать UnigineScript с Blueprint некорректно, так как первый это свой язык а Blueprint это средство графического программирования, по сути новомодное сейчас Nocode. У Unity для этого есть Bolt (и не сколько других альтернатив, сам Bolt владельцы движка специально выкупили с делали бесплатным для конкуренции с Blueprint). У вас не нашел подобного функционала. Он в движке используется куда чаще, чем С++, так как является куда проще. Хотя и ориентирован в первую очередь для дизайнеров и тех кто не умеет программировать. То есть начать работать в движке и создавать не сложные по функционалу проекты можно будучи далеким от программрования. И после всех новых фишек он прочно входит в Архивиз, судя по обзорам является в этом плане сильным конкурентом Vray и Corona. Еще много игр уровня ААА на нем выходят что сильно подкупает людей пользоваться им. А игр на вашем движке не могу найти даже, не говоря про ААА, но что там и инди почти нет (привет юнити).

1

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность