Fix Large Terrain Performance Issues #10
Loading…
Reference in New Issue
No description provided.
Delete Branch "large-terrain-performance-fix"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While this closes #3
, this also resolves another issue that has not currently been raised regarding the overhead of real-time editingDynamicTerrainInstance3D
s with a large size.Performance drops significantly because of how a large texture has to be re-uploaded to the GPU, causing a sync point, every frame.This PR aims to address the problem by usingViewportTextures
overImageTextures
for the real-time editing of the terrain map texture used by the terrain instance.This also subsequently retires the use ofDynamicTerrainInstance3D
in favor of a new interface for editing the terrain map in real-time calledMapEditorTerrainData
.Fix Large Terrain Performance Issuesto WIP: Fix Large Terrain Performance IssuesA better and less-disruptive solution would actually be to use
RenderingServer.texture_2d_update_partial()
, however that won't happen until https://github.com/godotengine/godot/issues/65762 is resolved.Narrowing down the focus of this PR to just being about closing #3.
WIP: Fix Large Terrain Performance Issuesto Fix Large Terrain Performance Issues@ -0,0 +12,4 @@
##
##
##
var size := Vector2i.ONE:
Missing doc comment.
@ -0,0 +39,4 @@
##
##
##
func get_texture() -> void:
Missing doc comment.
@ -6,1 +5,4 @@
const _SHADER := preload("res://terrain/terrain.gdshader")
enum PaintSlot {
Is this enum used anywhere anymore?