Pixophir

  • Jan 23, 2023
  • Joined Jun 13, 2022
  • 14 best answers
  • Afaik this has no easy solution in the engine.

    For larger terrain one would have to make an extension (in C++) that modifies the terrain surface, performs dynamic loading and unloading of terrain, collisions etc. This would be too slow to do in GDscript.

    2 LOD levels are not enough, something that keeps the number of triangles per screen area roughly equal, and moves with the camera, and loads and unloads parts of the terrain as the player moves. Also, it shouldn't copy terrain data for LOD levels (like for example mip maps) but work with and adapt the highest detail level on the flight. Memory is the limiting element here, even with just 16bit per point of terrain on the map we're talking about many gigabytes for large terrains.

    There are several well thought through terrain LOD systems, I am a fan of cdlod. I do have the core of such an LOD system. But I am unsure if I can integrate it in the engine's scene tree, which I may tackle once 4.0 is done.

  • So it stands written :-)

    But one day ... you know ... it comes open us, the wish to use the latest version.

    Btw., I can't run neither Vulkan nor OpenGL 4.5 on my old notebook with HD4400. and for an engine it is too slow, man 😎

    • Just saying, Intel HD 4000 is way below specs.

      It doesn't support Vulkan anyway, so time for a change.

      Try running in a window with a low resolution.

      Edit: re Vulkan support, it seems as if Vulkan 1.0 is supported (spotty) on Linux, and not at all on Windows.

      • Additionally, you would take all those repetitive expressions out and as consts before the match expressions. Only the case specific stuff is handled in the match branches.

        Apart from collapsing the whole thing to much less code, it is also tremendously much better for readability, less error prone, and in case of changes for instance at the scene tree there'd only be one line to change instead of six.

      • With many domino stones one might want to consider half of a physics time-step (30/s) for higher accuracy. Just like @cybereality said, I would search the problem elsewhere.

        Generally, If the time/step changes and things start to happen too slowly/fast, then one might have forgotten to account properly for the delta time that passed between steps.

        • 7892 replied to this.
        • I think what you want is just to inherit from a class that implements these methods virtually and override them. This would be basic C++.

        • Yeah, this is one method in GLSL as well, and performance is horribly because the texture has to be kept in CPU accessible memory, and some mapping and synchronisation must take place to prevent garbage.

          Instead, jut keep a copy of the data in CPU mem, no hassle at all, as small as it can get, and it works.

        • Depends how you do it. I have the height data as single channel 16bit textures on the CPU and upload them as 16 bit floats to the GPU for rendering. Float because GLSL doesn't allow type casts. I keep a copy as 16bit data on the CPU for frustum checks and to perform ray casts against, to prevent the camera from looking at the radish from below. So no to and fro between GPU and CPU is necessary.

          This runs even with 600 fps on my new 5600G full hd, but it's C++, single threaded.

        • I actually do collision tests against a surface triangle mesh, but that approach, though relatively exact, is too much computation for GDscript and needs lower level code. One also needs to keep the height data in CPU memory for this. There may be artefacts because of slight differences in how the surface is calculated on the GPU (visible) and CPU (physics) end.

          For "infinite" terrain you need swapping mechanisms anyway, on both ends. This is best done during loading or generation of the height texture. Communicating data back from a shader to the CPU is rather involved.

          Alternatively, one could transfer all physics computation to the GPU where the data is available. Some physics APIs allow the acceleration with the GPU, but Godot now brings its own physics on the CPU.

        • Cheeseness the map and museum were the very first things I gave attention to when I started production,

          It shows that you're in contact with real world palaeontology :-)

          The "deeper meaning" behind palaeontology/pre-history/archaeology, though they work with different methods, is documentation of the past real world, and putting things on display for the public.

          I see a bit of that reflected in your work. So, thanks, it's refreshingly cool and I like it :-)

        • 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.

          • 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 :-)

            • 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 ?

              • 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 ...

              • Let's not forget, one doesn't need an engine to write a game, and a lot of games are written in a stand alone manner. There may be a bias in game engine forums because there are people who use game engines, but if you look at for instance gamedev.net there are a lot of people who brew their own frameworks, tailored to their needs, or none at all. Abstraction may be a nice thing, but it shouldn't be a purpose in itself, if that makes some sense.

                Depending on the game of course, it might in the end be even more productive without an engine, because it takes a long time to get behind how a complex engine works, and how to make the most of it, how to bend the abstraction to one's will or adjust the will so that it fits into the abstraction, only to realise eventually that the corset said abstraction forces upon one needs too much adjustment, or isn't fit for the job.

                In this case, rendering 10s of thousands of objects with instancing, using textures to modify individual instances, maybe in a dynamic manner, isn't a big deal on a lower level (C/C++/OpenGL4.5/Vulkan), but I doubt Godot has the right tools for this. I may be wrong, though, haven't tried in the engine.

              • And these games exploit all kinds of things, like hierarchical data structures, instancing, and whatnot.

                With the right planning and the right game design one can render millions of objects without multithreading.

                Edit: ninja'd :-) Yes, I think you need to rethink the game design, and write down on paper how exactly these things interact with the player, what their goal and objective is. With that we can certainly give more concrete help.

                'nother edit: there's a lot of information on crowd rendering. I personally have not been there yet, but searching "how to render a crowd in a game" gives a lot of hits.

                https://developer.nvidia.com/gpugems/gpugems3/part-i-geometry/chapter-2-animated-crowd-rendering

                Of course, you will have to adapt that to Godot, and GDScript may be too slow. You will have to profile if you want to know which solution is better for your case. Can't say that often enough.

              • Your use-case doesn't merit threading, it slows execution time down. It is also a case of premature optimisation, aka "the root of all evil".

                I think it is good advice to first finish the game and have all planned features realised. Then think about optimisation, of which concurrency may be a part. And never optimise just like so. Always profile the execution with timers and objectively identify the parts that use up most of the time.

                The tools Godot offers in GDscript are very limited anyway. They don't offer atomic (indivisible) operations for example, that may be better for this case, but I don"t know your project.

                I find the suggestion of a manager node a good start. There all the villagers are in one spot. Later on, if villager movement really is the crucial point as identified with profiling, you can still think of concurrency.

                Just my 2 cents ...

                But of course, if you have the time to play with concurrency, then why not :-)

              • Thank you, Tomcat . And that's the answer.

                So the importer converts upon import to 8bi/channelt. That answers your question, @TwistedMind .

                And it also means that, as far as Godot is concerned, 16bit/channel PNG textures make no sense. If you need the precision, you must choose or write a different importer.

              • I gave you an explanation of how channels and bit depth are related and how to calculate the size of a pixel in bits. With PNG, it can be 8 or 16bit per channel, but 8bit is sufficient for any case of colouring or texturing.

                I said if you try to import a 16bit/channel texture where only 8bit are supported, you get an error or garbage (edit. or graceful crash, or the importer takes care and converts to 8bit, which is what I would do in such a case). You didn't state initially you're actually doing it and it works.

                Btw., where does it say Godot only supports 8bit/channel PNG textures ?

                Is there a reason you're using 16bit/channel ? Unless for specific use cases like monochrome height maps for example this doesn't make sense. Always keep the amount of data small.