Some block 16x16x16 nodes: content stone.
Another block 16x16x16 nodes: content stone /where/, dirt /where/, air /where/, etc.
Is that how is saved world? If this is true, can cleaning some block (setting it to all stone or all air) decrease size of map?
FOSS gamedev and creative worlds
This is a mostly frozen copy of the Minetest forums through 2017. If you know phpBB3 and would like to host any G-rated forum here, you can email: me@minetest.org If the email doesn't work, find out who's taken over Final Minetest from OldCoder and email them to get write access or an admin account.
I should have set this up years ago. But it's no tale of woe.
Whether the temperature is high or low, regardless of cold winds blow,
away we go like Edgar Allan Poe, on now with the show. BTW rhymes are welcome.
Question about map file
5 posts
• Page 1 of 1
-
nomohakon - Member
- Posts: 207
- Joined: Fri Aug 10, 2012 16:34
- IRC: nomohakon
- In-game: nomohakon
Question about map file
"To learn who rules over you, simply find out who you are not allowed to criticize." - Voltaire
"Knowledge, like air, is vital to life. Like air, no one should be denied it." - Alan Moore, V for Vendetta
- - -
"To never die... and to conquer all, that is winning." ―Illyria
"Knowledge, like air, is vital to life. Like air, no one should be denied it." - Alan Moore, V for Vendetta
- - -
"To never die... and to conquer all, that is winning." ―Illyria
-
Leroy - Member
- Posts: 258
- Joined: Thu Oct 18, 2012 23:43
nomohakon wrote:Some block 16x16x16 nodes: content stone.
Another block 16x16x16 nodes: content stone /where/, dirt /where/, air /where/, etc.
Is that how is saved world? If this is true, can cleaning some block (setting it to all stone or all air) decrease size of map?
I think that if there is less material to render, than take up less space
UBUNTU BRO!
-
nomohakon - Member
- Posts: 207
- Joined: Fri Aug 10, 2012 16:34
- IRC: nomohakon
- In-game: nomohakon
Sorry, i did not understand what you mean.
Left one takes much less space and (i believe) time to render.
Is that right or its always saved as in right part?
Left one takes much less space and (i believe) time to render.
Is that right or its always saved as in right part?
"To learn who rules over you, simply find out who you are not allowed to criticize." - Voltaire
"Knowledge, like air, is vital to life. Like air, no one should be denied it." - Alan Moore, V for Vendetta
- - -
"To never die... and to conquer all, that is winning." ―Illyria
"Knowledge, like air, is vital to life. Like air, no one should be denied it." - Alan Moore, V for Vendetta
- - -
"To never die... and to conquer all, that is winning." ―Illyria
- doserj
- Member
- Posts: 10
- Joined: Mon Dec 10, 2012 15:05
Here is my understanding.
Regarding map size: The data for a 16x16x16 block is stored zlib-compressed. So if every node in the block is the same, this should be substantially compressed.
Regarding rendering complexity: this is basically proportional to the size of the mesh, which is (roughly) proportional to the surface area. The surface area is basically the number of transitions between solid and non-solid nodes (e.g., stone-to-air). Transitions between different solid nodes (e.g., stone-to-dirt) don't affect the mesh-size.
In summary, a block consisting of only stone would have small map size and low rendering complexity. A block with only solid nodes, like stone, dirt, sand, etc would have a bigger map size (because it probably doesn't compress that well) but still roughly the same low rendering complexity. A block with alternating stone and air nodes will have relatively small map size (the repeating pattern should still compress somewhat), but quite high rendering complexity (because of many transitions and therefore high surface-area.).
Regarding map size: The data for a 16x16x16 block is stored zlib-compressed. So if every node in the block is the same, this should be substantially compressed.
Regarding rendering complexity: this is basically proportional to the size of the mesh, which is (roughly) proportional to the surface area. The surface area is basically the number of transitions between solid and non-solid nodes (e.g., stone-to-air). Transitions between different solid nodes (e.g., stone-to-dirt) don't affect the mesh-size.
In summary, a block consisting of only stone would have small map size and low rendering complexity. A block with only solid nodes, like stone, dirt, sand, etc would have a bigger map size (because it probably doesn't compress that well) but still roughly the same low rendering complexity. A block with alternating stone and air nodes will have relatively small map size (the repeating pattern should still compress somewhat), but quite high rendering complexity (because of many transitions and therefore high surface-area.).
- madarexxx
- Member
- Posts: 144
- Joined: Sat Aug 04, 2012 06:49
Sounds like lod realisation - cool
Sorry for my bad English, please help me learn it - correct my worst mistakes :)
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 6 guests