Fork from Cube2, Tesseract, or Red Eclipse? about vulkan-renderer

[lonnietc]

You are correct in the core idea that I am doing, but we can discuss more in some messaging on Discord if you want since I could also share with you some additional details and features along with some peer documentation that I was looking to also use as a guideline as well. My discord handle is TallyLC

[IAmNotHanni]

Hello!

Inexor is no longer a fork of any other project. It's a completely new engine written from the ground up in modern C++ using Vulkan API :)

Inexor does not use one single line of code from any cube-engine project. Porting Cube2 or any other cube-engine project to Vulkan is not possible I believe because the cube engine code is very hard to modify in the core. Furthermore, cube-engine follows an overall engine architecture that is outdated nowadays since it is entirely single threaded and uses only a main rendering loop. This was fine in 2002, but not enough to power what we envision.

While some brave projects try to refactor cube-engine, I highly recommend not to do so. The list of technical reasons for this is long. Therefore, Inexor trusts in our new engine. Understand that it will take time until it is in a presentable state, but we believe it's worth it.

Join our Discord for more info :)

[IAmNotHanni]

Once again, I would like to point out that a major challenge in porting Cube2 to Vulkan API is the overall difference in technology. Cube-engine uses OpenGl, and the difference between it and Vulkan API are massive.

I recommend you should watch Adam Sawicki's talk "Porting your engine to Vulkan or DX12": https://www.youtube.com/watch?v=6NWfznwFnMs&t=33s

And Dustin Land's "Getting explicit: How Hard is Vulkan really?": https://www.youtube.com/watch?v=0R23npUCCnw

More links can be found in our docs, enjoy: https://inexor-vulkan-renderer.readthedocs.io/en/latest/links/main.html

[IAmNotHanni]

This is our Discord Server: https://discord.com/invite/acUW8k7

[lonnietc]

Hello,

Thanks for the information and I have joined the Discord server.

My purpose is to build a very specialized voxel type engine that actually has many of the similar features that your inexor engine has been discussing, but a few more different ones as well.

I was also wondering about the development effort on the project as it seems that it has not been worked on in 5 months and just wanted to see what timeline is on it?

On this discussion, I also came across Imprimis:

https://project-imprimis.github.io/www/

https://project-imprimis.github.io/libprimis/index.html

https://github.com/project-imprimis/imprimis

Which uses the libprimis engine part and is composed of a rework of Cube2 Saurbraten and Tesseract although it does not have Vulan but seems to have an interesting base and has addressed some of the pipeline things that you mentioned.

Any thoughts?

Have a great day

[IAmNotHanni]

Hey

The Inexor engine is being developed through pull requests, so we do not push directly into the main branch. This means you will see a lot of progress being merged at once every few months. Currently, we're working on the new continuous integration which prevents a lot of work from being merged, but it should be fixed soon. Our current work can be seen in the pull request tab.

A voxel engine? nice! Inexor uses a cube-engine approach where there's an octree and a 6-directional heightmap on every face of the octree. It should be possible to implement a voxel in our engine now already, but the rendering features are still under construction (rendergraph is being refactored atm and there is a ton of features we need to implement in terms of rendering).

About imprimis: I respect them for what they do, but while they made impressive progress and put a lot of work into it, there are some problem I see. One problem is that you are not really refactoring the core of the engine. I don't think they will support Vulkan ever, because the underlying cube-engine code is not suited for it. Also, refactoring cube-engine introduces a lot of new bugs and I know they had problems with several segfaults which came after refactoring. Also, cube-engine itself has bugs and problems that are not fixed until today. I don't see any benefit in dealing with this any further, we just want to write a completely new engine. I don't believe that our progress is slower than the progress of imprimis because they have the benefit of starting from a working full game engine. But understand that once we reached a stable basis in our engine, we will be able to introduce new features faster because of our modern code structure and engine architecture. It's tempting to modify cube-engine to support simple features, but changing the core of the engine is a task that is pretty much close to impossible in my opinion.

[lonnietc]

Hello,

Thanks again for your wonderful insight and I will explore your engine more to see if maybe it is a good starting point for what I envision as well.

One of the many changes that I am targeting is in the area of P2P and an infinite (virtually) universe such that users will run a P2P node that will, in effect, make up parts of a highly distributed octree in that each node will hold parts of the new tree as well as replicates for part of other user's node tree for redundancy.

In general, the idea is to have a massively distributed P2P octree that can grow and be shared by the users in an attempt to provide for a type of 3D engine agnostic system. Users of different types 3D engines, like maybe one day Unity, Unreal, CryEngine, Flax, O3DE, Godot, and others will, one day maybe, be able to have a "plugin" for their 3D engine that will allow them to connect and interact with the API of the P2P Octree (was also considering BSP and others, but octree seems like the best general option) and thus be able to create worlds, modify them, and interact with others in the P2P universe all from different 3D engines.

Yea, that is a HUGE goal and dream, I know.

[IAmNotHanni]

Amazing! We had a similar idea at some point as well. The good news it that in contrast to cube-engine, Inexor supports an arbitrary number of octree layers. Each layer will have its own position, scale and rotation. Your use case could be implemented by stretching the octree in the xy plane while squashing it in the z plane. This non-uniform scale is not supported by our engine atm, but it would be possible to do this and it would not even have an impact on the performance, because the octree traversal would be the same

Note that while the octree collision pull request is in its finishing states, the octree itself still needs some more work (better API, documentation, using pool allocators for octree nodes, implementing edit history, material system for rendering...)

[IAmNotHanni]

So what you would want to do is really to create a big octree which

• has a big size
• has a big depth until the deepest node is reached
• has a non-uniform scale, the xy plane being stretched and the z direction being squashed. This could be set so that the squashing is a multiple number of the xy stretch

So in total, your game world would be very wide, but only as deep into the ground as needed (similar to Minecraft which has only 256 blocks in z). You could have 4 servers and each server is assigned to 2 octants for example.

An "infinite" game world could be done by streaming adjacent octrees (pretty much how Minecraft streams its chunks).

Note that Inexor is still in early stage and we have neither network support nor do we support octree streaming yet.

[IAmNotHanni]

Alright, see you on Discord! I want to close this issue then :)