UE5

What?
Unity couldn't handle a stable prefab system for 15 years. Blueprint introduces a proper entity/template system 7 years ago. Where you can put easily data and scripting together. Instead of clunky GameObjects - which are the same thing as AActor in UE4, but less performant (you need to iterate for components and cache reference yourself) and limited in functionally (lack of tightly integrated visual scripting, the major advantage of UE4)
Plus, I don't see any bloat in UE4 gameplay framework - if working on the character-based game. And no need to use all the systems. Can safely ignore them.

Well, DOTS might be extremely useful for some games or be a huge upgrade for a specific game, i.e. RTS with thousands of units. Sure
But what's revolutionary about it for the general engine community? Both C++ and C# support data-oriented programming. You can manage your game system this way in Unreal any day. No need to rewrite the entire gameplay-side archicterure.
OOP-heavy framework implemented in C++ doesn't cause a noticeable performance penalty in almost any 3D game. Simply because 3D games love to be GPU-bound. And underlying engine systems already work on separate threads.

Heck, even Sequencer in UE 4.26 moved away from OOP-based execution. And they did without changing anything for users! I only had to update 2 lines in custom Sequencer tracks. Nothing changed for people working in the editor.

Unity needs DOTS for performance reasons, mostly because C# environment wasn't designed for memory-intensive applications like rich 3D games. And C# performance with big OOP games might be terrible. This is something irrelevant for most of the games implemented in C++.
So, yeah, I see how DOTS might be useful for many Unity games, but can't see revolution here. It's just how Unity's marketing is selling it. They can't say "oh, you know, we choose C# for simple scripting of simple games, but the performance of the C# environment sucks if you're working on anything more complex".

Unity's marketing also sells HDRP with flawed CPU-side implementation. Rendering of relatively simple scenes can easily become CPU-bound because the engine doesn't handle well scene analysis and sending draw calls to GPU.

Meanwhile, UE5 moves to GPU-driven rendering. That means that the CPU is no longer processing the visible scene and dispatching draw calls to GPU. This is one of the major reasons while game performance is limited if there are thousands of individual mesh components in scenes. Modern APIs like DirectX 12 improved, we can have like 40% more draw calls generated and submitted to GPU. Your scene can jump from 15k draw calls to 20k.
Well... with GPU-driven rendering this CPU-to-GPU bottleneck disappears and you can have 500k draw calls

UE5 design in short
- Artists, level designers can forget about LOD, polycount and draw calls. Also, everyone working on the scene can forget about managing streaming sublevels. Finally, we got workflow as pleasant as open-world AAA engines, like The Witcher 3 or any Ubisoft game. This brings a huge productivity boost even to the small team, or the single dev working on 3D game.
- There's no core architecture overhaul. Nothing. You can update your game middle-production like upgrading between UE 4 versions, quite painless. Continue working. My custom system/editor needed just one line change to compile for UE5.
- Non-programmers (so the majority of the team) can still work with intuitive OOP-based blueprints. They don't anything more. But if you need to apply data-oriented patterns to your gameplay, you can do this anytime, like in UE4. Expose data table/assets to designers instead of UObject-based assets.

 

Sure, not saying it is not possible, same like super graphics on Unity.
Satisfactory is really good example of utilising core engine, of getting best results. But I sceptical, it is base feature and support of Unreal. Can you make it such performant, using blueprints?
Personally I would expect, satisfactory been programmed closer to c++, to get such results.
Unless some confirms otherwise?

Regarding forthnite, is not like there is +10k objects placed by players in single match.
May e few thousands at best? Please orrect me, if I am wrong.

And yet, these don't even move. They are placed and wait until get destroyed. There is some interaction to it for aurę. Yet same could be achieved with Unity classic OOP approach, without major performance sweat.

Other Unreal tech demo shows destructable buildings. It is all cool and that. But it appears, it does that mainly on GPU. Does that updates, or can update colliers?

 

I'm telling you that "deprecated" means nothing. It is not a royal decree with 100% guarantee attached. It is their opinion. "We think we'll retract this tech, and we think that the new tech is the way to go. Maybe". They can also undeprecate stuff later.

Code doesn't rot. If it works now and you didn't change it, it will always work the same way. It's not like a "deprecated" feature will change runtime behavior of your title past deployment.

Additionally, people working at unity are not supreme geniuses, they're largely average in their ability, plus a bit of specialized tech knowledge. They can make wrong judgement. (Unity Connect, anyone?)

In my experience, unity editor in general is more resistant to sudden death from crashes.

Why would you want to? It is like saying "Oh, it runs well. But can you rewrite it in Brainf*** and retain the same performance?"

Well, satisfactory belts move and machinery is animated. Fortnite ability to build anywhere and destroy anything is actually not a simple problem, because it involves dealing with PVS graph. Unity still relies on umbra, last I cheecked? Meaning the map is not just static, but has to be BAKED.

Additionally building system used in Satisfactory, Conan Exiles and Fortnite is something I saw in actual Unreal game more than once. I don't recall many Unity games that can do the same. Thinking about it, there is Subnautica, where you can build bases, but once you start stacking modules performance quickly nosedives. There's also supposedly Rust, but I never really played it.

 

Well I said that, as blueprint is a default tool in Unreal right? But anyone with c++ skills, can skip it I suppose.

Rust is nice example, with beatuful envirement, but on the same level of crafting and building world is minecraft, using java. Now try to make thing dynamic. I. E. Minecraft mods.

The good comparison in terms of dynamics and count of dynamic objects/instances is, how many rts games were released on Unreal and on Unity.

I don't know about Unreal in that regards (anyone pointing to some would be great), but Unity has plenty RTS and builder games. Mention Subnautica, tons of mobile small rts games, Cityskiline, not rts but plenty of things happens on screen at given time.

And we got number of games using Unity like FromTheDepths, Scraper, RoboCraft, or even not best example but KSP, etc.

So we see two different Engine tools, and different focuses / purposes.

 

To be fair I haven't used an application of any kind frequently, without it crashing. UE4 crashed on me. Every single version of Unity's crashed on me. Zbrush has crashed a lot on me. So have all my 3D apps come to think of it.

Crashing is something that happens when we're using apps that use funky optimised code here and there to get around the fact these applications are doing more than the computer is actually designed to do by brute force.

DOTS interestingly, kind of allows better brute forcing, or a pure way to just get the computer to do it's job without having to do weird optimisations that could cause race conditions, memory issues etc.

I don't disagree: Unity's pants down and just not very match fit right now, but given time I think there could be some real improvements to come. Problem is, I've been waiting a very, very long time.

 

Unreal has both C++ and blueprints, so....

I recall someone making a minecraft clone with blueprints only if that's what you were after.

Gothic Armada, Tom Clancy's End War and actually XCom 2.

I'm not sure if there's even a focus, to be honest.

 

Guys if you haven't spent a month learning unreal you should go do that.

You can make any type of game with either system, but right now Unreal is more stable and reliable. What I've found right away is that many of the common perceptions people have aren't true. My big regret right now is I didn't do this sooner. It could have saved me a lot of trouble. I am porting a walking sim game that i already prototyped in unity to unreal. Thats no trouble at all. I am also working on a turn based strategy game as well. I am slowly working on the AI using blueprints. This is something I couldnt dream of doing in unity.

If you are already familiar and comfortable with unity that is great because it's not going anywhere, but right now the new versions arent reliable, so its a good time sit back and wait for unity to get things straight. In the meantime might as well give yourself options and disregard what you think you already know - get hands on experience.

 

Unity is far more easier when it come to custom compute shader and procedural mesh. In unreal, both PMC and RMC suck and not support skeletal mesh. Everything is possible in Unity.

Look at this guys. https://twitter.com/zellah

He make a strand hair tool for unity support both urp and hdrp. Using compute shader and this is not shell shader. Because of Unity flexibility, the asset creator can make anything happens using unity.

Or another example. https://twitter.com/Sakura_Rabbiter
Well, she try UE5 but end up continue to make game with unity. Look at her posts, you will see the eye candy graphic come from unity hdrp.

So, unity can do everything and very flexible unlike ue that verystrict to its own rules + eula and you have to follow their way. Now, imagine unity start working on mesh shader solution for hdrp then we can have billion of triangles in the scene. HDRP is for experimental for sure.

 

That part is true. Unity has cleaner API and shader system is easier to alter.

It is worth mentioning, however, that with unreal being a C++ project, you can link with stuff you need when you need something unusual. Meaning you can interface with things like Cuda/OpenCL and OpenCV directly without a need of a middleman.

Also at times you don't really need to make experimental tech and what you have in mind more or less fits into existing rendering methods.

 

You have non-programmers programming things in your game?

 

In my experience of Unity, having non-nested prefab was never a bottleneck. There's always a clean workaround. Blueprint is good in the hands of artists, and prototyping designers. But in the long run it adds a lot of hidden technical debt as programmers would need to convert them to C++ for performance reasons.
If you don't agree with me on UE's bloated gameplay framework, that's fine. We all understand/perceive things differently, at different levels.

DOTS is not only useful for RTS games. Even without its cache friendly advantage or performance boost, it forces programmers to write much more understandable/maintainable code in the long run. It's basically a paradigm shift for programmers.

.

The only thing I have against DOTS is its steep learning curve for existing OOP programmers. Programmers will actually be very good and open minded to make the change. 80% of the programmers I worked with in big companies are die hard OOP fans and very resistant to change.

If the programmer knows the stuff, you can still optimize things to an acceptable state without DOTS. sometimes it's harder, but doable.

Again, C#'s performance is really not the one to blame for 95% of the unity games out there. Most performance issues are graphics and coding habits related. If code is done properly, you will never have any issue with C#'s performance.

HDRP, from my experience, is not very usable. I agree with you on this. Unity users will need to be very good to make something comparable.

Drawcalls are always issued from CPU. GPU doesn't dispatch drawcalls.
If there are thousands of draw calls, you either need to do occlusion culling, hierarchical LOD or some other tricks to optimize it. It's just that UE does it behind the scene. Unity programmers will need in-depth knowledge and write custom solutions for it.

To summarise this, UE is more like a buffed up version of RPG maker, you basically make the assets and use existing features. Unity is more of a framework that you really need to know a lot of stuff so you can write your custom solutions.

data table/assets are not data-oriented patterns. Data oriented design is all about slicing long sequential code into smaller tasks that are easier to multithread. Unity hired Mike Acton for this. You can find him on youtube.

 

https://www.unrealengine.com/en-US/...eons-in-unreal-engine?sessionInvalidated=true and of course an actual minecraft license, which was nearly all blueprints.

 

My argument was meant to be slightly less silly than "Unreal can crash because of plugins", which... uhh...

I have had Unity versions (LTS even), where I couldn't work on certain scenes because of insta-crashes when opening them and the solution was to wait for Unity updates. But crashing because of plugins, oh my!

With that said, excluding some really bad specific versions, I would say Unity is roughly on par with other software crashes-wise.

I mean... ~5+ years is a lot of time. They had that much to get their act together and they haven't. In that time, long standing issues haven't been fixed, new features introduced have been from sub-par to terrible (Collaborate, Timeline, everything UI related, SRPs), lightmapping still misses features that beast had and still has issues.

What's worse, even if the new DOTS workflow and everything based on it is amazing (and frankly, it won't be, right?), they still feel, what, 2 years away? At least?

In the mean time, I've been accused of breaking the EULA and been patronized by Unity evangelists.

I want my father to play my next game, but at this rate he'll die and I'll still be fighting Unity's lightmapping.

Many years ago we evaluated Unity and Unreal and chose Unity. I can truly say without a doubt in hindsight : It was the wrong F***ing choice.

 

But given it's actually still alpha, and not even beta really (since it's not feature complete) I'll have to wait a while. I learned that the hard way.

 

You really don't need to wait if it seems interesting to you. Its current state is enough to give you the taste of the brilliance. At least for me, I wish someone show me this in my university days. There is a thing or two in OOP that could transfer to data oriented design. But DOD is just... better.

 

isn't DOD and OOP just general design patterns? Meaning you can use a little of this and that based on the situation?

Like in 3d modeling you can do a highpoly>low poly workflow, or reverse that, but once you actually know what oyu are doing you tend to do a big mashup and it depends on a million specifics.

 

Yeah... DOD has been a thing since the 80s, people just bought into the Unity hype and think it's some sort of revolution or something.

It's the Unity paradox. C# really lends itself more to OOP than DOD. C# is somehow a Unity strength though, even though to have DOD with DOTS you have to write code that barely looks like C#.

 

I, as a programmer, find it revolutionary.
If someone discovered fire and disappeared. Another guy came along and show the use of fire to everyone. Whom do people considered revolutionary?
How is burst-compilable C# code not C# like? You don't have to write C++ header files and fight with broken intellisense that you get with UE's coding environment. That's already a plus for me.

 

Mostly you can. Although sometimes it's tricky and you need to be very aware what you're doing, because often times you need to move a ton of data if you switch between GameObjects and ECS. Obviously depends on the situation.

 

Switching from gameobjects to ECS is a very difficult and commercially not viable task. What I like about Unity is using ECS is an option, you can opt out of it. Whereas in unreal, the bloated gameplay framework is pushed into your throat, whether you like it or not.

 

Yes. But it may be confusing when DOTS terms comes into play. DOTS stands for Data Oriented Technology Stack. Which includes multiple techs (main one Jobs, Burst, Entities), including DOD paradigm.
You still can mix OOP and DOD, if need to. Or if transiting from OOP to DOTS in stages.

 

We're talking about doing some task in one and then others in the other. It's working just fine. Also called hybrid approach. Like moving entities in ECS but having a Cinemachine camera following a game object which is synced to the entity... or something.

Well, Unreal's code base won't win any beauty contest, I also wouldn't say it's the best way of doing things or it is thought out the best way, for sure, but it does the job and does the job well.
(I hate macros... why it has to be macros all the time?)

 

When you say a ton of data, can you give an example situation? Like is that something that only exist in say, an RPG with tons of data for character stats, or maybe an RTS with similar data needed for many unit types.

Would something like an action platformer, basic single player shooter, or puzzle game likely have this sort of problem?

 

That doesn't work that well, when C# as a language lacks features that make memory management easier. Its main flaw is being a GC language. If it had both non-gc and GC blocks, things would be better by a large margin.

A bug in a plugin in Unity will result in a bunch of errors spewed into a console, while in Unreal engine, the entire editor is killed off, and it does not exactly start instantly. When you're debugging that plugin, that stuff quickly gets on your nerves.

Also, the point of the example was internal change breaking your code and requiring an unknown workaround.

There's "taste of brilliance" and then there's "getting things done" and "being production ready".

"not DOD" does not mean "OOP". There's old school procedural style programming where you still toss structures around, but do not have any OOP concepts. That's a good stuff. However, that is not necessarily data oriented design.

I, as another programmer, find it forced and unnecessary workaround.against language limitations.
If we talk about actual paradigm shift level material, that would be something akin to prolog. That was "woah" moment when I found it. However, how many games are written in prolog?

It is exact same thing with unity, though. You use the engine, you use its framework.
When you start disliking the framework too much... you grab libsdl, and write a lightweight engine yourself.

 

It's a revolution for programmers, and that's pretty much it. Actually, even that's debatable, given how popular OOP is.

Introducing a 'paradigm shift' in programming with a 'steep learning curve' into the world's (previously) most easy to use game engine doesn't add a lot to its core value. Most people using Unity don't care about ultra-clean or ultra-maintainable code, they care about making good games in a reasonable timeframe. As a matter of fact, according to my basic understanding of ECS, writing code to do the same thing in OOP takes a small fraction of the time, since you don't have to care about who is managing what and operating on what where. Nor do you have to spend any time extricating some object that isn't supposed to march in lockstep with everything else.

ECS continues to come across to me as a performance optimization for a relatively small niche of games that need it. Which is great, and I'm glad it exists, but in my opinion it's not revolutionary, and quite likely not desirable, for most games made by most Unity users.

Unity is supposed to be, at its core, the easiest to use game engine, making the right tradeoffs to improve workflow and optimize the complexity of game making so that more and more people can use it. I think OOP is the least of all the tradeoffs that a game engine like this will have to accept. Everything Unity does should operate around the concept of first, providing a solid, polished, well-documented, feature-rich and supremely easy-to-use core, and secondly, the ability to add specific features needed for specific types of games, from the asset store or wherever else.

 

Absolutely. Last time I made a game in Unreal Engine was when I was testing a c# plugin which was working pretty well at the time. Unfortunately the c# plugin is now deprecated and archived, while another more popular UE4 C# plugin which recently released doesn't even come close to having the same functionality.

Not to mention Unity's API is a lot cleaner and flexible, while UE4 has a rigid coding structure around actors/pawns and game instances.

 

I never had to fight GC. For things that get created/destroyed on a low frequency basis. It's a none issue.
For other stuff, they are pooled.
And with ECS, GC is no longer an issue.

If you use the DOTS package enough, you will know which part of it is stable/production ready and which part is not.

I'm not a language expert and not going to debate you on this. Have it as you will.

[QUOTE
I, as another programmer, find it forced and unnecessary workaround.against language limitations.
If we talk about actual paradigm shift level material, that would be something akin to prolog. That was "woah" moment when I found it. However, how many games are written in prolog?[/QUOTE]

I get it, you don't like DOD. Hopefully one day you could find the 'woah' moment with DOD.

 

No, the problem is there is a lot missing you have to do all by yourself vs classic Unity. This adds a solid year to any project, or a requirement for staff to add the missing stuff. And there is a lot of missing stuff.

A common assumption by enthusiastic developers to state you can just jump in. You really can't if you're missing half of an audio pipeline, there are a ton of animation features missing and so on. Pretty rude awakening for a real project that needs to get done and shipped.

Adding the fact VR is my interest and it's no dice. It's really great for an RTS right now, but I'd achieve the same results in less time just using a few compute shaders or just slicing and threading the heck out of it with classic Unity.

DOTS is really something that needs a few more years. I won't be told differently, unless of course I want to play around, or I'm just one in a team of programmers.

 

Wow, I guess I'm somewhere in the middle... Nothing is revolutionary about ECS or DOD. Back in the 80-ies on smaller machines we didn't even have any choice but to work on things sequentially as possible. Having the same or similar properties in an array and constructing "entities" out of those. It was pure necessity.
But I'm also glad that Unity stepped up and started to implement it, because it is unquestionably superior in every level. And no, doesn't matter if C# is a GC-language or not. Results are all that matters, nothing else. Obviously, personal opinion and all.

Well, if you don't have some subsystem in the ECS part and you want to do the task in Game Objects, you need to make the data available. Sometimes it is easy just using proper data structures, sometimes you need to copy them. Copying is not ideal. I'm before my morning coffee, I couldn't name a clear example even if my life would depend on it at the moment. But yeah, in general, it is doable to maintain a hybrid approach.

 

Yeah it's superior. When it's finished and integrated properly in the engine. Right now it's a fast calculator on it's own.

 

"A plus" is not a revolution. Also I do not use intellisense, so... whatever.

DOD patterns are common in the industry, they are only new to Unity.

Also since it is not ready (and I mean, it's not even close, considering that stuff that Unity says are production ready are not ready, and DOTS is years away from even that), I do not care. I want to make games, not play with experimental engine features that for all I know might not even ever get finished.

 

There are workarounds like hooking up gameobjects with entities if you need features that currently are not mature in DOTS. Compute shaders deal with tasks that preferably don't involve read backs from GPU. The heaviest computation in RTS is neighbour lookup, which should really be done on CPU.

 

I think it's great they're doing it and I have done some DOTS dev, but recently evaluated it again and it's just not going to let me start or finish this VR title.

 

And why should I waste time on that when I can get things done NOW in another tool without reaching enlightment regarding which parts are ready? Or when more performant language is available and I'm proficient in it?

C# hemorrhages allocations.

Delegate call? Allocation.
Strings? Allocation. (also, they're immutable, which was an "amazing idea"(tm))
The language itself encourages use of reference types and immutability which is more allocations.

However, you have no control over deallocation, so all the tasty language features generate garbage which at some point of time will cause a spike you'll have no control over. it is non-deterministic.

It is possible to write code with zero allocations, but the result will not be C#.

In comparison, a C++ subroutine is more or less self-contained, and even if you create objects on heap, you know EXACTLY when they die. That is deterministic.

And that is essentually, a fundamental flaw of C#, and that's why unity is trying to use dots.

 

Chances are you will never need to move a lot of data between entities and gameobjects.
You are never meant to have over 50, give or take, dynamic gameobjects at any given time.

 

Don't forget Job System. It existed for a reason.

 

The fun thing about Dots situation is that if you're using Dots, you should be probably using C++, and will end up with shorter/cleaner code if you implement the whole thing in C++ to begin with.

In C++, arrays are native by default, lambdas do not cause allocations, there's no need for BurstCompiler (having to write a custom tool that feeds IL to LLVM through a converter doesn't really give any reason to be confident in the language performance), all types are value types by default, meaning no null checks, and control over memory is precise and deterministic.

So something like "data oriented design" may end up you declaring a naked array and blasting it with an equivalent of a parallel for. That is not something I'd call revolutionary, and like others said, that's how things used to work, say, 30-40 years ago.

 

For high frequency codepaths, ie Update(), I never encountered a situation where I'm forced to use delegate.
String changes are never in my high frequency codepath.

 

UE5 is a decent example of focusing main effort on one core product/ecosystem. Unity spreading resources for supporting 3 rendering pipelines and thus making Asset store publishers suffer a lot... Hope Standard rendering pipeline will be ditched ASAP and with decent state of Universal RP most of the resources finally will be driven to work on HDRP ecosystem.

But it's sad to see UE5 awesomeness where scene with insane detalisation consumes only about 6-8GB of VRAM while in Unity I'm waiting for 5 months for fix to texture streaming not working on dynamically spawned objects/materials thus making impossible to create rich content for my sandbox game and all that limited to 2-3K of objects with ray tracing due drawcalls CPU overhead...

 

Using C++ doesn't automatically make you write DOD code. It's the changed mindset, devising new algorithms so your code can actually run on all cores.

 

You're never forced to do anything, however, it is a convenience feature that makes life significantly easier and makes development faster.

If you can't use lambdas, can't use string operations without causing non-deterministic allocations you cannot control, and have to be aware which path is high or low frequency, what reason is there to keep using the language? Are you even gaining anything from sticking with it? Is it even the right tool for the job?

Of course you can avoid all that. However, that will result in slower development, larger and harder to read code.

I believe I never said that Using C++ automatically makes one write a DOD code. However, what I did say is that switching to the DOD paradigm would be far more trivial and would not require any custom tools. And on top of that you'll have deterministic lifetimes for structures you create.

 

I think these things are really easy once they become your habit.

One of the key concepts with DOD is to move existing component data in memory when a new component type is added to an entity. And that is enabled by Unity's entities package. So I think I will stop here. Learn it as you will, or not.

 

No, "broken Intellisense" is the feature of Visual Studio Intellisense which never handled properly large C++ codebase. Nobody working with C++ game engine uses it. Epic recommends to disable it in Getting Started programming guide.

Everyone seriously working with C++ in VS used to grab Visual Assist plugin, also comes with UE4-specific support.
But these days we have Resharper C++ which beats Visual Assist in every way. And now we also have Rider for UE (with Resharper integrated).

The beauty of using Rider is that supports both Unity and Unreal (even Godot to some degree) while providing amazing productivity features. And Unity-specific, Unreal-specific goodness we will never have in Visual Studio or VSC.

You can get used to headers. It has benefits too. Really, there's no need to become knight defending specific programming paradigm. With Unreal we use both OOP and DOD, no one even spends time to arguye or whatever. Just using what's needed at the given time.

You make it sounds like programmers relying on OOP are wrong and need to be enlightened. The truth is OOP is very natural way of constructing game worlds, intuitive for artists and designers. And yes, they do program game in blueprints in every Unreal project. It's a myth that all blueprints degrade performance and programmers need to rewrite all. Only the systems require attention of programmers. All the small scripting is fine in blueprints.

Plus designers aren't stupid monkeys, you can train them basics of proper scripting. And your game performance will be just fine. The same way as we train and cooperate with artists.

OOP and DOD are just tools, both perfectly valid paradigms. There's no need for any revolution here

PS There's some guy who apparently made VSC Intellisense fullt working with Unreal. I know some people love free VSC, although it's even actual IDE.

 

Unity said one of the main benefits of DOTS over C++ (not C#) was that they're able to create programs that compile to run consistently fast on different hardware, something that's actually apparently quite random in C++ land as it can make no assumptions while DOTS can. You could make DOTS in C++ and it would also be better than C++ is, at this task, due to assumptions and of course memory access patterns (over classic oop C++)

 

Thats anyones guess, but they're clearly working on it. As already stated, bridging the gap between blueprints and C++ would push a lot of people towards the engine - something they'd be insane not to capitalize on.

I belive they use a heavily modified version of UE3 (calling it 3.5), not 4 though.

 

In my opinion those things should not become a habit, as the idea of computer languages is to evolve and give more power to programmer, therefore there's no reason to stick with inferior tools.

That does not sound very impressive from a position of C++, where you can access raw memory and cast anything into anything else or have multiple different data types at a same address...

That sounds similar to their original IL2CPP argument.where they compile C# bytecode to C++ code.

Spoiler

C++ has llvm compiler which produces IR assembly, which can be compiled into other things, including javascript, which is how some people write WEB OpenGL programs in C++.

As in there's some truth in it, but there are also ways to address the issue.

Personally I'd prefer if C# received missing C++ features, or if unity released C++ bindings.

 

Krabl worked amazing for years and years but no longer does. I preferred it's method over the others. You attached a component to the mesh when you imported it and could adjust your target vertice count until you got a good mix of reduced verts vs appearance degradation. It worked miracles for us, but now I have to basically import meshes into an old version of unity, decimate, then export to use in the main project. Ended up using MeshKit last time and it was pretty decent but krabl was my favorite.

 

So, what happened to it? Given how unity API works, it should be possible to update it.
---------
I wonder if it would be possible to start a tradition of:
1. Requesting authors of dead assets to release the abandoned packages as open source.
2. Issuing bounties to update deprecated code.

 

Weird it looks like it does work again in 2021, it has errors upon import from legacy stuff like Nacl, Webplayer, Blackberry and Flash that's been long gone from Unity, commenting those lines gets rid of errors.

I tried it in 2018-19 a year+ ago with commenting those lines but it didn't work when you tried to use it, when I just now imported on 2021 it asks if you want to upgrade old api and seems like it works now.

 

Well, like I said earlier, one good thing about unity is that API is actually fairly resilient.

My previous statement about releasing old stuff as opensource and issuing bounties still stands though.