Use SuperTuxKart's Irrlicht fork for Minetest?

[Worldblender]

Instead of a switch to a different game engine (as found on viewtopic.php?f=3&t=22618) that certainly has significantly different interfaces that would require rewriting the graphical aspects of Minetest, I suggest something as a middle ground: Use the Irrlicht fork found in SuperTuxKart (STK) (the FOSS 3D kart racing game featuring Tux and friends), known as Antarctica, from https://github.com/supertuxkart/stk-cod ... b/irrlicht.

This fork is based off Irrlicht 1.8, r4350. Known changes from upstream:

Code: Select all

The following changes have been made:
- config changes in IrrCompileConfig.h
- primary sort by material type
- stencil RTT support
- drawall types
- materialtype override
- skies respect Z
- partial backport to expose setCurrentRendertime in the scene mgr (upstream)
- a workaround for every other RTTs flipping
- aabbox intersection support (upstream)
- texture override
- non-triangle VBO support
- extension order mismatch
- support for some RG texture formats

If Minetest can successfully be compiled and run with this Irrlicht fork, these are just some of the things possible using it, some found from https://supertuxkart.net/Antarctica:_Technical_Details:

• Physically Based Rendering (PBR)
• Image-Based Lighting (IBL)
• Instancing of multiple copies of an object
• Cascaded Shadow Mapping for sunlight
• Alchemy Engine's Ambient Obscurance algorithm for better shadows
• Radiance Hint Global Illumination

Additionally, work that can be shared upstream with STK includes, but is not limited to:

• Space-Partitioned Mesh (SPM) format; adds another option for loading 3D models into Minetest
• The GUI system that can be themed and likely has more options than the built-in Irrlicht GUI system
• The material system for configuring textures, which can potentially make the overall appearance better
• Shared tooling system in Blender (2.80 and later contributed by me at https://github.com/RQWorldblender/stk-blender/)

I'd like to see what other people think of this first. I might be able to spend some time working on this by myself, but it's better if I can get some occasional help along the way.

[ShadMOrdre]

Not to mention, by collaborating with another project, MT essentially gains more devs who are already well versed in the language and requisite skillset.

This is only a WIN / WIN.

Not to mention cross marketing with a rather well known foss game can up MTs stature and status as a must have go to opensource game. Besides, didn't someone over there add MT Sam to the lineup? If not, WHY NOT? That's free publicity!

[Worldblender]

Not to mention, by collaborating with another project, MT essentially gains more devs who are already well versed in the language and requisite skillset.

This is only a WIN / WIN.

Not to mention cross marketing with a rather well known foss game can up MTs stature and status as a must have go to opensource game. Besides, didn't someone over there add MT Sam to the lineup? If not, WHY NOT? That's free publicity!

No, I've not seen a kart with MT Sam yet. It might be something I can try working on some other time, however. I've got experience since I have worked on other STK stuff before at https://gitlab.com/Worldblender/stk-contrib-addons and https://gitlab.com/Worldblender/ssbu-karts-for-stk (currently being redone), both karts and tracks.

[ShadMOrdre]

I seem to recall someone did something along that line around here sometime in the last year.

I thought it'd be a cool idea because my son and I enjoy STK and MT.

[Worldblender]

I seem to recall someone did something along that line around here sometime in the last year.

I thought it'd be a cool idea because my son and I enjoy STK and MT.

I'm talking about that I did not find such a kart on https://online.supertuxkart.net/index.php. If you can find the kart and its Blender source files, I'll be glad to help upload it, making any changes if necessary.

Actually, it may be a few days or weeks from now before I start to look into compiling the latest Minetest, but with STK's Irrlicht library instead.

[sirrobzeroone]

Im absolutly no help with C code, but I am happy to help with any testing and documentation that might be needed.

[v-rob]

• Physically Based Rendering (PBR)
• Image-Based Lighting (IBL)
• Instancing of multiple copies of an object
• Cascaded Shadow Mapping for sunlight
• Alchemy Engine's Ambient Obscurance algorithm for better shadows
• Radiance Hint Global Illumination

Some of these things look pretty amazing, I'll be honest. The problem is that Minetest can't take advantage of them at all. Minetest fights Irrlicht more than working with it. To give an example: Irrlicht and Antarctica have some complex lighting systems that can look really awesome. Minetest, on the other hand, doesn't even touch Irrlicht's lighting system but uses its own. Many problems we have aren't Irrlicht's fault but our own, and to fix them, we'd need to rewrite a lot.

So really, I think we have two good options: either embrace Irrlicht wholeheartedly and use it to its full potential (in which case Antarctica would be much to our advantage), or curb back our use on it and use the bare essentials (in which case neither Irrlicht nor Antarctica is useful). Currently, we aren't really heading in either direction, and I think that's kind of a problem.

[PolySaken]

To give an example: Irrlicht and Antarctica have some complex lighting systems that can look really awesome. Minetest, on the other hand, doesn't even touch Irrlicht's lighting system but uses its own.

Oh god why‽
I see now why minetest is so bundy-feeling and isn't very popular.

[Worldblender]

Minetest fights Irrlicht more than working with it. To give an example: Irrlicht and Antarctica have some complex lighting systems that can look really awesome. Minetest, on the other hand, doesn't even touch Irrlicht's lighting system but uses its own. Many problems we have aren't Irrlicht's fault but our own, and to fix them, we'd need to rewrite a lot.

So really, I think we have two good options: either embrace Irrlicht wholeheartedly and use it to its full potential (in which case Antarctica would be much to our advantage), or curb back our use on it and use the bare essentials (in which case neither Irrlicht nor Antarctica is useful). Currently, we aren't really heading in either direction, and I think that's kind of a problem.

Aww! I didn't realize something like that would happen! Since I have a descent amount of coding experience, this looks like something that I could help out with (although it's hard for me to do a rewrite like that all by myself, unless other people help me). I wonder where I can get started? I could start out by making my own Minetest fork, seeing if it builds with Antarctica, and then fixing the necessary code, but I don't want to overwhelm myself with so much at once! Rewriting large chunks of Minetest to better take advantage of Irrlicht/Antarctica is likely to be too much work for myself.

[rubenwardy]

Minetest also has infinite* voxel maps and so needs to use algorithms that can cope with that. Traditional lighting like that provided by irrlicht is not a good idea. Voxel lighting works much better

STK is much more like a traditional game. Most of the map is static, which means you can bake lighting information for performance

[runs]

It would be the best approach. Irrlich is already in at dead stage.

Not going over to Antartika because it is based on Irlicht is counterproductive. For a simple reason, there is a 1% chance that Minetest would be ported to another engine right now, but to Antartika it is much more feasible.

Not to do so, waiting for the hope that it will be differently is to languish and languish in eternal decay.

[hex]

Wow, look at all those features Minetest doesn't need!

[PolySaken]

Wow, look at all those features Minetest doesn't need!

The Idea that minetest doesn't need things just because they would require an engine change is stupid. Literally noone would complain if minetest had always had actual lighting and shaders, so why complain about the idea of adding them?

[v-rob]

If we're going to switch to a fork of Irrlicht, we should consider which is the most useful to our needs. Does Antarctica afford features that are useful? Is another fork like IrrlichtBAW better? Is the license compatible with ours? Do they even have any features Minetest could use that Irrlicht doesn't have? Or should we work on using a development version of Irrlicht 1.9 instead of our current 1.8.4? We shouldn't change our fork for the sake of changing it, but really look at what would help and what wouldn't.

[runs]

If we're going to switch to a fork of Irrlicht, we should consider which is the most useful to our needs. Does Antarctica afford features that are useful? Is another fork like IrrlichtBAW better? Is the license compatible with ours? Do they even have any features Minetest could use that Irrlicht doesn't have? Or should we work on using a development version of Irrlicht 1.9 instead of our current 1.8.4? We shouldn't change our fork for the sake of changing it, but really look at what would help and what wouldn't.

It is not a matter of change it, but Irlicht is dead (6 years of apparent inactivity). So probably Minetest could be obsolete in a (remote?) future. The new technologies are important.

Irlicht do not support a good input system. So it is an engine not finished not polished.

Light colors are possible? I'd like color lights.

The best solution would be fork/restart Irlictch and go forward with it. Or join another project related to Irlitch.

[Worldblender]

There's more that SuperTuxKart implements:

• Use SDL2 for window creation, allowing better gamepad support
• A (likely) better GUI system, with skin support
• Android version, with iOS version coming in a future release
• Potential Vulkan support in the near future (not yet here)
• Add emoji support, complex text layout, and unicode file path support
• Potential copy/paste text support in text boxes

So in some areas, they are already ahead of Minetest in terms of certain features supported. The lighting system is not one of the things I'm really concerned about. It's more about being able to pool developer work, reduce reinventing the wheel times, and possibly better maintenance.

[hex]

Add emoji support

Just because some phone carriers bribed or blackmailed the Unicode people to include their smiley cancer into a text encoding doesn't mean anyone should actually support it.

[PolySaken]

Add emoji support

Just because some phone carriers bribed or blackmailed the Unicode people to include their smiley cancer into a text encoding doesn't mean anyone should actually support it.

Luddite
also emojis come from japan

[hex]

also emojis come from japan

BRB, moving to Japan so that everything I make instantly becomes good and nobody is allowed to say anything bad about it.

[PolySaken]

also emojis come from japan

BRB, moving to Japan so that everything I make instantly becomes good and nobody is allowed to say anything bad about it.

bad post
missed the point

[hex]

Colored smileys have no place in an international text encoding standard. They were a private, proprietary thing made by some Japanese mobile phone company, then adopted by Apple, Google, et al on their own phones, and then finally hamfisted into Unicode. Still, nobody took this seriously at all for a good few years, but alas, desktop OS and browser vendors finally caved in, and the internet started being flooded with this cancer ca. 2015

Now we have an international standard for posting a curated set of images inline alongside text. Which images we get to post is decided by one committee, already under heavy commercial and political pressure to add or remove individual images. Won't be long before corporate logos and products start being included in the set. All of this, may I remind you, in a standard for encoding text, even though emoji do not qualify as any sort of language or script. The images aren't even rendered consistently between vendors.

Also, as if rendering hardware accelerated text wasn't hard enough, now you have a few thousand colored pictures to consider as "text", generate atlases for, and support in your shaders. You thought you can use an alpha only texture to save VRAM? Too bad. Fonts may now carry colored pictures. I wonder how many vulnerabilities has this crap created across all of computing, just by the sheer amount of code produced to support it. Code written, CPU cycles wasted, carbon emitted. All in an effort to universally support someone's take on yellow f***ing smileys. Doesn't even include a decent set of colored blocks to at least support another generation of ANSI art, because creativity is for losers, boomers and luddites.

Business as usual in the 🤡🌍

[rubenwardy]

[duane]

Well, I'm enjoying hex's (very accurate) description of emojis immensely.

However, the thread is wandering a bit off-topic. :) [ <- used ironically ]

By the way, inactivity in a project does not mean that the project is obsolete. When it fails to work -- then and only then, is it obsolete. There are plenty of programs that people use every day that haven't been changed in years, because they don't need to be.

[Hume2]

When it fails to work -- then and only then, is it obsolete. There are plenty of programs that people use every day that haven't been changed in years, because they don't need to be.

Keyboard handling is broken for instance. Each time I want to write the number 4 (and sometimes 7), I have to write it in calculator and then copy-paste.

[CalebJ]

Add emoji support

Just because some phone carriers bribed or blackmailed the Unicode people to include their smiley cancer into a text encoding doesn't mean anyone should actually support it.

agreed with hex. Also, I specifically remember celeron55 was/is quite violently opposed to the idea of emotes in minetest.