Difference between revisions of "TODO"

From Minetest Developer Wiki
Jump to navigation Jump to search
Line 4: Line 4:
  
 
=== Things to do soon ===
 
=== Things to do soon ===
 +
 
==== Mapgen ====
 
==== Mapgen ====
 +
 
* Add configuration for DungeonGen
 
* Add configuration for DungeonGen
 
* Add configuration for CaveGen
 
* Add configuration for CaveGen
  
 
==== Mapgen V7 ====
 
==== Mapgen V7 ====
 +
 
* Get all biome definitions in!
 
* Get all biome definitions in!
  
 
==== DecorationDef ====
 
==== DecorationDef ====
 +
 
* Add Lua callbacks for decoration placement if requested
 
* Add Lua callbacks for decoration placement if requested
 
* Add L-system decoration support
 
* Add L-system decoration support
Line 19: Line 23:
  
 
==== BiomeDefManager ====
 
==== BiomeDefManager ====
 +
 
* Add biomemap cache
 
* Add biomemap cache
 
* Scale temperature and humidity noise to more sensible value ranges
 
* Scale temperature and humidity noise to more sensible value ranges
Line 27: Line 32:
  
 
==== MapVoxelManipulator ====
 
==== MapVoxelManipulator ====
 +
 
* Figure out a permanent, elegant solution to the walled-in cave problem - can use is_ground_content now - does this belong in VoxelManipulator?
 
* Figure out a permanent, elegant solution to the walled-in cave problem - can use is_ground_content now - does this belong in VoxelManipulator?
  
 
==== EmergeThread ====
 
==== EmergeThread ====
 +
 
* Figure out the thread priority mess
 
* Figure out the thread priority mess
 
* Assign thread affinities for a bit of a performance boost (reduce L2 cache misses)
 
* Assign thread affinities for a bit of a performance boost (reduce L2 cache misses)
  
 
==== Formspec ====
 
==== Formspec ====
 +
 
* Add double-click-to-move-inventory-to-chest support
 
* Add double-click-to-move-inventory-to-chest support
 
* Add craft recipe drawing support
 
* Add craft recipe drawing support
  
 
==== Other ====
 
==== Other ====
 +
 
* Make a library for reading a Minetest map without worrying about the database used. (libmtmap?)
 
* Make a library for reading a Minetest map without worrying about the database used. (libmtmap?)
 
* Add block tinting (grass, water, sky, etc.) (for biomes)
 
* Add block tinting (grass, water, sky, etc.) (for biomes)
 
* Add Fullbright option
 
* Add Fullbright option
  
<br />
 
 
=== Big, long term goals (Client) ===
 
=== Big, long term goals (Client) ===
 +
 
==== Hardware Lighting for Light Sources ====
 
==== Hardware Lighting for Light Sources ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
Benefits:
 
Benefits:
 +
 
* would allow variable light range and cutoff
 
* would allow variable light range and cutoff
 
* would free up param1 of MapNodes to be used for storing more immediate node metadata (always a good thing!).
 
* would free up param1 of MapNodes to be used for storing more immediate node metadata (always a good thing!).
Line 55: Line 66:
 
http://joshbeam.com/articles/dynamic_lightmaps_in_opengl/
 
http://joshbeam.com/articles/dynamic_lightmaps_in_opengl/
 
<br />
 
<br />
RealBadAngel is currently working on shader-based lighting. What strategy is he using??
+
RealBadAngel is currently working on shader-based lighting. ''What strategy is he using?''
 
<br />
 
<br />
 +
 
==== Occlusion Culling/Occlusion Query ====
 
==== Occlusion Culling/Occlusion Query ====
 +
 
Irrlicht does support occlusion culling.  If enabled, it culls scene nodes which are entirely out of the camera's view fulcrum. <br />
 
Irrlicht does support occlusion culling.  If enabled, it culls scene nodes which are entirely out of the camera's view fulcrum. <br />
Problem:  The entire map is an Irrlicht scene node. Why???  What was the rationale for this decision?<br />
+
Problem:  The entire map is an Irrlicht scene node. ''Why? What was the rationale for this decision?''<br />
 
Solution:  Make scene nodes per MapBlock. <br />
 
Solution:  Make scene nodes per MapBlock. <br />
 
While we're at it, playing around with scene nodes, it'd probably be a good idea to maintain two (or three) separate nodes for each MapBlock, one for each type of material.  Opaque, transparent, and liquid drawtypes.  This fixes the still unsolved material transparency problem.
 
While we're at it, playing around with scene nodes, it'd probably be a good idea to maintain two (or three) separate nodes for each MapBlock, one for each type of material.  Opaque, transparent, and liquid drawtypes.  This fixes the still unsolved material transparency problem.
 +
 
==== MapBlock Mesh Optimization ====
 
==== MapBlock Mesh Optimization ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
Remove redundant vertices.  Would require some thinking to come up with a good, fast algorithm for this; perhaps the optimization step can be combined with the mesh generation itself?
 
Remove redundant vertices.  Would require some thinking to come up with a good, fast algorithm for this; perhaps the optimization step can be combined with the mesh generation itself?
  
 
=== Big, long term goals (Server) ===
 
=== Big, long term goals (Server) ===
 +
 
==== Voxel Area Entities ====
 
==== Voxel Area Entities ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
How cool would it be to build a full-sized boat in Minetest, and then drive it around the ocean? That's one example of something that would be possible with this feature.<br />
 
How cool would it be to build a full-sized boat in Minetest, and then drive it around the ocean? That's one example of something that would be possible with this feature.<br />
Line 82: Line 99:
  
 
==== Envlock Scope Reduction ====
 
==== Envlock Scope Reduction ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
Envlock needs to be put on a diet. Seriously. This is believed to be the primary reason for perceived unresponsiveness in Minetest - solving this would help matters immensely.<br />
 
Envlock needs to be put on a diet. Seriously. This is believed to be the primary reason for perceived unresponsiveness in Minetest - solving this would help matters immensely.<br />
Line 92: Line 110:
  
 
==== Mapgen V5 ====
 
==== Mapgen V5 ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
Revival of the 3d perlin noise-based generator that produced excellent looking terrain. Used to be very slow, which is the reason why it was ultimately dumped for V6 - this is no longer a problem with the new perlin noise map functions, which are insanely fast. celeron55 specifically requested to be the one to do this.<br />
 
Revival of the 3d perlin noise-based generator that produced excellent looking terrain. Used to be very slow, which is the reason why it was ultimately dumped for V6 - this is no longer a problem with the new perlin noise map functions, which are insanely fast. celeron55 specifically requested to be the one to do this.<br />
Line 103: Line 122:
  
 
==== Pre-generate world ====
 
==== Pre-generate world ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
''' What needs to be done '''
 
''' What needs to be done '''
Line 108: Line 128:
  
 
==== Store block differences only ====
 
==== Store block differences only ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
Instead of storing everything in the database, only store the changed mapblocks (or even only modified nodes?).  This would save a lot of space.<br />
 
Instead of storing everything in the database, only store the changed mapblocks (or even only modified nodes?).  This would save a lot of space.<br />
Line 116: Line 137:
  
 
==== Add colorlike to node param types ====
 
==== Add colorlike to node param types ====
 +
 
''' Description '''<br />
 
''' Description '''<br />
 
Add a field like facedir, wallmounted, and liquidlike called colorlike that will allow the user to register a set of colors so that the color of some base node is modified on draw.  This would save many textures and node definitions.<br />
 
Add a field like facedir, wallmounted, and liquidlike called colorlike that will allow the user to register a set of colors so that the color of some base node is modified on draw.  This would save many textures and node definitions.<br />
Line 126: Line 148:
 
<br />
 
<br />
  
==== Rewrite falling code to c++ ====
+
==== Rewrite falling code to C++ ====
 +
 
 
''' Description '''<br />
 
''' Description '''<br />
 
nodeupdate() now very slow and can't handle large amount of falling nodes.
 
nodeupdate() now very slow and can't handle large amount of falling nodes.
Line 137: Line 160:
  
 
=== Big protocol changes ===
 
=== Big protocol changes ===
 +
 
There are several features that would probably bring benefits in the long term, but can't currently be merged because of network protocol incompatibility.
 
There are several features that would probably bring benefits in the long term, but can't currently be merged because of network protocol incompatibility.
 
That is, they either can't be implemented in a way that lets old clients connect to new servers and new clients to old servers, or it would be a major pain to do so.
 
That is, they either can't be implemented in a way that lets old clients connect to new servers and new clients to old servers, or it would be a major pain to do so.
Line 152: Line 176:
  
 
== TODO in minetest_game ==
 
== TODO in minetest_game ==
 +
 
=== To do immediately ===
 
=== To do immediately ===
* Make gold not look like American cheese
+
 
* Use a new texture for bronze blocks (and for other ore blocks too)
+
* Make gold not look like American cheese.
 +
* Use a new texture for bronze blocks (and for other ore blocks too).
 +
 
 
=== Gameplay mechanics ===
 
=== Gameplay mechanics ===
* Beds? Need to think about this one more. [http://forum.minetest.net/viewtopic.php?id=2625 Beds Mod]
+
 
 +
* Beds? Need to think about this one more. ''[http://forum.minetest.net/viewtopic.php?id=2625 Beds Mod]''
 
* Enderballs (or at least the teleportation aspect of it in something else). ''[http://forum.minetest.net/viewtopic.php?id=2805 Throwing mod by PilzAdam] has teleport arrows; use mese crystal fragments for teleportation?''
 
* Enderballs (or at least the teleportation aspect of it in something else). ''[http://forum.minetest.net/viewtopic.php?id=2805 Throwing mod by PilzAdam] has teleport arrows; use mese crystal fragments for teleportation?''
 +
 
=== Add things to surface ===
 
=== Add things to surface ===
 +
 
(so we do have something else than mining)
 
(so we do have something else than mining)
 +
 
* More trees. ''Not as a mod, nodes will be added on request if they are added to mapgen'' [http://forum.minetest.net/viewtopic.php?id=4394 More Trees Mod]
 
* More trees. ''Not as a mod, nodes will be added on request if they are added to mapgen'' [http://forum.minetest.net/viewtopic.php?id=4394 More Trees Mod]
 +
 
=== Sounds ===
 
=== Sounds ===
* Add more variants of each sound (4 sounds good)
+
 
* Add hurt sounds (already supported by the engine)
+
* Add more variants of each sound (4 sounds good).
 +
* Add hurt sounds and falling damage sounds (already supported by the engine).
  
 
== See also ==
 
== See also ==
  
 
* [[Terminology]]
 
* [[Terminology]]

Revision as of 18:02, 2 May 2014

TODO in Minetest

Things to do soon

Mapgen

  • Add configuration for DungeonGen
  • Add configuration for CaveGen

Mapgen V7

  • Get all biome definitions in!

DecorationDef

  • Add Lua callbacks for decoration placement if requested
  • Add L-system decoration support
  • Add cutoff handling
  • Give decorations some sort of unique ID so they can be referenced in biome definitions
  • Allow decorations to have unresolved biomes so they can be registered afterward

BiomeDefManager

  • Add biomemap cache
  • Scale temperature and humidity noise to more sensible value ranges
  • Add biome weight attribute
  • Find out how to account for elevation better!
  • Optimize K-means system for biome matching, and use instead of linear search?
  • Add Voronoi diagram maker?

MapVoxelManipulator

  • Figure out a permanent, elegant solution to the walled-in cave problem - can use is_ground_content now - does this belong in VoxelManipulator?

EmergeThread

  • Figure out the thread priority mess
  • Assign thread affinities for a bit of a performance boost (reduce L2 cache misses)

Formspec

  • Add double-click-to-move-inventory-to-chest support
  • Add craft recipe drawing support

Other

  • Make a library for reading a Minetest map without worrying about the database used. (libmtmap?)
  • Add block tinting (grass, water, sky, etc.) (for biomes)
  • Add Fullbright option

Big, long term goals (Client)

Hardware Lighting for Light Sources

Description
Benefits:

  • would allow variable light range and cutoff
  • would free up param1 of MapNodes to be used for storing more immediate node metadata (always a good thing!).
  • would allow colored light sources

Of course, can use dynamic lights, except they're very intensive and generally a scarce resource Dynamically generated lightmaps seem like a good way forward.
http://joshbeam.com/articles/dynamic_lightmaps_in_opengl/
RealBadAngel is currently working on shader-based lighting. What strategy is he using?

Occlusion Culling/Occlusion Query

Irrlicht does support occlusion culling. If enabled, it culls scene nodes which are entirely out of the camera's view fulcrum.
Problem: The entire map is an Irrlicht scene node. Why? What was the rationale for this decision?
Solution: Make scene nodes per MapBlock.
While we're at it, playing around with scene nodes, it'd probably be a good idea to maintain two (or three) separate nodes for each MapBlock, one for each type of material. Opaque, transparent, and liquid drawtypes. This fixes the still unsolved material transparency problem.

MapBlock Mesh Optimization

Description
Remove redundant vertices. Would require some thinking to come up with a good, fast algorithm for this; perhaps the optimization step can be combined with the mesh generation itself?

Big, long term goals (Server)

Voxel Area Entities

Description
How cool would it be to build a full-sized boat in Minetest, and then drive it around the ocean? That's one example of something that would be possible with this feature.
Voxel Area Entities are moveable ActiveObjects whose mesh and texture is user-modifiable via setting MapNodes in it. This is an extremely powerful feature, and while perhaps not of extreme difficulty to implement, there is very much to be done.
What needs to be done

  • A new derived SAO and CAO (they would need to be treated fundamentally differently), along with setNode() and removeNode() calls.
  • A derived VoxelManipulator class, perhaps called ObjectVoxelManipulator, which will be used to manipulate them.
  • These types of objects have meshes, and will need to be updated in MeshUpdateThread along with MapBlocks.
  • Some way to store these in the map. Perhaps these objects will get special non-block-ID keys in the map DB.
  • A decent way to serialize these objects. This detail in particular will require special attention.
  • For the previous two points, see http://irc.minetest.ru/minetest-dev/2013-10-21#i_3383926 for a discussion of a possible way to handle the objects.
  • Also see https://gist.github.com/rubenwardy/5b4ba1163afa1e504592 for user interface ideas,


Envlock Scope Reduction

Description
Envlock needs to be put on a diet. Seriously. This is believed to be the primary reason for perceived unresponsiveness in Minetest - solving this would help matters immensely.
What needs to be done

  • Add a thin abstraction layer for atomic operation intrinsics.
  • Replace Environment operations that require concurrency but are simple enough with the said atomic operations and clever ordering.
  • Add a thread-safe hashtable structure to be used instead of std::map (or core::map) where locks would be needed, make use of this.
  • RCU for Map things - big structures such as MapBlocks could benefit from Read-Copy-Update for synchronization. This is the biggest change, but the reward would be immense.


Mapgen V5

Description
Revival of the 3d perlin noise-based generator that produced excellent looking terrain. Used to be very slow, which is the reason why it was ultimately dumped for V6 - this is no longer a problem with the new perlin noise map functions, which are insanely fast. celeron55 specifically requested to be the one to do this.
What needs to be done

  • Class-ify the V5 mapgen code. Create noise objects and handle parameters in the constructor, destroy noise objects in the destructor.
  • Replace all NoiseBuffer calls with array accesses to the 3d noise result array
  • Replace lighting and liquid updates with calls to the parent Mapgen class' updateLiquid() and updateLighting(). Replace cave, dungeon, and tree generation with the appropriate generalized calls too.
  • Note: V5 has it's own cave generator, so the generalized call may not be appropriate.
  • Overall code cleanup would be nice in addition.


Pre-generate world

Description
What needs to be done

Store block differences only

Description
Instead of storing everything in the database, only store the changed mapblocks (or even only modified nodes?). This would save a lot of space.
What needs to be done

  • Change the mapblock saving code to only save modified blocks.
  • Change the mapblock loading code to mapgen, and then load changed blocks.


Add colorlike to node param types

Description
Add a field like facedir, wallmounted, and liquidlike called colorlike that will allow the user to register a set of colors so that the color of some base node is modified on draw. This would save many textures and node definitions.
This field would be (part of, at least) param2 in a MapNode. If colorlike is specified on its own, then it can define and use up to 256 colors. If used with facedir or wallmounted, then, it can only define and use 8 colors.
What needs to be done

  • Store a color LUT with the ContentFeatures for the defined node that is to be passed along from Lua when registering the node.
  • Figure out how to draw these colors in inventory screens and what not without having to prerender more textures
  • Bump ContentFeatures version


Rewrite falling code to C++

Description
nodeupdate() now very slow and can't handle large amount of falling nodes. 100-1000 falling nodes now makes server very slow, 10000+ cause segfault. To test - make sand floating island via mapgen, touch it
What needs to be done
Rewrite in core with queue (like Map::transformLiquids)

Big protocol changes

There are several features that would probably bring benefits in the long term, but can't currently be merged because of network protocol incompatibility. That is, they either can't be implemented in a way that lets old clients connect to new servers and new clients to old servers, or it would be a major pain to do so. The point of this section is to list such features so that they can be merged at once: a one-time incompatibility, perhaps coinciding with the release of 0.5.0, is better than breaking compatibility all the time. Note: Not all of the things listed below need to be done, these are just ideas.

  • A binary key-value storage which easily supports missing fields with default values (e.g. header, source, usage)
  • Using TCP for reliable data transfer (e.g. tcp_connection)
  • Make the client request mapblocks (e.g. tcp_blocks_2)
  • Improved authentication and encryption
  • Remove old compatibility kludges.
  • Many command IDs have become obsolete in the protocol: they could be consolidated
  • Change builtin CONTENT_* to 0, 1, 2


TODO in minetest_game

To do immediately

  • Make gold not look like American cheese.
  • Use a new texture for bronze blocks (and for other ore blocks too).

Gameplay mechanics

  • Beds? Need to think about this one more. Beds Mod
  • Enderballs (or at least the teleportation aspect of it in something else). Throwing mod by PilzAdam has teleport arrows; use mese crystal fragments for teleportation?

Add things to surface

(so we do have something else than mining)

  • More trees. Not as a mod, nodes will be added on request if they are added to mapgen More Trees Mod

Sounds

  • Add more variants of each sound (4 sounds good).
  • Add hurt sounds and falling damage sounds (already supported by the engine).

See also