I feel orthographic projection is such a strange feature to advertise at this point. It's essentially just not doing perspective scaling in your projection matrix.
Compare that to all the sci-fi looking things like Nanite and Lumen which completely change how we approach building game environments.
Assumption about the shape of your projection tend to creep into the weirdest places in complex renderers like the one in UE over time. I am willing to bet that a lot of the screen space lighting and post processing shaders had assumptions like that baked in. This can make adding a different projection type a heavy lift, even though nothing about it is magic.
Anything that involves raytracing would need to change from having a finite camera position in world space, to having an infinite one with parallel rays. There are some ways to make the math work out the same, but in general... nope.
Like, consider that you never actually need to scale anything in a perspective view, because you literally can't tell the difference (all the rays remain the same). In an orthographic view, scaling is the only way to actually zoom in/out. Oops, any code that assumed your view is unit-scale will break.
Perspective vs orthographic literally affects every single one of those fancy features you like.
I used UE4 professionally a few years back, and at the time ortho cameras were effectively unusable. Landscape actors were rendered at the worst LOD, for example, with no workarounds. Glad they're finally bringing them up to parity.
I suspect they are seeing a lot more penetration into the Product Vis/Architect/CAD markets now that polygon optimization to just get realtime isn't as much of a concern.
I agree, that does seem to be the reason behind it.
It is still the kind of basic thing that everyone who has written their own renderer has done, compared to all their other ground breaking new tech. Which is funny to me.
If you can read C++, this one is surprisingly easy to get into. You can do most things with the amazing graphical editor and for the very few cases where that isn't powerful enough, you can debug the whole thing in Visual Studio which means you can see parameters and stack traces for everything. And in my personal opinion, classes are predictably named and layered in an useful way.
I found learning it and working with it quite enjoyable, especially compared to my experience with Unity where the lack of source code forced some very ugly workarounds on us. And with "only" low millions in annual revenue, Unity wasn't even willing to discuss the price for source code access... but with UE, you get a triple A game as demo project for free.
I use unreal professionally. I would say that unreal is very opinionated in the way things are done. This is a good thing if you can stick to it and know how to leverage the systems in the way they were intended but makes it also makes it incredibly easy to shoot yourself in the foot by not adhering to the (sometimes unwritten) rules.
My wife and I started learning game development a year ago after 15-ish years in the software industry. UE is one of our main drivers. It is probably the hardest to learn when compared to Unity or Godot, but you also have some insane capabilities. Taking Godot detours definitely helped our understanding of how games work, and we should have embraced blueprints a lot more instead of trying to solve everything in C++.
TL;DR: yes, it's possible, but it has a learning curve.
Doing software on the side was quite common for 15 year olds during the 8 and 16 bit revolution, many well known game developers in UK started exactly at that age.
It depends on your background. Learning C++ is a prerequisite to being efficient in Unreal. If you already know C++ it can be done without too much hassle. If you also understand the basic principles of game development picking up UE is a breeze.
It doesn't have a linux version, so unless you're a gamer it's not worth the effort to get it running unless something has changed... Last time I found it easier to just download the UE5 source to mess around with it. Afterwards, it seems like I needed the Epic client for other reasons. I'm guessing there could be legitimate barriers although it's been a long time for me. Currently I'm downloading the new UE5 source again and take another stab at getting the Epic client running.
It is anything but lightweight. It's a full Chrome browser that struggles to show even the most basic "text with images" pages and hides useful functionality in corners while pestering you with multiple CTAs
It's actually an Unreal Engine 4 application, that only displays an Unreal Motion Graphics UI, that only contains a single Web Browser widget, that may or may not be chromium. Also its PresentInterval is locked to 2, so it'll never go over 30 FPS. Fun times!
If often amazes me how unresponsive the EGS application is.
Though my experiences modding various games with their unreal 4 dev kits were much worse. Especially coming from modding games with engines where you could edit scripts with the text editor of your choice.
I suppose it comes from their rocky launch when it was ... less than optimal. However, I can confirm that the Epic Games Launcher isn't causing any problems and it seems to be a good way to get UE.
As a side note, I would also recommend JetBrains Rider if you plan to do a lot of C++, it's miles ahead of Visual Studio when it comes to UE code completion.
I already have VS and the Windows SDK that includes MSVC and Clang. I just generally don't like to use it as an IDE (with few exceptions). I use it to build VS projects and that's about it.
No, I mean Rider. CLion seems to be built to work with CMake primarily which UE does not use. Rider specifically has an Unreal Engine plugin and does support C++ fairly well. It is the only IDE we could get UE code completion to work properly. Why this is the case I don't know, but if I had to guess I'd say something something msbuild.
"CLion seems to be built to work with CMake primarily" - you mean only? I mean, they recently implemented basic syntax highlighting for non-CMake projects, but you still can't use any of the actual analysis, refactoring, or debugging features without a CMakeLists.txt file.
I don't think UE has DRM in the editor. The launcher is AFAIK only needed to download the thing, which probably has a lot more to do with optimizing downloads than DRM. If you don't like it, just build it from source, it's not exactly complicated.
It is not publicly available. If you click on this link you get a 404 page: https://github.com/EpicGames/UnrealEngine You actually have to go and subscribe, agree to their terms, and then you get to view the source code. It happens to be free, but it is by no means "public". (I also don't have a problem with their license. Their business model is more than fair.)
I sell a source code license to my software. It does not allow redistribution. Any member of the public can pay me for a copy under that license.
That fits your definition but no one meaningfully calls my software Open Source.
Using that term your way in general conversation is only going to confuse things.
We already have terms like "source available" which fit your needs and which are far less ambiguous or contentious. The arguments over what "open source" means, in a software license context, was generally resolved many years ago.
Yes of course, there are at least 2 ways. You can install from source or you can download the engine directly and install it without the launcher, this is what I did in my linux computer.
Compare that to all the sci-fi looking things like Nanite and Lumen which completely change how we approach building game environments.