Brainstorming ideas for achieving "connected textures"

Post Reply
User avatar
Faustawk
Member
Posts: 26
Joined: Mon Jun 05, 2023 23:49
In-game: Faustawk

Brainstorming ideas for achieving "connected textures"

by Faustawk » Post

Recently I was developing a lua mapgen in order to experiment with different ways of handling grass. The standard method (dirt node with a grassy overlay) seems pretty limiting to me, and I wanted something more like the approach Rising World uses where grass is a sort of blanket layer that conforms to the soil underneath. To achieve this I created a 'grass carpet' node that uses a connected nodebox to droop down over the node below it, which looks quite nice and solves some of the issues I had with the old way of making grass.

However, this method also gave me the idea of having grass "spill over" to neighboring soil nodes, kind of like this:
Image

My original idea was to create a nodebox that approximates the old style of grassy dirt node, but with the ability to connect to neighboring soil. I then gave it a visual_scale of 3 and 48x48 textures, with some adjustments to make it look and behave like a normal node (I did it this way so I could avoid using more boxes than necessary). This actually looked great, and save for a small bug when smooth lighting is disabled and z-fighting from large distances, it gave the effect I wanted.

The problem with this method though is that it only solves one type of "connected texture", and I would quite like to use some other kinds, such as 9-segment textures for nodes that have border variants, or 3-segment textures for pillars and other things with 'middle' and 'end' variants. I can't find any pretty, performant method of creating effects like this, let alone more complex ones.

Does anyone else have ideas for how to create connected textures? Methods that are already in use? MT users don't really seem interested in visual polish so I might be pushing my luck here.

(The obvious solution is an engine-implemented dynamic texture drawtype or the ability to set the textures of a node via metadata, but that doesn't seem like it'll happen any time soon)
Last edited by Faustawk on Tue Jun 06, 2023 00:28, edited 2 times in total.

User avatar
Faustawk
Member
Posts: 26
Joined: Mon Jun 05, 2023 23:49
In-game: Faustawk

Re: Brainstorming ideas for achieving "connected textures"

by Faustawk » Post

Note that I forgot to mention: I'm aware that some of the 'glasslike' drawtypes have adaptive borders, but they're limited to /16th wide and use a 3d model which is bad for performance.

User avatar
Mantar
Member
Posts: 585
Joined: Thu Oct 05, 2017 18:46
Contact:

Re: Brainstorming ideas for achieving "connected textures"

by Mantar » Post

Faustawk wrote:
Tue Jun 06, 2023 00:16
Note that I forgot to mention: I'm aware that some of the 'glasslike' drawtypes have adaptive borders, but they're limited to /16th wide and use a 3d model which is bad for performance.
I was under the impression that a static .obj model is generally better for performance than equivalent nodeboxes.
That said, that grass spread effect looks fantastic!
Lead dev of Exile, git repo: https://codeberg.org/Mantar/Exile

User avatar
Skamiz Kazzarch
Member
Posts: 613
Joined: Fri Mar 09, 2018 20:34
GitHub: Skamiz
In-game: Skamiz
Location: la lojbaugag.

Re: Brainstorming ideas for achieving "connected textures"

by Skamiz Kazzarch » Post

Two approaches I took when I wanted something similar a while back:
Screenshot from 2023-06-06 20-06-29.png
Screenshot from 2023-06-06 20-06-29.png (158.63 KiB) Viewed 527 times
The right one, as you already noted, results in Z-fighting and bad lighting under certain conditions.
And the left one I only considered viable, because my use-case was in a custom game on a prebuilt map, where the players can't change the terrain significantly.

Only other alternative I can think of, is having nodes which act as decals, which are placed when a suitable node combination is detected.
This has the caveat that it requires the above node to be empty and, again, there is the balancing act between rising the decal above the node surface enough to avoid Z-fighting, but also so little it isn't noticeable from close up.


The engine unfortunately doesn't offer much in terms of changing a nodes appearance during runtime.
It's pretty much always boils down to a few options: connected nodeboxes, hardware coloring with palettes, rotation, or the various methods to fake it: swapping the node out for another one, using objects, maybe a few others...

Being able to actually change a nodes texture would be huge. Even if it's just something like: "Freeze on the Nth frame of the animation."
Alas, personally I got in the habit of just not having any expectations of the engine, use and abuse what is already implemented, and sometimes be pleasantly surprised when something I like does get implemented.

User avatar
Faustawk
Member
Posts: 26
Joined: Mon Jun 05, 2023 23:49
In-game: Faustawk

Re: Brainstorming ideas for achieving "connected textures"

by Faustawk » Post

Mantar wrote:
Tue Jun 06, 2023 17:21

I was under the impression that a static .obj model is generally better for performance than equivalent nodeboxes...
Yes, but worse than dynamically updating textures

User avatar
Faustawk
Member
Posts: 26
Joined: Mon Jun 05, 2023 23:49
In-game: Faustawk

Re: Brainstorming ideas for achieving "connected textures"

by Faustawk » Post

Skamiz Kazzarch wrote:
Tue Jun 06, 2023 18:45
Being able to actually change a nodes texture would be huge. Even if it's just something like: "Freeze on the Nth frame of the animation."
This would make for a great quick fix, it doesn't seem like it would be difficult to implement a drawtype that uses the param2 value as an index into an animation. Doing it that way would still require the lua mod to handle calculations and updating however, so it would have the same slow update speed as swapping nodes would.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests