Tilemap Editor: Depth Offset Editing

[ilexp]

Summary

While technically implemented, there is currently no way to access and edit per-Tile depth offsets from the editor. This should be changed in the long run, so depth can be tweaked easily.

Analysis

• Depth offset editing can probably be implemented as a (single?) new TilemapTool.
• A usable and cheap way to edit depth would be like the one implemented in the Tileset editor.
  • Left Mouse increases height.
  • Right mouse decreases height.
  • Holding each button and moving over different tiles will assign the same (updated) value to them.
  • Editing like this favors small local tweaks over large scale editing.
• It remains questionable whether other tools (rect, fill) are required for depth editing, but it seems like a safe bet to leave them out in a first implementation and extend when required later.
• There also should be a way to visualize the depth offsets of each tile.
  • Introduce a new CamViewLayer for this, which can be activated manually, but is automatically activated while using the depth TilemapTool and deactivated later.
  • Color coding seems to be a good way to approach this.

[ilexp]

Progress:

• Worked on a tilemap depth visualization layer.
• Discarded the results again, because the layered implementation had several issues.

Issues:

• The depth visualization layer naturally had to reproduce tilemap rendering logic.
• Did not show actual depth offsets, but had to reproduce what tilemaps would probably generate, thus had to reproduce depth offset logic.
• Did not interact well with tilemap highlighting and editing, because it essentially painted over it.

Solution:

• Don't visualize tilemap depth offsets in a distinct layer's rendering method
• Instead, consider introducing a base material override to ICmpTilemapRenderer in addition to the ColorTint property, which would allow to temporarily inject a depth visualization shader.
• Re-introduce a depth visualization, but let it modify how tilemaps are rendered, rather than painting over them.
  • In a CamViewLayer?
  • Would require extending the API in order to introduce temporary renderer changes.
  • Would look out of place if activating it in the Scene Editor or similar, because only tilemaps would be depth-visualized, but nothing else.
  • In the tilemap editor CamViewState?
  • Mixes well with the existing ColorTint overrides.
  • Keeping that kind of code in one place is probably a good thing.
  • Would make it more cohesive, since tilemap depths will likely never be displayed outside.

[ilexp]

Issue:

• When visualizing depth with the regular renderer and a custom shader override, there are several problems as well.
• The tilemap vertices only carry depth information - but not the actual height information that needs to be displayed.
• It might not interact well with custom tilemap renderers that require a custom shader to function properly or do not encode depth in vertex position.

Analysis:

• Maybe there does need to be custom tilemap rendering like in the previous layer-based rendering approach.
• There is probably no way around a certain degree of reproduced rendering logic.
• A different solution needs to be found that uses custom rendering for height visualization and solves the problems of the previous layer-rendering based approach:
  • Poor interaction with world space renderers.
  • Poor interaction with tilemap highlights of the editor state.
  • Poor interaction with tilemap editing UI and overlays.
  • Out of place when used outside the tilemap editor.

Approach A:

• Implement tilemap surrogate rendering logic into the tilemap editor, which allows to temporarily replace the rendering of an ICmpTilemapRenderer with a custom rendering routine.
• Could be done by filtering out the tilemap renderer in question using the regular object rendering predicate, and doing custom rendering in world space using the same parameters.
• To counter code duplication as much as possible, see what can be extracted from the default TilemapRenderer, especially with regard to depth offset generation.
  • Alternatively, don't generate depth offsets at all while in depth visualization mode.
  • Disadvantage: Users won't be able to observe the proper depth interaction between tilemaps and other objects while they're editing.
  • It might be better to mirror depth offset generation to some degree for a proper WYSIWYG experience.
• Manually implement tilemap highlighting code, so it works the same for the depth rendering and the actual tilemap rendering.
• Don't expose the heightmap rendering in a distinct layer, make it a part of the tilemap editor state.
  • Potentially move it to a distinct class and make it modular, so other tilemap overlays could be done as well, such as impassibility, custom tagging vis, etc.