Making Nodes smaller... (more fine-grained worlds)

[thomasthespacefox]

With v5 having a settable player collision box, Id be interested to see people make some heavy conversions where the old node=meter scale no longer applies.

While some may not like changing the apparent size of the nodes, i believe it could add a lot more depth, and even only doubling things sizes in nodes would be a very compelling shake-up.

Some thoughts:

-vastly larger scales will run into problems with the lighting system.
- Just about any overall scale change means everything from trees to plants to doors needs adjusting and rework.
- a 2x scale where (2 nodes=1 meter) might be a good scale to start with.
-

Any thoughts? Ideas?

important question:
What engine features would make this more practical?

[texmex]

Thought about this too. I suspect there’s a lot of hard-coded assumptions in the engine that we don’t notice as long as we keep to the default scale. For one, imagine a 8x worse view range…

[thomasthespacefox]

Thought about this too. I suspect there’s a lot of hard-coded assumptions in the engine that we don’t notice as long as we keep to the default scale. For one, imagine a 8x worse view range…

Kinda one of the reasons for the topic, as I know itll take some more flexibility in the engine to make things work. (and anything above 4x to have decent lighting at all)

one of the reasons i suggest 2x as a starting point is its the least extreme logical jump. So it will by definition, be the most tolerable, but still highlight issues.

[thomasthespacefox]

Few things we will likely need/want to make these scales work better: (not even touching on game-specific stuff such as biomes & mapgen)


- per-game camera distance modifiers. (for 3rd person view) (need)
- camera height modifiers (does this exist currently?) (need)
- jump height, walk & run speed, swim speed, all need to be different for obvious reasons.
- a new player model would be needed. (ideally one with a new look, as the player model from MTG would IMO look bland with even 2x the landscape detail.) or at least a resized one.
- the current light range would kinda be an issue. particularly for 8x. and makes 16x and higher effectively useless.

[ShadMOrdre]

I don't think this will work in the way you might expect.

You will still have the same overall number nodes, and if the node is scaled by 2, and the collision box is scaled by 2, then you have recoded and recompiled the engine to get where you are at this point, a 1 meter node, and a 2 meter tall player.

In my SL / Opensim days, scale was a widely discussed topic, amongst those in the "know". Most users created the largest avatars available. Spaces felt confined, being limited to 256x256 meter regions. Even with neighbor regions, the largeness of ones avatar made it all feel small. User avatars averaged over 4 meters tall. This wasn't easy to get users to recognize either, because everyone thinks bigger is better.

Once I transitioned to Opensim, from SL, I came across an article that really made sense, regarding scaling in virtual worlds. The article discussed, at length, how the above mentioned user habit reflected in their building habits. Because everything was bigger, the available space became "too small", and thus began the complaints about SLs strict policies regarding land ownership and such. In Opensim, even with as much space as my own servers could generate, scale was a major consideration. It does make things seem more realistic, when things are properly scaled.

In light of the many conversations here in the forums regarding world size, I think doubling anything will just make the world feel smaller, without any other effect or change in "feel". While being an Ent has always been something I want to experience, har har, I think in the long run, the world would feel smaller if I were larger within it. The real world feels that way.

[thomasthespacefox]

I don't think this will work in the way you might expect.

You will still have the same overall number nodes, and if the node is scaled by 2, and the collision box is scaled by 2, then you have recoded and recompiled the engine to get where you are at this point, a 1 meter node, and a 2 meter tall player.

In my SL / Opensim days, scale was a widely discussed topic, amongst those in the "know". Most users created the largest avatars available. Spaces felt confined, being limited to 256x256 meter regions. Even with neighbor regions, the largeness of ones avatar made it all feel small. User avatars averaged over 4 meters tall. This wasn't easy to get users to recognize either, because everyone thinks bigger is better.

Once I transitioned to Opensim, from SL, I came across an article that really made sense, regarding scaling in virtual worlds. The article discussed, at length, how the above mentioned user habit reflected in their building habits. Because everything was bigger, the available space became "too small", and thus began the complaints about SLs strict policies regarding land ownership and such. In Opensim, even with as much space as my own servers could generate, scale was a major consideration. It does make things seem more realistic, when things are properly scaled.

In light of the many conversations here in the forums regarding world size, I think doubling anything will just make the world feel smaller, without any other effect or change in "feel". While being an Ent has always been something I want to experience, har har, I think in the long run, the world would feel smaller if I were larger within it. The real world feels that way.

What im talking about here, is not just making the nodes "smaller". i mean the ability for a game in minetest, to completely overhaul the visual scale. meaning things looking "small" would be prevented, because literally every last node and entity would be designed for that scale.

I know that requires a lot of work, as default becomes useless in such a situation, Despite this, developers might be intrigued to make a game in minetest, as not all devs are interested in making games using meter-square blocks.

this is one part of a larger idea of getting more people to make games for minetest, by making minetest able to handle a greater verity of games.

[ShadMOrdre]

One could always go the route of HomeDecor. You can replace all the nodes with objects of your choice, including the default block. I think the engine, being geared towards voxels, should keep with the "sampled" 3d space approach, where measurements are rounded to the nearest ???

Look at this in the context of the world size debate. Smaller node dimensions essentially equates to either smaller scaled world sizes, due to the limit of the 16bit address space used for keeping coordinate values. You are essentially asking the same question, from a technical standpoint, because you have to keep track of a larger number of nodes within the 31km^3 cube. Smaller nodes means a smaller world size, or recoding to use a 32bit, or 64bit, coordinate value.

[Red_King_Cyclops]

What about making nodes larger? It would be as if the player had shrunken.

[ShadMOrdre]

No matter how large or small the blocks are, there are only so many addressable positions within the given dimensions. In this case, the 16 bit value that is used for each coordinate value only allows so many addressable spaces. Whether the nodes are larger or smaller, the available space in which to define them does not change.

The only real way to address that would be to update the engine to use larger integers for the address space.

You could make a mod, where the nodes are not nodes, but nodeboxes that are scaled accordingly, but getting them do place correctly would not work, as you would have overlapping blocks, or you'd have to place them based on the scale, every other block or so, and this would take even a lua mapgen, I think.

The best way to really deal with scaling, is to just build a world scaled in the way one wants. Use micronode to define smaller scaled items, making the player appear giant, or use regular nodes to build very large scaled items, making the player appear smaller.

Shad

[thomasthespacefox]

No matter how large or small the blocks are, there are only so many addressable positions within the given dimensions. In this case, the 16 bit value that is used for each coordinate value only allows so many addressable spaces. Whether the nodes are larger or smaller, the available space in which to define them does not change.

The only real way to address that would be to update the engine to use larger integers for the address space.

You could make a mod, where the nodes are not nodes, but nodeboxes that are scaled accordingly, but getting them do place correctly would not work, as you would have overlapping blocks, or you'd have to place them based on the scale, every other block or so, and this would take even a lua mapgen, I think.

The best way to really deal with scaling, is to just build a world scaled in the way one wants. Use micronode to define smaller scaled items, making the player appear giant, or use regular nodes to build very large scaled items, making the player appear smaller.

Shad

My whole point is not making the player appear larger, its the other way around, that instead of a node appearing to be 1-meter cube, its say, a 1/2 meter cube, or 1/4 meter cube. i.e. im talking changing the effective Level-of-detail in the terrain and map, using methods that would easily allow for not only the current style, but more fine-grained schemes.

currently: 1 node = 1 meter, so the player is 2 nodes tall, and as well, is 2 meters tall.
an example of what i mean: if 2 nodes = 1 meter, then the player would be 4 nodes tall, as the player would still be 2 meters tall, as the player is now.

as far as the map size argument, thats something that can be fixed if it really is an issue, but really, for example:

2x(where a door is 2x4 nodes) the current density would still have a 31 Km cube to work with. and 4x (where a door is 4x8 nodes) would still have an 15.5Km cube. so i don't see how this be as much of a game-breaking issue.

And by nodes, yes im talking about the size of the "addressable positions" themselves, not "how many positions node x covers"

as far as larger densities like 8x and 16x, the lighting system and camera are the larger problems here.

also, to clarify: I'm not talking about anything related to default or minetest game, as this would require replacing so much of minetest game that its basically pointless to do anything but write a game for minetest from the ground up, and thats IF minetest (engine) can handle it with its current featureset)

[ShadMOrdre]

One of the reasons for me being here in MT is the Opensimulator project, essentially what MT is to MC, OS is to SL. (Second Life). :)

I liked the OS concept, because of its "homebrew" mentality, and because of the shear potential that the software enables. I grew bored, however, because for creativity, there is just so much effort needed to pull off anything worth actually "immersing" oneself in, without either paying for content, hiring someone to create content, or learning how to create the content at lightspeed.

For me, MT offered the option of generating the content, with simple media options. I stay, because Lua is a far better scripting choice than a built in, rather limited, "proprietary" language. While there is certainly limitations with the engine, in regards to things like the node size, I gotta admit, I like the more natural looking views that I can generate with MT, that I could never pull of with OS.

OS can create "regions", areas of specific sizes, say 256x256x256 meters, but each of those spaces are limited by the number of objects that can be contained within them. In MT, all the trees in a 1sqkm area are freely roamed within, even at high view distances, when in the same space in OS, this would tax even the best of graphics cards.

I bring all this up, because somewhere in the future, I'd like to see the two projects come together in a meaningful way. MT can generate, process, and render laaarrrrggggeeee amounts of data. OS has alot of the "server" characteristics, graphics engine code, and other attributes that actually make it the best direction to take any new consideration of MT.

As a side, it's possible already to do what you are asking. Nodeboxes can be used in ways to make this possible. I've previously considered looking at the dig code, to see if I could somehow alter the active node, so that as I dig, parts of the node are dug away. Instead of animating through the crack animation, the node could be swapped with a "dug on" node, where a random amount is missing. This idea could easily be extended to simply separate the selected, or active, node into say, 8 nodes, (2x2x2). If you only deal with the active node, no engine changes are necessary, at least not so far as addressable space.

I like the idea of nodes being smaller, as you have laid out. It's one of the reasons I created a Shapes mod, to handle creating nodeboxes for a variety of nodes. Perhaps the above idea could be implemented for a usable mod, and simple nodeboxes used for simple divisions otherwise. The 2x2x2 square from above is essentially the stair block, so the inner, outer, stair, and slab blocks already represent 4 of the 7 nodeboxes needed for this. The only ones remaining also already exist in the moreblocks mod, as nodebox definitions, so the only effort would really be to handle to the active block, so that it can be divided at dig time, instead of cracking, or something like that.

Just be well aware, nodeboxes cause lag. This is the central reason I quit building nodebox styled architecture. It looks great, but lags like ......

Shad

[benrob0329]

I find this to be an interesting idea. I'm not sure how viable it is, but theoretically scaling the player up would work. The biggest problem I can see is that most people don't have a particularly high view range, and this might not be able to see "as far" when things are scaled.

I think that a game based around any large scale would need to have extra tools for laying large amounts of blocks, such as premade shapes to mimic nodes at current scale (like stairs).

[kestral]

Is this the effect you're after?

Here is minetest with the default character scaled by 4x. Most of what's needed is already in place, except for changing the camera position in third person view. If I try that I mainly just see the back of the character's head.

There are several options for texturing, but I decided to make the basic default textures world_aligned and scaled 4x to match the look of the default 1x game.

I've left out all vegetation nodes from my tests—that's a whole lot of work that would need to be done.

A big advantage of this scheme is how it works water. Now you can effectively place slabs and stairs in water without unsightly air gaps. However, I've also noticed that when I scale up the mapgen parameters, the smaller effective nodes make mountains much smoother, so they become almost trivial to climb.

Something like the digall mod is absolutely necessary for digging when using large scale values, but a solution would also need to be figured out for simplifying the placement of all these tiny nodes.

I also did 2x and 8x versions, but the process is the same.



This is all I had to do:

minetest.conf

• Scale all the movement_* values by 4x.
• Increase max_block_send_distance and max_block_generate_distance to as big a value as your system will allow.
• Also, adding binoculars to one's inventory helps to selectively increase viewing distance.

minetest_game/mods/player_api/init.lua

• Scale the collisionbox, stepheight, and eye_height values by 4x.

minetest_game/mods/player_api/models/character.b3d

• Scale the character model by 4x in blender. I think I also had to update the origin.

minetest_game/mods/default/nodes.lua

• Add align_style and scale to all the basic mapgen placed node tiles definitions, something like:
• tiles = {{name = "default_stone.png",
  align_style = "world",
  scale = 4,}},

scale4x.png

Minetest scaled example.

(306.13 KiB) Not downloaded yet

[thomasthespacefox]

Is this the effect you're after?

Here is minetest with the default character scaled by 4x. Most of what's needed is already in place, except for changing the camera position in third person view. If I try that I mainly just see the back of the character's head.

There are several options for texturing, but I decided to make the basic default textures world_aligned and scaled 4x to match the look of the default 1x game.

I've left out all vegetation nodes from my tests—that's a whole lot of work that would need to be done.

A big advantage of this scheme is how it works water. Now you can effectively place slabs and stairs in water without unsightly air gaps. However, I've also noticed that when I scale up the mapgen parameters, the smaller effective nodes make mountains much smoother, so they become almost trivial to climb.

Something like the digall mod is absolutely necessary for digging when using large scale values, but a solution would also need to be figured out for simplifying the placement of all these tiny nodes.

I also did 2x and 8x versions, but the process is the same.



This is all I had to do:

minetest.conf

• Scale all the movement_* values by 4x.
• Increase max_block_send_distance and max_block_generate_distance to as big a value as your system will allow.
• Also, adding binoculars to one's inventory helps to selectively increase viewing distance.

minetest_game/mods/player_api/init.lua

• Scale the collisionbox, stepheight, and eye_height values by 4x.

minetest_game/mods/player_api/models/character.b3d

• Scale the character model by 4x in blender. I think I also had to update the origin.

minetest_game/mods/default/nodes.lua

• Add align_style and scale to all the basic mapgen placed node tiles definitions, something like:
• tiles = {{name = "default_stone.png",
  align_style = "world",
  scale = 4,}},

scale4x.png

exactly! It be nice if someone would take the time to start a Minetest Game fork with the needed changes and building/digging tools.
at least for the likes of scale 2x and scale 4x... as those seem the most reasonable, and run into the least lighting and view range problems...

Even getting early test subgames out there on github, would certainly help spark ideas... not sure for names though... could call them something like "minetest micro 2x" and "minetest micro 4x" micro referring to the "smaller" blocks...

Though, both of these would take a lot of work to get to a polished state... eg, redoing the doors, making the torches not look like matches in 4x... etc.

[ShadMOrdre]

What's the point of scaling everything else up? Even if just the texture size for world alignment, it doesn't really make me feel "scaled" up.

I thought the idea was to make the player larger/smaller in regards to the node size.

I'd say, simply adjust the texture for the Sam model to use a more finely detailed pixel size.

I think the smaller pixel size would lend to a better experience, and would not require additional mods or code to make everything else work. Sam's wielded pick should be bigger, but the nodes he's digging should stay small, along with the pixel size on the texture. It would be far less effort and work to simply make Sam and his wield item use a higher res texture.

Shad

[Yvanhoe]

ShadMOrdre: I think the main idea is to increase the density of the world. To allow crafting of more detailed buildings or mechanisms. Imagine that we could fit 16 insulated mesecons wires in what is today one cube. Imagine that in place of pipeworks's autocrafter you had a 4x4x4 redesignable mini-factory.

It can open the way to very different ways of designing the world.

thomasthespacefox: I like the idea but this is really a starting point. The current size is actually a very good choice because many of the objects we want to interact with are one or two cubes in size: chests, doors, furnaces, etc... If we scale the universe, say, 4x, a typical door would take 4x8 = 32 nodes. How would that work? As a giant entity? Or if made of actual blocks, would you rotate blocks instantly when opening it?

A blocky world works well when you minimize the need for rotations and complex collision detection. With the current size, doors do not rotate, they just change state within their own blocks. Some blocks (like new chests that have an "opened state" model) do some collision detection but that's only one block away.

How are you going to react to something as simple as a cube blocking the door? A whole new syntax needs to be written. Don't get me wrong, that is exciting! And I'll surely follow if someone tries to do it, but there is more to the current scale of the world than just performance problems, there are some core design constraints.

[texmex]

Hey Kestral, would you mind putting together a demo mod out of the work you’ve already done?

[ShadMOrdre]

Or at least share the model? Hopefully, .b3d.. :)

[kestral]

Here it is:
https://github.com/kestral246/scaling_demo_4x_game

I packaged it as a game to make it self-contained, but 99.99% of it is just a copy of the standard minetest_game.

Please read all my Notes and Cautions before attempting to use this.

[texmex]

Thanks!

[Xudo]

There was a conversation about worlds of other scale in this GitHub issue: https://github.com/minetest/minetest/pull/8768