So Godot supports instancing. At least for static objects, and with the same material. I got up to 100,000 spinning cubes with the same texture, and I still had like 900 FPS. I tried with 1 million and it crashed my computer. But in the hundreds of thousands of objects is possible, even on mid-range hardware at 60 FPS, with the right optimizations. For example, if they are not animating, if they all have the same texture, though you can I think modify some properties (maybe a texture atlas with UV offset would work). And general rotation and position stuff. Having them be unique and animating is a huge issue, not just for Godot.

As I said, even AAA games have a lot of problems with this. Cyberpunk 2077 now has about 100 character on screen, but it didn't when it released. The city was much more sparse in the 25 - 50 character range, and it caused slow down. So this is difficult even for AAA devs with their own engine. I think anything is possible, with any engine or no engine. It just depends on how hard or time consuming it is, how much you have to use add-ons or modify the code, etc. I haven't looked into this aspect deep enough in Godot to say one way or the other.

I think one can animate instances. The necessary transformations would have to be done in the vertex stage, but I haven't done it by myself.

Putting so much load on a single shader stage will certainly cause a huge performance hit. One would have to explore the limits. But with today's hardware ...

This was clearly going a little too off topic, so split into it's own topic it was.

K :-)

How do I compare engines ? Well, do they run on Linux, are the sources accessible, are they worth spending my time :-)

And still I ask myself, do I really need an engine ?

    Pixophir And still I ask myself, do I really need an engine ?

    You can't develop a game without an engine. I think you mean 'do you need a IDE/editor"? Not every engine is a general purpose one. The idTech engine was pretty much just for doom and quake. There are other total conversion mod games that make use of the engine but they all remain very, uhh, quake-like for a reason. But there's still a clear engine in there or there wouldn't even be a game.

      Sure one can develop a game without an engine like Godot or the other big ones. It may even be easier to do so, for a given case, and more flexible and performant anyway.

      I am not talking about platformers or shooters or doing what everybody else can do, if it comes to simulation most engines I know are out of the question, or need such heavy internal programming that again an own framework may be quicker and easier.

      Actually, the few games I like do not rely on an engine (Factorio, Orbiter, the X series, ...), or use in-house engines or frameworks. KSP was the only one among those that used Unity, and I have the feeling that curbs its development by a lot.

      If only I was a real(tm) developer :-)

        Well technically there is still some sort of "engine".

        Even if it is not general purpose, there is an architecture that has to link various components (graphics, physics, sound, game logic, etc.) and this could be called an engine.

        Granted, it can be simple, it may just be a huge C++ main() function with a ton of code in it, but it's some sort of architecture.

        Oh semantics. But a linker is not a game engine.

        It remains a fact that one does not need an engine like Godot to write a game, as actual games show. Though some may use in-house engines, others just use light weight libraries to achieve their goal, in which case I would not use the term 'engine'. There are shades of gray, in between, if you write a resource manager, or a scene graph, would you name that 'engine' ?

        A game engine can make one's life easier, specifically for games like platformers, shooters, riddles, things that can be built from standard building blocks. If the planned game lends itself to the engine one can save a lot of time and concentrate on game logic and content creation. Most games do or can be made so. Most.

          Pixophir others just use light weight libraries to achieve their goal

          Semantics, sure. But the point is that bringing all these libraries together and writing logic on top of them results in a runtime that would be semantically classified as an 'engine'. As for rolling your own vs using an off the shelf one comes down to the needs and circumstances of a studio...

          A small indie entity consisting of 2 programmers 1 with audio engineering expertise and another with computer graphics experience might find it easy enough to build their own and maintain it too so long as it doesn't grown too big and accrue unmanageable amount of technical debt. But as I brought an example of the Red engine earlier even big studios can end up in a situation where at some point the calculus says that it's better to pick a pre-made engine to use to avoid that technical dept or at least an overwhelming amount of it.

          This is where I'd argue that Godot is actually a really good option, even in earlier versions godot had a fairly modular architecture but with godot 4 and the GDExtension API I think it becomes even better for this. You can still bring in your own custom solutions or other middleware and even the renderer architecture is pluginized where you can write your own renderer rather than use the default built-in one if your needs demand it but you don't have to build from scratch everything else, be it the IO/HID handling API's or the physics systems or what have you.

          What is 'easier' is entirely subjective.

            Pixophir Sure one can develop a game without an engine like Godot or the other big ones. It may even be easier to do so, for a given case, and more flexible and performant anyway.

            I'm watching the development of a game on the author's own engine. The developer is of course a monster because he works alone. But the spectacle is sad. In a new version of the game are constantly appearing new bugs, fixing old bugs, leads to another bug. So a normal engine, at least, is very desirable.

              i dont really care what engine im using, if it gets the job done for what im aiming at im allright with it.
              as they say , its not what u use, its how u use it. i simply chose godot because it was open source and was sick of unitys' politics and being bloated with features i didnt want nor needed.
              there is no skill in creating a high quality terrain level with megascans and speedtree in unreal imo. ive seen dozens of those, they all look the same to me.
              and the unity asset store makes it very tempting to just 'asset flip' and call it a day.

              I didn't expect it to deserve a separate branch… honestly…

              I'd like to mention an engine that is rarely and rarely talked about, but which is vastly superior to Ureal in terms of features.

              cybereality as well as robust terrain systems. You can create an entire forest landscape of AAA quality in a few hours.

              .. And I'm sure the engines have optimized for rendering large items, something you would have to do as well.

              UNIGINE has all this. It's strange that you don't hear much about it, although big games are coming out on it:

              It has a free, limited version.

              Sim SDK

              The flagship edition, designed for simulation and training (of both humans and AI). Includes full support for planet-scale scenarios, immersive display setups, high-level IG system, and other enterprise features.

              When I was choosing an engine for my project it was at the top of the list. What's the advantage of Godot over this monster (from my point of view)?

              1. UNIGINE requires a good programming experience. Without a good knowledge of C++ there's absolutely no point in going into it. Godot is perfect for learning. Whatever the outcome, Godot is already in a niche market where it has no competitors.
              2. UNIGINE is focused on working with 3ds Max and Maya. Godot has good integration with Blender.
              3. Godot is evolving in a good direction and you can expect large spaces to be within its reach.
              4. Separately, I want to note the system of assets in general and Destruction in particular.

              For now I'm going to sit tight on Godot, but if in the distant wonderful future it becomes cramped — I will consider options.

                It's all down to marketing and sometimes a bit of white lying mixed in with that, Unreal is getting such a boost because of how much big investor money is going into it which means they have better access to advertising as well as cough various government interests supporting them cough. So naturally that's what a lot of people are going to gravitate towards by default because they think big money = best software. This isn't necessarily true though as those of us in the know about software understand and depending on the situation open source software works fine in most use cases.

                Depending on the situation I'm kind of glad that all the industry focus is Unreal, I wouldn't want special interests getting their greasy hands on Godot and potentially ruining a good piece of software that could be left alone. I very much like software to be stable and not interfered with, I like Blender for that reason as well because it means even if there's a pretty significant update I can choose whether or not to update to it and carry on working on my projects uninterrupted.

                For the record, I'm also somebody who finally made the switch to Godot because of Unity's politics and nonsense, I was planning on it generally but I realised I was potentially putting myself at risk security wise even keeping that software installed on my PC. For what it's worth, I'm a dev that's looking to push Godot to the absolute limit.