Extruded drawtypes

[MirceaKitsune]

I wanted to bring attention to a feature that seems to have been forgotten, which I'd really like to see revived under some form. It was one of the things RealBadAngel had been working on, before the unfortunate event of his death occurred. Alongside shaders such as Bloom or Depth-of-Field, it was one of the visual improvements I was waiting most eagerly to see finished.

The feature allows for all flat drawtypes, such as "torch" or "plantlike", to use the extrusion system of the wielded item and have a width. This results in a much more beautiful and artistic appearance for plants and other items, as seen in the screenshots posted at the time:





Unfortunately both the original issue and pull request have been closed down and abandoned. They can still be found here, along with the code and discussions:

https://github.com/minetest/minetest/pull/1871
https://github.com/minetest/minetest/pull/3496

From what I understand, the problem was that this required new drawtype definitions, and it was suggested that a parameter to define the width which works for all drawtypes is used instead. I perfectly agree with this myself... sadly RBA was no longer around to finish up on the change.

Would it be possible for someone else to please pick up this code, and finalize the last concerns expressed about it? It is a beautiful improvement especially for grass and flowers, and I really wish to see it as part of the engine and use it at some point! Thank you.

[Sokomine]

Sounds like a very good idea. The screenshots look very intresting. "Flat" textures gaining depth like in itemframes sometimes looks very good.

[TumeniNodes]

It is a very beautiful visual, but there were/are valid points on both sides regarding this PR.

Thinking someone may have to take it all, go away for some time into the mountains of Tibet, and then return some 10 years from now with everything perfected.

I think there really are other options/means to enhancing the visual of plants which would be less demanding.
I am not sure things have changed so much since the last discussion to make this a viable addition. : /

It would be nicer, actually, to see someone take up RBA's fork, and continue his work with it.

[MirceaKitsune]

I also opened a new issue for this (#5666) and it's been discussed there briefly. Paramat made a valid argument that this effect can be technically achieved using meshes. However I believe that's not a good way to go for the following reasons:

Drawtype extrusion automatically generates the model for every texture, accounting for its alpha channel. If a texture update changes its transparency, a fixed model would also require manual updating. Further more, everyone making a texture package would have to make custom models for every extruded drawtype too. Not every texture artist might have the tools or knowledge to make models, whereas individual pixels are also a bit tricky and weird to model manually at accurate proportions and scale. For something as common and basic as simple extrusion, an automated way of generating the mesh would be an important convenience.

[MirceaKitsune]

To better explain why I'm supporting this feature, I put together a list of reasons for why I think it should exist, compared to doing this using 3D meshes. I posted it on the new issue, and will share it here too for further coverage:

• If it's a fixed model, you need to update it every time you update its texture (in case you're also updating its alpha channel which is almost always the case).
• If it's a fixed model, every custom texture package needs to make new models for every texture belonging to an extruded item (again if it changes the alpha channel).
• Not every texture artist has the tools and knowledge to create models. Someone might be able to create a texture in Photoshop, but not know Blender to make an extruded mesh for it.
• This effect is extremely tedious to model manually! Imagine opening up a 3D modeling program, placing little cubes one next to another, UV mapping each to match a precise pixel on an image, then removing hidden neighboring surfaces to get rid of extra vertices... it's a nightmare.
• As you need to distribute the model alongside the texture, clients connecting to servers might need to download it upon joining. In an engine where even 16px textures are optimized to the bone to reduce file size, countless 3D models for such a simple effect would likely not be desired.
• The exact same effect already exists in the engine and is widely used, for both wielded and dropped items as well as 3D clouds. Therefore this isn't even suggesting a completely new feature coded from scratch, just piping an existing algorithm into a few other use cases.
• Because we're doing the same thing with items, the effect also fits in from an artistic standpoint... not only does it not look out of place, but it's in fact the most logical result: The wielded item is normally flat too, and we extrude it to make it prettier... plants and torches are in the same situation, so why would they not be extruded? Think back to the old flat torches, or consider saplings for instance: If you hold one in your hand, it appears extruded... but once you placed it on the ground, the extrusion effect vanishes... logically this means the item changes shape which doesn't make much sense.

I think every point on this list is a good reason to consider the functionality. I agree with it staying disabled by default, if more people think it's ugly than they think it's pretty. However minetest_game should make it available by default, for every client that turns on this setting. Perhaps a single option should control extrusion as follows: 0 = disabled, 1 = wielditem and dropped items (current behavior, remains default), 2 = wielditem and dropped items + flat drawtypes.

Once more, I fully agree with a simple LOD system which should fix all performance concerns, where the effect is simply disabled for nodes further than a customizable view distance. Also keep in mind that with simple flat extrusion, vertices are only generated for the edges of pixels neighboring transparent pixels, therefore it's not a cube for each pixel and vertice count depends strictly on the complexity of the texture's alpha channel.

[azekill_DIABLO]

it's absolutly beautiful. We should really add it in minetest!

[ShadMOrdre]

I'd like to chime in here as well.

While making my lib_node_shapes mod, I considered trying to produce something similar to this, using nodeboxes. My intention was to create plants, leaves, and even a 3D chest and craft grid. These are still to be considered. I was further motivated by Calinou's and Tenplus1's Item Frame mod's.

Perfomance notwithstanding, (I use an AMD Neo II with an AMD Geode GPU, and two Dell Inspiron laptops with Core2 Duo CPUs running under 2GHz with Intel 945 built graphics, usually giving only 20fps max in Minetest), this should at least be an option.

In opposition of c55's own opinion, if minetest is a game engine, then shouldn't it provide more features and options instead of more limitations?

Voxel world, pixelated graphics, and other "retro" looking styles notwithstanding, minetest will need to evolve to accept that users may just want to use the engine to push the boundaries of a voxel world. This includes using smaller and smaller node sizes. Nodeboxes are an improvement to try to replicate this, but still fall far short. 3D models would be great. I'd like to create them in a Minetest world, where I have a better perspective. So will minetest engine support mesh creation from graphics? Or am I told to go learn Blender? To limit graphics creativity to only those with Blender or GIMP like skill sets is a slap in the face. It also harms minetest in the longer term, by limiting the content that can be provided to only that provided by those artists with the requisite skill set that are also willing to share. It's almost like Apple telling you to use a Samsung phone for your phone calling needs, because it can't be bothered to improve the phone calling capabilities of their phone products.

Pushing the boundaries is one of the incredible reasons that Minetest stands far and above a "Minecraft on steriods" definition.

paramat and c55, please reconsider this, or some better implementation of this, as this takes Minetest in directions that are good for the community, the software, and open source in general.

[MirceaKitsune]

Very well said ShadMOrdre, I agree with that.

My primary problem with Minetest, which I stated in all sorts of ways over the years, is that the developers seem to barely give attention to anything that has to do with visual improvements. The project is very active and the code is worked on daily, however this is always for API features or other engine improvements. Almost no one ever adds any visual enhancements... and if someone does and makes a pull request, everyone finds every possible reason to be against it, from "it looks ugly" to "but what if Minetest might not run perfectly on 20 year old computers". At this point I've given up on trying to change this trend, because I realize it will probably never go away.

And yeah, doing this with nodeboxes would be a nightmare: A Lua API to generate nodeboxes based on the transparency of a texture could be technically achievable, however it would be much more difficult and inefficient to do it there! Unlike the code, you can't implement a LOD system easily this way, and most importantly you can't remove the hidden neighboring surfaces in between nodeboxes which is a huge waste of performance.

[azekill_DIABLO]

i totally agree, who could say more?

[texmex]

if minetest is a game engine, then shouldn't it provide more features and options instead of more limitations

That's a big if. Or even if it is, from what I read above it is and will stay a niche engine for making MC-like games only. Which is all fine! It would however be self-deceit to imagine that as an engine it would cater to more than hobby game developers.

[azekill_DIABLO]

Alongside shaders such as Bloom or Depth-of-Field

??? Images??? it interest me.

[MirceaKitsune]

??? Images??? it interest me.

RealBadAngel had a Minetest fork that contained them, of course in an experimental and unfinished state. I don't think I have screenshots any longer unfortunately, but all I can say is they looked amazing! I wonder if and when anyone will ever attempt to bring them back again...

[Linuxdirk]

Almost no one ever adds any visual enhancements... and if someone does and makes a pull request, everyone finds every possible reason to be against it, from "it looks ugly" to "but what if Minetest might not run perfectly on 20 year old computers". At this point I've given up on trying to change this trend, because I realize it will probably never go away.

Yep. It's just sad that obviously no-one from the dev team really cares about the look and feel of Minetest (and a lot of them don't even care what everyday casual players want and only sit on top floor of their ivory tower and do whatever they want regardless of players really need it or not).

There is no other solution than accepting it. MT is developed. Slow and steady .. but slow. And not with graphics in mind.

[azekill_DIABLO]

??? Images??? it interest me.

RealBadAngel had a Minetest fork that contained them, of course in an experimental and unfinished state. I don't think I have screenshots any longer unfortunately, but all I can say is they looked amazing! I wonder if and when anyone will ever attempt to bring them back again...

i could. I'm secretly forking minetest.

[paramat]

... a feature that seems to have been forgotten, which I'd really like to see revived under some form. It was one of the things RealBadAngel had been working on, before the unfortunate event of his death occurred.

From what I understand, the problem was that this required new drawtype definitions, and it was suggested that a parameter to define the width which works for all drawtypes is used instead. I perfectly agree with this myself... sadly RBA was no longer around to finish up on the change.

Would it be possible for someone else to please pick up this code, and finalize the last concerns expressed about it?

In case people do not read the issue at Github, the above is not the case, it was closed for different reasons to this, and several weeks before his death.

Nodeboxes are an improvement to try to replicate this, but still fall far short. 3D models would be great. I'd like to create them in a Minetest world, where I have a better perspective. So will minetest engine support mesh creation from graphics? Or am I told to go learn Blender?

I can't use Blender either, and agree that an easier way to create 3D meshnodes would be good, such as building a structure out of full size nodes then having a mod or engine code shrink that down to any desired size.
Creating a structure by defining the co-ordinates of hundreds of tiny nodeboxes would be painful.
But my point here is what celeron55 wrote as his reason for closing it: we don't need yet another way to make fine-detail 3D structures when we have 2 already, better to add code that makes it easier to create meshnodes that includes a way to create extruded forms directly from textures.

My primary problem with Minetest, which I stated in all sorts of ways over the years, is that the developers seem to barely give attention to anything that has to do with visual improvements.

Almost no one ever adds any visual enhancements... and if someone does and makes a pull request, everyone finds every possible reason to be against it

Visual improvements are indeed added, and RBA added several shaders, and many visual improvements are supported. 'Visual improvements' is much more than fancy effects, those are just a small part of visual appearence.
If a submision is disapproved it is for good reasons explained in the threads, and not from some kind of aversion to things looking good.
It is not just fancy effects that make a game look good, the structure and textures of a world is what makes it look good and no amount of fancy effects could make it look good if the basic appearence does not.

The issue here seems to be that you have a quite extreme taste that focusses on very fancy and intensive special effects. I find it hard to understand why someone would not be particularly interested in the actual substance, dynamics and gameplay of a game and only be interested in the game if very fancy effects are added, it seems over-occupied with things that are shallow and superficial. it's obvious that a game can be great even if it has simple graphics, and that fancy effects can never make a bad game good.

Also of course, see celeron55's roadmap for the philosophy of the game, it really is not about fancy effects, celeron55 is uninterested in shaders and the game tends to attract devs who have a similar attitude to celeron55.

Yep. It's just sad that obviously no-one from the dev team really cares about the look and feel of Minetest (and a lot of them don't even care what everyday casual players want and only sit on top floor of their ivory tower and do whatever they want regardless of players really need it or not).

All of this is untrue and a very unfortunate delusion.

[texmex]

Thank you for taking the time to develop your thoughts from a developer point of view paramat. I feel as though the discussion is balanced up by your reply. Although I don't consider an extruded drawtype an extreme special effect, I also recognize the inclinement from us players/modders/etc towards visual improvement rather than under the hood counterparts, which might not be fair.

[MirceaKitsune]

Yes... I can't argue what paramat said there. I do believe the MineTest team ignores visual aspects in general... which isn't referring to models and textures, as much as to special effects and shaders. This is a general divide in the community; Some players (like myself) are interested in everything improving the overall feel and experience, whereas some developers thinks that's still a secondary concern.

A generalized function for extruding 2D images with alpha channels, using a flexible definition rather than hardcoding per drawtype, sounds excellent to me! I'm not personally picky about the implementation: I'm only interested in having the ability to do things like automatically extruded plants, whichever implementation this is achieved through. So in this case, maybe we can agree on a smart and useful way of achieving it, which won't feel like junk code to anyone?

[azekill_DIABLO]

Yes... I can't argue what paramat said there. I do believe the MineTest team ignores visual aspects in general...

i don't think so... but maybe you're true... look at terasology...

[MirceaKitsune]

i don't think so... but maybe you're true... look at terasology...

Yep... great example: Compare Terasology and Minetest (both with highest effects) and it's impossible not to see exactly what I mean.

[paramat]

I have seen many people say that terasology is almost unplayable with effects enabled. It tends to look 'good' in screenshots (and many enthuse over the screenshots alone) but playing it is very different. Maybe terasology is not a good example.

[TumeniNodes]

^ I can vouch for that.
Terasology is still in it's infancy, development-wise. And when you actually play it, well..., I don't want to say it's disappointing in relation to the screenshots but... (it kinda is...)

This is not a rip on Terasology development. Seeing it in images, and playing it are two completely different visual experiences.
They are also on a very different dev path, than Minetest

[texmex]

I've played Terasology and yes, it plays terribly. What I like about Minetest among many other things is that it's fast. Extruded drawtypes is not like bloom or blir however, but more of a "core look feature". If it would be taxing on hardware and therefore opt-in for some, I can understand why it's not included.

[azekill_DIABLO]

it should be optionnal for people with good computers.

[texmex]

it should be optionnal for people with good computers.

No. The look would be distinctively different for different rigs and subgame mkaers would have to have two looks in mind when creating. In this case it should be all or nothing I believe.

[MirceaKitsune]

I have seen many people say that terasology is almost unplayable with effects enabled. It tends to look 'good' in screenshots (and many enthuse over the screenshots alone) but playing it is very different. Maybe terasology is not a good example.

It all depends on hardware. The nice thing about such effects is that they can almost always be made modular, and of course disabled by default: If you're okay with getting 20fps instead of 60fps for beautiful looks, it's your choice to enable them. Minetest could easily support that, without getting in the way of any existing functionality and performance standards.