RobMadison said:
With Unreal Engine 5 out and looking leagues ahead of anything I've seen before, let alone anything I'd be even remotely capable of building, does anyone in the same situation feel like just giving up on their own effort?

Programmer71 said:
Sooner or later, there will be no more reason to write engine not even for fun

I don't agree with that, for a simple but fair reason, their target audience. Engines like Unity 3D and Unreal Engine are fighting for the same goal, profit and market share. This leads to both products targeting a wide range of developers and so potential customers and while people arrange with that most of the time, they also have to fight “intended design flaws” in both engines that lead to issues sooner or later.

Yes, both have a community and both offer a huge amount of paid or even free Assets to use but this won't satisfy all developers to change to Unreal or Unity. There are still engines out there, taking major companies like Deck13, EA, Ubisoft or Valve as an example (Source Engine 2 used in half-Life Alyx made an impressive result as well) also have another interest to keep their engines up to the market standards, fees. My emplyer for example is moving away from Unity in favor for it's own engine in order to “optimize the busines process” (whatever that means ¯\_(ツ)_/¯). In the end, there will always be the need for custom engines, at least at companies that have the budget to work on them.

Yes, Epic made a golden shot with Fortnite (btw. is there already an outcome from the Epic vs. Apple beef?) and they did the right thing to massively expand their Epic Game Store and Unreal Engine budgets and yes, their Demo looks impressive but in the end and because they decided to go open source, which I really appreciate, they just cook with water as well, no magic involved but some know-how we can now investigate, read about and maybe reproduce in some mannor to also get impressive results in the future.

So TL;DR: I take Unreal Engine and all other engines out there, which I can get the source code of, as a source of inspiration and motivation for my own work!

RobMadison said:
People say write games instead of engines

People say much on a long day, don't give to much on that. My father once told me “you won't get it to anything” and I proved him wrong. “experienced developers” told me “you can't make your own game engine” when I was young and fascinated from the rapid development and wuality of the young games industry and I proved them wrong as well.

If you want to make a game and you are in time and/or budget preasure, then you should at least consider to use a ready made and battle-tested third-party engine but as long as you don't have that preasure or just want to make an engine for fun, interest or reasearch reasons, make it and if it doesn't look that impressive, you still get value in knowledge!

RobMadison said:
I guess that should keep me going but when you watch Nanite in action and then go back to your own engine, any further work feels a bit futile

Like I pointed out above, take it as inspiration and motivation to go on and if you worry about your engine not getting that impressive results, you can still download the Unreal Engine 5 source and have a look into how nanite works and how you might implement something equal into your system.

Anyways, what keeps me going is that I see the wish for a change in games industry. Developers I worked with get more and more frustrated from those monolithic software giants they have to work with every day. I don't speak of anything specific but professional game engines seem to suffer from one weakness, they have 10, 20 or more GB you need to download and are full of features you don't need on every game you make (this is what I meant with being generic). And I mean they're right, I worked with both Unreal and Unity in the past and every Unity upgrade caused trouble in some of our code, in some of Unity's plugins but also when re-importing everything from the ground up for 72 or more hours.

So what we do with our project instead is to re-think the entire design of modern game engines from the ground up. I took a lot of inspiration from Unreal Engine 4 already (didn't mention that already right?) and also downloaded Unreal Engine 5 recently, without going into too much detail because I don't want to hijack this thread, we decided to make evrything powerful but simple. You don't need complicated build files or rely on certain locations you have to put your code into, you don't even have to download everything you don't want for getting started. Our required download size is 900kb instead of several GB. Ever tried to remove something from the Unreal Engine directory you really really are sure don't need to run your game?; always ended in the entire system complaining about not being able to build anymore ¯\_(ツ)_/¯. This can't happen with our project because everything is in packages and every package has only the mandatory dependencies it needs to compile. We're working open source entirely so instead of providing ready made binaries, we just packaged our source code into atomic pieces (every package just fulfills a single usecase) and build more complex systems out of those pieces.

(Did I say to not intend to hijack this thread? Visit our GitHub or get in touch via Discord if you want to know more about it)

Programmer71 said:
its impossible for a single man to compete with unreal

Juliean said:
Early version of unity haven been out for over a decade, and before that, there was RPG-Maker

Godot! Just saying ¯\_(ツ)_/¯

JoeJ said:
If your excited about Nanite i propose you do your own. It's an example of brilliant simplicity IMO, so not that complicated. Epic is generous to share code, there will be talks at GDC, people analysing it, etc. So we don't have to start from zero and spend 10 years on it like they did. I think i could do it in 6 months or surely less than a year.

They didn't spend 10 years. There are similar tech applications like Lionhead's MegaMeshes (they are not exactly the same, but similar in the purpose).

The theory behind goes back to 2007 , when Huges Hoppe publishe his work on geometry images, I have read that paper at that time, but the technology didn't allow to amplify the reconstruction in hardware. I think Unreal upload textures in the gpu and then with a compute shaders rebuilds the mesh, it is possible that uses also mesh shaders to cut part of the mesh outside the view frustum.

There is also source code accompaining the article, I had to google a bit, but I found an implementation written in legay opengl.

The process is not simple if you are used to vertices and surfaces, it takes some study to understand how the mesh is parametrized.

Vilem Otte said:
They didn't spend 10 years. There are similar tech applications like Lionhead's MegaMeshes (they are not exactly the same, but similar in the purpose).

I think Brian Karis mentioned on Twitter he worked 10 years on it. Not totally unlikely - they tried different things as well like geometry images. Though, maybe i remember this totally wrong.

First game i remember which did precalculated triangle reduction (beyond heightmap lod) was ‘Messiah’, IIRC from Shiny Entertainment (i love their MDK : )
They did it for characters. Very detailed results for the time.

Programmer71 said:
The theory behind goes back to 2007 , when Huges Hoppe publishe his work on geometry images, I have read that paper at that time, but the technology didn't allow to amplify the reconstruction in hardware. I think Unreal upload textures in the gpu and then with a compute shaders rebuilds the mesh, it is possible that uses also mesh shaders to cut part of the mesh outside the view frustum.

No, it's nothing like geometry images.

It's a reduction method, like in the paper ‘Surface Simplification Using Quadric Error Metrics’ for a random example.

The clou is they make clusters of 120 triangles, then form an island of adjacent cluster to merge them to a lower detailed single cluster. The island boundary stays fixed, so it's not reduced and no stitching is necessary. After that the boundary becomes an interior for further reductions when going up the hierarchy, to prevent some paths keep at too high detail. Really clever.

IDK how and if they support topological changes on geometry and UVs. Eventually they can not collapse small holes, and fuzzy UV maps might break pretty quickly. But for most stuff it will jut work.

I found this really interesting. It‘a a couple of hours long but Brian goes into quite a bit of detail on how it works:

It’s very interesting to think about the fact that for 2560x1440 resolution, drawing a polygon per pixel is only 2.2m polys - easy for today’s hardware. And it seems they’re doing software rasterisation, at least for the pixel sized polys (in compute shaders).

It’s really good to hear so many comments about you continuing with your engines. I think I would have always continued on with mine, it’s just living with that slight feeling of futility that bothered me but I’ve got past them for 10+ years so I guess it’s just ups and downs.

Incidentally, I think it’s fantastic that we are in the age where you can render assets in game that look ultra realistic but I think there’s an important divide that needs to be kept between reality and games. It‘a getting that balance between realism and gameplay and I think too much realism can certainly ruin gameplay. I come from a generation where it was a struggle to make graphics look good when you’ve only got two colours to play with in an 8x8 pixel block. Given that restriction, games were still super addictive. @programmer71 if your moniker is anything to go by, you might have had the same struggle…

Yes, you can write your own engine, but it's a lot of work.

I'm plugging away on writing a Second Life client in Rust, using Vulkan. The existing client is in C++, it's 15 years old, most of the work is done in one thread, and it makes way too many OpenGL draw calls. The client is open source and the protocols are semi-documented, so it doesn't take too much reverse engineering. Some early results:

This needs a lot of work, but the static content from Second Life is mostly being rendered properly. Mostly.

It would be much easier if I could just use parts of UE5 or Unity for this. But they don't help much. They assume you have a chance to preprocess much of the content in the editor before it goes into the game. That's not true here. Everything you see there was created by a user. About a hundred different users. Much of the content is not well optimized. The networking is completely different. There isn't really a game loop, just a screen refresh loop. Everything else is a stream of incoming events, plus returns from HTTP requests to the asset server.

Someone pointed out today in another posting that none of the major game engines was written as multiplayer-first. That's true. This is a real multiplayer-first system. It's been around for 18 years, and it's laggy. The question is whether the performance can be juiced up by using newer technology and throwing every core the user has, plus a gamer-level GPU, at the problem. We'll see. So far, it looks promising.

What makes this possible for one person is that I can use a lot of standard Rust crates. The original viewer has its own everything, down to its own math library and futures system. In 2021, I don't have to do that.